Tout ce que vous devez savoir sur le Project Mainline d'Android

L'un des plus grands changements d'Android ces dernières années qui a volé sous le radar, relativement parlant contre son importance, a été l'introduction de Ligne principale du projet sous Androïd 10. Google rend obligatoire l'inclusion de modules Mainline spécifiques dans les versions d'Android, avec Android 11 venir avec un total obligatoire combiné de 25 modules Mainline. Voici une explication sur ce qu'est Project Mainline et ce qu'il vise à résoudre, ainsi qu'une liste de tous les modules Project Mainline d'Android.

Qu'est-ce que le projet Mainline?

Pour bien comprendre Project Mainline, il va falloir revenir un peu en arrière. Si vous revenez quelques années en arrière, une grande partie de la conversation autour des mises à jour Android était centrée sur le problème de la fragmentation. La fragmentation était l'un des plus grands défis que Google devait résoudre sur Android à l'époque de l'ère Ice Cream Sandwich - Lollipop. Même si Android en tant que plate-forme recevait des mises à jour régulières selon un schéma largement prévisible, ces mises à jour mettaient très longtemps à parvenir aux consommateurs finaux, voire pas du tout. Ainsi, alors que Google corrigeait des bogues critiques et des problèmes de sécurité au niveau de la plate-forme, le déploiement réel de ces modifications laissait beaucoup à désirer. Il y avait / il y a beaucoup d'intermédiaires (fournisseur de SoC, OEM, transporteurs, etc.) et beaucoup de pièces mobiles impliquées dans la livraison des mises à jour à votre téléphone, et le problème de fragmentation n'est pas apparu comme s'il se résolvait sans nécessiter de coups durs interventions.

L'un des efforts majeurs pour résoudre ce problème a pris la forme de Projet Treble aux côtés d'Android 8.0 Oreo, qui impliquait une réarchitecture majeure d'Android, séparant les composants du framework du système d'exploitation Android des HAL du fournisseur et du noyau Linux. Project Treble, en substance, a modularisé Android en séparant le cadre du système d'exploitation du logiciel de niveau inférieur spécifique à l'appareil. De cette façon, les fabricants d'appareils (OEM) n'ont pas besoin d'attendre que les fabricants de silicium (fournisseur de SoC) mettent à jour le code d'implémentation de leur fournisseur, et les OEM peuvent mettre à jour le cadre du système d'exploitation Android indépendamment. Le résultat final est une adoption plus rapide des nouvelles versions d'Android de l'OEM, car elles n'ont plus besoin de attendez que l'intermédiaire (fournisseur de SoC) ait terminé son travail avant de pouvoir commencer à le faire les leurs.

Bien que la situation de mise à jour d'Android ne se soit pas considérablement améliorée dès le départ avec Project Treble, elle a largement permis à un OEM plus large la participation aux versions bêta d'Android 10 et d'Android 11, ainsi que la possibilité pour les équipementiers de mettre à jour plus rapidement un plus grand nombre de leurs appareils calendrier. De plus, tout le concept du GSI (Generic System Image) a eu un impact majeur sur le développement du marché secondaire sur nos forums.

Le développeur démarre Android 11 sur 22 appareils plus anciens avec un Project Treble GSI

Project Mainline prolonge les efforts de Project Treble. Alors que Treble a réduit la dépendance des OEM vis-à-vis des fournisseurs de SoC pour chaque mise à jour du système d'exploitation, Mainline réduit la dépendance de Google vis-à-vis des OEM pour fournir des mises à jour de sécurité aux composants clés du système d'exploitation. Project Mainline étend la philosophie Treble à des parties plus critiques du framework Android, supprimant les OEM en tant qu'intermédiaires dépendants de cette équation. Le but de Project Mainline est que Google prenne le contrôle des composants du framework et des applications système qui sont essentiel à la sécurité et au maintien de la cohérence du développement loin des OEM. Project Mainline est à juste titre appelé le le plus grand changement apporté à Android depuis Project Treble.

