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 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, quel que soit le targetSdkVersion de votre application.

Expérience utilisateur et UI du système

Android 17 inclut les modifications suivantes, qui visent à créer une expérience utilisateur plus cohérente et intuitive.

À partir d'Android 17, pour les applications ciblant Android 17 (niveau d'API 37) ou version ultérieure, le système applique une limite de mémoire stricte (1,5 * largeur de l'écran * hauteur de l'écran * 4) à l'utilisation combinée de la mémoire des bitmaps et des icônes présents dans le bundle RemoteViews. Le dépassement de ces limites génère une erreur fatale IllegalArgumentException et provoque l'arrêt du processus de l'application.

Pour en savoir plus, consultez UpdateAppWidget.

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 verrou de MessageQueue

À partir d'Android 17, les applications ciblant Android 17 (niveau d'API 37) ou version ultérieure reçoivent une nouvelle implémentation sans verrouillage de android.os.MessageQueue. La nouvelle implémentation améliore les performances et réduit les images manquantes, mais peut casser les clients qui réfléchissent sur les champs et méthodes privés MessageQueue.

Pour en savoir plus, y compris sur les stratégies d'atténuation, consultez le guide sur les changements de comportement de MessageQueue.

Les champs finaux statiques ne sont plus modifiables

Les applications exécutées sur Android 17 ou version ultérieure qui ciblent Android 17 (niveau d'API 37) ou version ultérieure ne peuvent pas modifier les champs static final. Si une application tente de modifier un champ static final à l'aide de la réflexion, cela entraînera une IllegalAccessException. Toute tentative de modification de l'un de ces champs via les API JNI (telles que SetStaticLongField()) entraînera le plantage de l'application.

Accessibilité

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

Cette fonctionnalité introduit de nouvelles API AccessibilityEvent et TextAttribute pour améliorer le retour vocal du lecteur d'écran pour la saisie de texte en langues CJKV. Les applications IME CJKV peuvent désormais signaler si un candidat à la conversion de texte a été sélectionné lors de la composition du texte. Les applications avec des champs de modification peuvent spécifier des types de modification de texte lors de l'envoi d'événements d'accessibilité de texte modifié. Par exemple, les applications peuvent spécifier qu'une modification de texte s'est produite lors de la composition du texte ou qu'une modification de texte résulte d'un commit. Cela permet aux services d'accessibilité tels que les lecteurs d'écran de fournir des commentaires plus précis en fonction de la nature de la modification du texte.

Nombre d'applications utilisant le SDK

Applications IME : lors de la définition de la composition de texte dans les champs d'édition, les IME peuvent utiliser TextAttribute.Builder.setTextSuggestionSelected() pour indiquer si un candidat à la conversion spécifique a été sélectionné.
Applications avec des champs de modification : les applications qui gèrent un InputConnection personnalisé peuvent récupérer les données de sélection des candidats en appelant TextAttribute.isTextSuggestionSelected(). Ces applications doivent ensuite appeler AccessibilityEvent.setTextChangeTypes() lors de l'envoi d'événements TYPE_VIEW_TEXT_CHANGED. Les applications ciblant Android 17 (niveau d'API 37) qui utilisent le TextView standard auront cette fonctionnalité activée par défaut. (Autrement dit, TextView gérera la récupération des données de l'IME et la définition des types de modification de texte lors de l'envoi d'événements aux services d'accessibilité.)
Services d'accessibilité : les services d'accessibilité qui traitent les événements TYPE_VIEW_TEXT_CHANGED peuvent appeler AccessibilityEvent.getTextChangeTypes() pour identifier la nature de la modification et ajuster leurs stratégies de commentaires en conséquence.

Confidentialité

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

ECH (Encrypted Client Hello) activé

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 une 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 si le serveur distant prend également en charge le protocole ECH. Si la négociation ECH échoue, le client envoie une extension ECH avec un contenu aléatoire (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 d'accès au 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 cette autorisation 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 et l'empreinte numérique des utilisateurs à leur insu. En déclarant et en demandant cette autorisation, votre application peut détecter les appareils sur le réseau local (LAN), tels que les appareils connectés ou les récepteurs de diffusion, et s'y connecter.

Les applications ciblant Android 17 (niveau d'API 37) ou version ultérieure disposent désormais de deux options pour 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 ignorer 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.

Masquer les mots de passe sur les appareils physiques

If an app targets Android 17 (API level 37) or higher and the user is using a physical input device (for example, an external keyboard), the Android operating system applies the new show_passwords_physical setting to all characters in the password field. By default, that setting hides all password characters.

The Android system shows the last-typed password character to help the user see if they mistyped the password. However, this is much less necessary with larger external keyboards. In addition, devices with external keyboards often have larger displays, which increases the danger of someone seeing the typed password.

If the user is using the device's touchscreen, the system applies the new show_passwords_touch setting.

Protection par code secret à usage unique pour les messages SMS standards

À partir d'Android 17, Android étend sa protection des OTP par SMS aux messages SMS standards (messages SMS contenant un OTP qui n'utilisent pas les formats WebOTP ni SMS Retriever). Pour la plupart des applications ciblant Android 17 (niveau d'API 37) ou version ultérieure, ces messages SMS ne sont disponibles que trois heures après leur réception. Ce délai vise à éviter le piratage des codes secrets à usage unique. Pendant ce délai de trois heures, la diffusion SMS_RECEIVED_ACTION est suspendue et les requêtes de base de données du fournisseur de SMS sont filtrées. Le message SMS est disponible pour ces applications après le délai.

Certaines applications, telles que l'application d'assistance SMS par défaut, les applications associées aux appareils connectés, etc., sont exemptées de ce délai. Toutes les applications qui s'appuient sur la lecture des messages SMS pour extraire les codes secrets à usage unique doivent passer aux API SMS Retriever ou SMS User Consent pour continuer à fonctionner.

Sécurité

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

Sécurité de l'activité

Dans Android 17, la plate-forme poursuit sa transition vers une architecture "sécurisée par défaut", en introduisant une série d'améliorations conçues pour atténuer les failles de sécurité de haute gravité telles que le hameçonnage, le détournement d'interaction et les attaques du député confus. Cette mise à jour exige des développeurs qu'ils activent explicitement les nouvelles normes de sécurité pour maintenir la compatibilité des applications et la protection des utilisateurs.

Voici les principaux impacts pour les développeurs :

Renforcement de BAL et amélioration de l'activation : nous affinons les restrictions concernant le lancement d'activités en arrière-plan (BAL) en étendant les protections à IntentSender. Les développeurs doivent migrer depuis la constante MODE_BACKGROUND_ACTIVITY_START_ALLOWED héritée. À la place, vous devez adopter des contrôles précis comme MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, qui limite les démarrages d'activité aux scénarios où l'application appelante est visible, ce qui réduit considérablement la surface d'attaque.
Outils d'adoption : les développeurs doivent utiliser le mode strict et les vérifications lint mises à jour pour identifier les anciens modèles et s'assurer d'être prêts pour les futures exigences du SDK cible.

Activer la CT par défaut

Si une application cible Android 17 (niveau d'API 37) ou version ultérieure, la transparence des certificats (CT) est activée par défaut. (Sur Android 16, la CT est disponible, mais les applications doivent l'activer.)

Safer Native DCL-C

Si votre application cible Android 17 (niveau d'API 37) ou une version ultérieure, la protection Safer Dynamic Code Loading (DCL) introduite dans Android 14 pour les fichiers DEX et JAR s'étend désormais aux bibliothèques natives.

Tous les fichiers natifs chargés à l'aide de System.load() doivent être marqués en lecture seule. Sinon, le système génère une exception UnsatisfiedLinkError.

Nous vous recommandons d'éviter le chargement dynamique de code dans la mesure du possible, car cela augmente considérablement le risque que l'application soit compromise par une injection ou une falsification de code.

Restreindre les champs d'informations permettant d'identifier personnellement l'utilisateur dans la vue de données CP2

Pour les applications ciblant Android 17 (niveau d'API 37) et les versions ultérieures, le fournisseur de contacts 2 (CP2) limite l'accès à certaines colonnes contenant des informations permettant d'identifier personnellement les utilisateurs (PII) dans la vue de données. Lorsque cette modification est activée, ces colonnes sont supprimées de la vue de données pour améliorer la confidentialité des utilisateurs. Les colonnes restreintes sont les suivantes :

Les applications qui utilisent ces colonnes à partir de ContactsContract.Data peuvent les extraire de ContactsContract.RawContacts à la place, en effectuant une jointure avec RAW_CONTACT_ID.

Appliquer des vérifications SQL strictes dans 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.

Intelligence

Android 17 inclut les modifications suivantes apportées à l'intelligence système.

Abandon de setContentCaptureEnabled

Content Capture is enabled by default on certain devices to allow on-device AI features to analyze screen contents for intelligent experiences.

Starting in Android 17, the ContentCaptureManager.setContentCaptureEnabled(boolean) API method is deprecated. For apps that target Android 17 (API level 37) or higher, calling setContentCaptureEnabled(false) no longer disables Content Capture.

If your app needs to continue disabling Content Capture or restrict screen contents from being captured by the system, you must transition to using the FLAG_SECURE window layout parameter.

To disable Content Capture, set the FLAG_SECURE flag on your window as shown in the following example:

Kotlin

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

Java

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

For more details, see the WindowManager.LayoutParams.FLAG_SECURE reference documentation.

Multimédia

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 des appareils

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

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

Nous avons introduit des modifications de l'API de plate-forme dans Android 16 pour ignorer les restrictions d'orientation, de format et de redimensionnement sur les grands écrans (sw >= 600 dp) pour les applications ciblant le niveau d'API 36 ou supérieur. Les développeurs ont la possibilité de désactiver ces modifications avec le SDK 36, mais cette option ne sera plus disponible pour les applications ciblant Android 17 (niveau d'API 37) ou version ultérieure.

Pour en savoir plus, consultez Les restrictions concernant l'orientation et la redimensionnabilité sont ignorées.

Connectivité

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

Comportement cohérent de BluetoothSocket read() pour RFCOMM

Pour les applications ciblant Android 17 (niveau d'API 37), la méthode read() de InputStream obtenu à partir d'un BluetoothSocket basé sur RFCOMM renvoie désormais -1 lorsque le socket est fermé ou que la connexion est interrompue.

Cette modification rend le comportement des sockets RFCOMM cohérent avec celui des sockets LE CoC et s'aligne sur la documentation standard InputStream.read(), qui indique que -1 est renvoyé lorsque la fin du flux est atteinte.

Les applications qui s'appuient uniquement sur la capture d'une IOException pour sortir d'une boucle de lecture peuvent être affectées par ce changement et doivent mettre à jour les boucles de lecture BluetoothSocket pour vérifier explicitement une valeur de retour de -1. Cela permet de s'assurer que la boucle se termine correctement lorsque l'appareil distant se déconnecte ou que le socket est fermé. Pour obtenir un exemple de l'implémentation recommandée, consultez l'extrait de code dans le guide Transférer des données Bluetooth.