App Standby — что это, уровни ожидания и принцип работы

Что такое App Standby

App Standby — это компонент системы управления энергопотреблением Android, введённый в Android 6.0 (API 23) и значительно переработанный в Android 9 (API 28). Его задача — определить, какие приложения пользователь использует редко, и ограничить их фоновую активность: сетевые запросы, синхронизацию, JobScheduler и AlarmManager. В отличие от Doze, App Standby не зависит от состояния экрана или движения устройства.

Система классифицирует приложения по четырём bucket (уровням): Active, Working Set, Frequent и Rare. Каждый уровень определяет, насколько сильно ограничивается фоновая активность. Переход между уровнями происходит автоматически на основе паттернов использования приложения: как часто пользователь открывает его, получает уведомления, взаимодействует с виджетами.

App Standby работает в паре с Doze Mode, но не заменяет его. Если Doze ограничивает фоновую активность всех приложений при бездействии устройства, то App Standby ограничивает конкретные приложения независимо от состояния устройства. Приложение с уровнем Rare будет иметь ограничения даже при активном использовании телефона, если пользователь не открывал его несколько дней.

Bucket в Android 9+

Начиная с Android 9 (API 28), Google ввела App Standby Buckets — формальную классификацию с числовыми значениями. Система использует машинное обучение для предсказания следующего запуска приложения. Если модель предсказывает, что приложение будет открыто в ближайшие часы, оно получает bucket Active. Если предсказание указывает на редкое использование — назначается Rare.

Как работает App Standby

App Standby анализирует несколько факторов для определения bucket: время с последнего открытия приложения пользователем, частота взаимодействия (количество запусков в день/неделю), получение FCM-уведомлений, наличие активных виджетов на рабочем столе и подписка на AlarmManager. Чем дольше приложение не используется, тем ниже его bucket и тем строже ограничения.

Системный сервис UsageStatsManager собирает статистику использования приложений и передаёт её в StandbyController — компонент framework, который рассчитывает bucket для каждого приложения. StandbyController также учитывает системные события: после обновления приложения его bucket сбрасывается до Active на несколько дней, чтобы пользователь мог оценить новые функции.

Важная особенность: App Standby не убивает процесс приложения, а ограничивает его фоновые возможности. Приложение продолжает работать, если пользователь взаимодействует с ним (bucket Active). Как только пользователь сворачивает приложение и не возвращается к нему, система начинает отсчёт времени бездействия и может понизить bucket до Working Set или Frequent.

Влияние FCM на bucket

Получение FCM high-priority сообщения может временно повысить bucket приложения до Active. Это даёт приложению возможность выполнить задачу (обработать сообщение, синхронизировать данные) без ограничений. Однако после завершения обработки bucket возвращается к исходному значению. Google рекомендует использовать этот механизм для доставки важных уведомлений, а не для поддержания приложения «в живых».

Уровни App Standby

App Standby использует четыре уровня (bucket) для классификации приложений. Каждый уровень определяет время задержки для фоновых задач: чем ниже уровень, тем дольше задержка. Система автоматически перемещает приложение между уровнями на основе статистики использования, собранной за последние 7–14 дней.

Active — активное приложение

Active — приложение, с которым пользователь взаимодействовал недавно (запускал, получал уведомление или использовал виджет). В этом bucket нет ограничений: JobScheduler запускается немедленно, сеть доступна, AlarmManager срабатывает точно. Приложение остаётся в Active до тех пор, пока пользователь не перестанет с ним взаимодействовать на несколько часов.

Working Set и Frequent

Working Set — приложение используется регулярно (несколько раз в неделю). Задержка фоновых задач до 2 часов. Frequent — приложение используется несколько раз в месяц. Задержка до 4 часов. В обоих уровнях сеть доступна только в окнах обслуживания, а AlarmManager может быть отложен. JobScheduler выполняет задачи в ближайшее окно.

Rare — редко используемое

Rare — самый строгий уровень, назначаемый приложениям, которые пользователь не открывал более 30 дней. Задержка фоновых задач достигает 24 часов. Сеть полностью блокируется вне окон обслуживания, AlarmManager срабатывает только с флагами setAndAllowWhileIdle() с ограничением 1 раз в 9 минут. FCM high-priority уведомления по-прежнему доставляются, но не могут повысить bucket.

Ограничения в App Standby

App Standby накладывает ограничения на несколько категорий фоновых операций. В отличие от Doze, ограничения App Standby действуют независимо от состояния экрана и зарядного устройства. Разработчик должен проектировать приложение с учётом этих ограничений, особенно если целевая аудитория использует приложение нерегулярно.

JobScheduler и WorkManager

JobScheduler — основной API, на который влияет App Standby. В зависимости от bucket задержка выполнения задач составляет от 2 до 24 часов. WorkManager, использующий JobScheduler под капотом (на API 23+), также подвержен этим задержкам. Для критических по времени задач используйте Expedited Work, который запускает Foreground Service под капотом и не зависит от bucket.

Сетевые ограничения

Приложения в bucket Working Set, Frequent и Rare не могут выполнять произвольные сетевые запросы в любое время. Система разрешает доступ к сети только в окнах обслуживания, которые синхронизированы с Doze. Для отправки критических данных используйте FCM high-priority с последующей синхронизацией в окне обслуживания.

