Изменения в поведении: приложения для Android 13 или более поздней версии.

Как и предыдущие выпуски, Android 13 включает изменения в поведении, которые могут повлиять на ваше приложение. Следующие изменения поведения применяются исключительно к приложениям, ориентированным на Android 13 или более позднюю версию. Если ваше приложение ориентировано на Android 13 или более поздней версии, вам следует изменить его так, чтобы оно правильно поддерживало такое поведение, если это применимо.

Обязательно ознакомьтесь со списком изменений поведения, которые влияют на все приложения, работающие на Android 13 .

Конфиденциальность

Разрешение на уведомление влияет на внешний вид службы переднего плана

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

Новое разрешение для работы ближайших устройств Wi-Fi.

В предыдущих версиях Android пользователю необходимо было предоставить вашему приложению разрешение ACCESS_FINE_LOCATION для выполнения нескольких распространенных сценариев использования Wi-Fi.

Поскольку пользователям сложно связать разрешения на определение местоположения с функциями Wi-Fi, Android 13 (уровень API 33) вводит разрешение времени выполнения в группе разрешений NEARBY_DEVICES для приложений, которые управляют подключениями устройства к ближайшим точкам доступа через Wi-Fi. Это разрешение NEARBY_WIFI_DEVICES соответствует следующим случаям использования Wi-Fi:

• Найдите близлежащие устройства, например принтеры или устройства для трансляции мультимедиа, или подключитесь к ним. Этот рабочий процесс позволяет вашему приложению выполнять следующие задачи:
  • Получайте информацию о точке доступа вне диапазона, например, через BLE.
  • Обнаруживайте устройства и подключайтесь к ним через Wi-Fi Aware, а также подключайтесь, используя локальную точку доступа.
  • Обнаруживайте устройства и подключайтесь к ним через Wi-Fi Direct.
• Инициируйте подключение к известному SSID, например к автомобилю или устройству умного дома.
• Запустите локальную точку доступа.
• Диапазон до ближайших устройств с поддержкой Wi-Fi.

Если ваше приложение не получает информацию о физическом местоположении от API Wi-Fi, запрашивайте NEARBY_WIFI_DEVICES вместо ACCESS_FINE_LOCATION , если вы ориентируетесь на Android 13 или более позднюю версию и используете API Wi-Fi. Когда вы объявляете разрешение NEARBY_WIFI_DEVICES , строго утверждайте, что ваше приложение никогда не получает информацию о физическом местоположении от API Wi-Fi. Для этого установите атрибут android:usesPermissionFlags в значение neverForLocation . Этот процесс аналогичен тому, который вы делаете в Android 12 (уровень API 31) и выше, когда вы утверждаете, что информация об устройстве Bluetooth никогда не используется для определения местоположения .

Узнайте больше о том, как запросить разрешение на доступ к устройствам Wi-Fi поблизости .

Детализированные медиа-разрешения

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

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

На рис. 1 показано приложение, которое запрашивает разрешение READ_MEDIA_AUDIO .

Если вы одновременно запросите разрешение READ_MEDIA_IMAGES и разрешение READ_MEDIA_VIDEO , появится только одно диалоговое окно системных разрешений.

Если вашему приложению ранее было предоставлено разрешение READ_EXTERNAL_STORAGE , то любые запрошенные разрешения READ_MEDIA_* предоставляются автоматически при обновлении. Вы можете использовать следующую команду ADB для просмотра обновленных разрешений:

adb shell cmd appops get --uid PACKAGE_NAME

Для использования датчиков тела в фоновом режиме требуется новое разрешение

В Android 13 представлена ​​концепция доступа «во время использования» к датчикам тела, таким как частота сердечных сокращений, температура и процент кислорода в крови. Эта модель доступа очень похожа на ту, которую система представила для определения местоположения в Android 10 (уровень API 29) .

Если ваше приложение предназначено для Android 13 и требует доступа к информации датчиков тела во время работы в фоновом режиме, вы должны объявить новое разрешение BODY_SENSORS_BACKGROUND в дополнение к существующему разрешению BODY_SENSORS .

Производительность и батарея

Использование ресурса батареи

Если пользователь переводит ваше приложение в «ограниченное» состояние для фонового использования батареи, в то время как ваше приложение предназначено для Android 13, система не передает широковещательную рассылку BOOT_COMPLETED или LOCKED_BOOT_COMPLETED до тех пор, пока приложение не будет запущено по другим причинам.

Пользовательский опыт

Элементы управления мультимедиа, полученные из PlaybackState

