Avec chaque version, des API Android spécifiques peuvent devenir obsolètes ou nécessiter une refactorisation afin d'offrir une meilleure expérience aux développeurs ou de prendre en charge de nouvelles fonctionnalités de la plate-forme. Dans ce cas, Android abandonnera officiellement les API obsolètes et redirigera les développeurs vers de nouvelles API à utiliser à la place.
L'abandon signifie que les API ne sont plus officiellement prises en charge, mais qu'elles restent disponibles pour les développeurs. Cette page présente certains des abandons de cette version d'Android. Pour voir d'autres abandons, reportez-vous au rapport de différences des API.
RenderScript
À partir d'Android 12, les API RenderScript sont obsolètes. Elles continueront de fonctionner, mais les fabricants d'appareils et de composants ne devraient plus proposer d'assistance pour l'accélération matérielle au fil du temps. Pour profiter pleinement de l'accélération du GPU, nous vous recommandons d'abandonner RenderScript.
Playlists Android
Les playlists Android sont obsolètes. L'API n'est plus gérée, mais les fonctionnalités actuelles restent pour la compatibilité.
Nous vous recommandons de lire et d'enregistrer les playlists au format m3u.
Abandons de l'API Display
Les appareils Android sont désormais disponibles dans de nombreux facteurs de forme différents, tels que les grands écrans, les tablettes et les pliables. Pour afficher le contenu de manière appropriée pour chaque appareil, votre application doit déterminer la taille de l'écran ou de l'affichage. Au fil du temps, Android a fourni différentes API pour récupérer ces informations. Dans Android 11, nous avons lancé l'API WindowMetrics et abandonné les méthodes suivantes:
Dans Android 12, nous vous recommandons toujours d'utiliser WindowMetrics et nous abandonnons les méthodes suivantes:
Les applications doivent utiliser les API WindowMetrics pour interroger les limites de leur fenêtre, ou Configuration.densityDpi pour interroger la densité actuelle.
Notez que la bibliothèque Jetpack WindowManager inclut une classe WindowMetrics compatible avec Android 4.0.1 (niveau d'API 14) ou version ultérieure.
Exemples
Voici quelques exemples d'utilisation de WindowMetrics.
Tout d'abord, assurez-vous que les activités de votre application peuvent être entièrement redimensionnables.
Une activité doit s'appuyer sur WindowMetrics à partir d'un contexte d'activité pour toute tâche liée à l'interface utilisateur, en particulier WindowManager.getCurrentWindowMetrics().
Si votre application crée un MediaProjection, les limites doivent être correctement dimensionnées, car la projection capture l'écran. Si l'application est entièrement redimensionnable, le contexte de l'activité renvoie les limites appropriées.
Kotlin
val projectionMetrics = activityContext
.getSystemService(WindowManager::class.java).maximumWindowMetrics
Java
WindowMetrics projectionMetrics = activityContext
.getSystemService(WindowManager.class).getMaximumWindowMetrics();
Si l'application n'est pas entièrement redimensionnable, elle doit interroger les limites à partir d'une instance WindowContext et récupérer les WindowMetrics de la zone d'affichage maximale disponible pour l'application à l'aide de WindowManager.getMaximumWindowMetrics().
Kotlin
val windowContext = context.createWindowContext(mContext.display!!,
WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
.maximumWindowMetrics
Java
Context windowContext = mContext.createWindowContext(mContext.getDisplay(),
WindowManager.LayoutParams.TYPE_APPLICATION, null;
WindowMetrics projectionMetrics = windowContext.getWindowManager()
.getMaximumWindowMetrics();