C’est une annonce qui confirme une tendance de fond observée depuis plusieurs mois. À partir de 2026, Google modifiera radicalement le rythme de publication du code source d’Android sur AOSP (Android Open Source Project). Désormais, les livraisons de code ne se feront plus quatre fois par an, mais seulement deux, lors des deuxième et quatrième trimestres. On vous explique pourquoi.
Pour le géant de Mountain View, cette décision répond à une logique de rationalisation industrielle. En s’alignant sur un modèle de développement dit « stable », Google souhaite simplifier la gestion de ses branches de code. L’objectif affiché est de garantir une meilleure fiabilité de la plateforme pour l’ensemble de l’écosystème. En réduisant la fréquence, Google espère éliminer les conflits techniques récurrents entre ses branches internes et publiques, tout en fournissant un code plus sécurisé et mieux testé. Que les utilisateurs se rassurent : ce changement n’impacte pas les correctifs de sécurité mensuels, qui continueront d’être publiés sur une branche dédiée pour protéger les appareils. Vous utilisez, par exemple, /e/OS ? Rien ne change.
Une pilule amère pour l’écosystème open source ?
Si la promesse de stabilité est louable, ce nouveau calendrier pourrait freiner l’élan de nombreux acteurs indépendants. Pour les projets comme LineageOS, GrapheneOS ou /e/OS, qui dépendent directement des publications AOSP pour construire leurs solutions alternatives souveraines (ce qu’a fait Punkt cette semaine avec l’annonce de son nouveau smartphone), ce ralentissement de la cadence est un défi.
Ce changement intervient d’ailleurs moins d’un an après que Google a cessé les contributions (commits) en temps réel sur les branches publiques. Comme nous l’anticipions déjà en mars 2025 dans notre article « Google va rendre le développement d’Android privé : quid de l’open source ?« , le développement d’Android se fait désormais quasi exclusivement à huis clos. Pour les développeurs de ROM personnalisées, cela signifie un accès plus tardif aux innovations et potentiellement un retard dans le support de fonctionnalités pour les appareils anciens ou non officiels.
S’adapter à la nouvelle donne : « android-latest-release »
Pour accompagner cette transition, Google recommande dorénavant aux contributeurs d’utiliser la branche de fichier manifeste android-latest-release plutôt que aosp-main. Cette branche pointera systématiquement vers la version la plus récente envoyée sur les serveurs AOSP, offrant ainsi un point de repère fixe dans ce nouveau cycle semestriel.
En résumé, si Google sécurise sa plateforme et facilite la vie des constructeurs partenaires, la communauté du logiciel libre doit, elle, composer avec un « mur » qui s’épaissit entre le développement interne de Google et la réalité du projet open source. Le défi pour 2026 sera de maintenir le dynamisme des systèmes d’exploitation alternatifs libres malgré ce délai de publication doublé.
Autre piste, plus radicale celle-là, cesser la dépendance aux bases d’Android pour se tourner vers une solution plus radicale encore, comme un smartphone Linux ?
Aller plus loin : le point technique entre aosp-main vs android-latest-release
Avec ce changement de rythme, Google clarifie la distinction entre le flux de travail continu et les versions stabilisées. Voici ce qu’il faut retenir pour vos environnements de build :
-
aosp-main : c’est la branche de développement actif. Elle contient le code le plus récent mais n’offre aucune garantie de stabilité immédiate pour une production.
-
android-latest-release : c’est désormais la branche recommandée par Google pour l’écosystème. Elle fait systématiquement référence à la version stable la plus récente publiée sur AOSP, s’alignant sur le nouveau cycle semestriel.
Pour les développeurs de ROM, basculer sur android-latest-release permet d’éviter les instabilités liées au développement en cours tout en bénéficiant de la plateforme validée par Google.
