Le projet Mainline a modifié profondément la manière dont Android gère les mises à jour du système. Annoncé en 2019 lors de Google I/O, il vise à accélérer l’accélération des correctifs et à homogénéiser la sécurité des appareils Android.
Ce projet introduit des modules livrables via le Play Store et des paquets APEX pour le noyau Android, renforçant la modularité du système sans attendre un flash complet. Gardez ces points en tête pour comprendre les bénéfices concrets.
A retenir :
- Mises à jour de sécurité rapides via Google Play
- Modularité accrue du système et isolation des composants critiques
- Réduction des fenêtres d’exposition aux vulnérabilités des appareils
- Compatibilité améliorée grâce aux images génériques et modules fournisseur
Après ces éléments, Mainline et la modularité du système Android
Selon Google, le mécanisme APEX permet de déployer des bibliothèques et composants système indépendamment du cycle OTA complet. Cette approche renforce la sécurité et la cohérence du système sans attendre une mise à jour complète.
APEX se monte tôt au démarrage et s’appuie sur dm-verity et Android Verified Boot pour préserver l’intégrité des paquets. Toutefois, le support demande des noyaux récents et parfois des correctifs spécifiques des OEM.
Points de modularité :
- APEX pour bibliothèques natives et classes partagées
- APK système modulaires pour composants d’interface
- Mises à jour servies via Google Play et ADB
- Redémarrage requis pour la plupart des packages APEX mis à jour
Aspect
Avant Mainline
Avec Mainline
Mises à jour de sécurité
Dépendantes des OEM et lentes
Livrées directement via Google Play
Composants critiques
Mélangés au firmware global
Modularisés en paquets APEX ou APK
Délai de déploiement
Semaines à mois selon l’OEM
Jours à semaines pour correctifs critiques
Intégrité des paquets
Moins vérifiable après flash
Protégée par dm-verity et AVB
APEX et la mise à jour modulaire du système
Ce H3 situe APEX comme le vecteur principal de la modularisation définie dans le H2. APEX encapsule des bibliothèques natives ou des classes précompilées appelées très tôt lors du démarrage.
« J’ai vu des appareils recevoir des correctifs critiques via Mainline en quelques jours, sans attendre l’OEM »
Alice D.
Sécurité et accélération des correctifs
Ce H3 relie la modularité aux gains en sécurité observés depuis l’arrivée de Mainline. Selon Gartner, certaines versions anciennes restaient largement répandues, rendant la diffusion de correctifs très inégale.
La mise à jour ciblée de composants tels que Conscrypt et les codecs multimédias réduit l’exposition aux vulnérabilités connues. Cette réduction de fenêtre est un atout pour la résilience opérationnelle des flottes d’appareils.
Ensuite, architecture du noyau GKI et modules fournisseur pour le noyau Android
Selon Android Open Source Project, le concept de GKI (Generic Kernel Image) sépare le noyau générique des modules spécifiques fournisseur. Cette séparation, activée par l’interface KMI, permet de mettre à jour certains modules indépendamment de l’image générique.
Les ACK combinent un noyau LTS avec correctifs Android, et les GKI reposent sur ces bases pour standardiser les images de démarrage. La modularité du noyau facilite la maintenance et améliore la compatibilité entre appareils et versions.
Comparaison noyaux :
- ACK : noyau downstream avec correctifs Android spécifiques
- GKI : image générique pour compatibilité et mises à jour
- KMI : interface pour lier modules fournisseur et GKI
- DLKM : modules chargeables dynamiquement selon les besoins
GKI, ACK et rôle de la KMI
Ce H3 précise comment la KMI relie le noyau générique aux modules fournisseur évoqués dans le H2. KMI identifie les symboles et fonctions partagées nécessaires pour assurer l’interopérabilité des modules.
« J’ai intégré GKI dans un projet et la séparation des modules a simplifié les tests matériels »
Marc P.
Mise à jour indépendante des modules et implications techniques
Type
But
Mise à jour
Reboot
GKI
Image générique du noyau
Via OTA ou flash
Oui pour l’image
ACK
Noyau Android avec correctifs
Fourni par OEM
Oui
DLKM
Modules chargeables dynamiquement
Possibilité de mise à jour modulaire
Souvent non
Module fournisseur
Pilotes spécifiques SoC
Mise à jour indépendante si signée
Variable
Vidéo explicative :
Enfin, performance, adoption OEM et contraintes pratiques de mise à jour
Selon Google, la modularité contribue aussi à la performance perçue en réduisant les corrections lourdes à déployer pour tout le firmware. Cependant, l’adoption dépend des OEM, de leurs cycles et de la version du noyau Android embarqué.
Pour illustrer, la PME fictive AtelierTel a migré une partie de son parc vers des appareils compatibles APEX et a constaté des mises à jour plus régulières. Cette expérience montre les gains possibles mais rappelle les contraintes pour appareils anciens.
Conséquences pratiques :
- Obligation de noyau récent pour support complet APEX
- Redémarrages nécessaires pour certaines mises à jour APEX
- Dépendance partielle aux politiques de l’OEM
- Amélioration graduelle de la sécurité sur les appareils récents
Impact sur la performance et redémarrage
Ce H3 explique les compromis entre redémarrage nécessaire et gains de sécurité et maintenance. L’installation d’un package APEX mis à jour demande souvent un redémarrage pour appliquer les nouvelles bibliothèques au runtime.
Démonstration vidéo :
« Mainline a changé la donne pour notre parc professionnel »
Sophie L.
Limites pour les appareils anciens et obligations OEM
Ce H3 rappelle que tous les appareils ne sont pas éligibles et que certains resteront hors du périmètre sans mise à niveau du noyau. Les OEM doivent intégrer des correctifs supplémentaires pour garantir un support complet des paquets APEX sur matériel ancien.
En pratique, la feuille de route dépendra du dialogue entre Google, fournisseurs de SoC et constructeurs, ainsi que des priorités commerciales. À défaut, une partie des utilisateurs restera sur des versions moins fréquemment corrigées.
« À court terme, certains appareils resteront exclus des bénéfices sans mise à niveau du noyau »
Paul R.
Source : Gartner, « Rapport 2019 sur les systèmes d’exploitation mobiles et la sécurité des appareils », Gartner, 2019 ; Google, « Project Mainline announcement », Google I/O, 2019 ; Android Open Source Project, « Documentation GKI », AOSP, 2026/03/11.
