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

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

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

Пользовательский опыт и системный пользовательский интерфейс

Android 16 (уровень API 36) включает в себя следующие изменения, направленные на создание более последовательного и интуитивно понятного пользовательского опыта.

Отказ от функции Edge to Edge прекращается

Android 15 强制执行全屏显示，以针对 Android 15（API 级别 35）的应用为目标平台，但您的应用可以通过将 R.attr#windowOptOutEdgeToEdgeEnforcement 设置为 true 来选择停用。对于以 Android 16（API 级别 36）为目标平台的应用，R.attr#windowOptOutEdgeToEdgeEnforcement 已被废弃并停用，并且您的应用无法选择不采用从边缘到边缘的布局。

  • 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 15 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会继续正常运行。
  • 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 16 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会被停用。

如需在 Android 16 中进行测试，请确保您的应用支持无边框设计，并移除所有 R.attr#windowOptOutEdgeToEdgeEnforcement 用法，以便您的应用在 Android 15 设备上也能支持无边框设计。如需支持从边缘到边缘的显示，请参阅 Compose 和 View 指南。

Для прогнозируемого возврата требуется миграция или отказ

对于以 Android 16（API 级别 36）或更高版本为目标平台且在搭载 Android 16 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不再调用 onBackPressed，也不再调度 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，但您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或者暂时选择停用，方法是在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false。

“返回主页”预测性返回动画。
预测性跨 activity 动画。
预测性跨任务动画。

API элегантных шрифтов устарели и отключены

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用，或针对以 Android 15（API 级别 35）为目标平台且通过将 elegantTextHeight 属性设置为 false 替换默认值的应用，
elegantTextHeight 行为。
以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其
elegantTextHeight 行为。

Основная функциональность

Android 16 (уровень API 36) включает в себя следующие изменения, которые изменяют или расширяют различные основные возможности системы Android.

Оптимизация графика работы с фиксированной ставкой

До ориентации на Android 16, когда scheduleAtFixedRate пропускало выполнение задачи из-за того, что оно находилось за пределами допустимого жизненного цикла процесса , все пропущенные выполнения выполнялись немедленно, когда приложение возвращалось к допустимому жизненному циклу.

При настройке Android 16 не более одного пропущенного выполнения scheduleAtFixedRate выполняется немедленно, когда приложение возвращается к допустимому жизненному циклу. Ожидается, что это изменение поведения улучшит производительность приложения. Проверьте это поведение в своем приложении, чтобы проверить, не затронуто ли оно ваше приложение. Вы также можете протестировать, используя платформу совместимости приложений и включив флаг совместимости STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS .

Форм-факторы устройств

Android 16 (уровень API 36) включает следующие изменения для приложений при отображении на устройствах с большим экраном.

Адаптивные макеты

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

Игнорировать ограничения по ориентации, изменению размера и соотношению сторон

Для приложений, ориентированных на Android 16 (API уровня 36), Android 16 включает изменения в управлении ограничениями ориентации, изменения размера и соотношения сторон. На дисплеях с минимальной шириной >= 600 dp эти ограничения больше не действуют. Приложения также заполняют всё окно дисплея, независимо от соотношения сторон или предпочитаемой пользователем ориентации, при этом эффект «пилларбоксинга» не используется.

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

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

Общие критические изменения

Игнорирование ограничений по ориентации, изменению размера и соотношению сторон может повлиять на пользовательский интерфейс вашего приложения на некоторых устройствах, особенно на элементы, разработанные для небольших макетов, заблокированных в портретной ориентации: например, могут возникнуть проблемы с растянутыми макетами, а также закадровой анимацией и компонентами. Любые предположения о соотношении сторон или ориентации могут привести к визуальным проблемам в вашем приложении. Узнайте больше о том, как их избежать и улучшить адаптивное поведение вашего приложения.

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

Подробности реализации

Следующие атрибуты манифеста и API среды выполнения игнорируются на устройствах с большим экраном в полноэкранном и многооконном режимах:

Следующие значения screenOrientation , setRequestedOrientation() и getRequestedOrientation() игнорируются:

  • portrait
  • reversePortrait
  • sensorPortrait
  • userPortrait
  • landscape
  • reverseLandscape
  • sensorLandscape
  • userLandscape

Что касается изменения размера дисплея, android:resizeableActivity="false" , android:minAspectRatio и android:maxAspectRatio не оказывают никакого влияния.

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

Исключения

Ограничения 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 (уровень API 36) включает следующие изменения, связанные с данными о здоровье и фитнесе.

Разрешения на здравоохранение и фитнес

Для приложений, ориентированных на Android 16 (уровень API 36) и выше, разрешения BODY_SENSORS используют более детальные разрешения в рамках android.permissions.health , которые также использует Health Connect . Начиная с Android 16, любой API, ранее требовавший BODY_SENSORS или BODY_SENSORS_BACKGROUND требует вместо этого соответствующего разрешения android.permissions.health . Это касается следующих типов данных, API и типов приоритетных служб:

