
Selon l'entreprise, ce changement vise à simplifier les choses, en s'appuyant sur un changement récent en faveur d'un développement basé sur le tronc. Comme Google travaille à la fois sur les branches publiques et privées d'Android, les deux branches ne sont pas synchronisées en ce qui concerne les fonctionnalités et la prise en charge des API. Cela oblige Google à fusionner fastidieusement les branches pour chaque version. En se concentrant sur la branche interne, Google affirme pouvoir rationaliser les versions et faciliter la vie de tous.
Après plus de 16 ans, Google apporte des changements importants à AOSP
Quel que soit le fabricant, tous les téléphones Android ont un point commun : leur base logicielle. Les fabricants peuvent fortement personnaliser l'aspect et la convivialité du système d'exploitation Android qu'ils livrent sur leurs appareils Android, mais sous le capot, la fonctionnalité centrale du système est dérivée de la même base open-source : le projet Android Open Source. Après plus de 16 ans, Google apporte des changements importants à la façon dont il développe la version open source d'Android dans le but de rationaliser son développement.
Le projet Android Open Source, ou AOSP en abrégé, est un système d'exploitation que Google publie sous la licence Apache 2.0. Apache 2.0 est une licence logicielle qui permet à quiconque d'utiliser, de distribuer ou de modifier et de distribuer des systèmes d'exploitation basés sur AOSP sans avoir à payer de droits de licence ou à publier le code source. Cette structure de licence permissive a facilité l'adoption généralisée de l'AOSP, ce qui a conduit à la création de forks personnalisés tels que One UI de Samsung.
Comme beaucoup d'autres projets open-source, l'AOSP accepte les contributions au code de développeurs tiers. Toutefois, Google assure lui-même la majeure partie du développement de l'AOSP, car il « traite le projet Android comme une opération de développement de produits à part entière » afin de « garantir la vitalité d'Android en tant que plateforme et projet à code source ouvert ». Par conséquent, Google a le dernier mot sur le code qui peut être fusionné dans l'AOSP et sur la date de publication de la nouvelle version du code source. La société développe les composants AOSP en privé pour permettre « aux développeurs et aux équipementiers d'utiliser une seule version d'Android sans avoir à suivre des travaux futurs inachevés pour rester dans la course ».
Afin d'équilibrer la nature ouverte de l'AOSP avec sa stratégie de développement de produits, Google maintient deux branches principales d'Android : la branche publique de l'AOSP et sa branche de développement interne. La branche AOSP est accessible à tous, tandis que la branche interne de Google est réservée aux entreprises ayant conclu un accord de licence avec Google Mobile Services (GMS).
Alors que certains composants du système d'exploitation, tels que la pile Bluetooth d'Android, sont développés publiquement dans la branche AOSP, la plupart des composants, y compris le framework principal du système d'exploitation Android, sont développés en privé dans la branche interne de Google. Google a confirmé qu'il allait bientôt transférer tout le développement du système d'exploitation Android vers sa branche interne, un changement destiné à rationaliser son processus de développement.
Un changement pour « simplifier les choses »
Google développant de grandes parties d'Android dans sa branche interne, la branche publique AOSP est souvent très en retard par rapport à ce qui est disponible en privé. Cette différence est évidente lorsqu'on compare la disponibilité des fonctionnalités et des API entre une version AOSP propre et la dernière version bêta d'Android 16 de Google, qui a été créée à partir de sa branche interne. Bien que le passage à un développement basé sur le tronc ait réduit cet écart, il persiste et continue de poser des problèmes à Google.
Cet écart oblige Google à consacrer du temps et des efforts à la fusion des correctifs entre la branche publique AOSP et sa branche interne. En raison de la différence entre les branches, des conflits de fusion surviennent souvent.
Prenons l'exemple de ce correctif (voir en source) qui active la fonctionnalité de loupe d'écran pour la barre de navigation et le clavier. Le correctif introduit un nouveau paramètre d'accessibilité, qui est placé à la fin de la liste des paramètres d'accessibilité. Cela crée un conflit de fusion car la longueur de la liste varie entre AOSP et la branche interne de Google.
Si la correction de ce problème spécifique est simple, de nombreux autres correctifs AOSP déclenchent des conflits de fusion similaires lorsqu'ils sont intégrés dans la branche interne de Google.
De même, le développement de la nouvelle API de zone de stockage déverrouillée d'Android a nécessité qu'un ingénieur de Google sélectionne un correctif de la branche interne de l'AOSP pour résoudre un conflit de fusion. En effet, alors que l'API a été développée dans l'AOSP, le fichier contenant les nouveaux drapeaux de construction d'Android a été développé en interne. Par conséquent, un correctif mettant à jour les fichiers de drapeaux de construction a dû être soumis en interne, puis appliqué à l'AOSP.
Il existe probablement d'innombrables exemples de conflits de fusion de ce type, et c'est la raison pour laquelle Google abandonne sa stratégie de développement Android à deux volets et transfère l'ensemble du développement en interne.
Les implications
Google a confirmé qu'il s'engageait à publier le code source d'Android, ce qui ne signifie pas qu'Android devienne fermé. L'entreprise continuera à publier le code source des nouvelles versions d'Android. Ainsi, lorsque Google sortira Android 16 dans le courant de l'année, nous obtiendrons le code source de la mise à jour. En outre, Google continuera à publier le code source du noyau Linux d'Android, car il est régi par la licence GPLv2, qui impose la publication du code source, et il est distinct de l'AOSP.
Ce qui changera, c'est la fréquence de publication du code source de certains composants d'Android. Certains composants comme le système de construction, le moteur de mise à jour, la pile Bluetooth, le cadre de virtualisation et la configuration SELinux sont actuellement AOSP-first, ce qui signifie qu'ils sont entièrement développés en public. La plupart des composants d'Android, comme le système d'exploitation principal, sont principalement développés en interne, bien que certaines fonctionnalités, comme l'API de la zone de stockage non verrouillée, soient toujours développées au sein de l'AOSP.
Le changement va entrer en vigueur dès la semaine prochaine
À partir de la semaine prochaine, tout le développement d'Android se fera dans les branches internes de Google, et le code source des modifications ne sera publié que lorsque Google publiera une nouvelle branche contenant ces modifications. Comme c'est déjà le cas pour la plupart des modifications apportées aux composants d'Android, Google consolide simplement ses efforts de développement dans une seule branche.
Ce changement n'aura qu'un impact minime sur les utilisateurs réguliers. Bien qu'il rationalise le développement du système d'exploitation Android pour Google, affectant potentiellement la vitesse de développement des nouvelles versions et la réduction des bogues, l'effet global sera probablement imperceptible. Par conséquent, ne vous attendez pas à ce que ce changement accélère les mises à jour du système d'exploitation de votre téléphone.
Ce changement aura également un impact minimal sur la plupart des développeurs. Les développeurs d'applications ne sont pas concernés, car ce changement ne porte que sur le développement de la...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.