Изменения поведения: приложения для Android 17 и выше

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

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

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

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

Новая реализация MessageQueue без блокировок

Beginning with Android 17, apps targeting Android 17 (API level 37) or higher receive a new lock-free implementation of android.os.MessageQueue. The new implementation improves performance and reduces missed frames, but may break clients that reflect on MessageQueue private fields and methods.

For more information, including mitigation strategies, see MessageQueue behavior change guidance.

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

Приложения, работающие на Android 17 или выше и ориентированные на Android 17 (уровень API 37) или выше, не могут изменять static final поля. Если приложение попытается изменить static final поле с помощью рефлексии, это вызовет исключение IllegalAccessException . Попытка изменить одно из этих полей через API JNI (например, SetStaticLongField() ) приведет к сбою приложения.

Доступность

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

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

This feature introduces new AccessibilityEvent and TextAttribute APIs to enhance screen reader spoken feedback for CJKV language input. CJKV IME apps can now signal whether a text conversion candidate has been selected during text composition. Apps with edit fields can specify text change types when sending text changed accessibility events. For example, apps can specify that a text change occurred during text composition, or that a text change resulted from a commit. Doing this enables accessibility services such as screen readers to deliver more precise feedback based on the nature of the text modification.

App adoption

  • IME Apps: When setting composing text in edit fields, IMEs can use TextAttribute.Builder.setTextSuggestionSelected() to indicate whether a specific conversion candidate was selected.

  • Apps with Edit Fields: Apps that maintain a custom InputConnection can retrieve candidate selection data by calling TextAttribute.isTextSuggestionSelected(). These apps should then call AccessibilityEvent.setTextChangeTypes() when dispatching TYPE_VIEW_TEXT_CHANGED events. Apps targeting Android 17 (API level 37) that use the standard TextView will have this feature enabled by default. (That is, TextView will handle retrieving data from the IME and setting text change types when sending events to accessibility services).

  • Accessibility Services: Accessibility services that process TYPE_VIEW_TEXT_CHANGED events can call AccessibilityEvent.getTextChangeTypes() to identify the nature of the modification and adjust their feedback strategies accordingly.

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

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

Включена функция ECH (Encrypted Client Hello).

В Android 17 появилась поддержка технологии Encrypted Client Hello (ECH), расширения TLS, повышающего конфиденциальность пользователей за счет шифрования Server Name Indication (SNI) в процессе установления соединения TLS. Это шифрование помогает предотвратить легкое определение сетевыми наблюдателями конкретного домена, к которому подключается ваше приложение.

Для приложений, ориентированных на Android 17 (уровень API 37) или выше, для TLS-соединений используется ECH. ECH активен только в том случае, если используемая приложением сетевая библиотека (например, HttpEngine, WebView или OkHttp) имеет встроенную поддержку ECH, а удаленный сервер также поддерживает протокол ECH. Если установить ECH не удается, клиент отправляет расширение ECH со случайным содержимым (механизм, называемый ECH GREASE). Подробнее о работе ECH GREASE см. в RFC 9849 .

Чтобы позволить приложениям настраивать это поведение, Android 17 добавляет новый элемент <domainEncryption> в файл конфигурации сетевой безопасности. Разработчики могут использовать <domainEncryption> внутри тегов <base-config> или <domain-config> для выбора режима шифрования доменных имен (например, "enabled" или "disabled" ) на глобальном уровне или для каждого домена отдельно.

Для получения более подробной информации см. документацию по протоколу Encrypted Client Hello .

Для приложений, ориентированных на Android 17, требуется разрешение на доступ к локальной сети.

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

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

Для получения более подробной информации см. документацию по правам доступа в локальной сети .

Скрытие паролей с физических устройств

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

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

Если пользователь использует сенсорный экран устройства, система применяет новую настройку show_passwords_touch .

Защита от одноразового пароля (OTP) для стандартных SMS-сообщений

Beginning with Android 17, Android is extending its SMS OTP protection to apply to standard SMS messages (SMS messages containing an OTP that do not use the WebOTP or SMS Retriever formats). For most apps targeting Android 17 (API level 37) or higher, these SMS messages do not become available until three hours after receipt. This delay is intended to help prevent OTP hijacking. During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

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

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

