L'image générique du noyau de Google est la prochaine étape vers la résolution du problème de fragmentation d'Android

Google s'efforce de réduire la fragmentation sur Android depuis des années, même si cela s'explique en partie par la nature inhérente d'Android et par l'épée à double tranchant du choix et de la liberté. Il existe d’innombrables constructeurs OEM actifs dans le domaine, 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 mettent du temps à être déployées à tous les niveaux, 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 triple. Annoncé aux côtés d'Android 8.0 Oreo en 2017, Project Treble a modularisé Android en séparant le cadre du système d'exploitation de l'implémentation du fournisseur (HAL et le fork du 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 mises à jour majeures du système d’exploitation.

La prochaine étape des plans de Google consistait à rationaliser la livraison des mises à jour des composants clés d’Android. Google a appelé cette initiative Ligne principale du projet lorsqu'il l'a présenté aux côtés d'Android 10 en 2019. Google a essentiellement pris le contrôle des composants clés du système d'exploitation et a 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.

Cependant, en ce qui concerne Treble, le noyau Linux ne devrait pas, de manière réaliste, être regroupé avec le code d'un 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 se concentre désormais sur le noyau Linux que les OEM livrent avec leurs appareils. Pour le contexte, Google transforme chaque noyau Linux principal en 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 se lancent ensuite que 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 expédier.

Le diagramme ci-dessus montre comment le noyau d'un périphérique passe par plusieurs couches de changements qui l'éloignent du noyau Linux LTS. Pour simplifier, nous commençons par le noyau Linux, et il est fusionné dans le noyau commun Android avec quelques modifications. À partir de là, le noyau commun Android 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 d’un périphérique est très éloigné du noyau Linux LTS avec lequel il a démarré.

En raison de tous ces forks, jusqu'à 50 % du code exécuté sur un appareil Android est du code hors arborescence, ce qui signifie qu'il ne provient pas des noyaux communs Linux ou AOSP en amont. Cela rend incroyablement difficile (sans parler du temps et des coûts) la fusion des modifications en amont. Pour les OEM, rien n’incite à le faire, mais cette pratique peut nuire à la sécurité des appareils. C'est également la raison pour laquelle de nombreux appareils Android restent sur les anciennes versions du noyau LTS, ce qui a pour effet secondaire que les appareils perdent 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 propose 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 datant déjà d'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 nécessitant 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 cela peut freiner la plateforme.

Par exemple, Code Aurora Forum, ou CAF en abrégé, héberge le code source de divers SoC Qualcomm Snapdragon. Qualcomm, en tant que SoC fournisseur, distribue une version forkée du noyau Linux aux OEM/ODM, et ces sociétés ajoutent ensuite des modifications spécifiques au périphérique lors de l'expédition. dispositifs. C’est ce qui ajoute plusieurs niveaux 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 pur AOSP, c'est pourquoi vous voyez parfois ROM « basées sur CAF » sur nos forums. Vous vous souvenez du Snapdragon 625 qui semblait équiper tant de smartphones de milieu de gamme pendant des années? Celui-ci a été lancé avec le noyau Linux 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) prenant en charge le noyau Linux 4.9. Le problème est que la plupart des constructeurs OEM ne mettra pas à jour les téléphones vers cette nouvelle version du noyau Linux, surtout pas les téléphones de milieu de gamme deux ans après la sortie de la puce. libéré. Certes, il est très rare qu'une mise à jour majeure du noyau comme celle-là se produise en premier lieu, mais le fait est qu'elle a s'est produit, ce n'est donc pas simplement un scénario impossible.

Dans l’ensemble, la fragmentation actuelle d’Android est un véritable désastre, pour le moins. Les dernières tentatives de Google pour remédier à cette fragmentation se présentent sous la forme de l'image générique du noyau, ou GKI.

Présentation de l'image générique du noyau

Afin de remédier à cette fragmentation, Google a travaillé sur l'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 SoC et OEM des modules de plug-in, éliminant ainsi le code hors 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éployer une image de démarrage avec un noyau qui exporte un KMI (Kernel Module Interface) qui est un sous-ensemble du KMI exporté par la GKI, exporte une API d'espace utilisateur qui est un surensemble de l'UAPI exposée par la GKI et prend en charge toutes les fonctionnalités de la GKI correspondante version

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

La série Google Pixel 6 a été lancée avec Android 12 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, il s'agit d'un système bien meilleur que la méthode de mise à jour via OTA, actuellement lourde, bien que cela signifie qu'il est intrinsèquement lié au cadre 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 et par version LTS (actuellement uniquement 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és 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 code spécifique au SoC ou à la carte.

Google souhaite 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 arrive en premier dans le noyau Linux principal, réduisant ainsi la « dette technique » accumulée hors du code hors arbre sur les appareils Android.

L'interface du module noyau (KMI)

L'interface du module 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 principal mais est plutôt déplacée vers 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 désormais du code hors arborescence dans des modules séparés.

Dans le rôle de Ted Kjos expliqué à Lors de la Linux Plumbers Conference de cette année, "le grand effort sur plusieurs années consiste à extraire tout le code spécifique au matériel du noyau générique et à l'intégrer dans les modules du fournisseur. Nous devons avoir une interface stable entre ces modules fournisseurs 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é en flashant l'image de démarrage GKI dans la partition de démarrage et l'image système GSI dans le système cloison. Le 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 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 supplier_boot et supplier. 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 compte y parvenir. Le noyau générique et les modules GKI feront partie de l'AOSP, et le GKI pourra communiquer avec le framework Android et la couche d'abstraction matérielle (HAL) qu'un fournisseur peut implémenter. Le code propriétaire spécifique qu'un fournisseur souhaite inclure dans le noyau (par exemple, les pilotes de caméra) sera plutôt transféré dans un module fournisseur qui devient une extension du GKI via le KMI.

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

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

Mais est-ce que ça aidera? Cela devrait être le cas, même s’il s’agira probablement d’une affaire pluriannuelle qui portera ses fruits visibles plus tard. Cela ne s’appliquera qu’aux appareils lancés avec Android 12, ce qui signifie que nous verrons des appareils sans GKI dans les années à venir. C'était également une critique du Project Treble lors de son annonce, même si évidemment tous les appareils lancés aujourd'hui le prennent en charge. Ces choses prennent du temps, et à mesure que Google prend lentement les rênes d'Android, le processus de développement est facilité pour tous les constructeurs OEM du pays. l'écosystème Android, même si certains d'entre eux préfèrent conserver le contrôle total du noyau Linux utilisé sur Android smartphones.