Google prévoit de passer à un modèle de développement « en amont d'abord » pour les fonctionnalités du noyau Linux sous Android à partir de 2023. Continuez à lire pour en savoir plus.
Lorsque vous voyez les mots « Android » et « fragmentation » dans la même phrase, votre esprit saute probablement immédiatement à l'idée suivante: Tableau de répartition des versions d'Android. Il existe quelques entités sur lesquelles la plupart des gens pointent du doigt lorsqu'ils se plaignent de la lenteur du déploiement généralisé des mises à jour du système d'exploitation Android, mais Google ne peut pas faire grand-chose pour le faire. forcer Les OEM doivent développer et déployer les mises à jour plus rapidement. Ce que Google peut cependant faire, c'est réduire le temps de développement et donc le coût de déploiement des mises à jour.
La première initiative majeure du projet à long terme de Google visant à réduire les charges de développement est 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.
Mais ce qui va suivre est encore plus important et constitue sans doute la partie la plus importante de la stratégie à long terme de Google. Lorsque nous avons souligné plus tôt comment Treble avait modularisé Android en séparant le cadre du système d'exploitation du implémentation du fournisseur, nous avons inclus le « fork du noyau Linux spécifique au périphérique » dans le cadre de ce fournisseur code. Quiconque est familier avec Linux sur les ordinateurs de bureau y reconnaîtra un problème: pourquoi est-il regroupé avec le code d'un fournisseur fermé? Le problème est que même si les appareils Android sont livrés avec le noyau Linux, ce noyau comporte un parcelle de code hors arbre.
Comment en sommes-nous arrivés là? Le problème, tel que décrit par l'ingénieur logiciel de Google, Todd Kjos, à la conférence des plombiers Linux de cette année (via ArsTechnica), c'est parce que le noyau Linux principal est dupliqué plusieurs fois avant d'être livré sur un appareil Android. Google transforme chaque noyau Linux principal en un "Noyau commun Android", 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.
En raison de ces changements, "jusqu'à 50 % du code exécuté sur un appareil est du code hors arborescence (et non issu des noyaux communs Linux ou AOSP en amont)", selon Google. La grande quantité de code hors arborescence sur ces appareils fait de la fusion des modifications en amont un processus long et difficile. Cela nuit à la sécurité des appareils, car les OEM doivent redoubler d'efforts pour mettre en œuvre des correctifs aux vulnérabilités découvertes dans le noyau Linux. De plus, la plupart des appareils Android utilisent des versions de noyau vieilles de plusieurs années, ce qui signifie qu'ils manquent des nouvelles fonctionnalités du noyau Linux.
Afin de résoudre ce problème, Google travaille sur l'Android Generic Kernel Image (GKI), qui est essentiellement 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.
Selon nos sources, les appareils qui se lancent avec Android 12 et livré avec le noyau Linux 5.10 doit déployer une image de démarrage signée par Google. Le propre de Google Pixel 6 La série sera lancée avec Android 12 prêt à l'emploi et sera livrée avec le noyau Linux 5.10, de sorte que les deux téléphones pourraient être les premiers appareils grand public à être livrés avec un GKI.
En outre, Todd Kjos de Google a révélé que la société prévoyait de passer à un modèle de développement « en amont d'abord » pour les nouvelles fonctionnalités du noyau Linux. Cela aidera Google à garantir que le nouveau code arrive en premier dans le noyau Linux principal, ce qui réduira la dette technique future résultant de l'atterrissage d'un plus grand nombre de codes hors de l'arborescence sur les appareils Android.
Lors de la Linux Plumbers Conference cette semaine, Kjos a déclaré: "Étant donné que les modules hors arborescence sont vraiment importants pour notre cas d'utilisation, nous nous attendons à toujours avoir un ensemble d'exportations et certaines choses qui sont différentes ou en plus de ce qui est prévu. en amont, mais l'ensemble de ce projet est un projet pluriannuel visant à éliminer autant de correctifs hors arborescence que possible et à s'aligner autant que possible sur en amont." Google vise à achever ses travaux visant à mettre en amont les fonctionnalités existantes et à isoler les changements de fournisseurs d'ici fin 2022. et, à partir de 2023, l'entreprise prévoit d'adopter ce modèle de développement « en amont d'abord » pour éviter de tels problèmes dans le avenir.