Google complique la création de ROM Android alternatives avec Android 16. Des projets comme LineageOS et GrapheneOS sont menacés : la firme de Mountain View cesse de partager des données importantes pour créer ces distributions personnalisées.
Alors que depuis peu, Android 16 est disponible, son existence menace les ROM alternatives qui ont une place importante dans l’écosystème. L’inquiétude a débuté en mars 2025 quand Google a annoncé que le développement serait entièrement en interne pour simplifier le travail.
À lire aussi : comment installer une ROM Custom sur Android ?
Les ROM personnalisés Android sont-elles en danger ?
We're seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures.
— Seang Chau (@seangchau) June 12, 2025
AOSP needs a reference target that is…
Sauf qu’à ce moment, tout allait bien : le développement a toujours eu lieu en privé et Google a promis qu’il continuerait à publier le code source via Android Open Source Project (AOSP). Sauf qu’Android 16 a beau ajouter de belles nouveautés, cette mise à jour change les choses.
Le code source est bien disponible via AOSP sous licence Apache 2.0 pour permettre l’utilisation, la distribution et la modification pour créer de nouvelles ROM personnalisées comme LineageOS. Sauf que des barrières se dressent.
Les arborescences des appareils Pixel ne sont plus disponibles, tout comme les fichiers binaires des pilotes et l’historique des commits. Google complique la tâche des développeurs qui souhaitent créer des forks Android avec ces disparitions.
Bref : il s’agit d’un premier pas vers la suppression de l’AOSP pour beaucoup. Sa fermeture serait un choc et une orientation fermée pour Android, similaire à iOS d’Apple. Google ne cesse de rendre son système d’exploitation moins ouvert au fil des années.
Seang Chau, responsable Android, se veut rassurant : « Des personnes parlent de l’abandon d’AOSP mais soyons clairs, il ne disparaîtra pas. Il s’agit d’une base logicielle accessible à tous, pensée pour permettre l’intégration par les constructeurs de matériel, les concepteurs de puces et les systèmes reposant sur diverses architectures d’instructions »
Quid de l’arrêt du partage des arborescences Pixel ? « Il est nécessaire pour AOSP de disposer d’une plateforme de référence modulable, économique et libre de toute dépendance matérielle, y compris vis-à-vis des équipements conçus par Google ». Pour Google, il s’agit d’abandonner les appareils Pixel comme référence pour les créateurs de ROM alternatives.
Seang Chau précise toutefois que ses équipes fourniront toujours l’appareil Android virtuel Cuttlefish pour les tests et les développeurs. Il s’agit d’une nouvelle cible de référence qui remplace les arborescences Pixel : « Cuttlefish est un dispositif Android virtuel adaptable, capable de fonctionner aussi bien à distance via des services cloud externes comme Google Cloud Engine, que localement sur des systèmes Linux x86 ou ARM64 »
Cette machine virtuelle a comme but de libérer les développeurs de la dépendance au matériel physique. Google promet une « totale fidélité avec le framework Android », aussi bien pour l’AOSP pur que personnalisé. Les images système génériques (GSI) sont aussi supportées.
Toutefois, cette alternative a des limites. Une machine virtuelle ne peut pas simuler des fonctionnalités matérielles, ce qui complique la détection et la réparation de bugs ou encore la création de nouvelles fonctions pour les développeurs.
LineageOS s’inquiète des décisions de Google
Nolen Johnson, contributeur LineageOS, explique à Android Authority qu’il sera « difficile » de créer des ROM personnalisées. Auparavant, « Il s’agissait simplement d’utiliser les configurations mises en place par Google. », d’ajouter une couche de personnalisation et de compiler pour créer un fork Android Pixel. Une méthode impossible avec Android 16.
Les développeurs n’ont plus qu’une option viable, se baser sur les anciennes arborescences publiques comme Android 15 pour « déduire à l’aveugle les ajustements requis en analysant des binaires déjà compilés, sans accès direct au code source ». Les fichiers de configuration permettent au système de build de créer une image appropriée sur l’appareil cible.
L’absence d’un accès à l’historique des commits complique un peu plus la situation puisqu’il servait de référence pour développer des ROM destinées à d’autres modèles. Et donc ajouter des fonctionnalités, corriger des bugs et ajouter des correctifs de sécurité.
Android 16 laisse donc présager une diminution des forks personnalisés, que ce soit pour le Pixel ou d’autres marques. Les appareils encore compatibles risquent de recevoir des mises à jour plus tardives face à un temps de développement allongé.
Réagissez à cet article !