AlarmManager

AlarmManager в App Standby подчиняется тем же правилам, что и в Doze: точные будильники (setExact()) откладываются, а setAndAllowWhileIdle() ограничен 1 срабатыванием за 9 минут. Для bucket Rare задержка может достигать 24 часов, что делает AlarmManager непригодным для точного планирования задач в редко используемых приложениях.

• JobScheduler — задачи откладываются на 2–24 часа в зависимости от bucket
• Сеть — доступ только в окнах обслуживания для Working Set и ниже
• AlarmManager — точные будильники откладываются; setAndAllowWhileIdle — 1/9 мин
• SyncManager — синхронизация аккаунтов задерживается до окна обслуживания
• Widget updates — частота обновления виджетов может быть снижена

Как получить исключение

Исключение из App Standby можно получить двумя способами: через пользовательские настройки батареи (ручной Whitelist) или через системный Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Однако Google строго регулирует доступ к исключениям — приложения, не имеющие весомой причины для исключения, рискуют быть отклонёнными в Google Play.

Пользователь может вручную отключить ограничения для конкретного приложения через Настройки → Приложения → [Приложение] → Батарея → Оптимизация → Не оптимизировать. Это полностью снимает ограничения App Standby и Doze для выбранного приложения. Разработчик может показать пользователю инструкцию или системный диалог, но не может принудительно добавить приложение в исключения.

Foreground Service с уведомлением автоматически получает временное исключение из App Standby. Пока сервис работает и отображает уведомление, приложение переводится в bucket Active независимо от его реального уровня. После остановки сервиса bucket возвращается к исходному значению. Это наиболее надёжный способ гарантировать фоновую работу без запроса системных исключений.

Когда запрашивать исключение

Запрашивать Whitelist имеет смысл только для приложений с критически важной фоновой функциональностью: навигация в реальном времени, мониторинг здоровья, VoIP-звонки, защита устройства. Для большинства приложений достаточно использовать Foreground Service или WorkManager. Google Play может отклонить публикацию, если приложение запрашивает исключение без очевидной необходимости.

// Запрос исключения из App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Проверка текущего статуса
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Тестирование App Standby

Тестирование App Standby через ADB позволяет принудительно назначить приложению любой bucket и проверить его поведение. Это критически важно для приложений, которые полагаются на фоновую синхронизацию, уведомления или периодические обновления. Тестирование необходимо проводить на физическом устройстве или эмуляторе с Android 9+.

Для принудительной установки bucket используется команда adb shell am set-standby-bucket [package] [bucket], где bucket может быть: active, working_set, frequent или rare. Для просмотра текущего bucket — adb shell am get-standby-bucket [package]. Система также позволяет симулировать длительное бездействие приложения через команду adb shell dumpsys usagestats.

# Установка bucket Rare для приложения
$ adb shell am set-standby-bucket com.example.app rare

# Просмотр текущего bucket
$ adb shell am get-standby-bucket com.example.app

# Сброс всех buckets до Active
$ adb shell dumpsys usagestats clear

# Просмотр всех buckets системы
$ adb shell dumpsys usagestats

Что проверять

После установки bucket Rare проверьте: выполняется ли WorkManager-задача в течение 24 часов, срабатывает ли AlarmManager, доставляются ли FCM-уведомления, работает ли Foreground Service без ограничений. WorkManager с политикой Expedited Work должен выполняться немедленно даже в bucket Rare, поскольку использует Foreground Service. Обычные задачи WorkManager будут отложены в соответствии с bucket.

Лучшие практики

Разработка приложения, устойчивого к App Standby, требует осознанного подхода к фоновым задачам. Основной принцип: не предполагать, что приложение всегда находится в bucket Active. Проектируйте фоновую работу так, чтобы она корректно выполнялась с задержками, характерными для bucket Frequent и Rare.

Используйте WorkManager с Expedited Work

Expedited Work (WorkManager 2.7+) запускает Foreground Service под капотом, что даёт задаче немедленное выполнение независимо от bucket. Это оптимальный выбор для задач, которые не могут быть отложены: отправка сообщения, синхронизация после оплаты, обработка входящего вызова. Обычные задачи WorkManager выполняются в окнах обслуживания с учётом bucket.

FCM для реактивации

Используйте FCM high-priority сообщения для пробуждения приложения из App Standby. Когда приложение получает такое сообщение, его bucket временно повышается до Active, и оно может выполнить необходимые задачи (синхронизация, обновление данных). После завершения обработки bucket возвращается к исходному уровню.

Избегайте постоянного удержания в памяти

Не пытайтесь обойти App Standby с помощью постоянных фоновых сервисов, WakeLock или периодических FCM-сообщений. Google активно борется с такими практиками — приложение может быть помечено как энергозатратное и ограничено ещё строже. Используйте WorkManager для периодических задач и Foreground Service только когда задача действительно видна пользователю.

• WorkManager — предпочтительный API; Expedited Work выполняет задачи без задержки
• FCM high-priority — временно повышает bucket до Active для обработки сообщения
• Не обходи App Standby — это приводит к блокировке приложения системой
• Foreground Service — временно переводит приложение в Active на время работы
• Тестируй приложение в bucket Rare и Frequent через ADB перед каждым релизом