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.
Fin de la possibilité de désactiver l'affichage bord à bord
Android 15 a appliqué l'affichage bord à bord pour les applications ciblant Android 15 (niveau d'API 35), mais votre application peut désactiver cette fonctionnalité en définissant R.attr#windowOptOutEdgeToEdgeEnforcement sur true. Pour les applications ciblant Android 16, R.attr#windowOptOutEdgeToEdgeEnforcement est obsolète et désactivé, et votre application ne peut pas désactiver l'affichage plein écran.
Pour les tests dans la version bêta 2 d'Android 16, assurez-vous que votre application est compatible avec l'affichage bord à bord et supprimez toute utilisation de R.attr#windowOptOutEdgeToEdgeEnforcement. Pour prendre en charge l'affichage bord à bord, consultez les conseils sur Compose et Views. Signalez-nous vos problèmes dans notre outil de suivi des problèmes sur la page des commentaires.
Migration ou désactivation requise pour la prévisualisation du Retour
For apps targeting Android 16 or higher and running on an
Android 16 or higher device, the predictive back system animations
(back-to-home, cross-task, and cross-activity) are enabled by default.
Additionally, onBackPressed is not called and
KeyEvent.KEYCODE_BACK is not dispatched anymore.
If your app intercepts the back event and you haven't migrated to predictive
back yet, update your app to use supported back navigation APIs. or
temporarily opt out by setting the
android:enableOnBackInvokedCallback attribute to false in the
<application> or <activity> tag of your app's AndroidManifest.xml file.
API de polices élégantes obsolètes et désactivées
Apps targeting Android 15 (API level 35) have the
elegantTextHeight
TextView attribute set to true by
default, replacing the compact font with one that is much more readable. You
could override this by setting the elegantTextHeight attribute to false.
Android 16 deprecates the
elegantTextHeight attribute,
and the attribute will be ignored once your app targets Android 16. The "UI
fonts" controlled by these APIs are being discontinued, so you should adapt any
layouts to ensure consistent and future proof text rendering in Arabic, Lao,
Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.
elegantTextHeight behavior for apps targeting Android
14 (API level 34) and lower, or for apps targeting Android 15 (API level 35)
that overrided the default by setting the elegantTextHeight
attribute to false.
elegantTextHeight behavior for apps targeting Android
16, or for apps targeting Android 15 (API level 35) that didn't override the
default by setting the elegantTextHeight attribute to
false.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
Prior to targeting Android 16, when scheduleAtFixedRate
missed a task execution due to being outside a valid
process lifecycle, all missed executions immediately
execute when the app returns to a valid lifecycle.
When targeting Android 16, at most one missed execution of
scheduleAtFixedRate is immediately executed when the app
returns to a valid lifecycle. This behavior change is expected to improve app
performance. Test this behavior in your app to check if your app is impacted.
You can also test by using the app compatibility framework
and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.
Facteurs de forme des appareils
Android 16 inclut les modifications suivantes pour les applications lorsqu'elles sont affichées sur des appareils à grand écran.
Mises en page adaptatives
With Android apps now running on a variety of devices (such as phones, tablets, foldables, desktops, cars, and TVs) and windowing modes on large screens (such as split screen and desktop windowing), developers should build Android apps that adapt to any screen and window size, regardless of device orientation. Paradigms like restricting orientation and resizability are too restrictive in today's multidevice world.
Ignore orientation, resizability, and aspect ratio restrictions
For apps targeting Android 16, Android 16 includes changes to how the system manages orientation, resizability, and aspect ratio restrictions. On displays with smallest width >= 600dp, the restrictions no longer apply. Apps also fill the entire display window, regardless of aspect ratio or a user's preferred orientation, and pillarboxing isn't used.
This change introduces a new standard platform behavior. Android is moving toward a model where apps are expected to adapt to various orientations, display sizes, and aspect ratios. Restrictions like fixed orientation or limited resizability hinder app adaptability, so we recommend making your app adaptive to deliver the best possible user experience.
You can also test this behavior by using the
[app compatibility framework][a16-kilo-14] and
enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT compat flag.
Common breaking changes
Ignoring orientation, resizability, and aspect ratio restrictions might impact your app's UI on some devices, especially elements that were designed for small layouts locked in portrait orientation: for example, issues like stretched layouts and off-screen animations and components. Any assumptions about aspect ratio or orientation can cause visual issues with your app. Learn more about how to avoid them and improve your app's adaptive behaviour.
Allowing device rotation results in more activity re-creation, which can result in losing user state if not properly preserved. Learn how to correctly save UI state in Save UI states.
Implementation details
The following manifest attributes and runtime APIs are ignored across large screen devices in full-screen and multi-window modes:
screenOrientationresizableActivityminAspectRatiomaxAspectRatiosetRequestedOrientation()getRequestedOrientation()
The following values for screenOrientation, setRequestedOrientation(), and
getRequestedOrientation() are ignored:
portraitreversePortraitsensorPortraituserPortraitlandscapereverseLandscapesensorLandscapeuserLandscape
Regarding display resizability, android:resizeableActivity="false",
android:minAspectRatio, and android:maxAspectRatio have no effect.
For apps targeting Android 16, app orientation, resizability, and aspect ratio constraints are ignored on large screens by default, but every app that isn't fully ready can temporarily override this behavior by opting out (which results in the previous behavior of being placed in compatibility mode).
Exceptions
The Android 16 orientation, resizability, and aspect ratio restrictions don't apply in the following situations:
- Games (based on the
android:appCategoryflag) - Users explicitly opting in to the app's default behavior in aspect ratio settings of the device
- Screens that are smaller than
sw600dp
Opt out temporarily
To opt out a specific activity, declare the
PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY manifest property:
<activity ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
...
</activity>
If too many parts of your app aren't ready for Android 16, you can opt out completely by applying the same property at the application level:
<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_BPMdepuis les services Santé WearSensor.TYPE_HEART_RATEà partir du Gestionnaire de capteurs AndroidheartRateAccuracyetheartRateBpmà partir de WearProtoLayoutFOREGROUND_SERVICE_TYPE_HEALTH, où l'autorisationandroid.permission.healthcorrespondante 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_RATEau lieu deBODY_SENSORS. - Pour l'accès aux capteurs en arrière-plan, demandez
READ_HEALTH_DATA_IN_BACKGROUNDau 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.