AOSP, Google et fabricants : qui contrôle Android ?

Google dirige le développement principal d'Android, mais ne contrôle pas seul tout ce qui arrive sur un téléphone. AOSP fournit la base ouverte du système, Google ajoute des services propriétaires, les fabricants créent leurs interfaces, les fournisseurs de composants livrent des pilotes et les opérateurs peuvent imposer des validations. Cette organisation en couches explique pourquoi deux appareils associés à l'écosystème Android peuvent fonctionner, évoluer et être mis à jour très différemment.

AOSP : une base ouverte principalement pilotée par Google

AOSP, pour Android Open Source Project, contient le code source de la base Android : composants du système, bibliothèques, outils, environnement d'exécution et applications élémentaires. Une grande partie est publiée sous licence Apache, tandis que le noyau Linux employé par Android relève notamment de la licence GPL. Le lien technique avec le noyau est particulièrement éclairant à l'occasion de l'anniversaire de Linux.

AOSP est ouvert, mais cela ne signifie pas que sa gouvernance est répartie à parts égales entre Google, les fabricants et une fondation indépendante. Google détermine l'essentiel de la feuille de route, développe de nombreux composants, organise leur intégration et publie les versions de référence. Des entreprises et des développeurs extérieurs peuvent contribuer, mais Google conserve une position centrale dans les décisions techniques.

Android est ouvert par son code de base, mais son développement principal reste dirigé par Google.

Une entreprise peut utiliser AOSP pour créer un système dérivé sans reprendre tous les produits de Google. Elle doit toutefois assurer elle-même les services, les applications, l'assistance et la maintenance qui ne sont pas inclus dans cette base.

Les services Google ne font pas tous partie d'AOSP

Un téléphone Android commercialisé avec le Play Store comporte généralement une couche propriétaire appelée Google Mobile Services, ou GMS. Elle réunit notamment le magasin d'applications, les services Google Play et plusieurs applications de Google. Ces éléments ne sont pas simplement téléchargeables dans AOSP comme du code libre : leur préinstallation dépend d'accords commerciaux et d'exigences de compatibilité.

Les services Google Play fournissent des fonctions utilisées par de nombreuses applications, comme certaines interfaces de localisation, de notification, d'authentification ou de sécurité. Une partie de l'expérience associée à Google Maps repose ainsi sur des composants qui dépassent la seule base AOSP. De même, Google Chrome peut être préinstallé sur un appareil certifié sans être le navigateur fondamental de tout système issu d'AOSP.

Il faut donc distinguer trois notions :

• AOSP, la base ouverte et modifiable du système ;
• Android compatible, un appareil respectant les exigences techniques définies pour l'écosystème ;
• Android avec GMS, un appareil autorisé à intégrer les services et applications propriétaires de Google ;
• un fork d'AOSP, un système dérivé qui peut employer une autre boutique et d'autres services.

Ce que les fabricants changent réellement

Samsung, Xiaomi, Oppo, Google et les autres constructeurs ne se contentent pas de poser un logo sur AOSP. Ils adaptent le système à leurs appareils et ajoutent une surcouche, c'est-à-dire un ensemble de modifications visibles ou internes. Cela peut inclure l'écran d'accueil, les réglages, l'appareil photo, les fonctions multitâches, l'économie d'énergie, les applications préinstallées et les mécanismes de connexion entre plusieurs appareils.

Chaque constructeur choisit aussi sa gamme de produits, la quantité de mémoire, les composants photographiques, les capteurs et la durée de maintenance annoncée. La comparaison avec l'écosystème d'Apple fait ressortir une différence structurelle : Apple conçoit le système et maîtrise une gamme matérielle limitée, alors qu'Android doit fonctionner sur des appareils produits par de nombreuses entreprises.

La marque Android et l'accès aux services Google ne donnent donc pas à Google un contrôle direct sur chaque détail d'un téléphone. Le fabricant demeure responsable de l'assemblage logiciel final, de son interface, de nombreuses applications et, le plus souvent, de la distribution des mises à jour.

Pilotes, puces et opérateurs : les acteurs moins visibles

Les fournisseurs de composants

Le système doit communiquer avec le processeur, le modem, l'écran, les caméras, le lecteur d'empreintes et les autres composants. Les fabricants de puces et d'équipements fournissent pour cela des pilotes, des bibliothèques et des couches d'adaptation. Certains éléments sont ouverts, d'autres restent propriétaires.

Si un fournisseur cesse de maintenir une plateforme matérielle, le constructeur du téléphone peut rencontrer des difficultés pour adopter une nouvelle base Android ou corriger certaines vulnérabilités. La capacité de mise à jour dépend donc autant de la chaîne matérielle que du code publié par Google.

Les opérateurs mobiles

Selon le pays, le modèle et le canal de vente, un opérateur peut tester une mise à jour avant sa diffusion. Il vérifie notamment les appels, les données mobiles, les appels sur Wi-Fi, la voix sur le réseau mobile moderne et les fonctions propres à son réseau. Il peut aussi demander des réglages ou des applications spécifiques.

L'opérateur ne développe pas la base d'Android, mais sa certification peut retarder une version destinée à ses clients. Son influence est généralement plus forte sur un appareil vendu et personnalisé par ses soins que sur un modèle acheté sans personnalisation opérateur. Cette dépendance aux réseaux rappelle combien la téléphonie mobile a évolué depuis le premier SMS.

Qui distribue les correctifs et pourquoi les délais varient

Un correctif suit souvent une chaîne comportant plusieurs responsables. Google corrige AOSP ou ses propres services. Le fournisseur de puces adapte les éléments liés au matériel. Le constructeur intègre le changement dans son système, le teste sur chaque modèle et prépare la distribution. Un opérateur peut ensuite effectuer une validation supplémentaire.

1. Une faille ou un dysfonctionnement est identifié dans une couche précise.
2. Le responsable de cette couche produit ou reçoit le correctif.
3. Le constructeur l'intègre à la version propre au modèle concerné.
4. Des tests vérifient le démarrage, les applications, le réseau et les composants.
5. La mise à jour est diffusée progressivement, parfois après validation d'un opérateur.

Toutes les mises à jour ne suivent cependant pas exactement ce circuit. Google peut actualiser ses applications et certains services par le Play Store. Des composants système modulaires peuvent également recevoir des correctifs sans nécessiter une mise à niveau complète préparée par le fabricant. Cette modularité réduit certaines dépendances, sans supprimer la responsabilité du constructeur pour le système global.

Pour juger la maintenance d'un téléphone, il faut examiner la durée de support promise, la fréquence des correctifs, la portée géographique de cet engagement et les éventuelles différences entre modèles. Comme dans l'écosystème logiciel associé à l'histoire de Microsoft, contrôler une plateforme ne signifie pas maîtriser chaque matériel, chaque application et chaque canal de distribution.