Платформа 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 Studio Panda добавляет интеграцию с LeakCanary непосредственно в профилировщик Android Studio в виде отдельной задачи, контекстуализированной в рамках IDE и полностью интегрированной с вашим исходным кодом.
Конфиденциальность
В Android 17 внесены следующие изменения для повышения конфиденциальности пользователей.
Защита от SMS-уведомлений с одноразовым паролем (OTP)
Начиная с Android 17, Android расширяет защиту SMS-сообщений, содержащих одноразовые пароли (OTP).
В предыдущих версиях Android эта защита в основном касалась формата SMS Retriever. Доставка сообщений, содержащих хеш SMS Retriever, задерживалась для большинства приложений на три часа. Однако некоторые приложения (например, обработчик SMS по умолчанию) были освобождены от этой задержки, и приложение, которому принадлежал хеш, также было исключено из нее.
Начиная с Android 17, защита распространяется также на сообщения в формате WebOTP. Если приложение имеет разрешение на чтение SMS-сообщений, но не является предполагаемым получателем сообщения WebOTP (как это определяется проверкой домена), сообщение не будет доступно приложению в течение трех часов после его получения. Это изменение призвано повысить безопасность пользователей, гарантируя, что только приложения, связанные с доменом, указанным в сообщении, могут программно прочитать код подтверждения.
В течение этой трехчасовой задержки широковещательная рассылка SMS_RECEIVED_ACTION приостанавливается, а запросы к базе данных поставщика SMS фильтруются. SMS-сообщение становится доступно этим приложениям после истечения задержки. Это изменение применяется ко всем приложениям , независимо от их целевого уровня API.
Некоторые приложения, такие как стандартное приложение-помощник для SMS, сопутствующие приложения для подключенных устройств и т. д., не подпадают под действие этой задержки. Всем приложениям, которые используют чтение SMS-сообщений для извлечения OTP, следует перейти на использование API SMS Retriever или SMS User Consent для обеспечения непрерывной работы.
Безопасность
В Android 17 включены следующие улучшения безопасности устройств и приложений.
используется план амортизации ClearTraffic
В одном из будущих релизов мы планируем отказаться от элемента usesCleartextTraffic . Приложениям, которым необходимо устанавливать незашифрованные (HTTP) соединения, следует перейти на использование файла конфигурации сетевой безопасности , который позволяет указывать, к каким доменам ваше приложение должно устанавливать соединения в открытом виде.
Обратите внимание, что файлы конфигурации сетевой безопасности поддерживаются только для уровней API 24 и выше. Если минимальное значение API вашего приложения ниже 24, вам следует выполнить оба следующих действия:
- Установите атрибут
usesCleartextTrafficвtrue - Используйте файл конфигурации сети.
Если минимальный уровень API вашего приложения равен 24 или выше, вы можете использовать файл сетевой конфигурации, и вам не нужно устанавливать параметр usesCleartextTraffic .
Ограничить неявные URI-гранты
В настоящее время, если приложение запускает интент с URI, содержащим действие ACTION_SEND , ACTION_SEND_MULTIPLE или ACTION_IMAGE_CAPTURE , система автоматически предоставляет целевому приложению права на чтение и запись по этому URI. Начиная с Android 18, система больше не будет автоматически предоставлять эти разрешения. По этой причине мы рекомендуем приложениям явно предоставлять соответствующие разрешения для URI, а не полагаться на систему в этом вопросе.
Чтобы обнаружить использование этих интентов в вашем приложении, используйте StrictMode с detectImplicitUriPermissionGrant() для запуска проверки на нарушение:
Котлин
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_MULTIPLE :
Котлин
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
Java
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
Для интентов ACTION_IMAGE_CAPTURE необходимо включить флаги FLAG_GRANT_READ_URI_PERMISSION и FLAG_GRANT_WRITE_URI_PERMISSION :
Котлин
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);
Ограничения на хранилище ключей для каждого приложения
Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.
If an app attempts to create keys beyond the limit, the creation fails with a
KeyStoreException. The exception's message string contains information
about the key limit. If the app calls getNumericErrorCode() on the
exception, the return value depends on what API level the app targets:
- Apps targeting Android 17 (API level 37) or higher:
getNumericErrorCode()returns the newERROR_TOO_MANY_KEYSvalue. - All other apps:
getNumericErrorCode()returnsERROR_INCORRECT_USAGE.
Блокировка трафика обратной связи между профилями.
Beginning with Android 17, cross-profile loopback traffic is no longer permitted by default. Loopback traffic within the same profile is not affected. This change applies to all apps running on Android 17 or higher, regardless of what API level the app targets.
Пользовательский опыт и пользовательский интерфейс системы
В Android 17 внесены следующие изменения, призванные обеспечить более согласованный и интуитивно понятный пользовательский интерфейс.
Восстановление видимости IME по умолчанию после поворота экрана.
Beginning with Android 17, when the device's configuration changes (for example, through rotation), and this is not handled by the app itself, the previous IME visibility is not restored.
If your app undergoes a configuration change that it does not handle, and the app needs the keyboard to be visible after the change, you must explicitly request this. You can make this request in one of the following ways:
- Set the
android:windowSoftInputModeattribute tostateAlwaysVisible. - Programmatically request the soft keyboard in your activity's
onCreate()method, or add theonConfigurationChanged()method.
Вклад человека
В Android 17 внесены следующие изменения, влияющие на взаимодействие приложений с устройствами ввода, такими как клавиатуры и сенсорные панели.
Сенсорные панели по умолчанию передают относительные события во время захвата указателя.
Beginning with Android 17, if an app requests pointer capture using
View.requestPointerCapture() and the user uses a touchpad, the system
recognizes pointer movement and scrolling gestures from the user's touches and
reports them to the app in the same way as pointer and scroll wheel movements
from a captured mouse. In most cases, this removes the need for apps that
support captured mice to add special handling logic for touchpads. For more
details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.
Previously, the system did not attempt to recognize gestures from the touchpad,
and instead delivered the raw, absolute finger locations to the app in a similar
format to touchscreen touches. If an app still requires this absolute data, it
should call the new View.requestPointerCapture(int) method with
View.POINTER_CAPTURE_MODE_ABSOLUTE instead.
СМИ
В 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передается только в том случае, если попытка автономного повторного сопряжения не удалась. Это уменьшает ненужную обработку ошибок в приложении, если система успешно восстанавливает соединение в фоновом режиме. - Уведомление пользователя: Система управляет повторным сопряжением посредством новых уведомлений и диалоговых окон пользовательского интерфейса. Пользователям будет предложено подтвердить попытку повторного сопряжения, чтобы убедиться, что они осведомлены о повторном подключении.
Производители периферийных устройств и разработчики сопутствующих приложений должны убедиться, что оборудование и приложение корректно обрабатывают переходы между состояниями соединения. Для проверки этого поведения смоделируйте удаленную потерю соединения, используя один из следующих методов:
- Вручную удалите информацию о соединении из периферийного устройства.
- Отключите устройство вручную в разделе: Настройки > Подключенные устройства