Для приложений, предназначенных для Android 13 (уровень API 33) и выше, система получает элементы управления мультимедиа из действий PlaybackState . Это позволяет системе отображать более богатый набор элементов управления, которые технически совместимы между телефонами и планшетными устройствами, а также согласовываться с тем, как элементы управления мультимедиа отображаются на других платформах Android, таких как Android Auto и Android TV.

На рис. 2 показан пример того, как это выглядит на телефоне и планшете соответственно.

До Android 13 система отображала до пяти действий из уведомления MediaStyle в том порядке, в котором они были добавлены . В компактном режиме — например, в свёрнутых быстрых настройках — отображалось до трёх действий, заданных с помощью setShowActionsInCompactView() .

Начиная с Android 13, система отображает до пяти кнопок действий на основе PlaybackState , как описано в следующей таблице. В компактном режиме будут отображаться только первые три слота действий. Для приложений, которые не предназначены для Android 13 или тех, которые не включают PlaybackState , система будет отображать элементы управления на основе списка Action , добавленного в уведомление MediaStyle , как описано в предыдущем абзаце.

Пользовательские действия размещаются в том порядке, в котором они были добавлены в PlaybackState .

Цветовая тема приложения автоматически применяется к содержимому WebView.

Для приложений, предназначенных для Android 13 (уровень API 33) или выше, метод setForceDark() считается устаревшим, что приводит к остановке работы при вызове метода.

Вместо этого WebView теперь всегда устанавливает медиа-запрос prefers-color-scheme в соответствии с атрибутом темы приложения isLightTheme . Другими словами, если isLightTheme имеет true или не указано, prefers-color-scheme имеет значение light ; иначе dark . Такое поведение означает, что светлый или темный стиль веб-содержимого применяется автоматически в соответствии с темой приложения, если содержимое поддерживает его.

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

Если вам по-прежнему необходимо настроить поведение цветовой темы вашего приложения, используйте вместо этого метод setAlgorithmicDarkeningAllowed() . Для обратной совместимости с предыдущими версиями Android мы рекомендуем использовать эквивалентный метод setAlgorithmicDarkeningAllowed() в AndroidX.

См. документацию по этому методу, чтобы узнать больше о том, какое поведение можно ожидать в вашем приложении в зависимости от его targetSdkVersion и настроек темы.

Возможности подключения

BluetoothAdapter#enable() и BluetoothAdapter#disable() устарели

Для приложений, предназначенных для Android 13 (уровень API 33) или более поздних версий, методы BluetoothAdapter#enable() и BluetoothAdapter#disable() считаются устаревшими и всегда возвращают false .

Следующие типы приложений освобождены от этих изменений:

• Приложения владельца устройства
• Приложения для владельцев профилей
• Системные приложения

Сервисы Google Play

Требуется разрешение для рекламного идентификатора

Приложения, использующие рекламный идентификатор сервисов Google Play и предназначенные для Android 13 (уровень API 33) и более поздних версий, должны объявить обычное разрешение AD_ID в файле манифеста своего приложения следующим образом:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

Если ваше приложение не декларирует это разрешение при настройке Android 13 или более поздней версии, рекламный идентификатор автоматически удаляется и заменяется строкой нулей.

Если ваше приложение использует пакеты SDK, которые объявляют разрешение AD_ID в манифесте библиотеки, то это разрешение по умолчанию объединяется с файлом манифеста вашего приложения. В этом случае вам не нужно объявлять разрешение в самом файле описания вашего приложения.

Дополнительную информацию см. в разделе «Рекламный идентификатор» в справке Play Console.

Обновлены ограничения, не связанные с SDK.

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

Если ваше приложение не предназначено для Android 13, некоторые из этих изменений могут не затронуть вас сразу. Однако, хотя в настоящее время вы можете использовать некоторые интерфейсы, не входящие в SDK ( в зависимости от целевого уровня API вашего приложения ), использование любого метода или поля, не входящего в SDK, всегда сопряжено с высоким риском поломки вашего приложения.

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

Дополнительные сведения об изменениях в этой версии Android см . в разделе Обновления ограничений интерфейса, не связанных с SDK, в Android 13 . Дополнительные сведения об интерфейсах, отличных от SDK, см. в разделе Ограничения на интерфейсы, не относящиеся к SDK .

Как и предыдущие выпуски, Android 13 включает изменения в поведении, которые могут повлиять на ваше приложение. Следующие изменения поведения применяются исключительно к приложениям, ориентированным на Android 13 или более позднюю версию. Если ваше приложение ориентировано на Android 13 или более поздней версии, вам следует изменить его так, чтобы оно правильно поддерживало такое поведение, если это применимо.