Pour le projet Mainline, Google utilise des modules Mainline fournis via le cadre des services Google Play et le Google Play Store. Chaque module Mainline est livré sous forme de fichier APK, de fichier APEX ou de fichier APK-in-APEX. Lorsqu'un module Mainline est mis à jour, l'utilisateur voit une notification "Google Play System Update" (GPSU) sur son appareil. En effet, pour fournir des mises à jour aux composants critiques, Google a contourné la nécessité d'attendre qu'un OEM déploie une mise à jour, choisissant de faire la tâche lui-même.

Comme États de Google sur le site Web d'Android:

Les composants système modulaires permettent aux partenaires Google et Android de diffuser largement, rapidement et de manière transparente les mises à jour sur les appareils des utilisateurs finaux de manière non intrusive. Par exemple, la combinaison de la fragmentation du codec multimédia et des bogues critiques peut considérablement ralentir l'adoption des applications et l'engagement des utilisateurs. Des mises à jour fréquentes des modules liés aux médias peuvent réduire la fragmentation des codecs pour rendre le comportement des applications multimédias plus cohérent sur différents appareils Android et corriger des bogues critiques pour renforcer la confiance des utilisateurs.

Android 10 ou supérieur convertit les composants système sélectionnés en modules, dont certains utilisent le format de conteneur APEX (introduit dans Android 10) et dont certains utilisent le format APK. L'architecture modulaire permet aux composants du système d'être mis à jour avec des correctifs de bogues critiques et d'autres améliorations au besoin, sans affecter les implémentations des fournisseurs de niveau inférieur ou les applications de niveau supérieur et prestations de service.

Comme Ars Technica mentionne:

Le projet Mainline, alias "Google Play System Updates", a été introduit dans Android 10 dans le cadre d'un effort majeur visant à rendre les composants système de base d'Android plus modulaires et pouvant être mis à jour. Mainline a introduit un nouveau type de fichier "APEX" spécifiquement pour les composants du système, dans le but d'expédier le code Android principal via le Play Store aussi facilement que vous expédiez une mise à jour d'application. Auparavant, le seul bloc de code livrable d'Android était l'APK, un type de fichier conçu à l'origine pour les applications tierces. Cela s'accompagnait de toutes sortes de restrictions de sécurité et ne pouvait démarrer que tard dans le processus de démarrage. APEX a donc été créé avec des composants système plus puissants à l'esprit. Les APEX ne peuvent être créés que par Google ou le fabricant de votre appareil. Ils peuvent donc être nettement plus puissants et héberger des composants de démarrage critiques tels que l'environnement d'exécution de l'application.

Mainline n'est pas seulement une solution technique, il s'agit également de faire en sorte que davantage de parties d'Android soient distribuées de manière centralisée par Google, qui consiste à négocier avec les fabricants d'appareils et à les amener tous à accepter d'expédier le même bloc de code. Les modules Mainline deviennent finalement obligatoires à expédier, donc Mainline est en fait une grande collaboration avec les fabricants d'appareils pour s'assurer qu'un seul module à l'échelle de l'écosystème répond aux besoins de chacun. Tous les modules Mainline ne sont pas des modules APEX ultra-puissants, certains ne sont que des APK qui sont désormais du code Android distribué par Google.

Ligne principale du projet — Modules

Avec Android 10, Google a mandaté l'inclusion de 13 modules Mainline spécifiques. Avec Android 11, le nombre total de modules obligatoires est de 25. Voici la liste complète, accompagnée de quelques détails clés:

