Quoi de neuf pour Android 12 ?!

La version finale d’Android 12 apporte son lot de nouveautés intéressantes, aussi bien pour les utilisateurs d’Android, que pour les développeurs d’applications en tous genres.

Dans cet article, je vous propose de vous faire un tour d’horizon des quelques changements apportés par cette nouvelle version. L’idée même de cet article est de vous rassurer (mais aussi de vous alerter) par rapport à l’impact du déploiement d’Android 12 chez vos différents utilisateurs.

Qu’est-ce qui change pour toutes les applications lancées sur Android 12 ?

Peu importe que votre application vise ou non Android 12 (targetVersion=31), certaines fonctionnalités changent si vous la lancez sur un téléphone possédant la dernière version.

Le nouveau Splash Screen

À partir d’Android 12, par défaut, chaque application démarre avec un écran de chargement qui utilise la Splashscreen API. Cette API vous permet de définir un splash screen entièrement customisable au sein de votre Thème. Cet écran vous permettra également d’effectuer des opérations indispensables au bon fonctionnement de votre application et qui nécessitent d’être chargées le plus tôt possible.

Le splash screen se compose d’une icône au format VectorDrawable
(pouvant être animée ou non), d’un background pour l’icône ainsi que d’un background pour l’écran.

Si vous utilisez actuellement un splash screen “fait-maison”, il est recommandé de migrer votre implémentation vers cette nouvelle API. Vous éviterez ainsi les comportements étranges et les possibles doubles splash screens sur Android 12. Heureusement, Google vous fournit un guide complet sur comment migrer sur la nouvelle API. Il existe également la librairie de support permettant d’obtenir un splash screen sur les anciennes versions d’Android (jusqu’à Android 6 - API 23).

Dépréciation de l’API Display

On a tous eu besoin un jour ou l’autre d’obtenir la taille de l’écran en pixels ou des informations sur l’écran du téléphone. De ce fait, nombre de développeurs sont familiers avec l’API Display qui permettait de résoudre bien des problèmes.

Néanmoins, avec l’arrivée des nouveaux écrans (écrans pliables, écrans de montres, notchs et poinçons) ainsi que la possibilité pour les apps d’être redimensionnées au sein d’un écran, cette API n’est plus très adaptée.

Désormais, il est donc recommandé d’utiliser l’API WindowManager fournissant l’objet WindowMetrics. À noter que celle-ci est disponible au sein de Jetpack et permet son utilisation jusqu’à Android 4.0 (API 14).

Fin du finish() sur le onBackPressed()

Avec cette nouvelle version de l’OS, les Activity ayant les Intent Filter ACTION_MAIN et CATEGORY_LAUNCHER n'appellent plus finish() lorsque le geste de navigation arrière est détecté. Concrètement, sur une activity de la sorte, le bouton/geste Home et le bouton/geste Back ont le même comportement et mettent simplement l’application en arrière-plan.

L’idée derrière ce changement est de pouvoir diminuer le temps de démarrage de l’application puisque cela évite de redémarrer complètement l’application. Pensez à vérifier que cet événement n’est pas écouté au sein de votre application.

Le Restricted Bucket activé par défaut

Déjà sur Android 9, Google avait introduit le concept d’App Standby Bucket. Pour faire simple, chaque application est catégorisée dans un "Bucket". Il permet au système Android de limiter l’accès à certaines ressources en fonction de la priorité du Bucket. Ces assignations sont dynamiques et gérées par le système d’exploitation. Il existe 5 buckets :

Le Restricted Bucket, ajouté sur Android 11, est sur la 12ème version activée par défaut. Cela signifie qu’en fonction de l’usage de votre application et de son fonctionnement, Android pourra retarder l’exécution de vos jobs, "oublier" d’afficher certaines de vos notifications, etc. Pour savoir au sein de votre code quel bucket est assigné à votre app, vous pouvez appeler getAppStandbyBucket().

