Google travaille depuis des années à réduire la fragmentation sur Android, bien qu’une partie de la cause soit la nature inhérente d’Android et l’épée à double tranchant du choix et de la liberté. Il existe d’innombrables OEM actifs dans l’espace, et tous souhaitent apporter leurs propres modifications à leurs propres appareils. Le problème est alors qu’il semble que les mises à jour du système d’exploitation Android soient lentes à se déployer dans tous les domaines, mais Google ne peut pas faire grand-chose pour forcer les OEM à mettre à jour leurs appareils. En tant que tel, la meilleure chose que Google puisse faire est de rendre le processus de mise à jour aussi simple et fluide que possible.

Soulager la douleur de la mise à jour Android

La première initiative majeure du projet à long terme de Google visant à réduire le fardeau du développement a été Projet Aigus. Annoncé aux côtés d’Android 8.0 Oreo en 2017, Project Treble a modularisé Android en séparant le framework du système d’exploitation de l’implémentation du fournisseur (HAL et le noyau Linux spécifique à l’appareil). Cela a permis aux OEM Android de rebaser plus facilement leurs systèmes d’exploitation sur le dernier framework AOSP, car ils pouvaient démarrer la dernière version sans avoir besoin du code mis à jour des fournisseurs. En conséquence, les OEM pourraient préparer leurs forks Android personnalisés plus rapidement qu’auparavant et, par extension, déployer plus rapidement les principales mises à jour du système d’exploitation.

L’étape suivante des plans de Google consistait à rationaliser la livraison des mises à jour des principaux composants Android. Google a appelé cette initiative Ligne principale du projet lorsqu’il l’a introduit aux côtés d’Android 10 en 2019. Google a essentiellement pris le contrôle des principaux composants du système d’exploitation et interdit aux OEM de les modifier. Ils ont ensuite mis en place un mécanisme de livraison via Google Play afin de pouvoir déployer à distance les mises à jour de ces composants clés sans avoir à attendre que les OEM appliquent eux-mêmes les correctifs. Mainline a considérablement amélioré la rapidité avec laquelle les appareils reçoivent les versions mises à jour des composants importants du système d’exploitation, améliorant ainsi la sécurité de l’écosystème Android dans son ensemble.

En ce qui concerne Treble, cependant, le noyau Linux ne devrait pas être regroupé avec le code fournisseur à source fermée. Todd Kjos à la conférence des plombiers Linux de cette année a expliqué dans le passé les difficultés rencontrées en matière de fragmentation sur Android, et une grande partie de celle-ci se concentre maintenant sur le noyau Linux que les OEM livrent avec leurs appareils. Pour le contexte, Google divise chaque noyau Linux principal dans un « Noyau commun Android” (ACK), qui suit de près la version principale mais ajoute quelques correctifs spécifiques à Android. Les fournisseurs de SoC comme Qualcomm, MediaTek et Samsung fork cette noyau pour chaque SoC qu’ils fabriquent. Les OEM prennent ensuite ce noyau spécifique au SoC et ajoutent des correctifs supplémentaires pour implémenter la prise en charge du matériel spécifique qu’ils souhaitent livrer.

Le diagramme ci-dessus montre comment le noyau d’un périphérique passe par plusieurs couches de changement qui l’abstrait loin du noyau Linux LTS. Pour le simplifier, nous commençons par le noyau Linux, et il est fusionné dans le noyau commun Android avec quelques modifications. À partir de là, Android Common Kernel est fusionné dans un noyau de fournisseur (Qualcomm, MediaTek, etc.) avec ses propres modifications et changements. Enfin, le noyau du fournisseur est fusionné dans le noyau spécifique au périphérique d’un OEM. À ce stade, le noyau de n’importe quel périphérique est très éloigné du noyau Linux LTS avec lequel il a commencé.

En raison de tous ces forks, jusqu’à 50 % du code exécuté sur un appareil Android est du code hors de l’arborescence, ce qui signifie qu’il ne provient pas des noyaux communs Linux ou AOSP en amont. Cela rend incroyablement difficile (pour ne pas dire chronophage et coûteux) la fusion des modifications en amont. Pour les OEM, il n’y a aucune incitation à le faire, mais cette pratique peut nuire à la sécurité des appareils. C’est aussi pourquoi de nombreux appareils Android sont laissés sur les anciennes versions du noyau LTS, ce qui a pour effet secondaire de perdre l’accès aux nouvelles fonctionnalités du noyau Linux.

Android est fragmenté, et Google le sait

