La mise à jour récente d’Android 16 par Google entraîne des changements significatifs dans la manière dont les développeurs créent des ROMs personnalisées pour les appareils Pixel, rendant leur tâche plus complexe et technique.
Google a pris une décision importante concernant Android 16, impactant la communauté des développeurs de ROMs personnalisées pour les Pixel. Bien que le code ouvert de l’AOSP reste accessible, il devient plus difficile de l’utiliser.
Pour ceux qui ont passé du temps à expérimenter avec Android, flasher des ROMs ou tester de nouvelles versions, AOSP, l’acronyme de Android Open Source Project, doit leur être familier. C’est la base de code ouvert d’Android, le fondement sur lequel repose tout le système d’exploitation. Il permet aux développeurs de créer des versions d’Android plus légères ou comportant des fonctionnalités uniques.
Cependant, la relation entre Google et cette communauté a souvent été marquée par des tensions. Il y a quelques mois, Google avait déjà annoncé un développement plus secret d’Android OS pour simplifier ses processus internes. À l’époque, l’inquiétude n’a pas duré, et Google avait assuré que le code source continuerait d’être publié. Aujourd’hui, une omission dans la dernière version d’AOSP d’Android 16 a de nouveau attiré l’attention, compliquant sérieusement la vie des développeurs de ROMs pour les Pixel. Bien que Google affirme qu’AOSP ne disparaît pas, la réalité révèle une complexification des accès.
Un changement significatif pour le Pixel
Comme promis, Google a publié le code source d’Android 16 peu après le lancement de cette nouvelle version, permettant ainsi aux développeurs de compiler leurs propres versions. Ce code a été mis en ligne dans l’AOSP, sous la licence Apache 2.0. Tout semblait normal jusqu’ici.
Cependant, plusieurs développeurs ont noté une absence notable dans la publication du code source d’Android 16: les « device trees » pour les appareils Pixel étaient manquants. De plus, Google n’a pas mis en ligne les nouveaux « driver binaries », nécessaires à la communication entre le logiciel et le matériel, et le code source du kernel (la partie centrale du système) a été publié avec un historique de « commits » « squashed », soit compressé en un seul. Cette situation a suscité des préoccupations, car Google partageait traditionnellement ces informations.
Ces absences ont conduit certains à penser que Google envisageait de mettre un terme à AOSP. Toutefois, Seang Chau, vice-président de la plateforme Android de Google, a fermement démenti ces idées dans un message sur X, précisant que « AOSP ne va pas disparaître ».
Nous constatons des spéculations selon lesquelles AOSP serait abandonné. Par conséquent, pour être clair, AOSP ne disparaît PAS. AOSP a été construit sur les bases d’une plate-forme ouverte pour les implémentations d’appareils, les fournisseurs SoC et les architectures d’instructions.
AOSP a besoin d’une cible de référence qui soit…
— Seang Chau (@seangchau) 12 juin 2025
Selon Google, l’absence des « device trees » pour Pixel est délibérée. L’entreprise justifie que l’AOSP nécessite une référence « flexible, configurable et abordable », et « indépendante de tout matériel spécifique, y compris ceux de Google ». À présent, au lieu d’utiliser les Pixel comme base pour l’AOSP, Google envisage d’utiliser un appareil virtuel nommé « Cuttlefish » comme référence.
Cuttlefish fonctionne sur PC et permet aux développeurs d’expérimenter avec de nouvelles fonctionnalités matérielles. Google continuera également de soutenir les GSI (Generic System Images), qui peuvent être installées sur presque tous les appareils Android.
Cette stratégie est en partie compréhensible : AOSP a été conçu comme une plateforme ouverte pour divers fabricants et architectures. Cuttlefish, étant un dispositif virtuel, représente une référence plus « neutre » que le Pixel, qui est un matériel final très personnalisé. Toutefois, le virtuel présente des limitations quand il s’agit de simuler le comportement véritable du matériel.
Les défis de la création d’une ROM personnalisée pour les Pixel
LineageOS est l’une des plateformes de ROMs emblématiques d’Android
C’est ici que surgit le véritable défi pour la communauté des développeurs de ROMs personnalisées. Nolen Johnson, un vétéran de LineageOS, a exprimé que le processus de création de ces ROMs pour les Pixel risque d’être « douloureux » à l’avenir.
Auparavant, les choses étaient plus simples. Les développeurs pouvaient s’appuyer sur les configurations fournies par Google, ajouter leurs personnalisations et compiler. C’était relativement simple. Maintenant, cette aide a disparu. Les développeurs devront prendre les anciens « device trees » publiés pour Android 15 et essentiellement « deviner et effectuer de l’ingénierie inverse à partir des binaires préconstruits » pour comprendre quels changements sont nécessaires chaque mois.
Pourquoi cela pose-t-il un problème? Pour créer une compilation complète d’Android pour un appareil (et non seulement une GSI), un « device tree » est indispensable. Cela constitue une collection de fichiers de configuration définissant la conception du matériel, les périphériques, les fichiers propriétaires, permettant au système de compilation de générer l’image appropriée. Auparavant, Google prenait en charge ce travail. Désormais, les développeurs devront créer leurs propres « device trees », sans accès à ces codes sources nécessaires.
Pour compliquer davantage les choses, la décision de Google de compresser l’historique des changements dans le code source du kernel pose également problème. Cet historique était souvent utilisé comme « référence » pour d’autres appareils, mais avec une réduction à un seul « commit », cela devient inapplicable.
Il est vrai que Google n’a aucune obligation légale de publier ces « device trees », ni de fournir les « driver binaries » ou de partager l’historique complet du kernel. L’entreprise l’a fait en raison du fait que les Pixel étaient considérés comme des dispositifs de référence pour l’AOSP, facilitant ainsi les compilations. En décidant de ne plus utiliser le Pixel comme référence, Google complique la tâche pour des projets majeurs comme LineageOS ou GrapheneOS qui conçoivent des versions d’Android pour ces appareils. Bien qu’ils puissent continuer à le faire, ce sera beaucoup plus ardu et coûteux.
L’avenir des Custom ROMs sur Pixel : plus difficile, mais pas impossible
Le logiciel du Google Pixel 9a, basé sur Android 15 / Photo de AndroAall
Cette nouvelle décision de Google représente un véritable défi pour la communauté des développeurs de ROMs personnalisées, notamment ceux travaillant avec les Pixel. Elle ravive des préoccupations déjà exprimées lorsque Google avait annoncé un développement plus privé d’Android. On peut observer que Google cherche à trouver un équilibre de plus en plus délicat entre son engagement envers l’open source et la nécessité d’optimiser ses propres processus, tout en essayant de garder un contrôle sur l’expérience utilisateur de ses appareils phares.
Malgré cela, la communauté de modding d’Android fait preuve d’une grande résilience. Il est fort probable que même si le processus devient plus long et complexe, les développeurs trouveront les moyens de continuer à proposer des Custom ROMs pour les Pixel. Ce qui est certain, c’est que ces changements ajoutent une couche supplémentaire de difficulté et de temps au processus, qui n’existait pas auparavant. Ce mouvement, sans anéantir l’AOSP, complique indéniablement les efforts de ceux qui, par passion et connaissance, créent une version différente d’Android pour d’autres utilisateurs. Reste à voir comment évoluera cette nouvelle dynamique entre Google et sa communauté plus « underground ».