Если ваше приложение использует эти API, оно должно запрашивать соответствующие детальные разрешения:

  • Для мониторинга частоты сердечных сокращений, SpO2 или температуры кожи во время использования: запросите детальное разрешение в android.permissions.health , например READ_HEART_RATE вместо BODY_SENSORS .
  • Для доступа к фоновому датчику: запросите READ_HEALTH_DATA_IN_BACKGROUND вместо BODY_SENSORS_BACKGROUND .

Эти разрешения аналогичны тем, которые защищают доступ к чтению данных из Health Connect — хранилища данных Android для здоровья, фитнеса и благополучия.

Мобильные приложения

Мобильные приложения, переходящие на использование READ_HEART_RATE и других детальных разрешений, также должны декларировать действие для отображения политики конфиденциальности приложения. Это требование аналогично Health Connect.

Связность

Android 16 (уровень API 36) включает следующие изменения в стеке Bluetooth для улучшения связи с периферийными устройствами.

Новые намерения в отношении убытков от облигаций и изменений в шифровании

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

  • 在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
  • 每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

  • 如果广播 ACTION_KEY_MISSING intent：

    系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

    您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

    如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。

  • 如果未广播 ACTION_KEY_MISSING intent：

    ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

    在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

Новый способ удаления связи Bluetooth

Все приложения, ориентированные на Android 16, теперь могут отключать сопряжение устройств Bluetooth с помощью общедоступного API в CompanionDeviceManager . Если сопутствующее устройство управляется как ассоциация CDM, то приложение может инициировать удаление связи Bluetooth с помощью нового API removeBond(int) на связанном устройстве. Приложение может отслеживать изменения состояния связи, прослушивая событие широковещательной передачи устройства Bluetooth ACTION_BOND_STATE_CHANGED .

Безопасность

Android 16 (уровень API 36) включает следующие изменения безопасности.

Блокировка версии MediaStore

Для приложений, предназначенных для Android 16 или более поздних версий, MediaStore#getVersion() теперь будет уникальным для каждого приложения. Это исключает идентификацию свойств из строки версии, чтобы предотвратить злоупотребление и использование методов снятия отпечатков пальцев. Приложения не должны делать никаких предположений относительно формата этой версии. Приложения уже должны обрабатывать изменения версий при использовании этого API, и в большинстве случаев им не нужно менять свое текущее поведение, если только разработчик не попытался получить дополнительную информацию, выходящую за рамки предполагаемой области действия этого API.

Более безопасные намерения

Функция Safer Intents — это многоэтапная инициатива безопасности, призванная повысить безопасность механизма разрешения намерений Android. Цель — защитить приложения от вредоносных действий путём добавления проверок при обработке намерений и фильтрации намерений, не соответствующих определённым критериям.

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

Реализуются два ключевых изменения:

  1. Явные намерения должны соответствовать фильтру намерений целевого компонента. Если намерение явно нацелено на компонент, оно должно соответствовать фильтру намерений этого компонента.

  2. Намерения без действия не могут соответствовать ни одному фильтру намерений: Намерения, для которых не указано действие, не должны разрешаться ни одним фильтром намерений.

Эти изменения применяются только в случае использования нескольких приложений и не влияют на обработку намерений в рамках одного приложения.

Влияние

Политика добровольного включения означает, что разработчики должны явно включить её в манифесте своего приложения, чтобы она вступила в силу. В результате влияние функции будет ограничено приложениями, разработчики которых:

  • Знают о функции Safer Intents и ее преимуществах.
  • Активно внедрять в свои приложения более строгие методы обработки намерений.

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

Хотя первоначальное влияние на Android 16 может быть ограниченным, инициатива Safer Intents имеет дорожную карту для более широкого применения в будущих версиях Android. Планируется в конечном итоге сделать строгое разрешение намерений поведением по умолчанию.

Функция Safer Intents может значительно повысить безопасность экосистемы Android, затруднив вредоносным приложениям использование уязвимостей в механизме разрешения намерений.

Однако переход к отказу от использования и обязательному применению должен тщательно контролироваться, чтобы исключить потенциальные проблемы совместимости с существующими приложениями.

Выполнение

Разработчикам необходимо явно включить более строгое сопоставление намерений с помощью атрибута intentMatchingFlags в манифесте приложения. Вот пример, где эта функция включена для всего приложения, но отключена/отключена для получателя:

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

Подробнее о поддерживаемых флагах:

Название флага Описание
EnsureIntentFilter Обеспечивает более строгое соответствие входящим намерениям
никто Отключает все специальные правила сопоставления для входящих намерений. При указании нескольких флагов конфликтующие значения разрешаются путём предоставления приоритета флагу «none».
allowNullAction Ослабляет правила сопоставления, позволяя сопоставлять намерения без действия. Этот флаг следует использовать вместе с «enforceIntentFilter» для достижения определённого поведения.