Google sait très bien qu’il s’agit d’un problème, et a même une section intitulée « Les coûts de la fragmentation » dans la documentation du développeur Android. Google dit que « la plupart des appareils phares sont livrés avec une version du noyau qui a déjà au moins 18 mois ». Pire encore, Google dit aussi que « Android 10 prend en charge les noyaux 3.18, 4.4, 4.9, 4.14 et 4.19, qui dans certains cas n’ont pas été améliorés avec de nouvelles fonctionnalités depuis Android 8 en 2017. » Cela rend difficile l’ajout de fonctionnalités qui nécessitent de nouvelles versions du noyau Linux. Le noyau Linux 3.18 a été lancé en décembre 2014, à l’époque où Android 5.0 Lollipop était la dernière version d’Android. C’est clairement un problème et peut freiner la plate-forme.

Par exemple, Code Aurora Forum, ou CAF en abrégé, héberge le code source de divers SoC Qualcomm Snapdragon. Qualcomm, en tant que fournisseur de SoC, distribue une version fourchue du noyau Linux aux OEM/ODM, et ces sociétés ajoutent ensuite des modifications spécifiques aux appareils sur les appareils d’expédition. C’est ce qui ajoute plusieurs couches de fragmentation. De plus, Qualcomm apporte des modifications au cadre AOSP pour optimiser Android pour chacune des plates-formes mobiles Snapdragon de l’entreprise. Qualcomm distribue en privé son noyau Linux modifié, son framework AOSP et d’autres outils logiciels à ses partenaires dans le cadre d’un Board Support Package, ou BSP. CAF est l’endroit où Qualcomm publie publiquement ces modifications du noyau Linux et les modifications du cadre AOSP.

Cette version CAF peut être utile pour les développeurs de ROM personnalisées qui souhaitent l’utiliser comme point de départ plutôt que comme AOSP pur, c’est pourquoi vous voyez parfois Des ROM « basées sur le CAF » sur nos forums. Vous vous souvenez du Snapdragon 625 qui semblait alimenter tant de smartphones de milieu de gamme pendant des années ? Cela a été lancé avec Linux Kernel 3.18, et ce n’est que vers la fin de 2018 (deux ans après le lancement du chipset) que Qualcomm a mis à jour les sources du noyau et les a publiées sur FAC pour msm8953 (le nom du chipset du Snapdragon 625) apportant la prise en charge du noyau Linux 4.9. Le problème est que la plupart des OEM ne mettront pas à jour les téléphones vers cette nouvelle version du noyau Linux, en particulier les téléphones de milieu de gamme deux ans après la sortie de la puce. Certes, il est très rare qu’une mise à jour majeure du noyau comme celle-ci se produise même en premier lieu, mais le fait est qu’elle a arrivé, ce n’est donc pas seulement un scénario impossible.

Dans l’ensemble, la fragmentation actuelle d’Android est un gâchis, pour le dire à la légère. Les dernières tentatives de Google pour corriger cette fragmentation se présentent sous la forme de l’image générique du noyau, ou GKI.

Présentation de l’image de noyau générique

Afin de remédier à cette fragmentation, Google a travaillé sur Android Generic Kernel Image (GKI). Il s’agit essentiellement d’un noyau compilé directement à partir d’une branche ACK. Le GKI isole les personnalisations des fournisseurs de SoC et des OEM aux modules de plug-in, éliminant le code hors de l’arborescence et permettant à Google de transmettre les mises à jour du noyau directement à l’utilisateur final. Depuis plus d’un an, Google travaille sur un moyen de fournir des mises à jour GKI via le Play Store, grâce à l’utilisation d’un module Mainline.

Par conséquent, les appareils lancés avec Android 12 et exécutant le noyau Linux 5.10.43 ou supérieur doivent effectuer l’une des opérations suivantes : selon Mishaal Rahman.

• Déployer une image de démarrage signée par Google

OU

• Déployez une image de démarrage avec un noyau qui exporte un KMI (Kernel Module Interface) qui est un sous-ensemble du KMI exporté par le GKI, exporte une API d’espace utilisateur qui est un sur-ensemble de l’UAPI exposé par le GKI et prend en charge toutes les fonctionnalités du correspondant Version GKI

Les fournisseurs peuvent créer des modules qui se connectent au GKI, mais l’idée du GKI est que Google assume la responsabilité de gérer les modifications du noyau. L’interface du module du noyau (ou KMI, plus à ce sujet dans les dernières parties de l’article) est effectivement l’endroit où le code hors de l’arbre est censé aller.

La série Google Pixel 6 a été lancée avec Android 12 prêt à l’emploi et est livrée avec le noyau Linux 5.10, et c’est le premier téléphone à être livré avec un GKI. Étant donné que Google pourrait potentiellement mettre à jour le noyau via le Play Store, nous pourrions même voir des mises à jour fréquentes du noyau, car les mises à jour du noyau LTS sont généralement publiées chaque semaine. Quoi qu’il en soit, c’est un bien meilleur système que la méthode actuellement lourde de mise à jour via OTA, bien que cela signifie qu’il est intrinsèquement lié au framework GMS.

