Как и в предыдущих версиях, Android 17 включает изменения в поведении, которые могут повлиять на ваше приложение. Следующие изменения в поведении применяются исключительно к приложениям, ориентированным на Android 17 или более поздние версии. Если ваше приложение ориентировано на Android 17 или более поздние версии, вам следует внести в него изменения для поддержки этих изменений, где это применимо.
Обязательно ознакомьтесь также со списком изменений в поведении, которые затрагивают все приложения, работающие на Android 17, независимо от targetSdkVersion вашего приложения.
Основная функциональность
В Android 17 внесены следующие изменения, которые модифицируют или расширяют различные основные возможности системы Android.
Новая реализация MessageQueue без блокировок
Начиная с Android 17, приложения, ориентированные на Android 17 (уровень API 37) или выше, получают новую реализацию android.os.MessageQueue без блокировок. Новая реализация повышает производительность и уменьшает количество пропущенных кадров, но может нарушить работу клиентов, которые используют закрытые поля и методы MessageQueue для рефлексии.
Для получения дополнительной информации, включая стратегии смягчения последствий, см. руководство по изменению поведения в MessageQueue .
Статические поля, являющиеся окончательными, теперь не подлежат изменению.
Apps running on Android 17 or higher that target
Android 17 (API level 37) or higher cannot change static final fields. If
an app attempts to change a static final field by using reflection, it will
cause an IllegalAccessException. Attempting to modify one of these fields
through JNI APIs (such as SetStaticLongField()) will cause the app to crash.
Доступность
В 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
InputConnectioncan retrieve candidate selection data by callingTextAttribute.isTextSuggestionSelected(). These apps should then callAccessibilityEvent.setTextChangeTypes()when dispatchingTYPE_VIEW_TEXT_CHANGEDevents. Apps targeting Android 17 (API level 37) that use the standardTextViewwill have this feature enabled by default. (That is,TextViewwill 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_CHANGEDevents can callAccessibilityEvent.getTextChangeTypes()to identify the nature of the modification and adjust their feedback strategies accordingly.
Конфиденциальность
В Android 17 внесены следующие изменения для повышения конфиденциальности пользователей.
Включена функция ECH (Encrypted Client Hello).
Android 17 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.
For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the client sends an ECH extension with randomized contents (a mechanism called ECH GREASE). See RFC 9849 for more details on how ECH GREASE works.
To allow apps to customize this behavior, Android 17 adds a new
<domainEncryption> element to the Network Security Configuration file.
Developers can use <domainEncryption> within <base-config> or
<domain-config> tags to select an ECH mode (for example,
"enabled" or "disabled") on a global or per-domain basis.
For more information, see the Encrypted Client Hello documentation.
Для приложений, ориентированных на 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 legacyMODE_BACKGROUND_ACTIVITY_START_ALLOWEDconstant. Instead, you should adopt granular controls likeMODE_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.
Включить КТ по умолчанию
Если приложение ориентировано на Android 17 (уровень API 37) или выше, прозрачность сертификатов (CT) включена по умолчанию. (На Android 16 прозрачность сертификатов доступна, но приложениям приходилось включать её вручную .)
Более безопасный коренной DCL—C
Если ваше приложение ориентировано на Android 17 (уровень API 37) или выше, то защита Safer Dynamic Code Loading (DCL), представленная в Android 14 для файлов DEX и JAR, теперь распространяется и на нативные библиотеки.
Все файлы, загружаемые с помощью System.load() должны быть помечены как доступные только для чтения. В противном случае система выдаст UnsatisfiedLinkError .
Мы рекомендуем приложениям по возможности избегать динамической загрузки кода, поскольку это значительно увеличивает риск взлома приложения путем внедрения или изменения кода.
Ограничение доступа к полям, содержащим персональные данные, в представлении данных CP2.
For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) restricts certain columns containing Personally Identifiable Information (PII) from the data view. When this change is enabled, these columns are removed from the data view to enhance user privacy. The restricted columns include:
Apps that are using these columns from ContactsContract.Data
can extract them from ContactsContract.RawContacts
instead, by joining with RAW_CONTACT_ID.
Внедрить строгие проверки SQL в CP2
Для приложений, ориентированных на Android 17 (уровень API Android 17 (уровень API 37)) и выше, Contacts Provider 2 (CP2) обеспечивает строгую проверку SQL-запросов при обращении к таблице ContactsContract.Data без разрешения READ_CONTACTS .
Благодаря этому изменению, если у приложения нет разрешения READ_CONTACTS , при запросе к таблице ContactsContract.Data устанавливаются параметры StrictColumns и StrictGrammar . Если запрос использует шаблон, несовместимый с этими параметрами, он будет отклонен, и будет выброшено исключение.
СМИ
В Android 17 внесены следующие изменения в работу с мультимедиа.
Фоновое усиление защиты звука
Начиная с Android 17, аудиофреймворк вводит ограничения на фоновые взаимодействия со звуком, включая воспроизведение аудио, запросы на фокусировку на аудио и API изменения громкости, чтобы гарантировать, что эти изменения инициируются пользователем осознанно.
Некоторые ограничения на воспроизведение звука распространяются на все приложения. Однако ограничения более строгие, если приложение ориентировано на Android 17 (уровень API 37). Если такое приложение взаимодействует со звуком в фоновом режиме, у него должна быть запущена служба переднего плана. Кроме того, приложение должно соответствовать одному или обоим из следующих требований:
- Сервис переднего плана должен обладать возможностью мониторинга во время использования (WIU).
- Приложение должно иметь точно такие же разрешения для будильника и взаимодействовать с аудиопотоками
USAGE_ALARM.
Для получения дополнительной информации, включая стратегии смягчения последствий, см. раздел «Усиление защиты фонового звука» .
форм-факторы устройств
В 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
Для приложений, ориентированных на Android 17 (уровень API 37), метод read() объекта InputStream , полученного из BluetoothSocket на основе RFCOMM, теперь возвращает -1 когда сокет закрывается или соединение разрывается.
Это изменение приводит поведение сокета RFCOMM в соответствие с сокетами LE CoC и согласуется со стандартной документацией InputStream.read() , в которой указано, что при достижении конца потока возвращается значение -1 .
Приложения, которые полагаются исключительно на перехват исключения IOException для выхода из цикла чтения, могут быть затронуты этим изменением и должны обновить циклы чтения BluetoothSocket, чтобы явно проверять возвращаемое значение -1 . Это гарантирует корректное завершение цикла при отключении удаленного устройства или закрытии сокета. Пример рекомендуемой реализации см. в фрагменте кода в руководстве по передаче данных Bluetooth .