Как и в предыдущих версиях, в 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 Aware.
Если ваше приложение не получает информацию о физическом местоположении из 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 .
Детализированные разрешения для медиа
READ_MEDIA_AUDIO . Если ваше приложение предназначено для Android 13 или более поздней версии и ему необходим доступ к медиафайлам, созданным другими приложениями , вам необходимо запросить одно или несколько из следующих детализированных разрешений на доступ к медиафайлам вместо разрешения READ_EXTERNAL_STORAGE :
| Тип носителя | Разрешение на запрос |
|---|---|
| Изображения и фотографии | READ_MEDIA_IMAGES |
| Видео | READ_MEDIA_VIDEO |
| Аудио файлы | READ_MEDIA_AUDIO |
Прежде чем получить доступ к медиафайлам другого приложения, убедитесь, что пользователь предоставил вашему приложению соответствующие детальные разрешения на доступ к медиафайлам.
На рисунке 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 , как описано в предыдущем абзаце.
| Слот | Действие | Критерии |
|---|---|---|
| 1 | Играть | Текущее состояние PlaybackState может быть одним из следующих:
|
| Загрузка счетчика | Текущее состояние PlaybackState может быть одним из следующих:
| |
| Пауза | Текущее состояние PlaybackState не соответствует ни одному из вышеперечисленных. | |
| 2 | Предыдущий | Действия PlaybackState включают ACTION_SKIP_TO_PREVIOUS . |
| Обычай | Действия PlaybackState не включают ACTION_SKIP_TO_PREVIOUS , а пользовательские действия PlaybackState включают пользовательское действие, которое еще не размещено. | |
| Пустой | Дополнительные параметры PlaybackState включают true логическое значение для ключа SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV . | |
| 3 | Следующий | Действия PlaybackState включают ACTION_SKIP_TO_NEXT . |
| Обычай | Действия PlaybackState не включают ACTION_SKIP_TO_NEXT , а пользовательские действия PlaybackState включают пользовательское действие, которое еще не размещено. | |
| Пустой | Дополнительные параметры PlaybackState включают true логическое значение для ключа SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT . | |
| 4 | Обычай | Пользовательские действия PlaybackState включают пользовательское действие, которое еще не размещено. |
| 5 | Обычай | Пользовательские действия PlaybackState включают пользовательское действие, которое еще не размещено. |
Пользовательские действия размещаются в том порядке, в котором они были добавлены в 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 в манифесте библиотеки, то это разрешение по умолчанию объединяется с файлом манифеста вашего приложения. В этом случае вам не нужно объявлять разрешение в файле manfiest вашего приложения.
Более подробную информацию см. в разделе «Идентификатор рекламы» в справке 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 .