Soumettre des correctifs

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.

1. Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.

   

2. 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.

• done (checkmark icon): Approved by code owner
• clear (cross icon): Not approved by code owner
• access_time (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 .