Резервные сегменты приложений

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 и выше:

Оцените приоритетную группу.

Чтобы проверить, к какому сегменту относится ваше приложение, выполните одно из следующих действий:

  • Вызовите метод getAppStandbyBucket() .

  • Выполните следующую команду в окне терминала:

    adb shell am get-standby-bucket PACKAGE_NAME

Система ограничивает скорость вашего приложения всякий раз, когда оно помещается в резервный сегмент приложения, значение которого больше STANDBY_BUCKET_ACTIVE (10).

Передовые методы

Если ваше приложение соответствует рекомендациям по использованию Doze и режима ожидания, внедрение этих функций управления питанием не составит труда. Однако некоторые ранее хорошо работавшие функции приложения могут вызвать проблемы.

  • Не пытайтесь манипулировать системой, чтобы она поместила ваше приложение в определенную категорию. Метод определения приоритетов может меняться, и каждый производитель устройств может разработать собственное приложение для ранжирования приложений со своим собственным алгоритмом. Вместо этого убедитесь, что ваше приложение ведет себя корректно независимо от того, в какой категории оно находится.
  • Если у приложения нет панели запуска, оно может никогда не попасть в категорию активных приложений. Рассмотрите возможность переработки дизайна вашего приложения и добавления такой панели.

  • Если пользователи не могут взаимодействовать с уведомлениями приложения, они не смогут инициировать продвижение приложения в активную категорию. В этом случае следует переработать некоторые уведомления, чтобы обеспечить возможность взаимодействия с ними. Рекомендации можно найти в шаблонах проектирования Material Design Notifications .

  • Если приложение не отображает уведомление при получении сообщения Firebase Cloud Messaging (FCM) с высоким приоритетом , пользователь не может взаимодействовать с приложением и, следовательно, повысить его статус до активного сегмента. Фактически, единственное предназначение сообщений FCM с высоким приоритетом — отправка уведомлений пользователю, поэтому такая ситуация не должна возникать. В версиях 12L (уровень API 32) и ниже, если вы некорректно помечаете сообщение FCM как сообщение с высоким приоритетом, если оно не вызывает взаимодействия с пользователем, это может привести к снижению приоритета будущих сообщений.

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