Questions fréquentes sur AOSP

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 d'élément à aosp-main ?

Vous ne pouvez pas envoyer d'élément à aosp-main, car cette branche est désormais en lecture seule.

Où dois-je proposer des modifications à l'AOSP ?

Vous devez proposer de nouvelles modifications à android-latest-release (lorsque vous utilisez Repo) ou à la branche de révision par défaut 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).

Pour en savoir plus, consultez Importer la modification pour examen.

Quelle branche dois-je synchroniser ?

• Lorsque vous utilisez Repo, synchronisez-vous avec 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/manifest

• Lorsque vous utilisez Git directement, synchronisez-vous avec la branche de révision par défaut spécifiée dans le android-latest-release fichier manifeste.

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é avec aosp-main, qui est une branche en lecture seule depuis le 27 mars 2025.

Où le code de la prochaine version est-il envoyé ?

Google envoie le code de la prochaine version à la dernière branche de version publique et met à jour le android-latest-release manifeste pour qu'il pointe vers cette branche.

Ma demande de modification sera-t-elle sélectionnée dans la branche android-latest-release et intégrée à Gerrit en interne ?

Une fois que vous avez importé une modification proposée, Google l'examine et, si elle est acceptée, la sélectionne et l'intègre à Gerrit en interne.

Comment savoir si ma demande de modification a été acceptée ?

Les modifications acceptées et sélectionnées apparaissent dans une future importation dans une branche de version sur l'hôte Android et peuvent être synchronisées avec le dépôt à l'aide d'android-latest-release. Il n'existe pas de mécanisme de notification lorsqu'une modification proposée est 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 version ?

1. Un contributeur externe propose une modification à android-latest-release (lorsqu'il utilise Repo) ou à la dernière branche de version spécifiée dans le fichier manifeste android-latest-release (lorsqu'il utilise Git directement).

2. Google examine la modification. Si la modification est :

   • acceptée, Google la sélectionne et la fusionne dans la branche de développement interne.

   • refusée, Google ne la sélectionne pas.

3. Le contributeur externe vérifie sa modification dans android-latest-release.

Que faire si je n'ai plus besoin de ma modification proposée ?

Si vous n'avez plus besoin de votre modification proposée, si vous ne voulez pas qu'elle soit fusionnée ou si vous savez que Google l'a déjà examinée, abandonnez-la 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 d'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é de la manière la plus large et la plus compatible possible, au profit 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 de développeurs et d'utilisateurs solides. Dans la plupart des cas, le code source Android est concédé sous licence Apache 2.0 permissive, plutôt que sous une 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 ?

Le lancement d'une plate-forme logicielle est 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 a engagé les ressources d'ingénierie professionnelles nécessaires pour s'assurer qu'Android est une plate-forme logicielle entièrement compétitive. Google traite 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 exécutant Android sont commercialisés.

En veillant à ce qu'Android soit un succès auprès des utilisateurs, nous contribuons à assurer la vitalité d'Android en tant que plate-forme et en tant que projet Open Source. Après tout, qui voudrait le code source d'un produit qui n'a pas marché ?

Notre objectif est de garantir un écosystème réussi autour d'Android. Nous avons ouvert le code source d'Android afin que chacun puisse modifier et distribuer le logiciel pour répondre à ses propres besoins.

Quelle est la stratégie globale de Google pour le développement de produits Android ?

Nous lançons d'excellents appareils sur un marché concurrentiel. Nous intégrons ensuite les innovations et les améliorations que nous avons apportées à la plate-forme de base en tant que version suivante.

En pratique, cela signifie que l'équipe d'ingénierie 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 lié au produit et ouvrent la voie à la vaste communauté d'OEM, qui suit avec davantage d'appareils tirant parti des nouvelles fonctionnalités. De cette façon, nous nous assurons 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 la plate-forme Android (par exemple, 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 de la branche stable actuelle, vers laquelle pointe le fichier manifeste android-latest-release. Il s'agit de la branche que les fabricants portent sur leurs appareils. Cette branche est toujours adaptée à la publication.

Enfin, Google travaille sur la prochaine version de la plate-forme Android en parallèle du développement d'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 expédier le logiciel le plus récent possible. Pendant ce temps, les développeurs ne veulent pas suivre constamment les nouvelles versions de la plate-forme lorsqu'ils écrivent des applications. Les deux groupes sont confrontés à une tension entre l'expédition de produits et le fait de ne pas vouloir être en retard.

Pour résoudre ce problème, certaines parties de la prochaine version d'Android, y compris les API de la plate-forme de base, 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 non terminés pour rester à jour.

Quand les versions du code source sont-elles publiées ?

Quand elles sont prêtes. 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 ce code source est toujours disponible. D'autres parties sont d'abord développées dans une arborescence privée, 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 de base sont prêtes suffisamment à l'avance pour que nous puissions publier le code source en avant-première avant la sortie de l'appareil. Dans d'autres versions, ce 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 à différentes formes de certification, y compris la certification réglementaire gouvernementale pour les régions où 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.

Lorsque la version est approuvée par les organismes de réglementation et les opérateurs, le fabricant commence la production en série des appareils, et nous commençons à publier le code source.

Parallèlement à la production en série, l'équipe Google lance plusieurs efforts pour préparer la version Open Source. Ces efforts incluent l'apport de modifications finales aux 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 effectue une signature finale pour publier le code 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 en série, le processus de publication du logiciel prend généralement environ un mois. Les versions du code source sont donc souvent publiées à peu près au même moment que les appareils sont mis à la disposition des utilisateurs.

Quel est le rapport 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 fonction 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'appartiennent pas à cet écosystème.

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.

Il existe des limites aux types de contributions de code que nous acceptons. Par exemple, quelqu'un peut vouloir contribuer à une API d'application alternative, telle qu'un environnement complet basé sur C++. Nous refuserions cette contribution, car Android encourage l'exécution des applications 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 sont incompatibles avec nos objectifs de licence.

Nous encourageons les personnes intéressées à contribuer au 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 la notion de committer. Toutes les contributions (y compris celles créées par des employés de 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 de 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.