Обязательно ознакомьтесь со списком изменений поведения, которые влияют на все приложения, работающие на Android 13 .

Конфиденциальность

Разрешение на уведомление влияет на внешний вид службы переднего плана

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

Новое разрешение для работы ближайших устройств Wi-Fi.

В предыдущих версиях Android пользователю необходимо было предоставить вашему приложению разрешение ACCESS_FINE_LOCATION для выполнения нескольких распространенных сценариев использования Wi-Fi.

Поскольку пользователям сложно связать разрешения на определение местоположения с функциями Wi-Fi, Android 13 (уровень API 33) вводит разрешение времени выполнения в группе разрешений NEARBY_DEVICES для приложений, которые управляют подключениями устройства к ближайшим точкам доступа через Wi-Fi. Это разрешение NEARBY_WIFI_DEVICES соответствует следующим случаям использования Wi-Fi:

• Найдите близлежащие устройства, например принтеры или устройства для трансляции мультимедиа, или подключитесь к ним. Этот рабочий процесс позволяет вашему приложению выполнять следующие задачи:
  • Получайте информацию о точке доступа вне диапазона, например, через BLE.
  • Обнаруживайте устройства и подключайтесь к ним через Wi-Fi Aware, а также подключайтесь, используя локальную точку доступа.
  • Обнаруживайте устройства и подключайтесь к ним через Wi-Fi Direct.
• Инициируйте подключение к известному SSID, например к автомобилю или устройству умного дома.
• Запустите локальную точку доступа.
• Диапазон до ближайших устройств с поддержкой Wi-Fi.

Если ваше приложение не получает информацию о физическом местоположении от API Wi-Fi, запрашивайте NEARBY_WIFI_DEVICES вместо ACCESS_FINE_LOCATION , если вы ориентируетесь на Android 13 или более позднюю версию и используете API Wi-Fi. Когда вы объявляете разрешение NEARBY_WIFI_DEVICES , строго утверждайте, что ваше приложение никогда не получает информацию о физическом местоположении от API Wi-Fi. Для этого установите атрибут android:usesPermissionFlags в значение neverForLocation . Этот процесс аналогичен тому, который вы делаете в Android 12 (уровень API 31) и выше, когда вы утверждаете, что информация об устройстве Bluetooth никогда не используется для определения местоположения .

Узнайте больше о том, как запросить разрешение на доступ к устройствам Wi-Fi поблизости .

Детализированные медиа-разрешения

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

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

На рис. 1 показано приложение, которое запрашивает разрешение READ_MEDIA_AUDIO .

Если вы одновременно запросите разрешение READ_MEDIA_IMAGES и разрешение READ_MEDIA_VIDEO , появится только одно диалоговое окно системных разрешений.

Если вашему приложению ранее было предоставлено разрешение READ_EXTERNAL_STORAGE , то любые запрошенные разрешения READ_MEDIA_* предоставляются автоматически при обновлении. Вы можете использовать следующую команду ADB для просмотра обновленных разрешений:

adb shell cmd appops get --uid PACKAGE_NAME

Для использования датчиков тела в фоновом режиме требуется новое разрешение

В Android 13 представлена ​​концепция доступа «во время использования» к датчикам тела, таким как частота сердечных сокращений, температура и процент кислорода в крови. Эта модель доступа очень похожа на ту, которую система представила для определения местоположения в Android 10 (уровень API 29) .

Если ваше приложение предназначено для Android 13 и требует доступа к информации датчиков тела во время работы в фоновом режиме, вы должны объявить новое разрешение BODY_SENSORS_BACKGROUND в дополнение к существующему разрешению BODY_SENSORS .

Производительность и батарея

Использование ресурса батареи

Если пользователь переводит ваше приложение в «ограниченное» состояние для фонового использования батареи, в то время как ваше приложение предназначено для Android 13, система не передает широковещательную рассылку BOOT_COMPLETED или LOCKED_BOOT_COMPLETED до тех пор, пока приложение не будет запущено по другим причинам.

Пользовательский опыт

Элементы управления мультимедиа, полученные из PlaybackState

Для приложений, предназначенных для Android 13 (уровень API 33) и выше, система получает элементы управления мультимедиа из действий PlaybackState . Это позволяет системе отображать более богатый набор элементов управления, которые технически совместимы между телефонами и планшетными устройствами, а также согласовываться с тем, как элементы управления мультимедиа отображаются на других платформах Android, таких как Android Auto и Android TV.

