Pendant près de vingt ans, Android a entretenu un rituel rassurant : un flux régulier de code source publié dans l’Android Open Source Project (AOSP), cadence trimestrielle à l’appui. En 2026, Google change la musique. Et ce qui ressemble à un ajustement d’ingénierie — deux publications par an au lieu de quatre — pourrait, à bas bruit, redessiner l’équilibre entre Google, les constructeurs… et toute la communauté Android.
Google confirme un nouveau calendrier de publication du code source dans AOSP : désormais, ce sera en Q2 et en Q4, soit deux « code drops » par an. L’objectif affiché : s’aligner avec un modèle de développement « trunk-stable », où les équipes travaillent sur un tronc principal plus stable plutôt que de multiplier des branches qui divergent.
Sur le site officiel, Google recommande aussi aux contributeurs d’utiliser android-latest-release plutôt que aosp-main, afin de pointer en permanence vers la dernière version réellement publiée dans AOSP.
En clair : le développement continue, mais le moment où le public récupère le code « proprement empaqueté » devient moins fréquent.
Ce que ça change techniquement : moins de « snapshots », plus de tronc
Jusqu’ici, la logique AOSP suivait de près le rythme des Quarterly Platform Releases (QPR) : un accès public au code plus régulier, en phase avec les jalons de la plateforme. Désormais, certaines évolutions arriveront plus tard dans AOSP, même si elles existent déjà côté Google et partenaires.
Le choix du « trunk-stable » n’est pas absurde sur le papier : un tronc stable peut limiter les régressions, réduire la dette de merge, et simplifier la collaboration interne. Mais, il a une contrepartie : la transparence « en continu » devient un luxe, pas une norme.
L’impact réel pour les utilisateurs : invisible… sauf si vous sortez des sentiers battus
Pour la majorité des gens, surtout côté Pixel, l’effet devrait être quasi imperceptible : les QPR et les mises à jour fonctionnelles continuent d’arriver comme d’habitude, et Google affirme maintenir la mécanique de patchs de sécurité réguliers.
Là où ça peut piquer, c’est pour les utilisateurs et développeurs qui vivent dans le monde Android « parallèle » :
- les ROMs custom (LineageOS, GrapheneOS, etc.) : ces projets s’appuient sur les publications AOSP pour intégrer rapidement changements système, correctifs et compatibilité. Avec deux publications par an, l’intégration de certaines nouveautés ou corrections pourrait être retardée, et le maintien de branches intermédiaires deviendra plus coûteux.
- les petits constructeurs et acteurs moins privilégiés : ceux qui n’ont pas d’accès anticipé aussi poussé que les géants du secteur pourraient se retrouver avec un décalage accru, surtout si la fenêtre publique se resserre.
Bref : pour « Android standard », rien ne casse. Pour « Android ouvert et modifiable », le temps s’allonge.
Le vrai enjeu : stabilité… ou verrouillage progressif ?
Google vend la mesure comme un plan de stabilité. Mais, dans l’écosystème Android, stabilité et contrôle ont souvent des frontières poreuses.
Deux inquiétudes remontent déjà :
- Moins de feedback en amont : Quand le code est publié plus tard, la communauté a moins d’occasions de détecter tôt des régressions, des SDK cassés ou des comportements indésirables, avant que tout soit « scellé » dans une publication plus massive.
- Un pas de plus vers le « jardin clos » : Android reste open source sur le socle AOSP — mais, une partie croissante de l’expérience Android moderne se joue déjà ailleurs (services Google, couches propriétaires, intégrations partenaires). Réduire la fréquence de publication AOSP, c’est aussi réduire la lisibilité du chantier pour le public. Et, mécaniquement, renforcer l’asymétrie entre ceux qui ont accès tôt… et les autres.
Ce n’est pas forcément un virage « anti-open source ». Mais, c’est un virage pro-Google, au sens où Google choisit un rythme qui sert d’abord son efficacité interne et ses partenaires majeurs — avec l’écosystème indépendant qui s’adapte après coup.
Un Android toujours ouvert, mais moins synchronisé avec le public
La nuance est importante : Google ne « ferme » pas Android. Il change la cadence de ce que le public voit et quand il le voit. Pour l’utilisateur lambda, c’est presque un non-sujet. Pour les développeurs de ROMs, les chercheurs sécurité, les petits industriels, c’est un changement structurel : l’Android « public » devient plus intermittent.
Et dans une industrie où la vitesse fait loi, l’intermittence finit souvent par ressembler à un retard imposé.
