Cette page décrit le processus complet de soumission d'un correctif au projet Android Open Source (AOSP), y compris comment demander une révision et suivre vos modifications avec Gerrit .
Conditions préalables
Pour commencer, assurez-vous d'avoir effectué les opérations suivantes :
- Initialisé votre environnement de construction
- Téléchargé la source
- Création d'un mot de passe à l'aide du générateur de mot de passe.
Ressources
- Pour plus de détails sur Repo et Git, consultez la page Outils de contrôle de code source .
- Pour plus d'informations sur les différents rôles au sein de la communauté Android Open Source, consultez la page Rôles du projet .
- Pour obtenir des informations sur les licences relatives à la contribution de code à la plate-forme Android, consultez la page Licences .
Pour les contributeurs
Authentification auprès du serveur
Si vous partagez une adresse IP avec d'autres utilisateurs, des quotas peuvent être déclenchés même pour des modèles d'utilisation réguliers. Cela peut se produire lorsque, par exemple, de nombreux utilisateurs synchronisent de nouveaux clients à partir de la même adresse IP dans un court laps de temps. L'accès authentifié utilise un quota distinct pour chaque utilisateur, quelle que soit l'adresse IP. Pour en savoir plus sur l'activation de l'accès authentifié, consultez Utilisation de l'authentification .
Démarrer une branche Repo
Pour chaque modification que vous avez l'intention d'apporter, démarrez une nouvelle branche dans le référentiel Git concerné :
repo start NAME .
You can start several independent branches at the same time in the same
repository. The branch NAME
is local to your
workspace and isn't included either on Gerrit or in the final source tree.
Making your change
Modify the source files, and validate your changes.
Commit the changes to your local repository with these commands:
git add -A
git commit -s
Modifier les descriptions
- Ligne 1 : titre
Fournir un résumé d'une ligne (50 caractères maximum )
Ce format est utilisé par Git et Gerrit pour divers affichages. C'est la partie la plus importante et la plus dense de votre message de validation. Envisagez d'utiliser des préfixes pour décrire la zone que vous avez modifiée, suivis d'une description de la modification que vous avez apportée dans ce commit, comme celui-ci qui a
ui
comme préfixe :ui: Removes deprecated widget
- Ligne 2 : vide
Gardez cette ligne vide, toujours.
- Ligne 3 : Corps
Rédigez une description plus longue, en commençant sur cette ligne.
Celui-ci doit contenir 72 caractères maximum. Décrivez le problème que le changement résout et comment. Bien que cela soit facultatif lors de l'implémentation de nouvelles fonctionnalités, il est très utile pour les autres plus tard s'ils se réfèrent à ce changement, en particulier pour le débogage.
Incluez une brève note de toutes les hypothèses ou informations de fond qui pourraient être importantes lorsqu'un autre contributeur travaille sur cette fonctionnalité.
Un ID de modification unique, votre nom et votre adresse e-mail, qui sont fournis lors repo init
, sont automatiquement ajoutés à votre message de validation.
Voici un exemple de message de validation :
Line 1, Headline - a short description Line 3, Body - Add the detailed description of your patch here. Use as many lines as needed. You can write an overall description, then list specifics. I6e3c64e7a:Added a new widget. I60c539a8f:Fixed the spinning image.To read a blog about good commit descriptions (with examples), see How to Write a Git Commit Message by Chris Beams.
Uploading to Gerrit
After you commit your change to your personal history, upload it to Gerrit with this command:
repo upload
If you started multiple branches in the same repository, you're prompted to select which ones to upload.
After a successful upload, Repo provides you with the URL of a new page on Gerrit. Click the link that Repo gives you to view your patch on the review server, add comments, or request specific reviewers for your patch.
Requesting a review
After you've uploaded your changes to Gerrit, the patch must be reviewed
and approved by the appropriate code owners. Locate code owners in
OWNERS
files.
To find the appropriate code owners and add them as reviewers for your change, follow these steps.
-
Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.
Figure 1. Suggest owners link in Gerrit Add code owners from the list as reviewers for your patch.
To determine the status of the files in your patch, check for the following icons next to the files in the patch.
- (checkmark icon): Approved by code owner
- (cross icon): Not approved by code owner
- (clock icon): Pending approval by code owner