На рис. 2 показан пример того, как это выглядит на телефоне и планшете соответственно.

До Android 13 система отображала до пяти действий из уведомления MediaStyle в том порядке, в котором они были добавлены . В компактном режиме — например, в свёрнутых быстрых настройках — отображалось до трёх действий, заданных с помощью setShowActionsInCompactView() .

Начиная с Android 13, система отображает до пяти кнопок действий на основе PlaybackState , как описано в следующей таблице. В компактном режиме будут отображаться только первые три слота действий. Для приложений, которые не предназначены для Android 13 или тех, которые не включают PlaybackState , система будет отображать элементы управления на основе списка Action , добавленного в уведомление MediaStyle , как описано в предыдущем абзаце.

Пользовательские действия размещаются в том порядке, в котором они были добавлены в PlaybackState .

Цветовая тема приложения автоматически применяется к содержимому WebView.

Для приложений, предназначенных для Android 13 (уровень API 33) или выше, метод setForceDark() считается устаревшим, что приводит к остановке работы при вызове метода.

Вместо этого WebView теперь всегда устанавливает медиа-запрос prefers-color-scheme в соответствии с атрибутом темы приложения isLightTheme . Другими словами, если isLightTheme имеет значение true или не указано, prefers-color-scheme имеет значение light ; иначе dark . Такое поведение означает, что светлый или темный стиль веб-содержимого применяется автоматически в соответствии с темой приложения, если содержимое поддерживает его.

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

Если вам по-прежнему необходимо настроить поведение цветовой темы вашего приложения, используйте вместо этого метод setAlgorithmicDarkeningAllowed() . Для обратной совместимости с предыдущими версиями Android мы рекомендуем использовать эквивалентный метод setAlgorithmicDarkeningAllowed() в AndroidX.

См. документацию по этому методу, чтобы узнать больше о том, какое поведение можно ожидать в вашем приложении в зависимости от его targetSdkVersion и настроек темы.

Возможности подключения

BluetoothAdapter#enable() и BluetoothAdapter#disable() устарели.

Для приложений, предназначенных для Android 13 (уровень API 33) или более поздних версий, методы BluetoothAdapter#enable() и BluetoothAdapter#disable() считаются устаревшими и всегда возвращают false .

Следующие типы приложений освобождены от этих изменений:

• Приложения владельца устройства
• Приложения для владельцев профилей
• Системные приложения

Сервисы Google Play

Требуется разрешение для рекламного идентификатора

Приложения, использующие рекламный идентификатор сервисов Google Play и предназначенные для Android 13 (уровень API 33) и более поздних версий, должны объявить обычное разрешение AD_ID в файле манифеста своего приложения следующим образом:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

Если ваше приложение не декларирует это разрешение при настройке Android 13 или более поздней версии, рекламный идентификатор автоматически удаляется и заменяется строкой нулей.

Если ваше приложение использует пакеты SDK, которые объявляют разрешение AD_ID в манифесте библиотеки, то это разрешение по умолчанию объединяется с файлом манифеста вашего приложения. В этом случае вам не нужно объявлять разрешение в самом файле описания вашего приложения.

Дополнительную информацию см. в разделе «Рекламный идентификатор» в справке Play Console.

Обновлены ограничения, не связанные с SDK.

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

Если ваше приложение не предназначено для Android 13, некоторые из этих изменений могут не затронуть вас сразу. Однако, хотя в настоящее время вы можете использовать некоторые интерфейсы, не входящие в SDK ( в зависимости от целевого уровня API вашего приложения ), использование любого метода или поля, не входящего в SDK, всегда сопряжено с высоким риском поломки вашего приложения.

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

Дополнительные сведения об изменениях в этой версии Android см . в разделе Обновления ограничений интерфейса, не связанных с SDK, в Android 13 . Дополнительные сведения об интерфейсах, отличных от SDK, см. в разделе Ограничения на интерфейсы, не относящиеся к SDK .

Как и предыдущие выпуски, Android 13 включает изменения в поведении, которые могут повлиять на ваше приложение. Следующие изменения поведения применяются исключительно к приложениям, ориентированным на Android 13 или более позднюю версию. Если ваше приложение ориентировано на Android 13 или более поздней версии, вам следует изменить его так, чтобы оно правильно поддерживало такое поведение, если это применимо.

Обязательно ознакомьтесь со списком изменений поведения, которые влияют на все приложения, работающие на Android 13 .

Конфиденциальность

Разрешение на уведомление влияет на внешний вид службы переднего плана

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