Тестирование и отладка

При включенном принудительном применении приложения должны работать корректно, если вызывающая сторона правильно заполнила намерение. Однако заблокированные намерения приведут к появлению предупреждений в журнале, таких как "Intent does not match component's intent filter:" и "Access blocked:" с тегом "PackageManager." Это указывает на потенциальную проблему, которая может повлиять на работу приложения и требует внимания.

Фильтр Logcat:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

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

Android 16 (уровень API 36) включает следующие изменения в политике конфиденциальности.

Разрешение локальной сети

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

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

План выпуска

Это изменение будет внедрено между двумя выпусками: 25-м кварталом 2020 года и 2021 года (будет объявлено позднее). Разработчикам крайне важно следовать этим рекомендациям во 2-м квартале 2020 года и делиться отзывами, поскольку эти меры защиты будут реализованы в более позднем выпуске Android . Кроме того, им необходимо будет обновить сценарии, зависящие от неявного доступа к локальной сети, следуя следующим рекомендациям, и подготовиться к отклонению и отзыву нового разрешения пользователем.

Влияние

На текущем этапе LNP — это функция, требующая согласия, что означает, что она будет затронута только приложения, которые согласились на её использование. Цель этапа согласия — дать разработчикам приложений понять, какие части их приложений зависят от неявного доступа к локальной сети, чтобы подготовиться к реализации защиты разрешений в следующем выпуске.

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

  • Прямое или библиотечное использование сырых сокетов на локальных сетевых адресах (например, протокол обнаружения сервисов mDNS или SSDP)
  • Использование классов уровня фреймворка, которые обращаются к локальной сети (например, NsdManager)

Для передачи трафика с адреса локальной сети и в обратном направлении требуется разрешение на доступ к локальной сети. В следующей таблице перечислены некоторые распространённые случаи:

Сетевые операции низкого уровня приложения Требуется разрешение локальной сети
Создание исходящего TCP-соединения да
Прием входящих TCP-соединений да
Отправка UDP-одноадресного, многоадресного, широковещательного сообщения да
Прием входящего UDP-одноадресного, многоадресного, широковещательного сообщения да

Эти ограничения реализованы глубоко в сетевом стеке и, следовательно, применяются ко всем сетевым API . Это включает в себя сокеты, созданные в нативном или управляемом коде, сетевые библиотеки, такие как Cronet и OkHttp, а также любые API, реализованные поверх них. Для разрешения служб в локальной сети (т.е. служб с суффиксом .local) потребуется разрешение локальной сети.

Исключения из правил, указанных выше:

  • Если DNS-сервер устройства находится в локальной сети, то для трафика к нему или с него (через порт 53) не требуется разрешение на доступ к локальной сети.
  • Приложениям, использующим Output Switcher в качестве встроенного средства выбора, не потребуются разрешения локальной сети (более подробные инструкции появятся в четвертом квартале 2025 года).

Руководство для разработчиков (по желанию)

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

  1. Перепрошейте устройство до сборки 25Q2 Beta 3 или более поздней.
  2. Установите приложение для тестирования.

  3. Переключить флаг Appcompat в adb:

    adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

  4. Перезагрузите устройство.

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

Чтобы восстановить доступ, необходимо предоставить приложению разрешение NEARBY_WIFI_DEVICES .

  1. Убедитесь, что приложение объявляет разрешение NEARBY_WIFI_DEVICES в своем манифесте.
  2. Откройте Настройки > Приложения > [Имя приложения] > Разрешения > Устройства поблизости > Разрешить .

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

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

Разрешение Исходящий запрос локальной сети Исходящий/входящий Интернет-запрос Входящий запрос локальной сети
Предоставленный Работы Работы Работы
Не предоставлено Неудачи Работы Неудачи

Используйте следующую команду, чтобы отключить флаг App-Compat.

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Ошибки

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

Примеры ошибок:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Определение локальной сети

Под локальной сетью в данном проекте понимается IP-сеть, которая использует сетевой интерфейс с возможностью широковещательной передачи, такой как Wi-Fi или Ethernet, но исключает сотовые (WWAN) или VPN-подключения.

Локальными сетями считаются:

IPv4:

  • 169.254.0.0/16 // Локальная ссылка
  • 100.64.0.0/10 // CGNAT
  • 10.0.0.0/8 // RFC1918
  • 172.16.0.0/12 // RFC1918
  • 192.168.0.0/16 // RFC1918

IPv6:

  • Локальная ссылка
  • Маршруты с прямым соединением
  • Заглушки сетей типа Thread
  • Несколько подсетей (TBD)

Кроме того, как многоадресные адреса (224.0.0.0/4, ff00::/8), так и широковещательный адрес IPv4 (255.255.255.255) классифицируются как адреса локальной сети.

Фотографии, принадлежащие приложению

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