Изменения поведения: все приложения

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

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

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

В Android 17 (уровень API 37) внесены следующие изменения, которые модифицируют или расширяют различные основные возможности системы Android.

Ограничения памяти приложения

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

Вы можете определить, повлияло ли это на работу вашего приложения, вызвав getDescription в ApplicationExitInfo ; если ваше приложение пострадало, причина завершения будет REASON_OTHER , а описание будет содержать строку "MemoryLimiter:AnonSwap" вместе с другой информацией. Вы также можете использовать профилирование на основе триггеров с TRIGGER_TYPE_ANOMALY для получения дампов кучи, которые собираются при достижении лимита памяти.

В разделе «Управление памятью вашего приложения» содержится информация, которая поможет вам диагностировать проблемы с памятью вашего приложения и оптимизировать потребление ресурсов.

Протестируйте работу вашего приложения с учетом ограничений по объему памяти.

Вы можете использовать Android Debug Bridge ( adb ) для настройки или отключения ограничений памяти на любом устройстве, которое их устанавливает. Команда оболочки am предоставляет три подкоманды для настройки ограничений памяти. (Эти команды не действуют на устройствах, которые не устанавливают ограничения памяти.)

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

Указывает ограничителю памяти игнорировать некоторые или все процессы. Передача UID (идентификатора пользователя Android) указывает ограничителю памяти игнорировать применение ограничений ко всем процессам, связанным с этим UID. Вы также можете передать all (игнорировать все приложения) или none (не игнорировать ни одно приложение). Передача none отменяет все предыдущие вызовы функции am memory-limiter ignore .

Если вы укажете ограничителю памяти игнорировать UID, вы все равно сможете применить ручное ограничение памяти к процессу внутри приложения, вызвав am memory-limiter manual .

manual

Указывает системе установить ограничение на использование памяти для процесса с указанным PID (идентификатором процесса). Ограничение на использование памяти указывается в виде целого числа в МБ; например, передача значения 30 означает, что процесс ограничен 30 МБ памяти. Передача значения max снимает все ограничения на использование памяти для этого процесса. Передача значения none снимает любые установленные вручную ограничения для процесса, восстанавливая ограничение по умолчанию (если таковое имеется).

status

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

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

В Android 17 внесены следующие изменения для повышения конфиденциальности пользователей.

Защита от SMS-уведомлений с одноразовым паролем (OTP)

从 Android 17 开始，Android 将扩大对包含一次性密码 (OTP) 的短信的保护范围。

在之前的 Android 版本中，此保护主要侧重于 SMS Retriever 格式。对于大多数应用，包含 SMS Retriever 哈希的消息的递送延迟了 3 小时。不过，某些应用（例如默认短信处理程序）不受此延迟的影响，拥有哈希的应用也不受此延迟的影响。

从 Android 17 开始，此保护也适用于 WebOTP 格式的消息。如果应用有权读取短信，但不是 WebOTP 消息的预期接收者（由网域验证确定），则该应用在收到消息后 3 小时内无法访问该消息。此变更旨在提高用户安全性，确保只有与消息中提及的网域关联的应用才能以编程方式读取验证码。

在这 3 小时的延迟期间，系统会保留 SMS_RECEIVED_ACTION 广播，并过滤 短信提供商 数据库查询。延迟结束后，这些应用即可使用短信。此变更适用于 所有应用，无论其目标 API 级别如何。

某些应用（例如默认短信助理应用、关联设备配套应用等）不受此延迟的影响。所有依赖于读取短信 来提取 OTP 的应用都应过渡到使用 SMS Retriever 或 SMS User Consent API，以确保功能持续可用。

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

В Android 17 включены следующие улучшения безопасности устройств и приложений.

используется план амортизации ClearTraffic

我们计划在未来的版本中弃用 usesCleartextTraffic 元素。需要建立未加密 (HTTP) 连接的应用应迁移为使用网络安全配置文件，该文件可让您指定应用需要与哪些网域建立明文连接。

请注意，网络安全配置文件仅在 API 级别 24 及更高版本中受支持。如果您的应用的最低 API 级别低于 24，您应执行以下两项操作：

  • 将 usesCleartextTraffic 属性设置为 true
  • 使用网络配置文件

如果应用的最低 API 级别为 24 或更高，您可以使用网络配置文件，而无需设置 usesCleartextTraffic。

Ограничить неявные URI-гранты