Безопасность деятельности

In Android 17, the platform continues its shift toward a "secure-by-default" architecture, introducing a suite of enhancements designed to mitigate high-severity exploits such as phishing, interaction hijacking, and confused deputy attacks. This update requires developers to explicitly opt in to new security standards to maintain app compatibility and user protection.

Key impacts for developers include:

  • BAL hardening & improved opt-in: We are refining Background Activity Launch (BAL) restrictions by extending protections to IntentSender. Developers must migrate away from the legacy MODE_BACKGROUND_ACTIVITY_START_ALLOWED constant. Instead, you should adopt granular controls like MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, which restricts activity starts to scenarios where the calling app is visible, significantly reducing the attack surface.
  • Adoption tools: Developers should utilize strict mode and updated lint checks to identify legacy patterns and ensure readiness for future target SDK requirements.

Включить КТ по ​​умолчанию

If an app targets Android 17 (API level 37) or higher, certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)

Более безопасный коренной DCL—C

Если ваше приложение ориентировано на Android 17 (уровень API 37) или выше, то защита Safer Dynamic Code Loading (DCL), представленная в Android 14 для файлов DEX и JAR, теперь распространяется и на нативные библиотеки.

Все файлы, загружаемые с помощью System.load() должны быть помечены как доступные только для чтения. В противном случае система выдаст UnsatisfiedLinkError .

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

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

Для приложений, ориентированных на Android 17 (уровень API Android 17 (уровень API 37)) и выше, Contacts Provider 2 (CP2) ограничивает отображение данных в определенных столбцах, содержащих персональные данные. При включении этой функции данные в этих столбцах удаляются для повышения конфиденциальности пользователей. К ограниченным столбцам относятся:

Приложения, использующие эти столбцы из ContactsContract.Data , могут извлекать их из ContactsContract.RawContacts , объединяя данные с помощью RAW_CONTACT_ID .

Внедрить строгие проверки SQL в CP2

For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) enforces strict SQL query validation when the ContactsContract.Data table is accessed without READ_CONTACTS permission.

With this change, if an app doesn't have READ_CONTACTS permission, StrictColumns and StrictGrammar options are set when querying the ContactsContract.Data table. If a query uses a pattern that isn't compatible with these, it will be rejected and cause an exception to be thrown.

СМИ

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

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

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

Некоторые ограничения на воспроизведение звука распространяются на все приложения. Однако ограничения более строгие, если приложение ориентировано на Android 17 (уровень API 37). Если такое приложение взаимодействует со звуком в фоновом режиме, у него должна быть запущена служба переднего плана. Кроме того, приложение должно соответствовать одному или обоим из следующих требований:

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

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

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

Изменения в API платформы позволяют игнорировать ограничения по ориентации, масштабируемости и соотношению сторон на больших экранах (sw>=600dp).

В Android 16 мы внесли изменения в Platform API, позволяющие игнорировать ограничения по ориентации, соотношению сторон и масштабируемости на больших экранах (sw >= 600dp) для приложений, ориентированных на API уровня 36 или выше. Разработчики могут отказаться от этих изменений в SDK 36, но эта возможность больше не будет доступна для приложений, ориентированных на Android 17 (API уровня 37) или выше.

Для получения дополнительной информации см. раздел «Ограничения на ориентацию и изменение размера игнорируются» .

Подключение

В Android 17 внесены следующие изменения для повышения согласованности и соответствия стандартному поведению Java InputStream для Bluetooth RFCOMM-сокетов.

Последовательное поведение функции чтения BluetoothSocket для RFCOMM

For apps targeting Android 17 (API level 37), the read() method of the InputStream obtained from an RFCOMM-based BluetoothSocket now returns -1 when the socket is closed or the connection is dropped.

This change makes RFCOMM socket behavior consistent with LE CoC sockets and aligns with the standard InputStream.read() documentation, which states that -1 is returned when the end of the stream is reached.

Apps that rely solely on catching an IOException to break out of a read loop may be impacted by this change and should update the BluetoothSocket read loops to explicitly check for a return value of -1. This ensures the loop terminates correctly when the remote device disconnects or the socket is closed. For an example of the recommended implementation, see the code snippet in the Transfer Bluetooth data guide.