GrapheneOS déplore l’attitude de Google sur les correctifs de sécurité d’Android
L’équipe de GrapheneOS n’est pas contente. Le nouveau rythme de parution des mises à jour d’Android laisse le système alternatif sur le bord de la route un trimestre sur deux.
Google a introduit des interfaces de programmation (API) supplémentaires dans Android 17 QPR1, mais ces nouvelles API ne sont disponibles que sur les appareils Pixel de Google. Pourtant, ces interfaces ne sont pas spécifiques aux Pixel : ce sont des fonctionnalités standard d’Android. Selon GrapheneOS, ces API ne seront accessibles aux autres fabricants et au projet Android Open Source Project (AOSP) qu’à partir de décembre 2026, avec la sortie d’Android 17 QPR2. C’est la première fois depuis Android Honeycomb (version 3.x) que Google adopte une telle approche. Si cette pratique se généralise, les appareils Pixel pourraient bénéficier de six mois d’avance par an sur les autres smartphones, créant un déséquilibre dans l’écosystème Android.
Google publie désormais les correctifs de sécurité d’Android uniquement lors des mises à jour trimestrielles (QPR1 et QPR2), et non plus chaque mois. Pourtant, le bulletin de sécurité de septembre 2026 pour les Pixel inclut des correctifs supplémentaires pour des composants standard d’Android, utilisés par d’autres fabricants. Ces correctifs ne sont pas inclus dans le bulletin de sécurité Android général ni partagés à l’avance avec les autres constructeurs. Résultat : les systèmes alternatifs comme GrapheneOS, basés sur AOSP, ne recevront ces correctifs qu’avec la mise à jour QPR2, soit avec plusieurs mois de retard. GrapheneOS peut contourner ce problème en analysant le code compilé, mais cette méthode prend du temps et réduit l’efficacité des correctifs anticipés.
Depuis 2026, Google ne publie le code source d’Android Open Source Project (AOSP) que deux fois par an, au deuxième et quatrième trimestre, au lieu de manière continue. Cette décision, annoncée en novembre 2024, vise officiellement à simplifier le développement et à stabiliser la plateforme. Cependant, cette modification a des conséquences indirectes : les fabricants tiers et les systèmes alternatifs comme GrapheneOS doivent désormais attendre ces mises à jour pour accéder au code complet. De plus, l’obtention du code source du noyau Linux, nécessaire pour adapter Android à de nouveaux appareils, est désormais soumise à un formulaire en ligne, ce qui allonge les délais. Par exemple, une demande déposée le 1ᵉʳ septembre 2026 n’a été satisfaite que le 17 septembre.
GrapheneOS, un système d’exploitation axé sur la sécurité, critique vivement les changements opérés par Google. L’équipe souligne que ces modifications compliquent son travail, notamment pour supporter les nouveaux appareils. Par exemple, Google a retiré la fonction MTE (Memory Tagging Extension), un outil de sécurité matériel, des derniers Pixel 11. GrapheneOS a trouvé une solution logicielle pour compenser ce retrait, mais cela entraîne une baisse de performance de 5 %. Malgré cela, l’équipe continue d’évaluer la faisabilité du support des Pixel 11. À l’inverse, GrapheneOS anticipe que les futurs appareils Motorola seront plus faciles à adapter, car Qualcomm, leur fournisseur de puces, commence à intégrer le MTE dans des modèles moins chers. Les premiers appareils Motorola sous GrapheneOS sont attendus en 2027, avec un modèle haut de gamme en première ligne.
Les modifications de Google dans la gestion d’AOSP et des correctifs de sécurité s’inscrivent dans une stratégie plus large visant à centraliser le développement d’Android en interne. Cette approche crée un retard constant pour les systèmes alternatifs comme GrapheneOS ou *LineageOS*, qui doivent s’adapter aux mises à jour tardives. GrapheneOS a déjà alerté à plusieurs reprises sur ces changements, notamment en janvier 2026, lorsque Google a annoncé le nouveau rythme de publication des *SDK* (kits de développement). L’entreprise avait alors assuré que les correctifs de sécurité continueraient à être publiés chaque mois, une promesse qui semble désormais remise en question. Ces tensions illustrent les défis croissants pour les acteurs indépendants dans l’écosystème Android.
