Android 9 (уровень API 28) и более поздние версии поддерживают App Standby Buckets . App Standby Buckets помогают системе приоритизировать запросы приложений на ресурсы в зависимости от того, как давно и как часто они использовались. На основе особенностей использования приложений каждое приложение помещается в один из пяти приоритетных сегментов . Система ограничивает ресурсы устройства, доступные каждому приложению, в зависимости от того, в каком сегменте оно находится.
Приоритетные ведра
Система динамически назначает каждое приложение приоритетному сегменту, переназначая приложения по мере необходимости. Система может полагаться на предустановленное приложение, которое использует машинное обучение для определения вероятности использования каждого приложения и назначает приложения соответствующим сегментам.
Если системное приложение отсутствует на устройстве, система по умолчанию сортирует приложения по времени их использования. Более активные приложения распределяются по контейнерам с более высоким приоритетом, что позволяет приложению использовать больше системных ресурсов. В частности, контейнер определяет частоту выполнения задач приложения и частоту срабатывания оповещений. Эти ограничения действуют только при питании устройства от аккумулятора. Во время зарядки устройства система не накладывает эти ограничения.
Приоритетными сегментами являются следующие:
- Активно : приложение используется или использовалось совсем недавно.
- Рабочий набор : приложение используется регулярно.
- Частое использование : приложение используется часто, но не ежедневно.
- Редко : приложение используется нечасто.
- Ограничено : приложение потребляет много системных ресурсов или может вести себя нежелательно.
Помимо этих приоритетных контейнеров, существует специальный контейнер «никогда» для приложений, которые установлены, но никогда не запускались. Система накладывает на такие приложения строгие ограничения.
Следующие описания относятся к непредиктивному случаю. Напротив, когда прогнозирование использует машинное обучение для прогнозирования поведения, группы выбираются с учётом будущих действий пользователя, а не на основе недавнего использования. Например, недавно использованное приложение может оказаться в группе редких приложений, поскольку машинное обучение предсказывает, что приложение может не использоваться в течение нескольких часов.
Активный
Приложение находится в активной корзине, пока оно используется, использовалось совсем недавно или когда оно выполняет любое из следующих действий:
- Запускает действие.
- Запускает длительную службу переднего плана.
- Нажимается пользователем из уведомления.
Если приложение находится в активной корзине, система накладывает минимальные ограничения на задания или сигналы тревоги приложения:
- Начиная с Android 16 (уровень API 36), фоновые задания имеют большую квоту времени выполнения, если они запускаются приложением в активном контейнере. Это касается как заданий, запланированных непосредственно с помощью
JobScheduler
, так и заданий, созданных другими библиотеками, такими как WorkManager илиDownloadManager
.
Взаимодействие с пользователем назначает приложениям статус активных
В Android 9 (уровень API 28) и выше, когда пользователь взаимодействует с вашим приложением определённым образом, система временно помещает его в активную корзину. После того, как пользователь прекращает взаимодействие с вашим приложением, система помещает его в корзину на основе истории использования.
Ниже приведены примеры взаимодействий, которые запускают такое поведение системы:
Пользователь нажимает на уведомление, которое отправляет ваше приложение.
Пользователь взаимодействует с приоритетной службой в вашем приложении, нажимая кнопку мультимедиа .
Пользователь подключается к вашему приложению, взаимодействуя с Android Automotive OS , где ваше приложение использует либо службу переднего плана, либо
CONNECTION_TYPE_PROJECTION
.
Рабочий набор
Приложение попадает в рабочий набор , если оно часто запускается, но неактивно. Например, приложение социальной сети, которое пользователь запускает почти ежедневно, вероятно, находится в рабочем наборе. Приложения также попадают в рабочий набор, если они используются косвенно.
Если приложение находится в рабочем наборе, система накладывает небольшие ограничения на его способность запускать задания и активировать оповещения. Подробнее см. в разделе Ограничения ресурсов управления питанием .
Частый
Приложение попадает в категорию «часто используемое », если оно используется регулярно, но не обязательно каждый день. Например, приложение для отслеживания тренировок, которое пользователь запускает в спортзале, может относиться к категории «часто используемое».
Если приложение находится в сегменте частого использования, система накладывает более строгие ограничения на его способность выполнять задания и активировать оповещения. Подробнее см. в разделе Ограничения ресурсов управления питанием .
Редкий
Приложение относится к категории «редкие» , если оно используется нечасто. Например, приложение для отелей, которое пользователь запускает только во время проживания в этом отеле, может относиться к категории «редкие».
Если приложение находится в категории «редкие», система накладывает строгие ограничения на его способность запускать задания и активировать оповещения. Система также ограничивает подключение приложения к интернету. Подробнее см. в разделе «Ограничения ресурсов управления питанием» .
Ограниченный
Этот контейнер, добавленный в Android 12 (уровень API 31), имеет самый низкий приоритет и самые высокие ограничения среди всех контейнеров. Система учитывает поведение вашего приложения, например, частоту взаимодействия пользователя с ним, чтобы решить, следует ли помещать ваше приложение в контейнер с ограничениями.
На устройствах с Android 13 (уровень API 33) и выше, если ваше приложение не подпадает под исключение , система помещает его в ограниченную корзину в следующих ситуациях:
Пользователь не взаимодействует с вашим приложением в течение определённого количества дней. В Android 12 (уровень API 31) и 12L (уровень API 32) это количество дней составляет 45. В Android 13 это количество дней сокращено до 8.
Ваше приложение вызывает чрезмерное количество трансляций или привязок в течение 24 часов.
Если система помещает ваше приложение в ограниченную корзину, применяются следующие ограничения:
- Вы можете запускать задания один раз в день в течение 10-минутного сеанса пакетной обработки. В течение этого сеанса система группирует задания вашего приложения с заданиями других приложений.
- Задания с ограничениями не выполняются сами по себе. В это же время должно быть запущено или отложено хотя бы одно другое задание, которое может включать в себя любое другое задание.
- Ваше приложение может выполнять меньше ускоренных заданий по сравнению с тем случаем, когда система помещает ваше приложение в менее ограничительную группу.
- Ваше приложение может активировать один будильник в день. Этот будильник может быть как точным , так и неточным .
Исключения из ограниченного списка
Следующие типы приложений не попадают в ограниченную корзину и обходят триггер бездействия, даже на Android 12 и выше:
- Приложения для сопутствующих устройств
- Приложения, работающие на устройстве в демонстрационном режиме
- Приложения владельца устройства
- Приложения владельца профиля
- Постоянные приложения
- VPN-приложения
- Приложения с ролью
ROLE_DIALER
- Приложения, которые пользователь явно назначил для предоставления «неограниченной» функциональности в системных настройках.
- Приложения с активными виджетами
- Приложения, которым предоставлено хотя бы одно из следующих разрешений:
Оцените приоритетный сегмент
Чтобы проверить, к какому сегменту относится ваше приложение, выполните одно из следующих действий:
Вызовите
getAppStandbyBucket()
.Выполните следующую команду в окне терминала:
adb shell am get-standby-bucket PACKAGE_NAME
Система ограничивает ваше приложение всякий раз, когда оно помещается в App Standby Bucket, значение которого превышает STANDBY_BUCKET_ACTIVE
(10).
Лучшие практики
Если ваше приложение соответствует лучшим практикам для режима Doze и режима ожидания, то последующие функции управления питанием не вызовут сложностей. Однако некоторые функции приложения, которые ранее работали без сбоев, могут вызывать проблемы.
- Не пытайтесь манипулировать системой, чтобы поместить ваше приложение в определённую группу. Способ определения приоритета системой может меняться, и каждый производитель устройства может написать собственное приложение для распределения по группам с собственным алгоритмом. Вместо этого убедитесь, что ваше приложение ведёт себя корректно, независимо от того, в какой группе оно находится.
- Если у приложения нет активности для запуска, оно может никогда не попасть в активную группу. Рассмотрите возможность редизайна приложения с добавлением такой активности.
Если пользователи не могут взаимодействовать с уведомлениями приложения, они не могут инициировать перемещение приложения в активную область. В этом случае рассмотрите возможность изменения дизайна некоторых уведомлений, чтобы пользователи могли взаимодействовать. Рекомендации см. в разделе «Шаблоны проектирования уведомлений в стиле Material Design».
Если приложение не отображает уведомление при получении высокоприоритетного сообщения Firebase Cloud Messaging (FCM) , пользователь не может взаимодействовать с приложением и, таким образом, переместить его в активный контейнер. Фактически, единственное предназначение высокоприоритетных сообщений FCM — отправка уведомлений пользователю, поэтому такая ситуация не должна возникать. В версии 12L (уровень API 32) и ниже, если вы ошибочно отметите сообщение FCM как высокоприоритетное, не вызывая взаимодействия с пользователем, это может привести к снижению приоритета последующих сообщений.
Если приложения распределены по нескольким пакетам, эти пакеты могут находиться в разных сегментах и иметь разные уровни доступа. Протестируйте эти приложения с пакетами, назначенными в разные сегменты, чтобы убедиться в их корректной работе.