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.

Fonctionnalité de base

Android 17 (niveau d'API 37) inclut les modifications suivantes qui modifient ou étendent diverses fonctionnalités de base du système Android.

Limites de mémoire des applications

Android 17 introduces app memory limits based on the device's total RAM to create a more stable and deterministic environment for your applications and Android users. In Android 17, limits are set conservatively to establish system baselines, targeting extreme memory leaks and other outliers before they trigger system-wide instability resulting in UI stuttering, higher battery drain, and apps being killed. While we anticipate minimal impact on the vast majority of app sessions, we recommend the following memory best practices, including establishing a baseline for memory.

You can determine if your app session was impacted by calling getDescription in ApplicationExitInfo; if your app was affected, the exit reason will be REASON_OTHER and the description will contain the string "MemoryLimiter:AnonSwap" along with other information. You can also use trigger-based profiling with TRIGGER_TYPE_ANOMALY to get heap dumps that are collected when the memory limit is hit.

The Manage your app's memory documentation gives information to help you diagnose your app's memory issues and optimize its resource consumption.

Test your app's behavior under the memory constraints

You can use Android Debug Bridge (adb) to adjust or disable the memory limits on any device that imposes them. The shell command am provides three subcommands to adjust the memory limits. (These commands have no effect on a device which does not impose memory limits.)

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

Instructs the memory limiter to ignore some or all processes. Passing a UID instructs the memory limiter to ignore all processes associated with that UID. You can also pass all (ignore all processes) or none (do not ignore any processes). Passing none overrides any previous calls to am memory-limiter ignore.

If you instruct the memory limiter to ignore a process, you can still apply a manual memory limit to the process by calling am memory-limiter manual.

manual

Instructs the system to impose a memory constraint on the process with the specified PID. The memory constraint is specified as an integer number of MB; for example, passing 30 specifies that the process is limited to 30 MB of memory. Passing max removes all memory limits on that process. Passing none removes any manual limits set on the process, restoring the system's default limit (if any).

status

Reports the current status of the memory limiter. The status includes the memory limits imposed on visible and non-visible processes.

Confidentialité

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

Protection des codes secrets à usage unique par SMS

À partir d'Android 17, Android étend sa protection pour les messages SMS contenant des mots de passe à usage unique (OTP).

Dans les versions précédentes d'Android, cette protection était principalement axée sur le format SMS Retriever. La distribution des messages contenant un hachage SMS Retriever a été retardée de trois heures pour la plupart des applications. Toutefois, certaines applications (comme le gestionnaire de SMS par défaut) étaient exemptées du délai, tout comme l'application propriétaire du hachage.

À partir d'Android 17, la protection s'applique également aux messages au format WebOTP. Si une application est autorisée à lire les messages SMS, mais n'est pas le destinataire prévu d'un message WebOTP (comme déterminé par la validation du domaine), le message n'est pas accessible à l'application avant trois heures après sa réception. Cette modification vise à améliorer la sécurité des utilisateurs en s'assurant que seules les applications associées au domaine mentionné dans le message peuvent lire le code de validation de manière programmatique.

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. Cette modification s'applique à toutes les applications, quel que soit leur niveau d'API cible.

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 inclut les améliorations suivantes pour la 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 d'URI implicites

Currently, if an app launches an intent with a URI that has the action ACTION_SEND, SEND_MULTIPLE, or ACTION_IMAGE_CAPTURE, the system automatically grants the read and write URI permissions to the target app. We plan to change this behavior in Android 18. For this reason, we recommend that apps explicitly grant the relevant URI permissions instead of relying on the system to grant them.

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.

Bloquer le trafic de bouclage entre profils

Beginning with Android 17, cross-profile loopback traffic is no longer permitted by default. Loopback traffic within the same profile is not affected. This change applies to all apps running on Android 17 or higher, regardless of what API level the app targets.

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.

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

À partir d'Android 17, lorsque la configuration de l'appareil change (par exemple, en cas de rotation) et que l'application ne gère pas ce changement, la visibilité précédente de l'IME n'est pas restaurée.

Si votre application subit un changement de configuration qu'elle ne gère pas et qu'elle a besoin que le clavier soit visible après le changement, vous devez le demander explicitement. Vous pouvez effectuer cette requête de l'une des manières suivantes :

  • Définissez l'attribut android:windowSoftInputMode sur stateAlwaysVisible.
  • Demandez le clavier virtuel par programmation dans la méthode onCreate() de votre activité ou ajoutez la méthode onConfigurationChanged().

Action humaine

Android 17 inclut les modifications suivantes qui affectent la façon dont les applications interagissent avec les appareils d'entrée 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

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.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

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

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, puis associer à nouveau le périphérique. 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 réassocier 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 changements de comportement suivants dans la pile Bluetooth :

  • Nouveau contexte d'association : ACTION_PAIRING_REQUEST inclut désormais l'extra EXTRA_PAIRING_CONTEXT, qui permet aux applications de faire la distinction entre une demande d'association standard et une tentative de réassociation autonome initiée par le système.
  • Mise à jour conditionnelle des clés : les clés de sécurité existantes ne seront remplacées que si le nouvel 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é pour l'intention : l'intention ACTION_KEY_MISSING n'est désormais diffusée que si la tentative de réassociation autonome échoue. Cela réduit la gestion des exceptions inutiles dans l'application si le système récupère correctement l'association en arrière-plan.
  • Notification utilisateur : le système gère le nouvel association via de nouvelles notifications et boîtes de dialogue de l'UI. Les utilisateurs seront invités à confirmer la tentative de réassociation pour s'assurer qu'ils sont au courant 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 de liaison à distance à l'aide de l'une des méthodes suivantes :

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