Google définit simplement le GKI comme suit :

• Il est construit à partir des sources ACK.
• Il s’agit d’un binaire à noyau unique plus des modules chargeables associés par architecture, par version LTS (actuellement, seul arm64 pour android11-5.4 et android12-5.4).
• Il est testé avec toutes les versions de la plate-forme Android prises en charge pour l’ACK associé. Il n’y a pas de dépréciation de fonctionnalité pendant la durée de vie d’une version du noyau GKI
• Il expose un KMI stable aux pilotes au sein d’un LTS donné.
• Il ne contient pas de SoC ou de code spécifique à la carte.

Google veut même être en mesure d’ici 2023 d’adopter un modèle de développement « en amont d’abord ». Cela aidera Google à garantir que le nouveau code atterrit en premier dans le noyau Linux principal, réduisant ainsi la « dette technique » accumulée dans le code hors de l’arborescence sur les appareils Android.

L’interface du module noyau (KMI)

L’interface du module du noyau, ou KMI, fait partie de la solution de Google à la fragmentation actuelle d’Android. Essentiellement, la prise en charge du SoC et de la carte ne se trouve plus dans le noyau central et est plutôt déplacée dans des modules chargeables. Le noyau et les modules peuvent alors être mis à jour indépendamment, car les modules sont mis à jour dans /lib/modules. Le GKI lui-même est censé être aussi propre et générique que possible, ce qui est rendu possible en déchargeant ce qui est maintenant du code hors de l’arbre dans des modules séparés.

En tant que Ted Kjos expliqué à Lors de la Linux Plumbers Conference de cette année, « le gros effort pluriannuel est d’extraire tout le code spécifique au matériel du noyau générique et dans les modules du fournisseur. Nous devons avoir une interface stable entre ces modules du fournisseur et le noyau générique afin qu’ils puissent être livrés de manière asynchrone. GKI 1.0 est essentiellement un « test de conformité ».

En fait, la compatibilité GKI signifie que l’appareil réussit les tests VTS et CTS-on-GSI+GKI avec l’image système générique (GSI) et le noyau GKI installés en flashant l’image de démarrage GKI dans la partition de démarrage et l’image système GSI dans le partition système. La Vendor Test Suite, ou VTS, est un test automatisé que tous les appareils doivent réussir pour être considérés comme compatibles avec Project Treble. La suite de tests de compatibilité, ou CTS, est requise pour accéder à la suite d’applications de Google.

Les appareils peuvent être livrés avec un noyau de produit différent et peuvent utiliser des modules chargeables que GKI ne fournit pas. Cependant, le produit et les noyaux GKI doivent charger des modules à partir des mêmes partitions vendor_boot et vendor. Par conséquent, tous les noyaux de produits doivent avoir la même interface de module de noyau binaire (KMI).

Le diagramme ci-dessus montre ce que Google veut faire et explique comment il entend y parvenir. Les modules Generic Kernel et GKI feront partie de l’AOSP, et le GKI peut communiquer avec le framework Android et la Hardware Abstraction Layer (HAL) qu’un fournisseur peut implémenter. Le code propriétaire spécifique qu’un fournisseur souhaite dans le noyau (par exemple, les pilotes de caméra) sera à la place poussé dans un module de fournisseur qui devient une extension de la GKI via la KMI.

Comment le GKI peut aider à résoudre le problème de fragmentation d’Android

Google a beaucoup travaillé pour rationaliser le processus de développement des smartphones. Chaque OEM veut sa propre identité de marque, et chaque OEM veut pouvoir être propriétaire de ses appareils. Contrairement au programme Android One, les smartphones Android peuvent être à peu près tout ce qu’ils veulent, tant qu’ils respectent l’ensemble de règles que Google énonce afin de recevoir une licence GMS. Cependant, dans le passé, Google n’a pas fait grand-chose pour régner dans le développement d’appareils Android, avec des changements tels que Project Treble, Mainline et maintenant le GKI étant beaucoup plus récents dans l’histoire d’Android.

Mais cela aidera-t-il? Cela devrait le faire, même si ce sera probablement une affaire de plusieurs années qui portera des fruits visibles plus tard. Cela ne s’appliquera qu’aux appareils lancés avec Android 12, ce qui signifie que nous allons voir des appareils qui n’ont pas de GKI dans les années à venir. C’était aussi une critique de Project Treble lorsque cela a été annoncé, bien que tous les appareils lancés de nos jours le prennent évidemment en charge. Ces choses prennent du temps, et comme Google prend lentement les rênes d’Android, le processus de développement est facilité pour tous les OEM de l’écosystème Android, même si certains d’entre eux préfèrent garder le contrôle total sur le noyau Linux utilisé sur les smartphones Android.