#android #alarmmanager #clock #android-doze
#Android #alarmmanager #часы #android-doze
Вопрос:
У меня есть приложение для будильника в Play Store, которое очень хорошо работает на большинстве устройств, но, к сожалению, некоторые устройства сообщают, что будильник не срабатывает в установленное время, и я пришел к выводу из исследования, что есть некоторые устройства, которые ограничивают работу приложений в фоновом режиме и убивают alarm manager!
Я обработал режим ожидания, используя следующий код :
if (Build.VERSION.SDK_INT >= 23)
{
alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, timeStamp, pendingIntent);
}
else if (Build.VERSION.SDK_INT >= 19)
{
alarmManager.setExact(AlarmManager.RTC_WAKEUP, timeStamp, pendingIntent);
}
else
{
alarmManager.set(AlarmManager.RTC_WAKEUP, timeStamp, pendingIntent);
}
Однако на некоторых устройствах этого кажется недостаточно.
Я читал, что служба переднего плана может помешать системе в любом случае отключить приложение, однако я также не могу этого гарантировать, поскольку у меня нет устройств, на которых возникает проблема.
Я хочу убедиться, что мой будильник отлично работает на всех устройствах и обрабатывает все сценарии, так что же можно сделать, чтобы убедиться, что мое приложение работает правильно и не отключено системой?
Ответ №1:
Вы должны использовать AlarmManagerCompat.setAlarmClock() для установки видимого пользователем будильника, подходящего для приложения будильника. Этот API использует setAlarmClock() в API 21 , который согласно его документации:
этим сигналам тревоги будет разрешено запускаться, даже если система находится в режиме ожидания с низким энергопотреблением (он же doze). Система также может выполнить некоторую подготовительную работу, когда видит, что появляется такой сигнал тревоги, чтобы уменьшить объем фоновой работы, которая может произойти, если это приведет к полному пробуждению устройства — это делается для того, чтобы избежать таких ситуаций, как большое количество устройств, на которых установлен будильник в одно и то же время утром, все просыпаются в это время и внезапно загружают сеть ожидающей фоновой работой. Таким образом, эти типы сигналов тревоги могут быть чрезвычайно дорогостоящими при использовании батареи и должны использоваться только по назначению.
Комментарии:
1. Спасибо, как вы думаете, этот метод также не позволит системе принудительно отключить приложение и, следовательно, диспетчер аварийных сигналов? Я видел два больших приложения в магазине, которые по-прежнему рекомендуют вручную вносить их приложение в белый список в режиме «не беспокоить» в настройках телефона @ianhanniballake
2. Пока вы используете
CATEGORY_ALARM, вам не придется беспокоиться о «Не беспокоить». Это совершенно отдельно для принудительной остановки — это всегда отменяет все , что ваше приложение может сделать для пробуждения, включая сигналы тревоги.3. Я только недавно понял, что «dnd» касается только звуков, а не оптимизации заряда батареи, мое приложение для будильника является исключительным, поскольку оно использует звук телефона, а не звук будильника, поэтому я думаю, что я бы все равно не беспокоился о «dnd». Другой вопрос, является ли setAlarmClock() точным? В широковещательном приемнике я проверяю минуты и часы кэшированного сигнала тревоги и сравниваю с текущим временем, поэтому, если часы и минуты не совсем совпадают, я отменяю свой сигнал тревоги. @ianhanniballake
4. Да,
setAlarmClock()точно. Я не знаю, почему вы усложняете свойBroadcastReceiverпротив простого вызоваcancel()AlarmManagerи сохранения всего устройства от пробуждения.5. эту проверку я выполняю, потому что при изменении часов устройств широковещательный приемник вызывается автоматически, даже если это было в неподходящее время. То же самое происходит при загрузке устройства, широковещательный приемник может сработать в неподходящее время. Знаете ли вы, как обойти эту проблему, вместо того, чтобы проверять время внутри широковещательного приемника?