Ce document contient des réponses aux questions générales sur la plate-forme Android Open Source (AOSP).
À propos d'android-latest-release
Pourquoi ne puis-je pas envoyer à aosp-main ?
Vous ne pouvez pas envoyer de modifications à aosp-main, car cette branche est désormais en lecture seule.
Où puis-je proposer des modifications à AOSP ?
Vous devez proposer de nouvelles modifications à android-latest-release (lorsque vous utilisez Repo) ou à la dernière branche de version spécifiée dans le fichier manifeste android-latest-release (lorsque vous utilisez Git directement). Il n'est pas nécessaire de déplacer les modifications proposées existantes sur d'autres branches (telles que aosp-main).
À quelle branche dois-je synchroniser ?
Lorsque vous utilisez Repo, synchronisez-vous sur
android-latest-releaseà l'aide de la commande suivante :repo init --partial-clone --no-use-superproject -b android-latest-release -u https://android.googlesource.com/platform/manifestLorsque vous utilisez Git directement, synchronisez-vous avec la branche de révision par défaut spécifiée dans le fichier manifeste
android-latest-release.
Pour en savoir plus sur la synchronisation des branches, consultez Initialiser le client Repo.
Le code d'android-latest-release sera-t-il fusionné avec aosp-main ?
Non, le code ne sera pas fusionné dans aosp-main, qui est une branche en lecture seule depuis le 27 mars 2025.
Où le code de la prochaine version est-il transféré ?
Google transfère le code de la prochaine version vers la dernière branche de version publique et met à jour le fichier manifeste android-latest-release pour qu'il pointe vers cette branche.
Ma demande de modification sera-t-elle sélectionnée à partir de la branche android-latest-release et insérée dans Gerrit en interne ?
Une fois la modification proposée importée, Google l'examinera et, si elle est acceptée, la sélectionnera dans Gerrit en interne.
Comment savoir si ma demande de modification a été acceptée ?
Les modifications acceptées et sélectionnées apparaissent dans un futur push vers une branche de version sur l'hôte Android et peuvent être synchronisées avec repo à l'aide de android-latest-release.
Il n'existe pas de mécanisme de notification pour savoir si une modification proposée a été acceptée ou refusée.
Quel est le workflow général entre le moment où une modification est proposée par un contributeur externe et celui où elle est fusionnée dans la dernière branche de publication ?
Un contributeur externe propose une modification à
android-latest-release(lors de l'utilisation de Repo) ou à la dernière branche de version spécifiée dans le fichier manifesteandroid-latest-release(lors de l'utilisation directe de Git).Google examine la modification. Si la modification est :
Acceptée, Google sélectionne cette modification et la fusionne dans la branche de développement interne.
Non acceptée, Google ne sélectionne pas la modification.
Le contributeur externe vérifie que sa modification a été prise en compte dans
android-latest-release.
Que faire si je n'ai plus besoin de la modification que j'ai proposée ?
Si vous n'avez plus besoin de la modification proposée, si vous ne souhaitez pas qu'elle soit fusionnée ou si vous savez que Google l'a déjà examinée, abandonnez la modification afin qu'elle reste dans l'historique des modifications proposées sur l'hôte Android.
Questions sur l'Open Source
Pourquoi Google a-t-il ouvert le code source Android ?
Google a lancé l'AOSP en réponse à ses propres expériences de lancement d'applications mobiles. Nous voulions nous assurer qu'une plate-forme ouverte serait toujours disponible pour les opérateurs, les OEM et les développeurs afin qu'ils puissent concrétiser leurs idées innovantes. Nous voulions également éviter tout point de défaillance central, afin qu'aucun acteur du secteur ne puisse restreindre ni contrôler les innovations des autres. Notre objectif le plus important avec l'AOSP est de nous assurer que le logiciel Android Open Source est implémenté aussi largement et de manière aussi compatible que possible, pour le bénéfice de tous.
Quel type de projet open source est Android ?
Google supervise le développement de l'AOSP de base et s'efforce de créer des communautés d'utilisateurs et de développeurs solides. Dans la plupart des cas, le code source Android est concédé sous licence permissive Apache 2.0, plutôt que sous licence copyleft. Nous avons choisi la licence Apache 2.0, car nous pensons qu'elle encourage l'adoption généralisée du logiciel Android. Pour en savoir plus, consultez Licences.
Pourquoi Google est-il responsable d'Android ?
Lancer une plate-forme logicielle est une tâche complexe. L'ouverture est essentielle au succès à long terme d'une plate-forme, car elle attire les investissements des développeurs et garantit des conditions de concurrence équitables. La plate-forme doit également être un produit attrayant pour les utilisateurs.
Google s'est engagé à fournir les ressources d'ingénierie professionnelle nécessaires pour faire d'Android une plate-forme logicielle entièrement compétitive. Google considère le projet Android comme une opération de développement de produits à grande échelle et conclut les accords commerciaux nécessaires pour s'assurer que d'excellents appareils fonctionnant sous Android sont mis sur le marché.
En veillant à ce qu'Android soit un succès auprès des utilisateurs, nous contribuons à la vitalité d'Android en tant que plate-forme et projet Open Source. Après tout, qui voudrait le code source d'un produit qui ne fonctionne pas ?
Notre objectif est de garantir un écosystème Android performant. Nous avons ouvert le code source d'Android pour que chacun puisse modifier et distribuer le logiciel en fonction de ses propres besoins.
Quelle est la stratégie globale de Google pour le développement de produits Android ?
Nous lançons des appareils performants sur un marché concurrentiel. Nous intégrons ensuite les innovations et les améliorations que nous avons apportées à la plate-forme principale en tant que prochaine version.
En pratique, cela signifie que l'équipe d'ingénieurs Android se concentre sur un petit nombre d'appareils "phares" et développe la prochaine version du logiciel Android pour prendre en charge ces lancements de produits. Ces appareils phares absorbent une grande partie du risque produit et ouvrent la voie à la vaste communauté OEM, qui suit avec d'autres appareils qui profitent des nouvelles fonctionnalités. Nous nous assurons ainsi que la plate-forme Android évolue en fonction des besoins des appareils réels.
Comment le logiciel Android est-il développé ?
Chaque version de plate-forme Android (telle que 1.5 ou 8.1) possède une branche correspondante dans l'arborescence Open Source. La branche la plus récente est considérée comme la version stable actuelle, à laquelle le fichier manifeste android-latest-release fait référence.
Il s'agit de la branche que les fabricants transfèrent vers leurs appareils. Cette branche est toujours adaptée à la publication.
Enfin, Google travaille sur la prochaine version de la plate-forme Android en même temps qu'il développe un appareil phare.
Pourquoi certaines parties d'Android sont-elles développées en privé ?
Il faut généralement plus d'un an pour commercialiser un appareil. Et, bien sûr, les fabricants d'appareils veulent proposer la dernière version logicielle disponible. De leur côté, les développeurs ne souhaitent pas suivre en permanence les nouvelles versions de la plate-forme lorsqu'ils écrivent des applications. Les deux groupes sont confrontés à une tension entre la livraison de produits et la crainte de prendre du retard.
Pour résoudre ce problème, certaines parties de la prochaine version d'Android, y compris les API de plate-forme principales, sont développées dans une branche privée. Ces API constituent la prochaine version d'Android. Notre objectif est d'attirer l'attention sur la version stable actuelle du code source Android pendant que nous créons la prochaine version de la plate-forme. Cela permet aux développeurs et aux OEM d'utiliser une seule version sans avoir à suivre les travaux futurs inachevés juste pour rester à jour.
Quand les versions du code source sont-elles publiées ?
Quand ils seront prêts. La publication du code source est un processus assez complexe. Certaines parties d'Android, comme le noyau, sont développées en Open Source et leur code source est toujours disponible. D'autres parties sont d'abord développées dans un arbre privé, et ce code source est publié lorsque la prochaine version de la plate-forme est prête.
Dans certaines versions, les API de la plate-forme principale sont prêtes suffisamment à l'avance pour que nous puissions publier le code source pour un aperçu avant la sortie de l'appareil. Dans les autres versions, cela n'est pas possible. Dans tous les cas, nous publions la source de la plate-forme lorsque nous estimons que la version est stable et que le processus de développement le permet.
Qu'implique la publication du code source d'une nouvelle version d'Android ?
La publication du code source d'une nouvelle version de la plate-forme Android est un processus important. Tout d'abord, le logiciel est intégré à une image système pour un appareil et soumis à diverses formes de certification, y compris la certification réglementaire gouvernementale pour les régions dans lesquelles les téléphones seront déployés. Le code est également soumis à des tests d'opérateur. Il s'agit d'une phase importante du processus, car elle permet de détecter les bugs logiciels.
Une fois la version approuvée par les organismes de réglementation et les opérateurs, le fabricant commence la production de masse des appareils et nous commençons à publier le code source.
Parallèlement à la production de masse, l'équipe Google lance plusieurs initiatives pour préparer la publication en Open Source. Ces efforts incluent l'apport de modifications finales à l'API, la mise à jour de la documentation (pour refléter les modifications apportées lors des tests de qualification, par exemple), la préparation d'un SDK pour la nouvelle version et le lancement des informations sur la compatibilité de la plate-forme.
Notre équipe juridique donne son approbation finale pour que le code soit publié en open source. Tout comme les contributeurs Open Source sont tenus de signer un contrat de licence de contributeur attestant de la propriété intellectuelle de leur contribution, Google doit vérifier que la source est autorisée à apporter des contributions.
À partir du début de la production de masse, le processus de publication du logiciel prend généralement environ un mois. Les publications du code source ont donc souvent lieu à peu près au même moment où les appareils sont mis à la disposition des utilisateurs.
Quel est le lien entre l'AOSP et le programme de compatibilité Android ?
L'AOSP gère le logiciel Android et développe de nouvelles versions. Comme il s'agit d'un logiciel Open Source, il peut être utilisé à n'importe quelle fin, y compris pour développer des appareils qui ne sont pas compatibles avec d'autres appareils basés sur la même source.
Le programme de compatibilité Android a pour but de définir une implémentation de base d'Android compatible avec les applications tierces écrites par les développeurs. Les appareils compatibles avec Android peuvent participer à l'écosystème Android, y compris Google Play. Les appareils qui ne répondent pas aux exigences de compatibilité n'en font pas partie.
En d'autres termes, le programme de compatibilité Android nous permet de distinguer les appareils compatibles avec Android de ceux qui exécutent simplement des dérivés du code source. Nous acceptons toutes les utilisations du code source Android, mais pour participer à l'écosystème Android, un appareil doit être identifié comme compatible avec Android par le programme.
Comment puis-je contribuer à Android ?
Vous pouvez signaler des bugs, écrire des applications pour Android ou contribuer au code source de l'AOSP.
Nous n'acceptons pas tous les types de contributions de code. Par exemple, un utilisateur peut souhaiter proposer une autre API d'application, comme un environnement complet basé sur C++. Nous refuserions cette contribution, car Android encourage les applications à s'exécuter dans l'environnement d'exécution ART. De même, nous n'accepterons pas les contributions telles que les bibliothèques GPL ou LGPL qui ne sont pas compatibles avec nos objectifs de licence.
Nous encourageons les personnes intéressées par la contribution de code source à nous contacter via les canaux listés dans la communauté Android avant de commencer tout travail. Pour en savoir plus, consultez Contribuer.
Comment devenir un committer Android ?
L'AOSP n'a pas vraiment de notion de commiteur. Toutes les contributions (y compris celles des employés Google) passent par un système Web appelé Gerrit, qui fait partie du processus d'ingénierie Android. Ce système fonctionne en tandem avec le système de gestion du code source Git pour gérer proprement les contributions au code source.
Un approbateur désigné doit examiner et accepter toutes les modifications proposées. Les approbateurs sont généralement des employés Google, mais les mêmes approbateurs sont responsables de toutes les demandes, quelle que soit leur origine.
Pour en savoir plus, consultez Envoyer des correctifs.