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 introduit des limites de mémoire pour les applications en fonction de la RAM totale de l'appareil afin de créer un environnement plus stable et déterministe pour vos applications et les utilisateurs Android. Dans Android 17, les limites sont définies de manière conservatrice pour établir des bases de référence système, en ciblant les fuites de mémoire extrêmes et autres valeurs aberrantes avant qu'elles ne déclenchent une instabilité à l'échelle du système entraînant des saccades de l'interface utilisateur, une consommation de batterie plus élevée et la fermeture des applications. Bien que nous prévoyions un impact minimal sur la grande majorité des sessions d'application, nous vous recommandons de suivre les bonnes pratiques suivantes concernant la mémoire, y compris d'établir une référence pour la mémoire.
Pour déterminer si la session de votre application a été affectée, appelez getDescription dans ApplicationExitInfo. Si votre application a été affectée, la raison de la sortie sera REASON_OTHER et la description contiendra la chaîne "MemoryLimiter:AnonSwap" ainsi que d'autres informations. Vous pouvez également utiliser le profilage basé sur des déclencheurs avec TRIGGER_TYPE_ANOMALY pour obtenir des vidages de tas collectés lorsque la limite de mémoire est atteinte.
Pour vous aider à détecter les fuites de mémoire, Android Studio Panda ajoute l'intégration de LeakCanary directement dans le profileur Android Studio en tant que tâche dédiée, contextualisée dans l'IDE et entièrement intégrée à votre code source.
Sécurité
Android 17 inclut les améliorations suivantes concernant la sécurité des appareils et des applications.
Plan d'abandon de usesClearTraffic
In a future release, we plan to deprecate the usesCleartextTraffic element.
Apps that need to make unencrypted (HTTP) connections should migrate to
using a network security configuration file, which lets you
specify which domains your app needs to make cleartext connections to.
Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:
- Set the
usesCleartextTrafficattribute totrue - Use a network configuration file
If your app's minimum API level is 24 or higher, you can use a network
configuration file and you don't need to set usesCleartextTraffic.
Restreindre les autorisations d'URI implicites
Currently, if an app launches an intent with a URI that has the action Send,
SendMultiple, or ImageCapture, 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 du 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 newERROR_TOO_MANY_KEYSvalue. - All other apps:
getNumericErrorCode()returnsERROR_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.
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:windowSoftInputModesurstateAlwaysVisible. - Demandez le clavier virtuel par programmation dans la méthode
onCreate()de votre activité ou ajoutez la méthodeonConfigurationChanged().
Action humaine
Android 17 inclut les modifications suivantes qui affectent la façon dont les applications interagissent avec les périphériques d'entrée tels que les claviers et les pavés tactiles.
Les pavés tactiles génèrent des événements relatifs par défaut lors de la capture du pointeur
À partir d'Android 17, si une application demande la capture du pointeur à l'aide de View.requestPointerCapture() et que l'utilisateur utilise un pavé tactile, le système reconnaît les mouvements du pointeur et les gestes de défilement effectués par l'utilisateur, et les signale à l'application de la même manière que les mouvements du pointeur et de la molette de défilement d'une souris capturée. Dans la plupart des cas, cela évite aux applications qui prennent en charge les souris capturées d'ajouter une logique de gestion spéciale pour les pavés tactiles. Pour en savoir plus, consultez la documentation de View.POINTER_CAPTURE_MODE_RELATIVE.
Auparavant, le système ne tentait pas de reconnaître les gestes effectués sur le pavé tactile. Au lieu de cela, il fournissait à l'application les coordonnées absolues des doigts dans un format semblable à celui des contacts sur un écran tactile. Si une application a toujours besoin de ces données absolues, elle doit appeler la nouvelle méthode View.requestPointerCapture(int) avec View.POINTER_CAPTURE_MODE_ABSOLUTE.
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_REQUESTinclut désormais l'extraEXTRA_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_MISSINGn'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.