Новое разрешение для работы ближайших устройств Wi-Fi.

В предыдущих версиях Android пользователю необходимо было предоставить вашему приложению разрешение ACCESS_FINE_LOCATION для выполнения нескольких распространенных сценариев использования Wi-Fi.

Поскольку пользователям сложно связать разрешения на определение местоположения с функциями Wi-Fi, Android 13 (уровень API 33) вводит разрешение времени выполнения в группе разрешений NEARBY_DEVICES для приложений, которые управляют подключениями устройства к ближайшим точкам доступа через Wi-Fi. Это разрешение NEARBY_WIFI_DEVICES соответствует следующим случаям использования Wi-Fi:

• Найдите близлежащие устройства, например принтеры или устройства для трансляции мультимедиа, или подключитесь к ним. Этот рабочий процесс позволяет вашему приложению выполнять следующие задачи:
  • Получайте информацию о точке доступа вне диапазона, например, через BLE.
  • Обнаруживайте устройства и подключайтесь к ним через Wi-Fi Aware, а также подключайтесь, используя локальную точку доступа.
  • Обнаруживайте устройства и подключайтесь к ним через Wi-Fi Direct.
• Инициируйте подключение к известному SSID, например к автомобилю или устройству умного дома.
• Запустите локальную точку доступа.
• Диапазон до ближайших устройств с поддержкой Wi-Fi.

Если ваше приложение не получает информацию о физическом местоположении от API Wi-Fi, запрашивайте NEARBY_WIFI_DEVICES вместо ACCESS_FINE_LOCATION , если вы ориентируетесь на Android 13 или более позднюю версию и используете API Wi-Fi. Когда вы объявляете разрешение NEARBY_WIFI_DEVICES , категорически утверждайте, что ваше приложение никогда не получает информацию о физическом местоположении от API Wi-Fi. Для этого установите атрибут android:usesPermissionFlags в значение neverForLocation . Этот процесс аналогичен тому, который вы делаете в Android 12 (уровень API 31) и выше, когда вы утверждаете, что информация об устройстве Bluetooth никогда не используется для определения местоположения .

Узнайте больше о том, как запросить разрешение на доступ к устройствам Wi-Fi поблизости .

Детализированные медиа-разрешения

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

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

На рис. 1 показано приложение, которое запрашивает разрешение READ_MEDIA_AUDIO .

Если вы одновременно запросите разрешение READ_MEDIA_IMAGES и разрешение READ_MEDIA_VIDEO , появится только одно диалоговое окно системных разрешений.

Если вашему приложению ранее было предоставлено разрешение READ_EXTERNAL_STORAGE , то любые запрошенные разрешения READ_MEDIA_* предоставляются автоматически при обновлении. Вы можете использовать следующую команду ADB для просмотра обновленных разрешений:

adb shell cmd appops get --uid PACKAGE_NAME

Для использования датчиков тела в фоновом режиме требуется новое разрешение

В Android 13 представлена ​​концепция доступа «во время использования» к датчикам тела, таким как частота сердечных сокращений, температура и процент кислорода в крови. Эта модель доступа очень похожа на ту, которую система представила для определения местоположения в Android 10 (уровень API 29) .

Если ваше приложение предназначено для Android 13 и требует доступа к информации датчиков тела во время работы в фоновом режиме, вы должны объявить новое разрешение BODY_SENSORS_BACKGROUND в дополнение к существующему разрешению BODY_SENSORS .

Производительность и батарея

Использование ресурса батареи

Если пользователь переводит ваше приложение в «ограниченное» состояние для фонового использования батареи, в то время как ваше приложение предназначено для Android 13, система не передает широковещательную рассылку BOOT_COMPLETED или LOCKED_BOOT_COMPLETED до тех пор, пока приложение не будет запущено по другим причинам.

Пользовательский опыт

Элементы управления мультимедиа, полученные из PlaybackState

Для приложений, предназначенных для Android 13 (уровень API 33) и выше, система получает элементы управления мультимедиа из действий PlaybackState . Это позволяет системе отображать более богатый набор элементов управления, которые технически совместимы между телефонами и планшетными устройствами, а также согласовываться с тем, как элементы управления мультимедиа отображаются на других платформах Android, таких как Android Auto и Android TV.

На рис. 2 показан пример того, как это выглядит на телефоне и планшете соответственно.

До Android 13 система отображала до пяти действий из уведомления MediaStyle в том порядке, в котором они были добавлены . В компактном режиме — например, в свёрнутых быстрых настройках — отображалось до трёх действий, заданных с помощью setShowActionsInCompactView() .