目前，如果应用启动的 intent 具有 URI，且该 URI 具有操作 ACTION_SEND、ACTION_SEND_MULTIPLE或 ACTION_IMAGE_CAPTURE，则系统会自动向目标应用授予读取和 写入 URI 权限。从 Android 18 开始，系统将 不再自动授予这些权限。因此，我们建议应用明确授予相关 URI 权限，而不是依赖系统授予这些权限。

如需检测应用中这些 intent 的使用情况，请将 StrictMode 与 detectImplicitUriPermissionGrant() 结合使用，以触发违规行为：

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

或者，您也可以监控包含消息 Please set the grant explicitly in the app 的已记录异常，该消息会在系统隐式设置授予时显示。您可以使用以下 adb 命令监控这些日志：

adb logcat | grep "Please set the grant explicitly in the app"

如需明确授予必要的权限，请将 FLAG_GRANT_READ_URI_PERMISSION标志添加到ACTION_SEND和 ACTION_SEND_MULTIPLEintent：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

对于 ACTION_IMAGE_CAPTURE intent，请同时添加FLAG_GRANT_READ_URI_PERMISSION 和 FLAG_GRANT_WRITE_URI_PERMISSION 标志：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Ограничения на хранилище ключей для каждого приложения

Приложениям следует избегать создания чрезмерного количества ключей в Android Keystore, поскольку это общий ресурс для всех приложений на устройстве. Начиная с Android 17, система устанавливает ограничение на количество ключей, которыми может владеть приложение. Лимит составляет 50 000 ключей для приложений, не являющихся системными и ориентированных на Android 17 (уровень API 37) или выше, и 200 000 ключей для всех остальных приложений. Для системных приложений установлен лимит в 200 000 ключей, независимо от того, на какой уровень API они ориентированы.

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

  • Приложения, ориентированные на Android 17 (уровень API 37) или выше: getNumericErrorCode() возвращает новое значение ERROR_TOO_MANY_KEYS .
  • Для всех остальных приложений: getNumericErrorCode() возвращает ERROR_INCORRECT_USAGE .

Блокировка трафика обратной связи между профилями.

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

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

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

Восстановление видимости IME по умолчанию после поворота экрана.

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

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

  • Установите атрибут android:windowSoftInputMode в значение stateAlwaysVisible .
  • Запросите экранную клавиатуру программным способом в методе onCreate() вашего Activity или добавьте метод onConfigurationChanged() .

Вклад человека

В Android 17 внесены следующие изменения, влияющие на взаимодействие приложений с устройствами ввода, такими как клавиатуры и сенсорные панели.

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

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

Ранее система не пыталась распознавать жесты с тачпада, а вместо этого передавала приложению необработанные абсолютные координаты пальцев в формате, аналогичном касаниям сенсорного экрана. Если приложению по-прежнему требуются эти абсолютные данные, оно должно вызывать новый метод View.requestPointerCapture(int) с View.POINTER_CAPTURE_MODE_ABSOLUTE .

СМИ

В Android 17 внесены следующие изменения в работу с мультимедиа.

Фоновое усиление защиты звука

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

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

Для получения дополнительной информации, включая стратегии смягчения последствий, см. раздел «Усиление защиты фонового звука» .

Подключение

В Android 17 внесены следующие изменения для улучшения возможностей подключения устройств.

Автономное повторное сопряжение при потере соединения Bluetooth

В Android 17 появилась функция автономного повторного сопряжения — системное улучшение, предназначенное для автоматического устранения потери соединения Bluetooth.

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

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

  • Новый контекст сопряжения: теперь параметр ACTION_PAIRING_REQUEST включает дополнительный параметр EXTRA_PAIRING_CONTEXT , который позволяет приложениям различать стандартный запрос на сопряжение и попытку повторного сопряжения, инициированную автономной системой.
  • Условное обновление ключей: существующие ключи безопасности будут заменены только в том случае, если повторное сопряжение пройдет успешно и новое соединение будет соответствовать или превосходить уровень безопасности предыдущего соединения.
  • Изменена синхронизация интента: теперь интент ACTION_KEY_MISSING передается только в том случае, если попытка автономного повторного сопряжения не удалась. Это уменьшает ненужную обработку ошибок в приложении, если система успешно восстанавливает соединение в фоновом режиме.
  • Уведомление пользователя: Система управляет повторным сопряжением посредством новых уведомлений и диалоговых окон пользовательского интерфейса. Пользователям будет предложено подтвердить попытку повторного сопряжения, чтобы убедиться, что они осведомлены о повторном подключении.

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

  • Вручную удалите информацию о соединении из периферийного устройства.
  • Отключите устройство вручную в разделе: Настройки > Подключенные устройства