Как и предыдущие выпуски, Android 16 включает изменения в поведении, которые могут повлиять на ваше приложение. Следующие изменения поведения применяются исключительно к приложениям, предназначенным для Android 16 или более поздней версии. Если ваше приложение ориентировано на Android 16 или более поздней версии, вам следует изменить его так, чтобы оно поддерживало такое поведение, если это применимо.
Обязательно ознакомьтесь также со списком изменений поведения, которые влияют на все приложения, работающие на Android 16, независимо от targetSdkVersion
вашего приложения.
Пользовательский опыт и системный интерфейс
Android 16 включает следующие изменения, призванные создать более последовательный и интуитивно понятный пользовательский интерфейс.
Отключение от края до края прекращается
Android 15 обеспечивает сквозную поддержку приложений, ориентированных на Android 15 (уровень API 35), но ваше приложение может отказаться, установив для R.attr#windowOptOutEdgeToEdgeEnforcement
значение true
. Для приложений, предназначенных для Android 16, R.attr#windowOptOutEdgeToEdgeEnforcement
устарел и отключен, и ваше приложение не может отказаться от перехода от края к краю.
Для тестирования в Android 16 Beta 2 убедитесь, что ваше приложение поддерживает сквозную обработку, и удалите любое использование R.attr#windowOptOutEdgeToEdgeEnforcement
. Чтобы обеспечить сквозную поддержку, см. руководство по созданию и представлениям . Сообщите нам о проблемах в нашем трекере проблем на странице обратной связи .
Для прогнозного возврата требуется миграция или отказ
Для приложений, ориентированных на Android 16 или более поздней версии и работающих на устройстве Android 16 или более поздней версии, прогнозируемая системная анимация (возврат домой, перекрестная задача и перекрестная активность) включена по умолчанию. Кроме того, onBackPressed
не вызывается и KeyEvent.KEYCODE_BACK
больше не отправляется.
Если ваше приложение перехватывает обратное событие и вы еще не перешли на предиктивную обратную навигацию, обновите свое приложение, чтобы оно использовало поддерживаемые API обратной навигации . или временно отказаться, установив для атрибута android:enableOnBackInvokedCallback
значение false
в теге <application>
или <activity>
файла AndroidManifest.xml
вашего приложения.
API-интерфейсы элегантных шрифтов устарели и отключены.
В приложениях, ориентированных на Android 15 (уровень API 35), атрибуту elegantTextHeight
TextView
по умолчанию присвоено значение true
, что заменяет компактный шрифт гораздо более читаемым. Вы можете переопределить это, установив для атрибута elegantTextHeight
значение false
.
В Android 16 атрибут elegantTextHeight
устарел, и этот атрибут будет игнорироваться, как только ваше приложение будет ориентировано на Android 16. Поддержка «шрифтов пользовательского интерфейса», управляемых этими API, прекращается, поэтому вам следует адаптировать любые макеты, чтобы обеспечить согласованное и перспективное отображение текста на арабском, лаосском, мьянманском, тамильском, гуджаратском, каннада, малаялам, одиа, телугу или тайском языках.