Uploading a replacement patch
Suppose a reviewer looked at your patch and requested a small modification. You can amend your commit within Git, which results in a new patch on Gerrit that has the same change ID as the original.
git add -A
git commit --amend
Lorsque vous téléchargez le correctif modifié, il remplace l'original à la fois sur Gerrit et dans votre historique Git local.
Résolution des conflits de synchronisation
Si d'autres correctifs sont soumis à l'arborescence source qui entrent en conflit avec le vôtre, rebasez votre correctif sur le nouveau HEAD
du référentiel source. Pour ce faire, exécutez cette commande :
repo sync
La commande repo sync
récupère les mises à jour du serveur source, puis tente de rebaser automatiquement votre HEAD
sur le nouveau HEAD
distant.
Si le rebase automatique échoue, effectuez un rebase manuel.
repo rebase
Un autre outil pour gérer le conflit de rebase est git mergetool
. Lorsque vous avez réussi à fusionner les fichiers en conflit, exécutez cette commande :
git rebase --continue
Une fois le rebasage automatique ou manuel terminé, exécutez repo upload
pour soumettre votre correctif rebasé.
Après l'approbation d'une soumission
Une fois qu'une soumission a franchi le processus d'examen et de vérification, Gerrit fusionne automatiquement la modification dans le référentiel public. Les autres utilisateurs peuvent exécuter repo sync
pour extraire la mise à jour dans leurs clients locaux respectifs.
Pour les projets en amont
Android utilise un certain nombre d'autres projets open source, tels que le noyau Linux et WebKit, comme décrit dans Android Software Management . Pour la plupart des projets qui résident sous external/
, apportez les modifications en amont, puis informez les responsables Android de la nouvelle version en amont qui contient vos modifications.
Vous pouvez également télécharger des correctifs qui entraînent le suivi d'une nouvelle version en amont. Notez que ces changements peuvent être difficiles à apporter si le projet est largement utilisé dans Android, comme la plupart des plus grands mentionnés ci-dessous, qui sont généralement mis à jour avec chaque version.
Un cas particulier intéressant est Bionic. Une grande partie du code provient de BSD, donc à moins que le changement ne concerne un code nouveau pour Bionic, veuillez faire un correctif en amont, puis une extraction d'un tout nouveau fichier à partir du BSD approprié.
Noyau Android
Effectuez toutes les modifications en amont. Pour obtenir des conseils généraux, suivez les directives de contribution du noyau Android et la page Développer le code du noyau pour GKI .
soins intensifs
Apportez toutes les modifications au projet ICU dans external/icu
(dossiers icu4c/
et icu4j/
) sur la page d'accueil ICU-TC . Voir Soumettre des bogues ICU et des demandes de fonctionnalités pour en savoir plus. Ajoutez le libellé « android » à toutes les requêtes Jira en amont.
CLDR
La plupart des données linguistiques d'ICU proviennent du projet Unicode CLDR . Soumettez toutes les demandes en amont selon Contributing to CLDR et ajoutez l'étiquette "android".
LLVM/Clang/Compilateur-rt
Apportez toutes les modifications aux projets liés à LLVM ( external/clang
, external/compiler-rt
, external/llvm
) sur la page Infrastructure du compilateur LLVM .
mksh
Apportez toutes les modifications au projet MirBSD Korn Shell sur external/mksh
en envoyant un e-mail à miros-mksh
sur le domaine mirbsd.org
(aucun abonnement requis pour y soumettre) ou sur Launchpad .
OpenSSL
Apportez toutes les modifications au projet OpenSSL dans external/openssl
sur la page OpenSSL .
V8
Soumettez toutes les modifications apportées au projet V8 sur external/v8
sur la page de publication V8 . Voir Contribuer à V8 pour plus de détails.
Kit Web
Apportez toutes les modifications au projet WebKit sur external/webkit
sur la page WebKit . Démarrez le processus en signalant un bogue WebKit . Dans le bogue, utilisez Android
pour les champs Plate-forme et Système d'exploitation uniquement si le bogue est spécifique à Android. Les bogues sont beaucoup plus susceptibles de recevoir l'attention des réviseurs après l'ajout d'un correctif proposé et l'inclusion de tests. Voir Contribuer du code à WebKit pour plus de détails.
zlib
Apportez toutes les modifications au projet zlib dans external/zlib
sur la page d'accueil de zlib .