Android Oreo

Pour Android O, les développeurs ont du pain sur la planche:

• les services en tâche de fond sont limités;
• les background receivers ne peuvent plus être déclarés dans le manifest pour les intents implcites;
• les icônes doivent être changées pour adhérer au nouveau look;
• les notifications peuvent maintenant être postées dans des canaux;
• et il y a quelques nouveautés comme le mode « Picture in picture »

Edit: Android 8.0 Oreo est sorti pout le public le 21 août 2017.

Limites sur les services en tâche de fond

Afin d’économiser la batterie des appareils, les applications sont maintenant soumises à de fortes restrictions.

Tout va bien quand l’application est en foreground, c’est-à-dire quand l’application

• a une activité visible
• a un service foreground, visible pour l’utilisateur par une notification
• a un service utilisé par une autre application foreground

En effet, une application en foreground peut lancer un service.

Une application en foreground peut aussi créer un service foreground avec la nouvelle méthode startForegroundService(). Un tel service apparaît comme une notification à l’utilisateur. C’est par exemple ce que fait un lecture de musique.

Par contre, quand ces conditions ne sont plus respectées, l’application est en background, puis après quelques minutes passe en mode idle. Et là c’est le drame: les services en background sont purement et simplement arrêtés. Par ailleurs, il n’est plus possible de promouvoir un service de background à foregound.

Donc, si vous avez des background services, il va falloir les réécrire:

• Soit vous les transformez en services foreground. Mais si vous vouliez un foreground service, vous l’aviez déjà probablement avant.
• Soit il s’agit bien d’une tâche de fond que l’utilisateur n’a pas besoin de voir, et dans ce cas vous devez le remplacer par un autre chose, par un exemple un appel au JobScheduler

Limitations sur les broadcast receivers

De même, les broadcast receivers implicites dans le manifest étaient catastrophiques pour la mémoire: en particulier, de nombreuses applications souscrivaient à <a href="https://developer.android.com/reference/android/net/ConnectivityManager.html#CONNECTIVITY_ACTION" rel="noopener" target="_blank">android.net.conn.CONNECTIVITY_CHANGE</a>. Dès lors, dès que l’appareil changeait de réseau (changement de point Wifi, passage en 4G, etc.), toutes ces applications étaient créés pour invoquer leur broadcast receiver. Comme l’appareil n’a pas assez de mémoire, ces applications avaient tendances à tuer les applications récemment utilisées par l’utilisateur, causant leur redémarrage au prochain usage.

Android Nougat a arrêté de supporter CONNECTIVITY_CHANGE dans le manifeste.

Android O renforce la contrainte: plus aucun broadcast receiver implicite ne peut être déclaré dans le manifeste.

Cependant, Ii est toujours possible de recevoir des broadcasts explicites, c’est-à-dire ce qui déclarent une application. Et il est toujours possible d’enregistrer un broadcast receiver de façon programmatique, qu’il soit explicite ou implicite.

Les icônes adaptatives

Certains launchers ont des icônes transparentes (par défaut auparavant), d’autres avec un fond rond, d’autres avec un fond carré, etc. Plutôt que de laisser le lancer d’applications implémenter des hacks, les icônes adaptatives décrivent comment l’icône de l’application s’adapte selon les désidératas du lanceur.

L’idée est d’harmoniser l’apparence du launcher. Pour moi, c’est un gros échec: d’abord parce que seules les applications écrites pour O sont adaptatives; l’icône des autres est inchangée. Au lieu d’harmonie (de belles icônes transparentes), le lanceur Google est hideux: les apps Google sont dans des cercles blanc (c’est la nouvelle mode) alors que les apps non mises à jour sont transparentes.

Par ailleurs, j’aimais les belles icônes transparentes (Play store, Calendar, camera, Drive, etc.) Je trouve très moche qu’elles soient maintenant contraintes dans un petit rond.

Picture-in-picture

Si votre application affiche des vidéos le mode picture-in-picture est pour vous!

À noter: une application peut entrer en mode pip de façon programmatique; mais elle ne peut en sortir elle-même. Seul l’utilisateur peut restaurer le mode plein écran.

Notification channels

Si votre application publie beaucoup de notifications, les canaux y mettront un peu d’ordre. Par exemple, un réseau social pourrait créer un canal pour les notifications de message personnel, les invitations à rejoindre des groupes, les messages dans des groupes, les identifications sur des photos, les événements, etc.

L’utilisateur est alors libre dans les paramètres d’Android d’activer ou désactiver les notifications de ces différents canaux.

Évidemment, il faut ré-écrire la façon dont vos notification sont postées…

Downloadable fonts

Ce mécanisme permet à une application de demander à une autre de lui fournir une police de caractères. J’imagine que Google Play services va ainsi offrir quelques polices courantes.

En un mot

Cela représente beaucoup de travail pour les développeurs d’application, mais un réel bénéfice pour les utilisateurs avec un usage de la batterie réduit.

La vraie question est: est-ce que les développeurs d’applications vont se donner la peine de ce travail, vu le peu de fonctionnalités qu’ils ont par ailleurs à gagner?