Начиная с Android 13, система отображает до пяти кнопок действий на основе PlaybackState , как описано в следующей таблице. В компактном режиме будут отображаться только первые три слота действий. Для приложений, которые не предназначены для Android 13 или тех, которые не включают PlaybackState , система будет отображать элементы управления на основе списка Action , добавленного в уведомление MediaStyle , как описано в предыдущем абзаце.

Пользовательские действия размещаются в том порядке, в котором они были добавлены в PlaybackState .

Цветовая тема приложения автоматически применяется к содержимому WebView.

Для приложений, предназначенных для Android 13 (уровень API 33) или выше, метод setForceDark() считается устаревшим, что приводит к остановке работы при вызове метода.

Вместо этого WebView теперь всегда устанавливает медиа-запрос prefers-color-scheme в соответствии с атрибутом темы приложения isLightTheme . Другими словами, если isLightTheme имеет true или не указано, prefers-color-scheme имеет значение light ; иначе dark . Такое поведение означает, что светлый или темный стиль веб-содержимого применяется автоматически в соответствии с темой приложения, если содержимое поддерживает его.

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

Если вам по-прежнему необходимо настроить поведение цветовой темы вашего приложения, используйте вместо этого метод setAlgorithmicDarkeningAllowed() . Для обратной совместимости с предыдущими версиями Android мы рекомендуем использовать эквивалентный метод setAlgorithmicDarkeningAllowed() в AndroidX.

См. документацию по этому методу, чтобы узнать больше о том, какое поведение можно ожидать в вашем приложении в зависимости от его targetSdkVersion и настроек темы.

Возможности подключения

BluetoothAdapter#enable() и BluetoothAdapter#disable() устарели.

Для приложений, предназначенных для Android 13 (уровень API 33) или более поздних версий, методы BluetoothAdapter#enable() и BluetoothAdapter#disable() считаются устаревшими и всегда возвращают false .

Следующие типы приложений освобождены от этих изменений:

• Приложения владельца устройства
• Приложения для владельцев профилей
• Системные приложения

Сервисы Google Play

Требуется разрешение для рекламного идентификатора

Приложения, использующие рекламный идентификатор сервисов Google Play и предназначенные для Android 13 (уровень API 33) и более поздних версий, должны объявить обычное разрешение AD_ID в файле манифеста своего приложения следующим образом:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

Если ваше приложение не декларирует это разрешение при настройке Android 13 или более поздней версии, рекламный идентификатор автоматически удаляется и заменяется строкой нулей.

Если ваше приложение использует пакеты SDK, которые объявляют разрешение AD_ID в манифесте библиотеки, то это разрешение по умолчанию объединяется с файлом манифеста вашего приложения. В этом случае вам не нужно объявлять разрешение в самого мрачного файла вашего приложения.

Чтобы узнать больше, см. Рекламный идентификатор в Play Console Help.

Обновленные не-SDK-ограничения

Android 13 включает в себя обновленные списки ограниченных не-SDK интерфейсов на основе сотрудничества с разработчиками Android и последнего внутреннего тестирования. По возможности, мы следим за тем, чтобы общественные альтернативы были доступны, прежде чем мы ограничим не-SDK интерфейсы.

Если ваше приложение не нацелено на Android 13, некоторые из этих изменений могут не сразу повлиять на вас. Однако, хотя в настоящее время вы можете использовать некоторые не-SDK-интерфейсы ( в зависимости от целевого уровня API вашего приложения ), использование любого метода или поля не SDK всегда несет высокий риск разрушения вашего приложения.

Если вы не уверены, использует ли ваше приложение не SDK интерфейсы, вы можете проверить свое приложение , чтобы выяснить. Если ваше приложение полагается на не-SDK-интерфейсы, вам следует начать планировать миграцию в альтернативы SDK. Тем не менее, мы понимаем, что некоторые приложения имеют допустимые варианты использования для использования не-SDK-интерфейсов. Если вы не можете найти альтернативу использованию не-SDK-интерфейса для функции в вашем приложении, вам следует запросить новый публичный API .

Чтобы узнать больше об изменениях в этом выпуске Android, см. Обновления ограничений не SDK интерфейса в Android 13 . Чтобы узнать больше о не-SDK-интерфейсах в целом, см. Ограничения на не-SDK-интерфейсы .

Как и в более ранних выпусках, Android 13 включает в себя изменения поведения, которые могут повлиять на ваше приложение. Следующие изменения поведения применяются исключительно к приложениям, которые нацелены на Android 13 или выше. Если ваше приложение нацелено на Android 13 или выше, вам следует изменить ваше приложение для правильной поддержки этого поведения, где это применимо.

