Comme les versions précédentes, Android 16 apporte des modifications de comportement pouvant affecter votre application. Les modifications de comportement suivantes s'appliquent exclusivement aux applications qui ciblent Android 16 ou version ultérieure. Si votre application cible Android 16 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 16, quelle que soit la targetSdkVersion
de votre application.
Expérience utilisateur et interface utilisateur du système
Android 16 inclut les modifications suivantes, qui visent à créer une expérience utilisateur plus cohérente et intuitive.
Migration ou désactivation requise pour la prévisualisation du Retour
Pour les applications ciblant Android 16 ou version ultérieure et exécutées sur un appareil Android 16 ou version ultérieure, les animations système de prévisualisation du Retour (retour à l'écran d'accueil, multitâche et multi-activité) sont activées par défaut.
De plus, onBackPressed
n'est pas appelé et KeyEvent.KEYCODE_BACK
n'est plus distribué.
Si votre application intercepte l'événement "Retour" et que vous n'avez pas encore migré vers la prévisualisation du Retour, mettez à jour votre application pour qu'elle utilise les API de navigation "Retour" compatibles ou désactivez temporairement cette fonctionnalité en définissant l'attribut android:enableOnBackInvokedCallback
sur false
dans la balise <application>
ou <activity>
du fichier AndroidManifest.xml
de votre application.
Fonctionnalité de base
Android 16 inclut les modifications suivantes qui modifient ou étendent diverses fonctionnalités de base du système Android.
Optimisation de la planification des tâches à tarif fixe
Avant de cibler Android 16, lorsque scheduleAtFixedRate
manquait une exécution de tâche en raison de l'absence d'un cycle de vie de processus valide, toutes les exécutions manquées s'exécutaient immédiatement lorsque l'application revenait à un cycle de vie valide.
Lorsque vous ciblez Android 16, une seule exécution manquée de scheduleAtFixedRate
est immédiatement exécutée lorsque l'application revient à un cycle de vie valide. Ce changement de comportement devrait améliorer les performances de l'application. Testez ce comportement dans votre application pour vérifier si elle est concernée.
Vous pouvez également effectuer des tests à l'aide du framework de compatibilité des applications et en activant l'indicateur de compatibilité STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS
.
Grands écrans et facteurs de forme
Android 16 inclut les modifications suivantes pour les applications lorsqu'elles sont affichées sur des appareils à grand écran.
Mises en page adaptatives
Les applications Android s'exécutant désormais sur différents appareils (téléphones, tablettes, appareils pliables et ordinateurs de bureau) et les modes de fenêtrage sur les grands écrans (comme l'écran partagé et le fenêtrage pour ordinateur de bureau), les développeurs doivent créer des applications Android qui s'adaptent à n'importe quelle taille d'écran et de fenêtre, quelle que soit l'orientation de l'appareil. Les paradigmes tels que la restriction de l'orientation et la redimensionnabilité sont trop restrictifs dans le monde multi-appareils d'aujourd'hui.
Ignorer les restrictions d'orientation, de redimensionnement et de format
Pour les applications ciblant Android 16, Android 16 inclut des modifications de la façon dont le système gère l'orientation, le redimensionnement et les restrictions d'aspect. Sur les écrans dont la largeur la plus petite est d'au moins 600 dp, les restrictions ne s'appliquent plus. Les applications remplissent également l'intégralité de la fenêtre d'affichage, quel que soit le format ou l'orientation préférée de l'utilisateur. Le format pillarbox n'est pas utilisé.
Ce changement introduit un nouveau comportement standard de la plate-forme. Android évolue vers un modèle dans lequel les applications doivent s'adapter à différentes orientations, tailles d'écran et formats. Les restrictions telles que l'orientation fixe ou la redimensionnement limité entravent l'adaptabilité de l'application. Nous vous recommandons donc de rendre votre application adaptative pour offrir la meilleure expérience utilisateur possible.
Modifications destructives courantes
Ignorer les restrictions d'orientation, de redimensionnement et de format peut avoir un impact sur l'interface utilisateur de votre application sur certains appareils, en particulier sur les éléments conçus pour de petites mises en page verrouillées en mode portrait: par exemple, des problèmes tels que des mises en page étirées, des animations et des composants hors écran. Toute hypothèse concernant le format ou l'orientation peut entraîner des problèmes visuels avec votre application. En savoir plus sur la façon de les éviter et d'améliorer le comportement adaptatif de votre application
Autoriser la rotation de l'appareil entraîne une recréation plus fréquente des activités, ce qui peut entraîner la perte de l'état de l'utilisateur s'il n'est pas correctement conservé. Découvrez comment enregistrer correctement l'état de l'UI dans Enregistrer les états de l'interface utilisateur.
Détails de l'implémentation
Les attributs de fichier manifeste et les API d'exécution suivants sont ignorés sur les appareils à grand écran en mode plein écran et multifenêtre:
screenOrientation
resizableActivity
minAspectRatio
maxAspectRatio
setRequestedOrientation()
getRequestedOrientation()
Les valeurs suivantes pour screenOrientation
, setRequestedOrientation()
et getRequestedOrientation()
sont ignorées:
portrait
reversePortrait
sensorPortrait
userPortrait
landscape
reverseLandscape
sensorLandscape
userLandscape
En ce qui concerne la redimensionnabilité de l'écran, android:resizeableActivity="false"
, android:minAspectRatio
et android:maxAspectRatio
n'ont aucun effet.
Pour les applications ciblant Android 16, les contraintes d'orientation, de redimensionnement et de format de l'application sont ignorées sur les grands écrans par défaut, mais chaque application qui n'est pas entièrement prête peut temporairement remplacer ce comportement en désactivant cette option (ce qui entraîne le comportement précédent, à savoir le placement en mode de compatibilité).
Exceptions
Les restrictions d'orientation, de redimensionnement et de format d'Android 16 ne s'appliquent pas dans les situations suivantes:
- Jeux (basé sur l'indicateur
android:appCategory
) - Utilisateurs qui activent explicitement le comportement par défaut de l'application dans les paramètres de format de l'appareil
- Écrans de moins de
sw600dp
Désactiver temporairement
Pour désactiver une activité spécifique, déclarez la propriété de fichier manifeste PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY
:
<activity ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
...
</activity>
Si trop de parties de votre application ne sont pas prêtes pour Android 16, vous pouvez désactiver complètement la fonctionnalité en appliquant la même propriété au niveau de l'application:
<application ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>
Santé et remise en forme
Android 16 inclut les modifications suivantes concernant les données de santé et de remise en forme.
Autorisations de santé et remise en forme
Pour les applications ciblant Android 16 ou version ultérieure, les autorisations BODY_SENSORS
passent aux autorisations précises sous android.permissions.health
, également utilisées par Santé Connect. Toute API qui nécessitait auparavant BODY_SENSORS
ou BODY_SENSORS_BACKGROUND
nécessite désormais l'autorisation android.permissions.health
correspondante. Cela affecte les types de données, les API et les types de services de premier plan suivants:
HEART_RATE_BPM
depuis les services Santé WearSensor.TYPE_HEART_RATE
à partir du Gestionnaire de capteurs AndroidheartRateAccuracy
etheartRateBpm
à partir de WearProtoLayout
FOREGROUND_SERVICE_TYPE_HEALTH
, où l'autorisationandroid.permission.health
correspondante est requise à la place deBODY_SENSORS
Si votre application utilise ces API, elle doit désormais demander les autorisations précises correspondantes:
- Pour la surveillance de la fréquence cardiaque, de la SpO2 ou de la température cutanée pendant l'utilisation : demandez l'autorisation précise sous
android.permissions.health
, par exempleREAD_HEART_RATE
au lieu deBODY_SENSORS
. - Pour l'accès aux capteurs en arrière-plan, demandez
READ_HEALTH_DATA_IN_BACKGROUND
au lieu deBODY_SENSORS_BACKGROUND
.
Ces autorisations sont les mêmes que celles qui protègent l'accès à la lecture des données de Santé Connect, le datastore Android pour les données de santé, de remise en forme et de bien-être.