Changements de comportement : toutes les applications

La plate-forme Android 17 apporte des modifications de comportement susceptibles d'affecter votre application. Les modifications de comportement suivantes s'appliquent à toutes les applications lorsqu'elles s'exécutent sur Android 17, peu importe la targetSdkVersion. Vous devez tester votre application, puis la modifier si nécessaire afin de prendre en charge ces modifications, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui n'affectent que les applications ciblant Android 17.

Sécurité

Android 17 inclut les améliorations suivantes en matière de sécurité des appareils et des applications.

Plan d'abandon de usesClearTraffic

Dans une prochaine version, nous prévoyons d'abandonner l'élément usesCleartextTraffic. Les applications qui doivent établir des connexions non chiffrées (HTTP) doivent migrer vers l'utilisation d'un fichier de configuration de la sécurité réseau, qui vous permet de spécifier les domaines auxquels votre application doit établir des connexions en texte clair.

Notez que les fichiers de configuration de la sécurité réseau ne sont compatibles qu'avec le niveau d'API 24 et les niveaux supérieurs. Si le niveau d'API minimal de votre application est inférieur à 24, vous devez effectuer les deux actions suivantes :

  • Définissez l'attribut usesCleartextTraffic sur true.
  • Utiliser un fichier de configuration réseau

Si le niveau d'API minimal de votre application est de 24 ou plus, vous pouvez utiliser un fichier de configuration réseau et vous n'avez pas besoin de définir usesCleartextTraffic.

Restreindre les autorisations URI implicites

Actuellement, si une application lance un intent avec un URI dont l'action est Send, SendMultiple ou ImageCapture, le système accorde automatiquement les autorisations de lecture et d'écriture de l'URI à l'application cible. Nous prévoyons de modifier ce comportement dans Android 18. C'est pourquoi nous recommandons aux applications d'accorder explicitement les autorisations d'URI pertinentes au lieu de s'appuyer sur le système pour les accorder.

Limites de keystore par application

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

  • Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
  • All other apps: getNumericErrorCode() returns ERROR_INCORRECT_USAGE.

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.

Restauration de la visibilité de l'IME par défaut après une rotation

Beginning with Android 17, when the device's configuration changes (for example, through rotation), and this is not handled by the app itself, the previous IME visibility is not restored.

If your app undergoes a configuration change that it does not handle, and the app needs the keyboard to be visible after the change, you must explicitly request this. You can make this request in one of the following ways:

  • Set the android:windowSoftInputMode attribute to stateAlwaysVisible.
  • Programmatically request the soft keyboard in your activity's onCreate() method, or add the onConfigurationChanged() method.

Action humaine

Android 17 inclut les modifications suivantes, qui affectent la façon dont les applications interagissent avec les appareils de saisie humaine, tels que les claviers et les pavés tactiles.

Les pavés tactiles fournissent des événements relatifs par défaut lors de la capture du pointeur

Beginning with Android 17, if an app requests pointer capture using View.requestPointerCapture() and the user uses a touchpad, the system recognizes pointer movement and scrolling gestures from the user's touches and reports them to the app in the same way as pointer and scroll wheel movements from a captured mouse. In most cases, this removes the need for apps that support captured mice to add special handling logic for touchpads. For more details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.

Previously, the system did not attempt to recognize gestures from the touchpad, and instead delivered the raw, absolute finger locations to the app in a similar format to touchscreen touches. If an app still requires this absolute data, it should call the new View.requestPointerCapture(int) method with View.POINTER_CAPTURE_MODE_ABSOLUTE instead.

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 demandes de focus audio et les API de modification du volume, afin de s'assurer que ces modifications sont lancées intentionnellement par l'utilisateur.

Si l'application tente d'appeler des API audio alors qu'elle ne se trouve pas dans un cycle de vie valide, les API de lecture audio et de modification du volume échouent silencieusement, sans générer d'exception ni fournir de message d'échec. L'API de focus audio échoue avec le code de résultat AUDIOFOCUS_REQUEST_FAILED.

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.

Connectivité

Android 17 inclut les modifications suivantes pour améliorer la connectivité des appareils.

Réassociation autonome en cas de perte de l'association Bluetooth

Android 17 introduit le réappairage autonome, une amélioration au niveau du système conçue pour résoudre automatiquement la perte d'association Bluetooth.

Auparavant, si une association était perdue, les utilisateurs devaient accéder manuellement aux paramètres pour dissocier le périphérique, puis l'associer à nouveau. Cette fonctionnalité s'appuie sur l'amélioration de la sécurité d'Android 16 en permettant au système de rétablir les associations en arrière-plan sans que les utilisateurs aient à accéder manuellement aux paramètres pour dissocier et associer à nouveau les périphériques.

Bien que la plupart des applications ne nécessitent pas de modifications de code, les développeurs doivent être conscients des modifications de comportement suivantes dans la pile Bluetooth :

  • Nouveau contexte d'association : ACTION_PAIRING_REQUEST inclut désormais l' EXTRA_PAIRING_CONTEXT extra, qui permet aux applications de faire la distinction entre une demande d'association standard et une tentative de réappairage autonome initiée par le système.
  • Mises à jour conditionnelles des clés : les clés de sécurité existantes ne seront remplacées que si le réappairage réussit et que la nouvelle connexion atteint ou dépasse le niveau de sécurité de l'association précédente.
  • Timing modifié de l'intent : l'intent ACTION_KEY_MISSING n'est désormais diffusé que si la tentative de réappairage autonome échoue. Cela réduit la gestion des erreurs inutiles dans l'application si le système récupère l'association en arrière-plan.
  • Notification utilisateur : le système gère le réappairage via de nouvelles notifications et boîtes de dialogue de l'interface utilisateur. Les utilisateurs seront invités à confirmer la tentative de réappairage pour s'assurer qu'ils sont conscients de la reconnexion.

Les fabricants de périphériques et les développeurs d'applications associées doivent vérifier que le matériel et l'application gèrent correctement les transitions d'association. Pour tester ce comportement, simulez une perte d'association à distance à l'aide de l'une des méthodes suivantes :

  • Supprimer manuellement les informations d'association du périphérique
  • Dissocier manuellement l'appareil dans : Paramètres > Appareils connectés