Обязательно ознакомьтесь с списком изменений поведения, которые влияют на все приложения, работающие на Android 13 .

Конфиденциальность

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

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

Новое разрешение на время выполнения для близлежащих устройств Wi-Fi

В предыдущих версиях Android пользователь должен предоставить ваше приложение разрешение ACCESS_FINE_LOCATION для завершения нескольких общих вариантов использования Wi-Fi.

Поскольку пользователям трудно связывать разрешения на местонахождение с функциональностью Wi-Fi, Android 13 (API-уровень 33) вводит разрешение на время выполнения в группе разрешений NEARBY_DEVICES для приложений, которые управляют подключением устройства с близлежащими точками доступа через Wi-Fi. Это разрешение, NEARBY_WIFI_DEVICES , выполняет варианты использования Wi-Fi, такие как следующее:

• Найдите или подключитесь к близлежащим устройствам, таким как принтеры или устройства для литья медиа. Этот рабочий процесс позволяет вашему приложению выполнять подобные задачи:
  • Получите информацию AP из группы, например, через BLE.
  • Откройте для себя и подключитесь к устройствам через Wi-Fi Aware и подключитесь, используя точку доступа только для локала.
  • Откройте для себя и подключитесь к устройствам через Wi-Fi Direct.
• Инициируйте соединение с известным SSID, таким как автомобиль или устройство для умного дома.
• Начните точку горячей точки.
• Диапазон до близлежащих устройств Wi-Fi.

Пока ваше приложение не получает информацию о физическом местоположении из API Wi-Fi, запрашивайте NEARBY_WIFI_DEVICES вместо ACCESS_FINE_LOCATION , когда вы нацелитесь на Android 13 или выше и используете API Wi-Fi. Когда вы объявляете разрешение NEARBY_WIFI_DEVICES , убедительно утверждает, что ваше приложение никогда не получает информацию о физическом местоположении из API Wi-Fi. Для этого установите атрибут android:usesPermissionFlags PersissionFlags для neverForLocation . Этот процесс похож на тот, который вы делаете в Android 12 (API -уровне 31) и выше, когда вы утверждаете, что информация об устройстве Bluetooth никогда не используется для местоположения .

Узнайте больше о том, как запросить разрешение на доступ к близлежащим устройствам Wi-Fi .

Гранулированные носители

Если ваше приложение предназначено для Android 13 или выше, и вам необходимо получить доступ к медиа -файлам, которые создали другие приложения , вы должны запросить одно или несколько из следующих граналичных разрешений на носитель вместо разрешения READ_EXTERNAL_STORAGE :

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

На рисунке 1 показано приложение, которое запрашивает разрешение READ_MEDIA_AUDIO .

Если вы запросите как разрешение READ_MEDIA_IMAGES , так и разрешение READ_MEDIA_VIDEO одновременно, появляется только один диалог разрешения системы.

Если ваше приложение было ранее предоставлено разрешение READ_EXTERNAL_STORAGE , то при обновлении предоставляются любые запрошенные разрешения READ_MEDIA_* . Вы можете использовать следующую команду ADB для просмотра обновленных разрешений:

adb shell cmd appops get --uid PACKAGE_NAME

Использование датчиков тела на заднем плане требует нового разрешения

Android 13 вводит концепцию «how in in use» для датчиков тела, таких как частота сердечных сокращений, температура и процент кислорода в крови. Эта модель доступа очень похожа на ту, которую система, введенная для местоположения в Android 10 (уровень 29 API) .

Если ваше приложение предназначено для Android 13 и требует доступа к информации датчика тела во время работы в фоновом режиме, вы должны объявить о новом разрешении BODY_SENSORS_BACKGROUND в дополнение к существующему разрешению BODY_SENSORS .

Производительность и батарея

Использование ресурсов аккумулятора

Если пользователь помещает ваше приложение в состояние «Ограниченное» для использования фоновой батареи, в то время как ваше приложение нацелено на Android 13, система не доставляет трансляцию BOOT_COMPLETED или трансляцию LOCKED_BOOT_COMPLETED до тех пор, пока приложение не будет запущено по другим причинам.

Пользовательский опыт

Управление среды, полученные из PlaybackState

Для приложений, нацеленных на Android 13 (API -уровень 33) и выше, система получает средства управления носителями из действий PlaybackState . Это позволяет системе показывать более богатый набор элементов управления, которые технически соответствуют телефону и планшетными устройствами, а также соответствуют тому, как управления носителями отображаются на других платформах Android, таких как Android Auto и Android TV.

