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

À 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 interrompre les clients qui reflètent 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 modifications du comportement de MessageQueue behavior change guidance.

Les champs statiques finals 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é.

Prise en charge de l'accessibilité pour la saisie au clavier physique IME complexe

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 opportuniste d'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 opportunistically 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 connection automatically falls back to a standard TLS handshake without SNI encryption.

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, "opportunistic", "enabled", or "disabled") on a global or per-domain basis.

For more information, see the Encrypted Client Hello documentation.

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.

Sécurité

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

Sécurité des activités

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 par délégation confuse. 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, Background Activity Launch) 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 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.)

DCL natif plus sécurisé : C

Si votre application cible Android 17 (niveau d'API 37) ou une version ultérieure, la protection du chargement dynamique du code (DCL) plus sécurisé 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.

Limiter les champs PII dans la vue de données CP2

Pour les applications ciblant Android 17 (niveau d'API 37) ou une version ultérieure, Contacts Provider 2 (CP2) limite l'accès à certaines colonnes contenant des informations permettant d'identifier personnellement l'utilisateur (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 limitées incluent les suivantes :

Les applications qui utilisent ces colonnes à partir de ContactsContract.Data peuvent les extraire de ContactsContract.RawContacts à la place, 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 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

À 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 priorité 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 en arrière-plan, elle doit exécuter un service de premier plan. De plus, l'application doit répondre à une ou aux deux exigences suivantes :

  • Le service de premier plan doit disposer de fonctionnalités "pendant l'utilisation" (WIU, while-in-use).
  • 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 la sécurité de l'audio en arrière-plan.

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)

Dans Android 16, nous avons apporté des modifications aux API de plate-forme 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 le redimensionnement sont ignorées.

Connectivité

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

Comportement cohérent de BluetoothSocket read() pour RFCOMM

Pour les applications ciblant Android 17 (niveau d'API 37), la read() méthode de l'InputStream obtenue à 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 du socket RFCOMM cohérent avec les 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 reposent uniquement sur l'interception d'une IOException pour sortir d'une boucle de lecture peuvent être affectées par cette modification et 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 du guide Transférer des données Bluetooth.