Pour fournir un contexte aux colonnes ci-dessus, la colonne intitulée "Appareil mis à niveau ou lancé avec Android 11" inclut des détails indiquant si le module doit être présent (ou ne doit pas être présent, en cas de données de fuseau horaire en raison de l'inclusion de son alternative) sur tous les appareils qui ont été mis à niveau vers Android 11 ou qui se lancent avec Android 11 hors du boîte. De même, les appareils lancés avec Android 10 doivent inclure quelques modules, il est fortement recommandé d'en inclure quelques autres et ne sont pas pris en charge par les autres. Pour les appareils mis à niveau vers Android 10 (par opposition à ceux lancés avec Android), la liste des modules requis est plus courte.

Que fait chaque module Mainline?

Voici une brève explication pour chacun des modules Mainline :

Adbd

Le module adbd gère les sessions de débogage adb et IDE en ligne de commande. La modularisation d'adbd permet à Google d'apporter plus rapidement des améliorations de performances et des corrections de bogues. Ceci est crucial car certains bogues dans le passé étaient liés à l'épuisement de la batterie et pouvaient amener les appareils à continuer à utiliser 100% du processeur jusqu'à ce que le téléphone meure. Il est donc crucial pour Google d'obtenir ces correctifs, car adb est largement utilisé par les développeurs d'applications et les OEM pour les tests.

Exécution de l'API des réseaux de neurones Android

Il s'agit d'une bibliothèque située entre une application et des pilotes principaux. L'API est à son tour une API Android C pour exécuter des opérations d'apprentissage automatique à forte intensité de calcul sur des appareils mobiles et pour permettre des opérations d'inférence accélérées par le matériel.

Diffusion cellulaire

La diffusion cellulaire fait référence aux alertes d'urgence et non urgentes (telles que les alertes AMBER). Ce module concerne les tâches liées à ces alertes, ainsi que d'autres fonctions auxiliaires telles que le décodage des SMS et le géofencing pour les alertes d'urgence sans fil.

Conscrypter

Le module Conscrypt gère l'implémentation TLS d'Android et d'autres fonctions cryptographiques telles que les générateurs de clés, les chiffrements et les résumés de messages. L'expédier en tant que module permet à Google d'accélérer les améliorations de sécurité, sans avoir besoin de s'appuyer sur les mises à jour OTA.

Résolveur DNS

Comme son nom l'indique, le résolveur DNS résout le DNS, c'est-à-dire qu'il convertit les URL lisibles par l'homme en adresses IP. Le module contient le code qui implémente le résolveur de stub DNS, et l'expédier sous forme de module permet à Google de fournir une meilleure protection des utilisateurs contre l'interception DNS et les attaques de mise à jour de configuration.

Interface utilisateur des documents

L'interface utilisateur des documents est le module chargé de contrôler l'accès à des fichiers spécifiques pour les composants qui gèrent les autorisations de document. Comme l'indique Google, faire de l'accès au stockage et des autorisations un module augmente la confidentialité et la sécurité des utilisateurs finaux, tandis que la fonctionnalité de superposition de ressources d'exécution (RRO) permet aux OEM de thématiser l'expérience (en se référant à l'application Fichiers) s'ils en ont besoin pour. En tant que module, tous les appareils Google-Android seront livrés avec la même expérience d'interface utilisateur Documents.

Services Ext

Ce module comprend des composants de structure pour les fonctionnalités de base du système d'exploitation telles que le classement des notifications, les stratégies de correspondance de texte de remplissage automatique, le cache de stockage, le chien de garde des packages et d'autres services.

Bibliothèque IPsec/IKEv2

Ce module de bibliothèque s'intéresse aux fonctionnalités nouvelles et existantes autour de l'interfonctionnement LAN sans fil (IWLAN) et les VPN, tels que la négociation des paramètres de sécurité tels que les clés, les algorithmes et le tunnel configurations. L'idée de la modularisation de ces fonctions est de promouvoir la cohérence de l'écosystème et de fournir un moyen de fournir des solutions rapides aux problèmes de sécurité et d'interopérabilité.

Ce sont trois modules bifurqués, mais ils ont des fonctions qui dépendent les unes des autres. Ces modules multimédias gèrent les types et codes multimédias, interagissent avec l'ExoPlayer, exposent les contrôles de transport et les informations de lecture au framework, optimisent les métadonnées indexées, etc. Se souvenir Stagefright, l'exploit qui a changé Android et a amené le concept même de mises à jour de sécurité mensuelles sur la plate-forme? Cet exploit reposait sur des vulnérabilités au sein de la bibliothèque de lecture multimédia. Ainsi une modularisation des composants médias permet à Google de réagir rapidement et largement en cas de bugs de sécurité détectés dans ce composant souvent ciblé.

La fonction de ce module ressort immédiatement de son nom, même si son objectif ne l'est pas. Le module Métadonnées du module contient... des métadonnées sur la liste des modules de l'appareil. Et c'est à peu près tout.

Composants de la pile réseau, configuration des autorisations de la pile réseau, connexion au portail captif

Le module Network Stack Components fournit des services IP communs, la surveillance de la connectivité réseau et la détection du portail de connexion captif. Le module de configuration des autorisations définit l'autorisation qui permet aux autres modules d'effectuer des tâches liées au réseau. Le module de connexion au portail captif traite des portails captifs - pages Web qui s'affichent lorsque connecté à certains réseaux Wi-Fi publics, où l'utilisateur est invité à entrer des détails pour accéder à Internet accès.

Contrôleur d'autorisation

Ce module fournit des politiques de confidentialité et des éléments d'interface utilisateur pouvant être mis à jour concernant l'octroi et la gestion des autorisations. Si cela semble familier à ce que fait Package Installer, c'est parce que c'est le cas. Des fonctions telles que l'octroi d'autorisations d'exécution, la gestion et le suivi de l'utilisation faisaient partie de l'application Package Installer jusqu'à Android 9. Dans Android 10, l'application Package Installer est divisée en sections pour permettre la mise à jour de la logique des autorisations. Le module Permission Controller est fourni sous forme de fichier APK et, dans Android 11, le module peut révoquer automatiquement les autorisations d'exécution pour les applications qui n'ont pas été utilisées pendant une période prolongée.

Extensions SDK

Ce module est un peu difficile à comprendre et par conséquent à expliquer. Chaque version d'Android se voit attribuer un niveau de SDK (généralement +1 par rapport à son prédécesseur). Lorsqu'une application cible un SDK particulier, on suppose que le développeur a pris en compte les changements de comportement et d'API de la plate-forme apportés par la version Android.

Le module SDK Extensions décide du niveau "extension SDK" de l'appareil et expose les API pour que les applications interrogent le niveau d'extension SDK. C'est à peu près tout ce que mentionne la documentation officielle. Ars Technica, cependant, mentionne qu'il s'agit probablement d'une couche d'API secondaire qui sera expédiée via le Play Store.

Statsd, paquet de version de train de télémétrie

Statsd est responsable de la collecte des métriques des appareils. Le package Telemetry Train Version, en revanche, ne contient pas de code actif ni de fonctionnalité propre. Il contient simplement un numéro de version pour le "Telemetry Train" qui, selon Google, est un ensemble de modules liés aux métriques. En fonction du numéro de version, Google Play affiche la version du correctif de sécurité aux utilisateurs finaux et détermine si des mises à jour sont disponibles pour les modules liés aux métriques.

Partage de connexion

Le module Tethering partage la connexion Internet de l'appareil avec d'autres appareils clients connectés via Wi-Fi, USB, Bluetooth ou Ethernet. Le module comprend les composants de connexion et leurs dépendances. En utilisant ce module Tethering, les OEM peuvent s'appuyer sur une implémentation de référence unique et standard et apporter une expérience cohérente sur tous les appareils.

Données de fuseau horaire

Le module de données de fuseau horaire met à jour l'heure d'été (DST) et les fuseaux horaires sur les appareils Android, normalisant à la fois les données (qui peuvent et change assez fréquemment en réponse à des raisons religieuses, politiques et géopolitiques) et le mécanisme de mise à jour à travers l'écosystème. Android 8.1 et Android 9 utilisaient un mécanisme de mise à jour des données de fuseau horaire basé sur APK, et Android 10 le remplace par un mécanisme de mise à jour de module basé sur APEX. Google déclare qu'AOSP continue d'inclure le code de plate-forme nécessaire aux mises à jour basées sur APK, donc les appareils mis à niveau vers Android 10 peuvent toujours recevoir des mises à jour des données de fuseau horaire fournies par les partenaires via le APK. Cependant, Google avertit que les mises à jour basées sur APK remplacent une mise à jour basée sur APEX.

Wifi

Il s'agit du module pour la fonctionnalité Wi-Fi. Les utilisateurs finaux peuvent désormais bénéficier d'une expérience Wi-Fi cohérente sur tous les appareils Android, ainsi que de correctifs pour les problèmes d'interopérabilité via les mises à jour de modules, l'application les développeurs peuvent obtenir une fragmentation réduite de la plate-forme, et les OEM peuvent répondre aux exigences des opérateurs tout en réduisant les coûts pour les particuliers personnalisations.

---

Espérons que cet article souligne à quel point Project Mainline est important pour l'écosystème Android de Google.