На рисунке 2 показан пример того, как это выглядит на телефоне и планшетном устройстве соответственно.

До Android 13 система отображала до пяти действий из уведомления MediaStyle в том порядке, в котором они были добавлены . В компактном режиме, например, в свернутых быстрых настройках были показаны до трех действий, указанных с setShowActionsInCompactView() .

Начиная с Android 13, система отображает до пяти кнопок действия на основе PlaybackState , как описано в следующей таблице. В компактном режиме будут отображаться только первые три слота действий. Для приложений, которые не нацелены на Android 13 или на тех, которые не включают в себя PlaybackState , система будет отображать элементы управления на основе списка Action , добавленных в уведомление MediaStyle , как описано в предыдущем абзаце.

Пользовательские действия размещаются в том порядке, в котором они были добавлены в PlaybackState .

Цветная тема приложения применяется автоматически к контенту WebView

Для приложений, нацеленных на Android 13 (API-уровень 33) или выше, метод setForceDark() устарел, что приводит к не-операционной, если метод вызван.

Вместо этого WebView теперь всегда устанавливает медиа-запрос prefers-color-scheme в соответствии с атрибутом темы приложения isLightTheme . Другими словами, если isLightTheme true или не указана, prefers-color-scheme light ; В противном случае, dark . Такое поведение означает, что свет или темный стиль веб -контента применяется автоматически в соответствии с темой приложения, если контент поддерживает его.

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

Если вам все еще нужно настроить поведение цветовой темы вашего приложения, используйте вместо этого метод setAlgorithmicDarkeningAllowed() . Для обратной совместимости с предыдущими версиями Android мы рекомендуем использовать эквивалентный метод setAlgorithmicDarkeningAllowed() в Androidx.

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

Возможности подключения

BluetoothAdapter#enable () и BluetoothAdapter#Disable () устарел

Для приложений, нацеленных на Android 13 (API -уровне 33) или выше, методы BluetoothAdapter#enable() и BluetoothAdapter#disable() устанавливаются и всегда возвращают false .

Следующие типы приложений освобождаются от этих изменений:

• Приложения владельца устройства
• Приложения владельца профиля
• Системные приложения

Сервисы Google Play

Разрешение, необходимое для идентификатора рекламы

Приложения, которые используют идентификатор рекламы Google Play Services и целевой Android 13 (API -уровне 33) и выше, должны объявить нормальное разрешение AD_ID в манифестском файле их приложения следующим образом:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

Если ваше приложение не объявляет об этом разрешении при нацеливании на Android 13 или выше, идентификатор рекламы автоматически удаляется и заменяется на ряд нулей.

Если ваше приложение использует SDK, которые объявляют разрешение AD_ID в манифесте библиотеки, то разрешение по умолчанию объединяется с манифестом вашего приложения. В этом случае вам не нужно объявлять разрешение в самого мрачного файла вашего приложения.

Чтобы узнать больше, см. Рекламный идентификатор в Play Console Help.

Обновленные не-SDK-ограничения

Android 13 включает в себя обновленные списки ограниченных не-SDK интерфейсов на основе сотрудничества с разработчиками Android и последнего внутреннего тестирования. По возможности, мы следим за тем, чтобы общественные альтернативы были доступны, прежде чем мы ограничим не-SDK интерфейсы.

Если ваше приложение не нацелено на Android 13, некоторые из этих изменений могут не сразу повлиять на вас. Однако, хотя в настоящее время вы можете использовать некоторые не-SDK-интерфейсы ( в зависимости от целевого уровня API вашего приложения ), использование любого метода или поля не SDK всегда несет высокий риск разрушения вашего приложения.

Если вы не уверены, использует ли ваше приложение не SDK интерфейсы, вы можете проверить свое приложение , чтобы выяснить. Если ваше приложение полагается на не-SDK-интерфейсы, вам следует начать планировать миграцию в альтернативы SDK. Тем не менее, мы понимаем, что некоторые приложения имеют допустимые варианты использования для использования не-SDK-интерфейсов. Если вы не можете найти альтернативу использованию не-SDK-интерфейса для функции в вашем приложении, вам следует запросить новый публичный API .

Чтобы узнать больше об изменениях в этом выпуске Android, см. Обновления ограничений не SDK интерфейса в Android 13 . Чтобы узнать больше о не-SDK-интерфейсах в целом, см. Ограничения на не-SDK-интерфейсы .