elegantTextHeight
для приложений, ориентированных на Android 14 (уровень API 34) и ниже, или для приложений, ориентированных на Android 15 (уровень API 35), которые переопределили значение по умолчанию, установив для атрибута elegantTextHeight
значение false
. 
elegantTextHeight
для приложений, ориентированных на Android 16, или для приложений, ориентированных на Android 15 (уровень API 35), которые не переопределили значение по умолчанию, установив для атрибута elegantTextHeight
значение false
.Основная функциональность
Android 16 включает следующие изменения, которые изменяют или расширяют различные основные возможности системы Android.
Оптимизация планирования работы с фиксированной ставкой
До ориентации на Android 16, когда scheduleAtFixedRate
пропускало выполнение задачи из-за того, что оно находилось за пределами допустимого жизненного цикла процесса , все пропущенные выполнения выполнялись немедленно, когда приложение возвращалось к допустимому жизненному циклу.
При настройке Android 16 не более одного пропущенного выполнения scheduleAtFixedRate
выполняется немедленно, когда приложение возвращается к допустимому жизненному циклу. Ожидается, что это изменение поведения улучшит производительность приложения. Проверьте это поведение в своем приложении, чтобы проверить, не затронуто ли оно ваше приложение. Вы также можете протестировать, используя платформу совместимости приложений и включив флаг совместимости STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS
.
Форм-факторы устройств
Android 16 включает следующие изменения в приложениях, отображаемых на устройствах с большим экраном.
Адаптивные макеты
Поскольку приложения Android теперь работают на различных устройствах (таких как телефоны, планшеты, складные устройства, настольные компьютеры, автомобили и телевизоры) и имеют оконные режимы на больших экранах (например, разделенный экран и окно рабочего стола), разработчикам следует создавать приложения Android, которые адаптируются к любому экрану и размеру окна, независимо от ориентации устройства. Такие парадигмы, как ограничение ориентации и возможности изменения размера, слишком ограничительны в современном мире, использующем множество устройств.
Игнорировать ограничения ориентации, изменения размера и соотношения сторон.
Для приложений, предназначенных для Android 16, Android 16 включает изменения в том, как система управляет ограничениями ориентации, изменения размера и соотношения сторон. На дисплеях с наименьшей шириной >= 600 dp ограничения больше не применяются. Приложения также заполняют все окно дисплея, независимо от соотношения сторон или предпочтительной ориентации пользователя, при этом пилларбокс не используется.
Это изменение вводит новое стандартное поведение платформы. Android движется к модели , в которой приложения должны адаптироваться к различным ориентациям, размерам дисплея и соотношениям сторон. Такие ограничения, как фиксированная ориентация или ограниченная возможность изменения размера, препятствуют адаптивности приложения, поэтому мы рекомендуем сделать ваше приложение адаптивным, чтобы обеспечить наилучшее взаимодействие с пользователем.
Вы также можете проверить это поведение, используя [инфраструктуру совместимости приложений][a16-kilo-14] и включив флаг совместимости UNIVERSAL_RESIZABLE_BY_DEFAULT
.
Общие критические изменения
Игнорирование ограничений на ориентацию, изменение размера и соотношение сторон может повлиять на пользовательский интерфейс вашего приложения на некоторых устройствах, особенно на элементы, которые были разработаны для небольших макетов, заблокированных в книжной ориентации: например, такие проблемы, как растянутые макеты, анимация и компоненты за пределами экрана. Любые предположения о соотношении сторон или ориентации могут вызвать визуальные проблемы в вашем приложении. Узнайте больше о том, как их избежать и улучшить адаптивное поведение вашего приложения.
Разрешение вращения устройства приводит к большему повторному созданию активности, что может привести к потере состояния пользователя, если оно не будет сохранено должным образом. Узнайте, как правильно сохранить состояние пользовательского интерфейса, в статье Сохранение состояний пользовательского интерфейса .
Детали реализации
Следующие атрибуты манифеста и API среды выполнения игнорируются на устройствах с большим экраном в полноэкранном и многооконном режимах:
-
screenOrientation
-
resizableActivity
-
minAspectRatio
-
maxAspectRatio
-
setRequestedOrientation()
-
getRequestedOrientation()
Следующие значения для screenOrientation
, setRequestedOrientation()
и getRequestedOrientation()
игнорируются:
-
portrait
-
reversePortrait
-
sensorPortrait
-
userPortrait
-
landscape
-
reverseLandscape
-
sensorLandscape
-
userLandscape
Что касается изменения размера дисплея, android:resizeableActivity="false"
, android:minAspectRatio
и android:maxAspectRatio
не имеют никакого эффекта.
Для приложений, предназначенных для Android 16, ограничения ориентации, изменения размера и соотношения сторон приложения по умолчанию игнорируются на больших экранах, но каждое приложение, которое не полностью готово, может временно отменить это поведение, отключив его (что приводит к переводу предыдущего поведения в режим совместимости).
Исключения
Ограничения на ориентацию, изменение размера и соотношение сторон Android 16 не применяются в следующих ситуациях:
- Игры (на основе флага
android:appCategory
) - Пользователи явно соглашаются на поведение приложения по умолчанию в настройках соотношения сторон устройства.
- Экраны меньше, чем
sw600dp
Временно отказаться от участия
Чтобы отказаться от определенного действия, объявите свойство манифеста PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY
:
<activity ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
...
</activity>
Если слишком много частей вашего приложения не готовы для Android 16, вы можете полностью отказаться, применив то же свойство на уровне приложения:
<application ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>
Здоровье и фитнес
Android 16 включает следующие изменения, связанные с данными о здоровье и фитнесе.
Разрешения для здоровья и фитнеса
Для приложений, предназначенных для Android 16 или более поздней версии, разрешения BODY_SENSORS
переходят на детальные разрешения в разделе android.permissions.health
, также используемые Health Connect . Любой API, ранее требующий BODY_SENSORS
или BODY_SENSORS_BACKGROUND
теперь требует соответствующего разрешения android.permissions.health
. Это влияет на следующие типы данных, API и типы служб переднего плана:
-
HEART_RATE_BPM
от Wear Health Services -
Sensor.TYPE_HEART_RATE
из Android Sensor Manager -
heartRateAccuracy
иheartRateBpm
из WearProtoLayout
-
FOREGROUND_SERVICE_TYPE_HEALTH
, где вместоBODY_SENSORS
требуется соответствующее разрешениеandroid.permission.health
Если ваше приложение использует эти API, теперь оно должно запрашивать соответствующие подробные разрешения:
- Для мониторинга сердечного ритма, SpO2 или температуры кожи во время использования: запросите детальное разрешение в
android.permissions.health
, напримерREAD_HEART_RATE
вместоBODY_SENSORS
. - Для доступа к фоновому датчику: запросите
READ_HEALTH_DATA_IN_BACKGROUND
вместоBODY_SENSORS_BACKGROUND
.
Эти разрешения такие же, как и те, которые защищают доступ к чтению данных из Health Connect , хранилища данных Android для данных о здоровье, фитнесе и самочувствии.