Google complexifie le développement de ROM Android alternatives, remettant en cause leur existence même. À partir d'Android 16, l'entreprise arrête de partager publiquement des données qui permettaient la création de ces forks. 

Elles n'ont clairement plus autant la cote qu'aux débuts d'Android, mais les ROM alternatives font encore partie de l'identité du système d'exploitation mobile. Leur développement risque toutefois de se compliquer fortement, ce qui pourrait entraîner à terme leur disparition. Google est-il en train de clouer le cercueil des distributions alternatives d'Android, type LineageOS et GrapheneOS ? Point sur la situation.

L'inquiétude a commencé grandir en mars 2025. Google annonçait que le développement d'Android serait désormais effectué à 100 % en interne afin de simplifier le flux de travail. Dans les faits, cette décision ne change pas grand-chose, puisqu'une très grande partie du développement se déroulait déjà en privé. En outre, l'entreprise promettait de continuer à publier le code source et d'alimenter l'Android Open Source Project (AOSP), la version publique et accessible à tous d'Android.

Android 16 rabat les cartes

Mais les passionnés ont eu une mauvaise surprise avec la récente sortie de la première version stable d'Android 16. Google a bien mis à disposition le code source de la mise à jour via l'AOSP. Comme d'habitude, il est publié sous Apache 2.0, une licence permissive qui autorise son utilisation, sa distribution, sa modification, ainsi que la distribution de versions modifiées, permettant de créer de nouvelles ROM personnalisées à partir de la base fournie.

Il manque toutefois quelques éléments par rapport à ce que Google procurait autrefois. Les arborescences des appareils Pixel ne sont plus disponibles, tout comme les fichiers binaires des pilotes et l'historique des commits. La disparition de ces trois types de données traduit une transparence devenue plus opaque de Google pour le développement d'Android. Et surtout, elle complique gravement la tâche des développeurs qui souhaitent mettre au point des forks Android.

Cette révélation a conduit certains à envisager que Google effectuait ici le premier pas vers la suppression pure et simple de l'AOSP. Celui-ci n'est certes plus aussi utile que dans le passé, mais sa fermeture constituerait néanmoins un choc. Elle symboliserait le repli sur soi d'Android, qui se rapprocherait alors bien plus d'iOS que de l'Android des premières années. En vérité, Google a pris de multiples directions au fil des années rendant son OS moins ouvert et personnalisable. Tuer AOSP n'en serait que le coup de grâce.

AOSP n'est pas remis en cause, selon Google

Mais nous n'en sommes encore là. Ayant eu vent de la panique générale se dispersant dans la communauté des développeurs, Seang Chau, grand patron d'Android, a tenu à se montrer rassurant. “Certains spéculent sur l'abandon d'AOSP. Soyons clairs : AOSP ne disparaîtra pas. AOSP a été conçu comme une plateforme ouverte pour les implémentations d'appareils, les fournisseurs de SoC et les architectures de jeux d'instructions”, a-t-il réagi sur X (Twitter).

Il donne aussi une explication quant à l'arrêt du partage des arborescences d'appareils Pixel. “AOSP a besoin d'une cible de référence flexible, configurable et abordable, indépendante de tout matériel, y compris ceux de Google”, fait-il savoir. En ne rendant plus publiques les arborescences des Pixel, Google veut donc forcer les créateurs de distributions alternatives à ne plus prendre ses Pixel comme cible de référence.

Seang Chau précise que ses équipes vont continuer de mettre à disposition l'appareil Android virtuel Cuttlefish à des fins de test et de développement. Celui-ci devient même la nouvelle cible de référence, maintenant que les arborescences Pixel deviennent inaccessibles au public. “Cuttlefish est un appareil Android virtuel configurable qui peut s'exécuter à la fois à distance (à l'aide d'offres cloud tierces telles que Google Cloud Engine) et localement (sur des machines Linux x86 et ARM64)”, indique Google dans AOSP.

Son objectif est de libérer les développeurs d'une certaine dépendance au matériel physique pour développer et valider les modifications de code. “Reproduisez le comportement basé sur le framework d'un appareil réel en privilégiant la haute fidélité en maintenant un alignement étroit avec le framework principal”, écrit Google sur la page AOSP présentant Cuttlefish. Il est ajouté qu'il existe de nombreuses similitudes entre Android Emulator et Cuttlefish, mais que ce dernier “garantit une fidélité totale avec le framework Android”, qu'il s'agisse d'AOSP pur ou d'une version déjà personnalisée.

Les ROM alternatives en danger ?

Les images système générique (GSI), des implémentations Android pures contenant du code AOSP non modifié, sont, elles aussi, toujours prises en charge par Google, apprend-on. Vouloir s'affranchir d'un appareil commercial et personnalisé comme les smartphones Pixel peut partir d'un bon sentiment. Mais l'alternative, une machine virtuelle, a aussi ses limites. Elle ne peut que simuler des fonctionnalités matérielles, ce qui peut rendre la tâche des développeurs ardue au moment de détecter ou de réparer d'éventuels bugs, ou même pour développer une nouvelle fonction.

Et ce n'est pas le seul facteur qui va compliquer le développement de forks Android. Cité par Android Authority, Nolen Johnson, contributeur du projet LineageOS, estime qu'il va devenir “pénible” de créer des ROM personnalisées à l'avenir. Jusqu'ici, “il suffisait de récupérer les configurations créées par Google”, puis d'y ajouter une couche de personnalisation et de compiler l'ensemble pour mettre au point un fork Android pour Pixel. Cela n'est plus possible à partir d'Android 16, puisque Google garde pour soi les arborescences.

Il va donc falloir se baser sur les anciennes arborescences d'appareils publiées par Google (celles pour Android 15 étant les plus récentes), pour ensuite “deviner et rétroconcevoir à l'aveugle, à partir des binaires pré-compilés, les modifications nécessaires”, expose le développeur. Cet ensemble de fichiers de configuration est critique, car il permet au système de build de créer une image appropriée pour l'appareil visé.

Ne plus avoir accès à l'historique des commits du code source n'arrange pas non plus la situation. Celui-ci était utile comme point de référence pour le développement de ROM à destinations d'autres modèles. Il facilitait l'intégration de fonctionnalités, de corrections de bugs et de correctifs de sécurité.

Il est donc fort probable qu'on voie encore moins de forks personnalisés à l'avenir, que ce soit pour les Pixel ou d'autres marques. Et pour les appareils qui seront encore supportés, les mises à jour risquent de prendre plus longtemps à arriver, étant donné que les temps de développement vont s'allonger.