Android 14 DP2 : nouvelles capacités pour les développeurs et les boutiques tierces d’applications

L’arrivée de la deuxième Developer Preview d’Android 14 donne une meilleure idée de la direction prise par Google avec son nouveau système. Plusieurs changements intéressants directement liés à la vie privée et aux passkeys sont présents, même si l’on est encore clairement sous le capot.

La première préversion (DP1) était discrète en matière de nouveautés. Non pas qu’elle en était exempte, mais puisque ces « DP » concernent les développeurs – c’est écrit dans le nom – les apports touchent très peu à l’interface et aux fonctions. À la place, beaucoup de changements dans les API, les autorisations, la gestion des appels, etc.

La DP2 introduit plusieurs modifications qui auront, cette fois, des répercussions directes pour les utilisateurs.

Sélection des photos et gestionnaire d’identifiants

Premier gros changement, le sélecteur de photos. Si les développeurs se servent de Photo Picker dans leurs applications (ce qui est le cas le plus souvent), aucun changement. En revanche, pour celles qui ne s’en servent pas, mais qui permettent quand même de choisir des photos ou vidéos (via respectivement READ_MEDIA_IMAGES et READ_MEDIA_VIDEO), une nouvelle fenêtre de demande d’autorisation apparaîtra.

Elle laissera le choix entre trois possibilités :

• Donner l’accès à toutes les photos
• Ne donner l’accès qu’à une sélection de photos
• Ne pas donner l’accès

C’est en fait une répercussion des autorisations demandées par Photo Picker, pour qu’il n’y ait plus d’exception. Et si ce système vous parle, c’est aussi parce qu’Android s’est inspiré d’iOS sur ce point, comme pratiquement tout ce qui touche aux permissions d’applications depuis quelques années.

L’autre nouveauté est la disponibilité de Credential Manager sous forme d’API, présente dans les services Google Play et dont la compatibilité peut remonter jusqu’à Android 4.4 et son niveau 19 d’API (ce qui ne nous rajeunit pas).

Traduction, les gestionnaires de mots de passe vont pouvoir s’en servir pour une insertion des identifiants plus simple. Surtout, le Credential Manager a été mis à jour pour prendre en charge les passkeys (dans la DP1), comme nous l’indiquions dans notre Brief. Puisque les gestionnaires se mettent graduellement au pas sur ce point, leurs utilisateurs pourront synchroniser leurs passkeys dans ces derniers, au lieu d’utiliser un compte Google qui pourrait les limiter en fonction de leurs besoins.

Et toujours sous le capot

Puisque l’on est dans une Developer Preview, la majorité des apports concernent donc les développeurs directement et seront « invisibles ».

Par exemple, des restrictions ont été instaurées sous Android 10 (niveau 29 d’API) pour limiter le démarrage d’activités en arrière-plan par les applications. Elles posaient en effet certains problèmes, comme l’interruption intempestive de l’expérience utilisateur. Pour réduire encore davantage ce phénomène, Android 14 donne aux applications au premier plan davantage de contrôle sur leur capacité à interagir avec d’autres applications pour lancer des activités en arrière-plan. Elles devront notamment accorder des privilèges pour ces lancements.

Changement également pour les notifications utilisant FLAG_ONGOING_EVENT, qui seront désormais rejetables par l’utilisateur, tant que l’appareil utilisé est déverrouillé. Elles resteront fixes dans le cas contraire, et les applications pouvant interagir avec les notifications ne pourront pas non plus agir dessus. Les notifications importantes, comme celles provenant du système, gardent leur statut « non-dismissible ».

Les développeurs vont pouvoir en outre récupérer plus facilement les paramètres régionaux de l’utilisateur (Celsius ou Farenheit, premier jour de la semaine, format des dates, etc.). Ces accès permettront notamment de s’adapter automatiquement en cas de changement, par exemple quand une personne reste assez longtemps dans un autre endroit et souhaite adapter ses habitudes.

Android 14 introduit aussi plusieurs nouvelles API à destination des boutiques alternatives d’applications. On trouve par exemple la méthode requestUserPreapproval() qui diffère le téléchargement des fichiers APK après l’approbation d’installation par l’utilisateur, setRequestUpdateOwnership() qui permet aux installeurs de préciser qu’ils s’occuperont eux-mêmes des prochaines mises à jour, ou encore setDontKillApp() qui peut installer des fonctions optionnelles d’une application en s’appuyant sur des APK fractionnés.

Google dit également avoir encore simplifié le travail de mise à jour de la compatibilité en rendant optionnels (opt-in) les modifications dans les applications. L’éditeur ajoute être en demande désormais des retours sur les changements dans les API et la manière dont ils affectent les applications. Il met en avant ses tests de compatibilité, pour se donner le temps d’adapter le code si besoin.

La version finale en test pendant l'été

Google ajoute que la stabilité de la plateforme devrait être atteinte en juin. De là, il faudra encore plusieurs semaines pour que le système entre dans sa phase finale de test. C’est l’occasion de rappeler qu’à l’instar des versions précédentes, ces Developer Previews ne touchent presque pas à l’interface ou aux éléments visibles par les utilisateurs. Ces derniers apparaîtront dans les bêtas, qui devraient commencer en avril.

Ces préversions ne fonctionnent pour l’instant que sur les Pixel 7 Pro, Pixel 7, Pixel 6a, Pixel 6 Pro, Pixel 6, Pixel 5a 5G, Pixel 5 et Pixel 4a (5G). Pour se faire une idée, il est également possible de télécharger la dernière préversion d’Android Studio et se servir de l’Emulator.