Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Modifications de comportement : applications ciblant Android 17 ou version ultérieure

Comme les versions précédentes, Android 17 apporte des modifications de comportement pouvant affecter votre application. Les modifications de comportement suivantes s'appliquent exclusivement aux applications qui ciblent Android 17 ou version ultérieure. Si votre application cible Android 17 ou une version ultérieure, vous devez la modifier pour qu'elle prenne en charge ces comportements, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui affectent toutes les applications exécutées sur Android 17, peu importe la targetSdkVersion de votre application.

Fonctionnalité de base

Android 17 inclut les modifications suivantes qui modifient ou étendent diverses fonctionnalités de base du système Android.

Nouvelle implémentation sans verrouillage de 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.

Les champs statiques finals ne sont plus modifiables

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.

Accessibilité

Android 17 apporte les modifications suivantes pour améliorer l'accessibilité.

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.

Confidentialité

Android 17 inclut les modifications suivantes pour améliorer la confidentialité des utilisateurs.

Activation d'ECH (Encrypted Client Hello)

Android 17 introduit la compatibilité de la plate-forme avec Encrypted Client Hello (ECH), une extension TLS qui renforce la confidentialité des utilisateurs en chiffrant l'indication du nom du serveur (SNI) dans le handshake TLS. Ce chiffrement permet d'empêcher les observateurs du réseau d'identifier facilement le domaine spécifique auquel votre application se connecte.

Pour les applications ciblant Android 17 (niveau d'API 37) ou version ultérieure, ECH est utilisé pour les connexions TLS. ECH n'est actif que si la bibliothèque réseau utilisée par l'application (par exemple, HttpEngine, WebView ou OkHttp) a intégré la prise en charge d'ECH et que le serveur distant prend également en charge le protocole ECH. Si la négociation ECH n'est pas possible, le client envoie une extension ECH avec un contenu aléatoire (un mécanisme appelé ECH GREASE). Pour en savoir plus sur le fonctionnement d'ECH GREASE, consultez la norme RFC 9849.

Pour permettre aux applications de personnaliser ce comportement, Android 17 ajoute un nouvel élément <domainEncryption> au fichier de configuration de la sécurité réseau. Les développeurs peuvent utiliser <domainEncryption> dans les balises <base-config> ou <domain-config> pour sélectionner un mode ECH (par exemple, "enabled" ou "disabled") au niveau global ou par domaine.

Pour en savoir plus, consultez la documentation Encrypted Client Hello.

Autorisation de réseau local requise pour les applications ciblant Android 17

Android 17 introduit l'autorisation d'exécution ACCESS_LOCAL_NETWORK pour protéger les utilisateurs contre les accès non autorisés au réseau local. Étant donné que cela relève du groupe d'autorisations NEARBY_DEVICES existant, les utilisateurs qui ont déjà accordé d'autres autorisations NEARBY_DEVICES ne sont pas à nouveau invités à le faire. Cette nouvelle exigence empêche les applications malveillantes d'exploiter l'accès illimité au réseau local pour le suivi des utilisateurs et le fingerprinting secrets. En déclarant et en demandant cette autorisation, votre application peut découvrir des appareils sur le réseau local (LAN), tels que des appareils connectés ou des récepteurs de diffusion, et s'y connecter.

Les applications ciblant Android 17 (niveau d'API 37) ou version ultérieure ont désormais deux façons de maintenir la communication avec les appareils du réseau local : adopter des sélecteurs d'appareils protégeant la confidentialité et gérés par le système pour éviter l'invite d'autorisation, ou demander explicitement cette nouvelle autorisation au moment de l'exécution pour maintenir la communication sur le réseau local.

Pour en savoir plus, consultez la documentation sur l'autorisation du réseau local.

Masquage des mots de passe sur les appareils physiques

Si une application cible Android 17 (niveau d'API 37) ou une version ultérieure et que l'utilisateur utilise un périphérique d'entrée physique (par exemple, un clavier externe), le système d'exploitation Android applique le nouveau paramètre show_passwords_physical à tous les caractères du champ de mot de passe. Par défaut, ce paramètre masque tous les caractères du mot de passe.

Le système Android affiche le dernier caractère du mot de passe saisi pour aider l'utilisateur à voir s'il a fait une erreur de frappe. Toutefois, cela est beaucoup moins nécessaire avec les grands claviers externes. De plus, les appareils dotés de claviers externes ont souvent des écrans plus grands, ce qui augmente le risque que quelqu'un voie le mot de passe saisi.

Si l'utilisateur utilise l'écran tactile de l'appareil, le système applique le nouveau paramètre show_passwords_touch.

Protection OTP pour les messages SMS standards

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.

Sécurité

Android 17 apporte les améliorations suivantes à la sécurité des appareils et des applications.

Sécurité des activités

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.

Activation de CT par défaut

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 natif plus sûr : C

If your app targets Android 17 (API level 37) or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries.

All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError.

We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.

Limitation des champs d'informations personnelles dans la vue de données 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.

Application de vérifications SQL strictes dans CP2

Pour les applications ciblant Android 17 (niveau d'API 37) ou version ultérieure, Contacts Provider 2 (CP2) applique une validation stricte des requêtes SQL lorsque la table ContactsContract.Data est consultée sans l'autorisation READ_CONTACTS.

Avec ce changement, si une application ne dispose pas de l'autorisation READ_CONTACTS, les options StrictColumns et StrictGrammar sont définies lors de l'interrogation de la table ContactsContract.Data. Si une requête utilise un modèle qui n'est pas compatible avec ceux-ci, elle sera refusée et une exception sera générée.

Contenus multimédias

Android 17 inclut les modifications suivantes concernant le comportement des contenus multimédias.

Renforcement de l'audio en arrière-plan

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

Some audio restrictions apply to all apps. However, the restrictions are more stringent if an app targets Android 17 (API level 37). If one of these apps interacts with audio while it is in the background, it must have a foreground service running. In addition, the app must meet one or both of these requirements:

The foreground service must have while-in-use (WIU) capabilities.
The app must have the exact alarm permission and be interacting with USAGE_ALARM audio streams.

For more information, including mitigation strategies, see Background audio hardening.

Facteurs de forme d'appareil

Android 17 inclut les modifications suivantes pour améliorer l'expérience utilisateur sur une gamme de tailles et de facteurs de forme d'appareils.

Modifications de l'API de la plate-forme pour ignorer les contraintes d'orientation, de redimensionnement et de format sur les grands écrans (sw>=600dp)

We introduced Platform API changes in Android 16 to ignore orientation, aspect ratio, and resizability restrictions on large screens (sw >= 600dp) for apps targeting API level 36 or higher. Developers have the option to opt out of these changes with SDK 36, but this opt-out will no longer be available for apps that target Android 17 (API level 37) or higher.

For more information, see Restrictions on orientation and resizability are ignored.

Connectivité

Android 17 introduit la modification suivante pour améliorer la cohérence et s'aligner sur le comportement standard InputStream Java pour les sockets RFCOMM Bluetooth.

Comportement cohérent de BluetoothSocket read() pour 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.