« Android 17 QPR1 est la première version depuis Android Honeycomb (3.x) qui ajoute de nouvelles API pour les développeurs d’applications sans publication dans l’Android Open Source Project. Les nouvelles API sont actuellement exclusives à Pixel OS et ne sont pas disponibles pour les autres OEM Android », débute le fil de GrapheneOS sur X et Mastodon.

L’équipe dénonce une nouvelle fois les changements intervenus chez Google dans la parution des mises à jour pour Android. Dans les grandes lignes, elles ne sont plus reversées dans Android Open Source Project que durant le deuxième et le quatrième trimestres.

Deux gros reproches

L’agacement de l’équipe est palpable. Dans son fil, elle pointe surtout deux problèmes majeurs pour son propre fonctionnement.

D’une part, la disponibilité de la première QPR (Quarterly Platform Release) pour Android 17 montre la présence de nouvelles interfaces de programmation (API). Or, cette QPR1 n’est disponible que sur les propres appareils Pixel de Google. L’équipe de GrapheneOS indique qu’il ne s’agit pourtant pas d’API spécifiques aux Pixel : ce sont des interfaces Android standard, qui ne parviendront à l’AOSP et aux autres fabricants qu’en décembre 2026 avec Android 17 QPR2.

Selon l’équipe, c’est la première fois depuis l’ancienne version Honeycomb que Google ajoute ainsi des API sans les reverser immédiatement dans AOSP. Si Google répète le schéma, il pourrait donc y avoir six mois sur douze pendant lesquels les appareils Pixel seraient les seuls à profiter de ces interfaces.

D’autre part, comme on pouvait le prévoir, la question des correctifs de sécurité se pose. Le bulletin Pixel de septembre 2026 contient des correctifs supplémentaires qui touchent des composants standard de la plateforme Android, également employés par des appareils tiers. Pourtant, ces correctifs ne figurent pas au bulletin de sécurité Android du même mois, ni dans les correctifs communiqués en avance aux fabricants. En clair, les fabricants tiers et les systèmes alternatifs basés sur AOSP – dont GrapheneOS – ne recevront ces correctifs supplémentaires qu’avec la mise à jour QPR2.

L’équipe précise bien qu’elle peut les fournir plus tôt en faisant de la rétro-ingénierie du code binaire. Elle prévient toutefois : si un correctif diffusé sous forme compilée est rétro-analysable en quelques jours, le système d’accès anticipé perd une grande part de sa justification.

Une période décidément complexe

La période n’est pas simple pour Graphene. Si le système est connu pour son positionnement strict sur la sécurité, elle a décidément maille à partir avec Google depuis les changements annoncés dans le rythme de parution des mises à jour et leur disponibilité.

Il y a quelques semaines, Graphene avait averti que le support des récents Pixel 11 allait s’avérer complexe. Déconseillant l’achat de ces derniers, l’équipe avait fustigé le choix de Google de ne plus intégrer la fonction MTE (marquage mémoire) dans ses téléphones, alors que Graphene s’en sert copieusement pour vérifier l’intégrité des données en mémoire. La situation a cependant évolué, l’équipe indiquant que la gestion du MTE peut être assurée de manière logicielle, au prix d’un surcoût de 5 % pour les performances générales. Surcoût qu’elle estime raisonnable au vu des enjeux. Pour l’équipe, le retrait de l’accélération matérielle dans le cache du processeur est un choix financier avant tout. Si elle parvient à un MTE pleinement fonctionnel, elle pourra annoncer le support des Pixel 11.

Les changements dans la gestion d’AOSP agacent donc. Il s’agit d’une conséquence lointaine d’une modification annoncée en novembre 2024 dans le rythme de parution des SDK (kits de développement). En janvier 2026, Google annonçait en effet qu’elle ne publierait plus le code d’AOSP que deux fois par an, pour aligner ses calendriers de développement. En d’autres termes, il s’agissait officiellement d’une simplification.

« À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l’écosystème, nous publierons le code source sur AOSP aux deuxième et au quatrième trimestre. Pour créer et contribuer à AOSP, nous vous recommandons d’utiliser android-latest-release au lieu de aosp-main. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP », prévenait alors Google.

Pourtant, l’entreprise avait précisé dans la foulée à Android Authority que ce nouveau rythme ne changerait a priori rien pour les correctifs de sécurité, affirmant qu’elle continuerait à les publier chaque mois « sur une branche dédiée uniquement à la sécurité pour les versions pertinentes […], tout comme elle le fait aujourd’hui ». Une belle assurance déjà contestée plusieurs mois avant par un autre système bâti sur AOSP, LineageOS.

Motorola attendu de pied ferme

En janvier, nous rappelions également que le développement d’Android était devenu totalement interne, avec pour conséquence un retard constant d’AOSP sur Android. Nous relevions alors que les Pixel allaient avoir un avantage logiciel sur les appareils concurrents et les ROM alternatives.

Dans son dernier fil, l’équipe de GrapheneOS mentionne aussi la concrétisation d’une de ses craintes : le code source du noyau n’étant plus disponible par simple téléchargement, le délai s’allonge pour le récupérer à cause d’un passage obligatoire par un formulaire. L’équipe le confirme dans l’un des messages, une requête pour obtenir ce code source le 1ᵉʳ septembre n’ayant abouti que le 17.

Désormais, le travail d’adaptation se concentre directement sur la version QPR1 d’Android 17, mais il faudra attendre la QPR2 en décembre pour diffuser une mise à jour, en se basant sur le code qui aura été effectivement publié dans AOSP. Jusqu’ici, le travail avance par rétro-ingénierie et tâtonnements.

Dans un message, l’équipe affirme une fois de plus que les futurs appareils Motorola seront plus simples à supporter que les Pixel, qui ont perdu un sérieux avantage (la situation ne change pas pour les anciennes gammes). Le reste dépendra de Qualcomm, qui a tendance à considérer la sécurité comme un luxe, la fonction MTE n’ayant été présente jusqu’ici que dans les puces les plus onéreuses. Chez GrapheneOS, on espère ainsi la voir arriver sur des modèles moins chers, afin que l’offre Motorola équipée du système puisse toucher le milieu de gamme.

Pour rappel, les premiers appareils de Motorola sous GrapheneOS sont attendus pour l’année prochaine, sans plus de précisions pour l’instant. Le premier appareil sera destiné au segment haut de gamme.