Краткий ответ

Нужно проверить фактическое состояние специального доступа точных будильников на тестовом устройстве и сопоставить его с результатом постановки alarm. Если при отключённом доступе точная постановка завершается исключением либо не создаёт ожидаемое событие, а после выдачи доступа тот же сценарий работает, причина находится в политике ОС, а не в бизнес-логике планировщика.

Исторический контекст

Мобильные ОС ограничивают точные фоновые события ради экономии энергии: частые пробуждения процессора ухудшают автономность и мешают системе объединять фоновые операции. Поэтому Android выделяет точные будильники в особый механизм с отдельным контролем доступа, особенно для приложений, которым точность не является критически важной.

Постановка проблемы

Вызов setExactAndAllowWhileIdle требует отличать три состояния: разрешение выдано, разрешение запрещено и возможность использовать неточный alarm. Проверка только факта вызова метода недостаточна: приложение может не обработать исключение, неправильно показать пользователю состояние доступа или считать постановку успешной до фактического разрешения ОС.

Ошибка приводит к пропущенным или отложенным напоминаниям. При этом тест на одном устройстве может проходить, если доступ был выдан ранее, а чистая установка на другом устройстве выявит проблему.

Подробное решение

Сначала зафиксируйте матрицу условий: версия Android, целевой SDK, новая установка, обновление приложения, состояние специального доступа и режим энергосбережения. Для каждого запуска журналируйте состояние доступа непосредственно перед постановкой alarm, результат вызова и факт получения broadcast.

На Android следует проверять состояние специального доступа через AlarmManager.canScheduleExactAlarms(). Затем нужно выполнить сценарий с запрещённым доступом, убедиться, что приложение корректно обрабатывает отказ, открыть системный экран выдачи доступа, вернуться в приложение и повторить постановку.

Контрольный эксперимент — заменить точную постановку на неточную. Если неточный alarm создаётся, но точный недоступен до выдачи специального доступа, это подтверждает влияние политики ОС. Если оба варианта не срабатывают, дополнительно проверяют регистрацию receiver, корректность PendingIntent, время устройства и ограничения фоновой работы.

Важно не считать setExactAndAllowWhileIdle гарантией абсолютной точности: ОС может допускать небольшую задержку, а режимы энергосбережения влияют на момент доставки. Этот API предназначен для событий, где отклонение по времени существенно; для обычной синхронизации лучше использовать менее строгие фоновые механизмы.

Минимальная проверка состояния выглядит так:

val alarmManager = getSystemService(AlarmManager::class.java)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S &&
    !alarmManager.canScheduleExactAlarms()) {
    startActivity(Intent(Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM))
    return
}
alarmManager.setExactAndAllowWhileIdle(
    AlarmManager.RTC_WAKEUP, triggerAtMillis, pendingIntent
)

Проверка версии нужна потому, что специальный доступ и его поведение зависят от версии Android и параметров приложения. Нельзя переносить результат одного устройства на всю матрицу совместимости.

Ситуация из практики

Приложение напоминаний корректно работало на тестовом телефоне, но после чистой установки на Android 13 уведомление не появлялось вовремя. Рассматривались три варианта: увеличить число повторных попыток, заменить alarm на периодическую фоновую задачу или проверить специальный доступ.

Повторные попытки скрывали симптом и могли создавать дубликаты. Фоновая задача была бы экономичнее, но не обеспечивала требуемую точность. Тестировщик сравнил чистую установку с обновлением, отключил доступ к точным будильникам в системных настройках, проверил canScheduleExactAlarms() и зафиксировал результат постановки.

После выдачи доступа точное событие стало создаваться, а при запрете приложение показывало понятное состояние вместо ложного сообщения об успешной установке. Выбранное решение — явно обрабатывать отсутствие доступа и применять точные alarm только для действительно критичных напоминаний.

Что кандидаты часто упускают

Достаточно ли проверить, что вызов setExactAndAllowWhileIdle не завершился ошибкой?

Нет. Нужно проверить и фактическое состояние разрешения, и последующую доставку события. Успешное возвращение из вызова не доказывает, что receiver зарегистрирован правильно, PendingIntent совпадает с ожидаемым или событие будет доставлено в нужный момент.

Можно ли всегда заменить точный alarm на фоновую задачу?

Нет. Фоновая задача обычно подходит для синхронизации и других операций без строгого дедлайна, но её запуск планируется с учётом ограничений ОС и не гарантирует точный момент. Для будильника или напоминания, где важны минуты, такая замена меняет функциональное требование.

Почему тест нужно повторять после обновления приложения, а не только после чистой установки?

Состояние специального доступа может зависеть от сценария установки и обновления, версии Android и ранее выданных пользователем разрешений. Обновление также может изменить целевой SDK и поведение политики ОС. Поэтому чистая установка и обновление — разные состояния совместимости, каждое из которых должно быть проверено отдельно.