Exclusif Google décide de mettre fin à l’open source Android
Aux fins de reportages d'actualité et de discussions purement intéressantes, Ai Faner a mené diverses « déductions sur table de sable » sur les stratégies d'entreprises technologiques bien connues et a imaginé de nombreux scénarios.
Mais je ne m'attendais pas à ce que la situation la plus improbable arrive réellement à Google.
AOSP (Android Open Source Project) est un projet open source dirigé par Google qui fournit un cadre de base et des composants de base pour tous les systèmes d'exploitation des appareils Android. C'est l'équivalent d'une « salle blanche » où les développeurs peuvent librement télécharger, modifier et distribuer son code, et créer des systèmes personnalisés basés sur celui-ci, notamment Xiaomi HyperOS, vivo OriginOS, OPPO ColorOS et même le système Android des téléphones Pixel, tous basés sur AOSP.
La maintenance d'Android par Google est divisée en deux voies : la branche publique AOSP est ouverte aux développeurs du monde entier, contient du code purement open source et n'implique aucun service propriétaire de Google. Tout fabricant ou particulier peut développer un système basé sur cette branche. La branche interne fermée n'est disponible que pour les fabricants ayant signé l'accord GMS (Google Mobile Services).
Concrètement, Google ne maintiendra plus la branche publique actuelle de l'AOSP, fermera progressivement les ressources de support associées et pourra cesser de mettre à jour le code source des composants en dehors des obligations légales open source (code sous GPL et autres accords).
À partir de la semaine prochaine, tous les développements Android seront réalisés exclusivement au sein des branches internes de Google. Après un certain temps, la succursale externe peut ne plus être publique, voire être complètement fermée. En outre, les outils et environnements d'intégration/livraison continue (CI/CD) d'AOSP peuvent également être arrêtés, et même Android Gerrit (https://android-review.googlesource.com/) peut être arrêté. Désormais, seuls les employés de Google peuvent accéder aux succursales internes de l'AOSP ou soumettre du code. Le processus de développement d'Android ne sera plus transparent.
D'un point de vue général, Google réduira progressivement le contenu inclus dans AOSP jusqu'à ce que AOSP n'existe plus en tant que projet open source et en tant que concept.
En prenant l'histoire comme guide, le projet OpenSolaris (c'est-à-dire le projet open source correspondant au système d'exploitation Solaris), après qu'Oracle a acquis Sun et annoncé un « open source retardé » pour OpenSolaris, n'a pas ouvert plus de la moitié du code sous la licence CDDL jusqu'à la dissolution du département de développement de Solaris.
Personne ne sait si la promesse de Google à l'Android Authority de "continuer l'open source, il suffit de le reporter" n'est que des mots vides de sens – après tout, un report indéfini est aussi une sorte de report.
Selon Ai Faner, l'idée générale du code source fermé d'Android est de ne conserver en fin de compte que les parties open source requises par la licence d'infection forte GPL, principalement les pilotes et les correctifs de l'état du noyau Linux. D'autres parties des couches moyennes et supérieures qui utilisaient auparavant des licences open source libres telles qu'Apache seront éventuellement fermées ; les futures versions d'Android ne seront plus publiées ni mises à jour après la publication du code source.
Le niveau de décision en la matière se situe au niveau de la haute direction de Google. On pense qu'ils prendront cette décision au plus tard début 2025. L'exécution de l'ensemble de la stratégie s'effectuera sur une période plus longue, au moins pendant plusieurs années, jusqu'à ce que l'AOSP perde complètement son sens.
Le véritable motif de la décision de Google n’est pas encore clair, mais selon l’analyse et la compréhension d’Ai Faner, il s’agit principalement de réduire les dépenses et d’augmenter les revenus :
AOSP dispose de plusieurs pipelines de code et d'un grand nombre de branches dans différentes dimensions (telles que le numéro de version, la progression de la version, etc.). Compte tenu des codes en amont et en aval du projet et de la collaboration entre plusieurs entreprises, cela est encore plus compliqué, rendant la maintenance et la gestion très difficiles, ce qui entraîne une grande quantité de ressources informatiques et des coûts en heures de main d'œuvre. Google voudra peut-être économiser ces coûts. Considérant que le département Android a offert à tous les employés la possibilité de « démission volontaire » début 2025, la logique de réduction des dépenses n'est pas difficile à comprendre. En outre, les fabricants qui ont signé un accord de partenariat sont également obligés de regrouper les services Google afin d'augmenter les revenus publicitaires de Google, ce qui à son tour augmente les revenus globaux de l'entreprise.
Heureusement, à l’heure actuelle, l’impact direct de l’AOSP à source fermée sur l’industrie n’est pas catastrophique, et l’impact intuitif sur les utilisateurs finaux de téléphones mobiles est également minime.
La plupart des principaux fabricants de téléphones mobiles ont déjà signé divers accords de partenariat agréés avec Google. Les fabricants dans le cadre des accords existants peuvent toujours obtenir et utiliser le dernier code source d'Android, obtenir la certification Google GMS, généralement préinstaller des services et des applications tels que Google Play et Gmail, et bénéficier de l'assistance de Google. Toutes les affaires restent comme d’habitude.
L’impact réel ne sera pas démontré directement, mais se reflétera de manière latérale sur une période de temps plus longue. Ceci sera expliqué en détail plus tard.
AOSP, n'existe plus ?
Les points suivants nécessitent des éclaircissements :
- Étant donné que la plupart du code AOSP est publié sous la licence Apache 2.0, n’importe qui peut en créer une copie. Il existe également divers miroirs AOSP sur d'autres plates-formes de services de code, telles que GitHub et la communauté Android nationale. Google n'a pas le droit de mettre hors ligne d'autres bases de codes AOSP « non officielles ». Ce qui a été open source ne peut pas être révoqué.
- En d'autres termes, tant qu'il peut être téléchargé à partir d'autres canaux non officiels, les utilisateurs peuvent toujours utiliser le dernier code AOSP mis à jour de Google et le modifier selon leurs propres besoins. En principe, si vous disposez de suffisamment de développeurs puissants, vous pouvez transformer l'AOSP précédent en votre propre système pour le maintenir et le mettre à jour.
Android/AOSP n’a jamais été un véritable projet open source, et les fondamentalistes de la communauté l’ont toujours critiqué.
Comme mentionné précédemment, Android fonctionne actuellement sur le noyau Linux, qui est open source sous licence GPL. La GPL est une licence très contagieuse qui exige que toutes les œuvres dérivées soient open source conformément à la licence GPL, mettant ainsi en œuvre l'esprit de l'open source illimité et élargissant la communauté.
Afin de construire l'écosystème commercial Android, Google a créé un modèle de licence qui équilibre les besoins open source et commerciaux. Google divise la plateforme Android en plusieurs parties : la partie sous-jacente du noyau Linux reste sous licence GPL v2 (comme requis), tandis que la majeure partie du code AOSP adopte la licence Apache 2.0, plus permissive. Cette structure de licence permet aux fabricants d'appareils de modifier et de personnaliser Android sans avoir à ouvrir toutes les modifications, tout en permettant aux entreprises de créer des applications et des services propriétaires sur la plate-forme Android. Le service propriétaire de Google, GMS (Google Mobile Services), est distinct de l'AOSP et adopte des conditions de licence différentes. Cette approche hybride crée un modèle qui maintient l’ouverture tout en offrant une flexibilité commerciale à l’écosystème.
Plus précisément, le noyau Linux est basé sur la licence GPL. Bien que le module du noyau doive être forcé à être open source selon la GPL, les applications de l'espace utilisateur ne sont pas affectées par la contagiosité de la GPL et n'ont donc pas besoin d'être open source. Certaines applications de l'espace utilisateur sont également différentes des distributions Linux traditionnelles, comme l'utilisation de la libc bionic au lieu de la glibc, de l'utilisation de toybox au lieu de busybox, etc. De plus, Google utilise également la « couche d'abstraction matérielle » (HAL), qui permet aux fabricants de stocker des informations commerciales confidentielles qu'ils ne souhaitent pas divulguer, telles que le code et la logique derrière certaines fonctions propriétaires spécifiques, sur cette couche, qui fournit une ABI (Application Binary Interface) stable afin que les fabricants puissent mettre à jour leur code propriétaire indépendamment de la couche de structure Android.
Bien entendu, la Linux Foundation était très mécontente des méthodes de fonctionnement de Google qui violaient l'esprit de l'open source et a une fois supprimé AOSP du projet open source Linux.
Le résultat est que la couche inférieure de l'AOSP est open source selon la GPL, et qu'un grand nombre de couches intermédiaires sont vaguement open source (partiellement fermées) selon Apache. Les applications basées sur cela peuvent choisir leurs propres attributs open source et fermés en fonction des souhaits et des objectifs commerciaux du développeur.
Google lui-même le fait. En fait, depuis Android 4.4 KitKat en 2013, toutes les versions d'Android ne sont plus entièrement open source. Certains des pilotes, de l'interface utilisateur et un grand nombre de produits et services de base de la couche d'application développée par Google pour le système Android, également connu sous le nom de suite GMS, sont tous de source fermée.
AOSP existe, mais ce n'est pas Android complet. C'est pourquoi de nombreux développeurs de systèmes souligneront que « Android natif » (en référence au système d'exploitation de Google Nexus/Pixel) n'est pas égal à AOSP.
Bien qu'AOSP soit un projet open source, Google ne fusionne pas souvent les demandes de fusion soumises par des tiers (la fusion du code AOSP nécessite l'approbation des employés de Google et de nombreux PR meurent dans Gerrit Review). C'est également ce que de nombreux développeurs considèrent comme la plus grande différence entre l'AOSP et les projets open source typiques. Il est difficile pour les participants d’acquérir un réel sentiment de participation à l’AOSP.
Sur le site officiel du projet AOSP, Google a écrit cette « philosophie de gouvernance » :
Google dirige l'AOSP, qui est responsable de la maintenance et du développement d'Android. Bien qu'Android se compose de plusieurs sous-projets, AOSP est strictement géré par projet. Google traite et gère Android comme un produit logiciel unique et monolithique, plutôt que comme une version, une spécification ou un ensemble de pièces remplaçables. L'intention de Google est que les fabricants d'appareils portent Android sur leurs appareils ; ils n'appliquent pas les spécifications ni ne organisent les versions.
Ce passage décrit assez clairement les intentions de Google. Si l'AOSP est un âne de travail, alors le moment est venu de tuer l'âne.
Quel impact le code source fermé d’Android apportera-t-il ?
À retenir : les marques de téléphones grand public et leurs utilisateurs n’ont rien à craindre.
Tout d’abord, passons en revue l’accord entre Google et Android OEM :
- AOSP, tout fabricant peut utiliser AOSP pour le développement sans le consentement de Google ;
- Accord d'engagement de compatibilité Android ACC, accord de distribution d'applications mobiles MADA, accord supplémentaire sur les appareils d'entreprise EDLA, etc., pour n'en nommer que quelques-uns. Grâce à des accords, des contraintes commerciales sont établies entre Google et les OEM. Seuls les OEM ayant signé l'accord ACC peuvent développer des systèmes d'exploitation via AOSP et les appeler systèmes d'exploitation Android, et obtenir les droits d'utilisation de la marque Android et d'autres droits.
- Google Mobile Services GMS comprend des fonctions back-end telles que le noyau de service Google et le système de compte, ainsi que des applications frontales telles que Google Play Store, YouTube, Gmail et Calendrier. Ce n'est que lorsque l'entreprise a signé l'accord ci-dessus et que le modèle de téléphone mobile a réussi le test de compatibilité de Google que GMS peut être préinstallé.
La combinaison d'ACC, MADA/EDLA et d'autres protocoles garantit que Google a un contrôle généralement absolu sur le système d'exploitation Android.
La plupart des marques de téléphones mobiles Android actuelles, notamment Xiaomi, Vivo, OPPO, Samsung, etc., ont signé des accords avec Google. S'il n'y a pas de surprise, Google aurait dû les contacter pour les rassurer et s'assurer que la future coopération se poursuive comme d'habitude.
Dans le passé, un nombre considérable de fabricants d’équipements et de puces utilisaient l’AOSP pour développer des produits, mais n’obtenaient pas la certification des appareils Android de Google. L'appareil n'avait pas besoin d'être préinstallé avec GMS Family Bucket et pouvait éviter les exigences de certification de Google.
Il existe des milliards, voire des dizaines de milliards d’appareils Android non certifiés. Grâce à cet AOSP de source fermée, Google pourrait inciter les équipementiers non certifiés à se plier à lui-même et à signer les différents accords évoqués ci-dessus.
Il est très probable que le code du système de cockpit intelligent développé sur la base de l'AOSP ne soit plus fourni gratuitement aux fabricants du monde entier. À moins que les constructeurs automobiles signent un accord avec Google, ils ne pourront pas obtenir le dernier code. Bien entendu, les constructeurs automobiles peuvent également continuer à utiliser d’anciens systèmes de développement open source.
Ce n’est pas un fait, c’est juste une possibilité. La décision de Google de fermer Android cette fois-ci n’exclut pas la possibilité de tenter de reconquérir le marché des appareils non certifiés, ou du moins d’en obtenir une part. Bien que ce vaste marché ait été créé par les équipementiers eux-mêmes, il ne serait pas ce qu’il est aujourd’hui sans l’AOSP.
De ce point de vue, les consommateurs d’appareils Android non certifiés pourraient être concernés, même si cela ne sera bien sûr pas évident. L'impact vient principalement de l'aspect financier : si les OEM souhaitent continuer à préinstaller le système d'exploitation Android, ils doivent se conformer à la gestion et aux exigences de Google en matière d'appareils. Ce coût sera bien entendu répercuté sur les consommateurs, ce qui entraînera des prix plus élevés. De plus, les consommateurs ne peuvent utiliser que des canaux tels que Google Play pour télécharger des applications. L’espace vital des marchés d’applications tierces (comme F-Droid) est également devenu plus petit. Google peut également facturer des frais pour tous les paiements intégrés à l'application.
Certains fabricants pourraient ne pas vouloir se soumettre à Google et leurs produits se retireront du marché, réduisant ainsi les choix des consommateurs ; mais en même temps, tout code AOSP publié par Google avant la fermeture du code source peut toujours être utilisé en théorie. Les fabricants peuvent créer le code à volonté et le développer, le mettre à jour et le maintenir eux-mêmes. On estime que les consommateurs de réfrigérateurs intelligents ne se soucieront pas de savoir si le réfrigérateur est préinstallé avec le dernier système d'exploitation Android.
Cependant, cela pourrait revenir au cliché de la « fragmentation Android » : si les fabricants d'appareils non autorisés continuent de suivre leur propre chemin et d'utiliser du code ancien, qui n'est plus officiellement maintenu, pour développer des produits, alors la fragmentation ne sera peut-être pas aussi simple qu'un numéro de version – mais peut être similaire à la Chine d'aujourd'hui, avec une fragmentation globale du push, de la version, de la fonction, de l'apparence, du nom, de l'expérience, etc., et une image étrange qui s'étendra à l'échelle mondiale.
Violation des droits des développeurs
Le code source fermé d'AOSP a un impact plus évident sur les développeurs ROM tiers d'applications Android.
La scène où une centaine d’écoles de pensée s’affrontaient sur des ROM tierces Android sera également enterrée par l’histoire. Le meilleur résultat pour les développeurs de ROM est d'utiliser la dernière version mise à jour d'AOSP pour la modifier, puis de conserver la version actuelle jusqu'à ce qu'elle devienne lentement obsolète, jusqu'à ce qu'ils abandonnent finalement le projet.
Quant aux développeurs d’applications, ils peuvent toujours obtenir le SDK dont ils ont besoin auprès de Google, et cela ne devrait pas avoir beaucoup d’impact direct dans l’ère post-AOSP.
Cependant, avant cela, en raison du degré considérable de fragmentation d'Android, les développeurs devaient obtenir des codes système de différents fabricants et appareils comme machines de test afin de s'adapter aux différentes versions du système et aux différentes marques de modèles. Il s’agit d’un coût important pour les petites et moyennes entreprises, notamment les développeurs indépendants. Il n’est pas certain que cette situation s’aggrave à l’avenir.
Si le cadre de vie des petits et moyens promoteurs est encore plus comprimé, l'effet de transmission sera que les forts seront toujours forts, l'innovation sera freinée et davantage de monopoles apparaîtront. Par conséquent, une fois que Google aura fait ce qu'il devait faire, il devrait fournir des plans de suivi pour assurer la survie des petits et moyens développeurs.
L'approche la plus extrême mais la moins inattendue
Auparavant, dans le contexte du découplage technologique entre la Chine et les États-Unis, Ai Faner avait imaginé plusieurs possibilités pour qu'Android « coupe l'approvisionnement » des fabricants chinois de téléphones mobiles : interdire l'affichage des marques Android sur les téléphones mobiles vendus à l'étranger, interdire la pré-installation de GMS, fermer « directement » la source AOSP aux fabricants chinois, et même suspendre l'autorisation de ces fabricants et les annuler/supprimer de l'OHA.
De toutes les possibilités, l’AOSP à source entièrement fermée est la moins probable. Ai Faner a un jour pensé que c'était trop honteux de le faire.
Au stade naissant des appareils mobiles intelligents, Google a pris la décision d'ouvrir Android en source ouverte, ce qui a non seulement acquis une réputation de technologie ouverte, mais a également conquis un grand nombre de fabricants et d'utilisateurs de Symbian, Windows Mobile, Nokia et BlackBerry à l'époque.
Bien sûr, Nokia, BlackBerry et Microsoft ont chacun fait des détours, ce qui a joué un rôle important dans la victoire de Google. Mais Android open source de Google est sans aucun doute la décision la plus correcte sur la voie de s'emparer aujourd'hui de plus de 70 % des parts d'Android sur le marché des systèmes d'exploitation mobiles.
Il y a encore des employés au sein de Google qui reconnaissent l'importance et la valeur à long terme de l'open source dans la vulgarisation de la technologie. Que ce soit en raison d'exigences commerciales et supérieures, ou de statut personnel, ils écrivent du code et effectuent des travaux de maintenance pour le projet Android, et AOSP est également le transporteur de ces travaux. Cependant, la valeur commerciale de l’AOSP pour Android et Google n’est plus la même.
Bien que la principale motivation de cette opération soit la réduction des coûts, à long terme, elle aidera également Google à augmenter ses revenus. Après tout, dans le passé, il était difficile pour Google d'obtenir des revenus directs ou des avantages indirects tels que des données provenant d'appareils non certifiés exécutant des systèmes d'exploitation basés sur AOSP.
Avant cet incident, Google gagnait de l'argent grâce à Android principalement en facturant aux OEM l'autorisation et la certification dans le cadre d'un accord de partenariat. Pour utiliser Android dans un cadre de conformité commerciale, les fabricants doivent signer un accord. Des détails tels que le contenu et la méthode de l'accord spécifique peuvent être différents, mais les règles générales restent inchangées. La principale source de revenus de Google sont les revenus publicitaires et le partage d'applications obtenus grâce aux applications et services Google préinstallés (recherche, Play Store, etc.).
Évidemment, les équipements non certifiés ne peuvent pas générer de revenus pour Google, mais l'existence de l'AOSP est « une robe de mariée pour les gens ». Comme toute entreprise commerciale, je crains qu’elle veuille se couper au plus vite de ces équipements et de ces fabricants.
# Bienvenue pour suivre le compte public officiel WeChat d'Aifaner : Aifaner (WeChat ID : ifanr). Un contenu plus passionnant vous sera fourni dès que possible.
Ai Faner | Lien original · Voir les commentaires · Sina Weibo