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.

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 parcel RemoteViews. Le dépassement de ces limites génère une erreur IllegalArgumentException fatale et entraîne le plantage 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 verrouillage de MessageQueue

À partir d'Android 17, les applications ciblant Android 17 (niveau d'API 37) ou une 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 le nombre d'images manquées, mais peut endommager les clients qui réfléchissent aux champs et méthodes privés de MessageQueue.

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

Les champs statiques finaux 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îne 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 la lecture vocale du lecteur d'écran pour la saisie dans les 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 comportant des champs de modification peuvent spécifier des types de modification de texte lors de l'envoi d'événements d'accessibilité de modification de texte. 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 du texte de composition dans les champs de modification, 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. Cette fonctionnalité sera activée par défaut pour les applications ciblant Android 17 (niveau d'API 37) qui utilisent le TextView standard. (Autrement dit, TextView gérera la récupération des données à partir 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 feedback 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 prise en charge de la plate-forme pour Encrypted Client Hello (ECH), une extension TLS qui améliore 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) intègre la compatibilité avec ECH et que le serveur distant est également compatible avec le protocole ECH. Si l'ECH ne peut pas être négocié, 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 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") de manière globale ou par domaine.

Pour en savoir plus, consultez la documentation sur 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. Comme 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 invités à le faire à nouveau. Cette nouvelle exigence empêche les applications malveillantes d'exploiter un accès illimité au réseau local pour suivre et identifier les utilisateurs de manière dissimulée. En déclarant et en demandant cette autorisation, votre application peut détecter les appareils du 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 moyens de maintenir la communication avec les appareils du réseau local : adopter des sélecteurs d'appareils gérés par le système et protégeant la confidentialité 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 d'accès au réseau local.

Masquer les 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 saisie. Toutefois, cela est beaucoup moins nécessaire avec les claviers externes plus grands. 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 par OTP pour les SMS standards

À partir d'Android 17, Android étend sa protection des OTP par SMS aux SMS standards (SMS contenant un OTP qui n'utilisent pas les formats WebOTP ou SMS Retriever). Pour la plupart des applications ciblant Android 17 (niveau d'API 37) ou version ultérieure, ces SMS ne sont disponibles que trois heures après leur réception. Ce délai vise à empêcher le piratage des mots de passe à usage unique. Pendant ce délai de trois heures, la diffusion de SMS_RECEIVED_ACTION est suspendue et les requêtes de base de données du fournisseur de SMS sont filtrées. Le 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 à un appareil connecté, etc., sont exemptées de ce délai. Toutes les applications qui lisent les SMS pour extraire les OTP doivent passer aux API SMS Retriever ou Consentement utilisateur SMS 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 suite d'améliorations conçues pour atténuer les attaques de gravité élevée telles que l'hameçonnage, le détournement d'interaction et les attaques par substitution d'identité. Cette mise à jour nécessite que les développeurs acceptent explicitement de 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 du BAL et amélioration de l'activation : nous affinons les restrictions de lancement d'activités en arrière-plan (BAL) en étendant les protections à IntentSender. Les développeurs doivent migrer depuis l'ancienne constante MODE_BACKGROUND_ACTIVITY_START_ALLOWED. À la place, vous devez adopter des contrôles précis tels que MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, qui limite les démarrages d'activité aux scénarios dans lesquels 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 qu'ils sont prêts à répondre aux futures exigences du SDK cible.

Activer la transparence des certificats par défaut

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

DCL natif plus sûr – 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 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) ou version ultérieure, Contacts Provider 2 (CP2) limite l'accès à certaines colonnes contenant des informations permettant d'identifier personnellement l'utilisateur dans la vue des données. Lorsque ce changement est activé, ces colonnes sont supprimées de la vue des données pour améliorer la confidentialité des utilisateurs. Les colonnes limitées sont les suivantes :

Les applications qui utilisent ces colonnes de ContactsContract.Data peuvent les extraire de ContactsContract.RawContacts en les joignant à RAW_CONTACT_ID.

Appliquer des 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 accessible 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 rejetée et une exception sera générée.

Intelligence

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

Abandon de setContentCaptureEnabled

La capture de contenu est activée par défaut sur certains appareils pour permettre aux fonctionnalités d'IA on-device d'analyser le contenu de l'écran afin de proposer des expériences intelligentes.

À partir d'Android 17, la méthode d'API ContentCaptureManager.setContentCaptureEnabled(boolean) est obsolète. Pour les applications qui ciblent Android 17 (niveau d'API 37) ou version ultérieure, l'appel de setContentCaptureEnabled(false) ne désactive plus la capture de contenu.

Si votre application doit continuer à désactiver la capture de contenu ou à empêcher le système de capturer le contenu de l'écran, vous devez passer au paramètre de mise en page de la fenêtre FLAG_SECURE.

Pour désactiver la capture de contenu, définissez l'option FLAG_SECURE sur votre fenêtre, comme illustré dans l'exemple suivant :

Kotlin

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

Java

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

Pour en savoir plus, consultez la documentation de référence sur WindowManager.LayoutParams.FLAG_SECURE.

Multimédia

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

Renforcement de l'audio en arrière-plan

À partir d'Android 17, le framework audio applique des restrictions sur les interactions audio en arrière-plan, y compris la lecture audio, les requêtes de focus audio et les API de modification du volume, afin de s'assurer que ces modifications sont lancées intentionnellement par l'utilisateur.

Certaines restrictions audio s'appliquent à toutes les applications. Toutefois, les restrictions sont plus strictes si une application cible Android 17 (niveau d'API 37). Si l'une de ces applications interagit avec l'audio lorsqu'elle est en arrière-plan, elle doit exécuter un service de premier plan. De plus, l'application doit remplir l'une ou les deux conditions suivantes :

Le service de premier plan doit disposer de fonctionnalités d'utilisation (WIU).
L'application doit disposer de l'autorisation Alarme exacte et interagir avec les flux audio USAGE_ALARM.

Pour en savoir plus, y compris sur les stratégies d'atténuation, consultez Renforcement de l'audio en arrière-plan.

Facteurs de forme des appareils

Android 17 inclut les modifications suivantes pour améliorer l'expérience utilisateur sur différents types et tailles 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)

Nous avons modifié l'API de la plate-forme dans Android 16 pour ignorer les restrictions d'orientation, de redimensionnement et de format 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 désactivation ne sera plus disponible pour les applications qui ciblent Android 17 (niveau d'API 37) ou une version ultérieure.

Pour en savoir plus, consultez Les restrictions d'orientation et de redimensionnement 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 en Java pour les sockets RFCOMM Bluetooth.

Comportement cohérent de read() de BluetoothSocket pour RFCOMM

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

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

Les applications qui s'appuient uniquement sur l'interception d'une IOException pour sortir d'une boucle de lecture peuvent être affectées par ce changement. Elles doivent mettre à jour les boucles de lecture BluetoothSocket pour vérifier explicitement une valeur de retour de -1. Cela garantit 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.