C’est officiel, à partir de ce mois-ci (août 2021 pour ceux qui nous lisent plus tard) le format de déploiement des applications sur le Play Store change !

En effet, Google nous impose désormais de passer par les App Bundle pour déployer une nouvelle application ou une mise à jour.

De nombreux clients nous ont questionnés sur le sujet. Pourquoi ? Quels apports ? Est-ce obligatoire ?

Dans cet article, nous allons prendre un peu de temps pour expliquer tout cela… Tout en essayant de rester très haut niveau pour que cela reste compréhensible à toutes et tous, devs ou non.

Les mises à jour du Play Store, une longue histoire

Régulièrement, les devs et responsables qui s’occupent de la publication et du maintien des applications font en sorte de se tenir à jour de tous ces changements. Ils sont parfois purement techniques, parfois uniquement légaux.

Dans la liste des TOP 3 qu’on retrouve, vous avez déjà dû entendre parler de:

• Mise à jour de la fiche Play Store pour respecter les politiques de confidentialité
• Mise à jour de la version minimum target d’Android (à la différence de la version minimum compatible, on parle ici de pour quelle version cible l’application est « construite)
• Mise à jour de certaines librairies utilisées par le Play Store (souvent Billing, celle qui permet le paiement)

Aujourd’hui, on va s’arrêter sur la 2ème ligne d’août 2021:

New apps and games must publish with the Android App Bundle

Google Play Store Changes Timeline

C’est officiel, à partir d’août, notre bon vieux format APK part à la retraite? (en tout cas pour le Google Play Store)

Une histoire de packaging

L’idée, c’est qu’écrire du code c’est bien, mais arrive un moment ou ce code, il faut l’envoyer aux utilisateurs, normal. Et pour faire ça, on va « packager » notre application.

Sur Windows on va avoir des .exe, sur iOS des .ipa et sur Android des apk pardon, des app bundle (.aab pour Android App Bundle).

Chaque système à son propre système de packaging, sa propre façon de comprendre une application pour la faire tourner.

L’ancêtre APK

APK est présent depuis la genèse d’Android, donc depuis 2008.

Autant vous dire qu’a l’époque, les problématiques n’étaient pas les mêmes dans le développement, les applications étaient simples, sans fioritures graphiques et avec peu de fonctionnalités.

Pour rappel, les applications Android, à l’époque c’était ça :

On est loin des applications qu’on peut voir maintenant.

Cela dit, le principe d’un apk n’a jamais vraiment changé.

D’ailleurs, si on prend un fichier apk, qu’on l’ouvre et qu’on regarde ce qu’il y a dedans, on peut être surpris… ou pas d’ailleurs, parce qu’on y retrouve

• notre code source (compilé)
• nos resources, images, icones, etc
• nos langues
• quelques métadonnées

Rien de bien incroyable somme toutes, on pourrait presque imaginer qu’un zip ferait l’affaire (d’ailleurs on va y revenir).

La route vers le futur

Les années passent, on a vu de plus en plus de constructeurs arriver sur le marché, qui dit plus de constructeurs, dit plus de façons de faire, dit plus de matériel différent.
Et du matériel, pour une application, c’est impactant !

En effet, on doit faire en sorte que notre application parle la même langue que le processeur du téléphone, c’est l’étape de la compilation (pour faire simple).
Hors cette langue, elle n’est pas la même que l’on soit sur du Intel ou du Arm ou autre, du x86 ou du 64 bits. Pas de solution magique ici, il faut « traduire » le code source dans toutes les langues possibles.

En plus, maintenant, on a des téléphones pour toutes les paluches, du grand, du petit, du moyen, du pliable… Et toutes ces tailles d’écrans, il faut pouvoir faire une interface graphique qui s’adapte bien ! (surtout sur l’iconographie et les images pour éviter la pixellisation)

Pour continuer sur notre lancée, quand on publie une application, on ne publie pas une application par pays, ni une application par langue.
Mais désormais, quand on va chercher à atteindre une population « mondiale » avec notre application alors on doit embarquer beaucoup, beaucoup de langues différentes.

Finalement, si on compare les applications de 2008 avec celles de 2021, on peut faire le constat suivant:

• Elles sont plus complètes (plus de features = plus de code)
• Elles sont plus jolies (donc plus d’images, de visuels)
• Elles sont multilangues (donc plusieurs fichiers de traductions)
• Elles sont multi-constructeur (donc plusieurs « compilations »).

Et grosso modo, tout ça, bah il faut l’envoyer à l’utilisateur. Pour faire cela, Android a trouvé un moyen simple : un zip. (je vous avais dit qu’on y reviendrait)

Parce que oui, le format apk c’est un zip renommé, ni plus ni moins.

Et tout ça… Bah ça commence à faire beaucoup, beaucoup d’octets à faire transiter, depuis une dizaine d’années, les applications sont passées de quelques méga-octets (ou dizaine de méga-octets) à plusieurs centaines pour les plus gourmandes.

Une problématique de taille

Plusieurs éléments de réponses:

• Déjà, le stockage.
  Côté serveur, en plus de pas être super écologique, ça coûte cher, donc stocker des millions d’apk, de chacun quelques centaines de mégas, ce n’est pas terrible.
  Mais surtout, côté téléphone, les modèles bas et milieu de gamme ont souvent un stockage réduit pour économiser, donc avoir une grosse application peut être un frein à l’installation.
• Ensuite, la data.
  Aujourd’hui, en tout cas en France, pour beaucoup, on a des forfaits data illimités. On ne se pose plus trop la question de la taille des applications. Ce n’est pas le cas partout… Si on payait au consommé, on serait surement plus regardant. Et encore une fois, les échanges réseaux, ça a un coût monétaire et écologique.
• Enfin, le temps de cerveau (ou de calcul).
  Dans les méthodologies récentes, une grande partie des processus est automatisée. Par exemple le build d’une application. C’est automatisé et ça se fait dans le Cloud, où on achète des minutes de calcul.
  Hors pourquoi payer pour des minutes qui ne seront pas utilisées ? Si notre application n’est que sur tablette, pourquoi payer pour créer un package sur téléphone ?

Toutes ces problématiques, Google en a bien pris conscience, et pour remédier à cela, il a créé il y a quelques années, un nouveau format de packaging.

L’App Bundle à la rescousse

La solution, elle n’est pas si nouvelle que ça….

Dans le console Google Play, les devs avaient déjà la possibilité d’uploader plusieurs apk différents pour plusieurs versions de processeurs différents par exemple.
En revanche, cela nécessitait beaucoup de travail côté dev pour implémenter ce multi-apk et des coûts associés.

Ce que Google a fait, c’est qu’il l’a fait pour nous ! Avec Android App Bundle (aab)

Présenté pour la première fois aux Google I/O 2018, le nouveau format App Bundle permet aux devs de ne faire qu’un seul package, un aab et l’envoyer sur le Play Store.

Mais du coup, comment cela fonctionne côté Android ? Il supportait le format App Bundle depuis le début ? Et bien non, et c’est là que c’est malin.
Pour rendre ce système compatible sur tout le parc Android sans avoir à implémenter un nouveau packaging dans le système Google a imaginé le process suivant:

1. Les devs packagent un App Bundle sans se soucier des tailles d’écrans, processeurs, langues et autre.
2. Les devs envoient cet App Bundle sur le Play Store
3. Lorsqu’un utilisateur veut télécharger l’application, le Play Store analyse le téléphone (ou tablette) et repère : le processeur, la langue, la taille d’écran, etc..
4. En fonction de ces informations, le Play Store va générer (si il n’existe pas déjà) un apk spécialement pour ce triptique (et le stocker) : cet apk est donc léger car il est optimisé spécialement pour une taille d’écran, une langue et un processeur. (NDLR: je simplifie ici, plusieurs apk sont générés en fait, mais le principe est bien celui-ci)
5. Ce même apk est téléchargé par le téléphone et stocké par Google, il sera fourni aux autres modèles du même type.

Avec cette méthode, si aucun utilisateur de votre application n’a d’écran hdpi, les ressources ne sont jamais utilisées dans l’apk !!

APK est mort, vive APK

Pour réussir ce tour de passe-passe, vous imaginez bien que c’est un peu plus compliqué.

Au niveau des devs, plusieurs choses sont à mettre en place, par exemple déléguer la signature des applications au Play Store (cela est lié au fait que App Bundle ne génère pas 1 mais 2 apk minimum par application, hors ces APK doivent avoir la même signature sur Android pour fonctionner)

Si on veut aller plus loin, c’est aussi une porte ouverte vers beaucoup de fonctionnalités qui seront de plus en plus vues sur Android, par exemple

• Les mises à jour d’une partie de l’application uniquement (au lieu de toute l’application)
• Les fonctionnalités « on-demand » introduites par les instant-apps (on ouvre un site et c’est l’application qui s’ouvre, même si elle n’est pas installée)

De plus, cela permet d’augmenter notre cible cliente qu’on risque de perdre à cause de quelques méga-octets de trop.

Ce format est donc l’avenir, et même le présent depuis ce mois d’août 2021.

On peut conclure notre explication sur une dernière remarque
On a concentré toute notre analyse sur le Google Play Store, hors il existe des stores alternatifs (Amazon App Store (Amazon va supporter App Bundle !), Huawei App Gallery et d’autres).
Sur ces stores, le format officiel reste apk… pour l’instant !

On en a fini pour cet article qui, je l’espère, vous aura apporté des clés de compréhension sur le fonctionnement des formats d’applications sur Android, mais aussi un peu plus de « pourquoi » vos équipes de devs vous demandent de migrer une fonctionnalité comme celle là.

Annexes

Voici un peu de resources sur le sujet App Bundle qui m’ont aidé à comprendre et à rédiger cet article:

• https://docs.google.com/document/u/2/d/e/2PACX-1vR6mxjY6z1J3LvAlhhnNDDwKFmfcjcFqfyXZ7UG8RTOX3mMZtw1Snj1YDA-Wfp3IhcghAvjx-fUmtRs/pub
• https://android-developers.googleblog.com/2020/11/new-android-app-bundle-and-target-api.html
• https://android-developers.googleblog.com/2021/06/the-future-of-android-app-bundles-is.html
• https://developer.android.com/platform/technology/app-bundle