Attention à vos jobs "primordiaux" qui risquent potentiellement de passer à la trappe.

Qu’est-ce qui change côté développement si l’on cible Android 12 ?

En effet, qui dit nouvelle version dit changements de comportements côté développement. De nouvelles fonctionnalités arrivent avec ce nouveau SDK et d’autres disparaissent (anciennement dépréciées). Enfin, certaines sont profondément modifiées.

La position approximative

Désormais, si l’application cible Android 12, l’utilisateur peut limiter l’accès à la position GPS afin qu’elle soit approximative. Ainsi, si vous utilisiez jusqu’à présent la permission ACCESS_FINE_LOCATION, il est possible que la demande soit ignorée. Il est donc conseillé d’associer la permission ACCESS_COARSE_LOCATION à votre demande. Cela permettra notamment à votre utilisateur de pouvoir choisir sur une Dialog s’il veut vraiment vous autoriser à utiliser la position précise.

Si vous ciblez Android et que vous ne faites pas les changements nécessaires, attendez vous à voir apparaître un message dans le Logcat : ACCESS_FINE_LOCATION must be requested with ACCESS_COARSE_LOCATION.

Restrictions sur les démarrages de Foreground Services en arrière-plan

Toujours dans une optique d’optimiser les usages en ressources des applications et d’éviter les abus, Android 12 limite désormais la possibilité pour les applications de lancer des Foreground Services lorsque l’application est en arrière plan. C’est un changement à ne pas prendre à la légère car si vous êtes concernés et que vous ne faites pas les changements nécessaires, le système peut lever une exception : ForegroundServiceStartNotAllowedException.

Il existe néanmoins des exceptions à ce nouveau comportement qui permet à votre service de continuer à fonctionner. En voici quelques-unes :

• Vous recevez un message "High-Priority" de Firebase Cloud Messaging (attention à bien vérifier que vos messages FCM ne sont pas affectés par le Restricted Bucket)

• L’utilisateur interagit avec un élément de votre UI liée à votre application telle qu’une bulle, une notification ou encore un widget

• Votre app est tout bonnement la méthode d’Input sélectionnée par l’utilisateur

• Votre application reçoit différents Intents liés au reboot du téléphone via un BroadcastReceiver (ACTION_BOOT_COMPLETED, ACTION_LOCKED_BOOT_COMPLETED, or ACTION_MY_PACKAGE_REPLACED)

• Et plein d’autres exceptions. N’hésitez pas à faire un tour sur la documentation pour s’assurer que cela fonctionne chez vous.

  Si malheureusement vous êtes concernés par les restrictions, deux possibilités s’offrent à vous. La première est de refactorer votre code pour utiliser le désormais bien connu WorkManager. La deuxième possibilité est de modifier votre service afin qu’il soit lancé à un moment précis dans le futur en utilisant une Exact Alarm. Pour ça, vous devez demander la permission SCHEDULE_EXACT_ALARM introduite également avec Android 12.

Nouvelle UI sur les notifications customisées

Dans l’optique d’uniformiser les notifications customisables, Google a revu la façon dont elle s’affichait et notamment la partie customisable. Ainsi, voilà à quoi ressemble une notification sur Android 12:

Dans les faits, les changements ne sont pas énormes mais cela permet d’apporter un peu plus d’uniformité sur les différentes notifications qu’un utilisateur peut recevoir.

Conclusion

Vous avez eu un petit aperçu des changements les plus marquants d’Android 12, mais ce ne sont pas les seuls. Je vous invite à lire la documentation pour avoir accès à la liste complète des changements.

Vous l’aurez compris, Android 12 apporte son lot de nouveautés, et, avec ceci, son lot de potentiels effets indésirables, breaking changes, fonctionnalités dépréciées, etc. Néanmoins, de nombreux guides de migration ou d’alternatives sont fournis par les équipes de Google afin que ces montées de version se passent de la façon la plus douce possible.