Auf dieser Seite wird der vollständige Prozess der Übermittlung eines Patches an das Android Open Source Project (AOSP) beschrieben, einschließlich der Anforderung einer Überprüfung und der Nachverfolgung Ihrer Änderungen bei Gerrit . Gerrit ist ein webbasiertes Code-Review-System für Projekte, die Git verwenden. Gerrit fördert eine stärker zentralisierte Nutzung von Git, indem er allen autorisierten Benutzern ermöglicht, Änderungen einzureichen, die automatisch zusammengeführt werden, wenn sie die Codeüberprüfung bestehen. Darüber hinaus vereinfacht Gerrit die Überprüfung, indem es Änderungen nebeneinander im Browser anzeigt und Inline-Kommentare ermöglicht.
Voraussetzungen
Stellen Sie zunächst sicher, dass Sie Folgendes getan haben:
- Initialisierte Ihre Build-Umgebung
- Habe die Quelle heruntergeladen
- Mit dem Passwortgenerator ein Passwort erstellt .
- Unterzeichnen Sie die Lizenzvereinbarungen für Mitwirkende
Ressourcen
- Einzelheiten zu Repo und Git finden Sie auf der Seite „Source Control Tools“ .
- Informationen zu verschiedenen Rollen innerhalb der Android Open Source-Community finden Sie auf der Seite Projektrollen .
- Lizenzinformationen zum Beitragen von Code zur Android-Plattform finden Sie auf der Seite „Lizenzen“ .
Git konfigurieren
Um Gerrit nutzen zu können, muss Ihre E-Mail-Adresse mit einem registrierten Google-Konto verknüpft sein. Führen Sie die folgenden Befehle aus, um Git mit einem Namen und einer E-Mail-Adresse zu konfigurieren, die einem registrierten Google-Konto zugeordnet sind:
git config --global user.name Your Name
git config --global user.email your_email@gmail.com
Authentifizieren Sie sich beim Server
Wenn Sie eine IP-Adresse mit anderen Benutzern teilen, können Kontingente auch bei regelmäßigem Nutzungsverhalten ausgelöst werden. Dies kann beispielsweise passieren, wenn viele Benutzer innerhalb kurzer Zeit neue Clients von derselben IP-Adresse synchronisieren. Beim authentifizierten Zugriff wird unabhängig von der IP-Adresse für jeden Benutzer ein separates Kontingent verwendet. Informationen zum Aktivieren des authentifizierten Zugriffs finden Sie unter Authentifizierung verwenden .
Starten Sie einen Repo-Zweig
Starten Sie für jede Änderung, die Sie vornehmen möchten, einen neuen Zweig im entsprechenden Git-Repository:
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.
Make your change
Modify the source files, and test your changes.
For any changes made, follow License header best practices.
Commit your change
Commit the changes to your local repository with these commands:
git add -A
git commit -s
Beschreibungen ändern
- Zeile 1: Überschrift
Geben Sie eine einzeilige Zusammenfassung an ( maximal 50 Zeichen).
Dieses Format wird von Git und Gerrit für verschiedene Darstellungen verwendet. Es ist der wichtigste und dichteste Teil Ihrer Commit-Nachricht. Erwägen Sie die Verwendung von Präfixen, um den Bereich zu beschreiben, den Sie geändert haben, gefolgt von einer Beschreibung der Änderung, die Sie in diesem Commit vorgenommen haben, wie zum Beispiel dieses mit dem Präfix
ui
:ui: Removes deprecated widget
- Zeile 2: Leer
Lassen Sie diese Zeile immer leer.
- Zeile 3: Körper
Schreiben Sie eine längere Beschreibung, beginnend mit dieser Zeile.
Dies muss mit maximal 72 Zeichen fest umbrochen werden. Beschreiben Sie, welches Problem die Änderung löst und wie. Obwohl dies bei der Implementierung neuer Funktionen optional ist, ist es für andere später sehr hilfreich, wenn sie auf diese Änderung verweisen, insbesondere beim Debuggen.
Fügen Sie eine kurze Notiz zu allen Annahmen oder Hintergrundinformationen bei, die wichtig sein könnten, wenn ein anderer Mitwirkender an dieser Funktion arbeitet.
Eine eindeutige Änderungs-ID sowie Ihr Name und Ihre E-Mail-Adresse, die während repo init
angegeben werden, werden automatisch zu Ihrer Commit-Nachricht hinzugefügt.
Hier ist eine Beispiel-Commit-Nachricht:
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.
Upload 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.
Request 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.
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
Upload 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
Wenn Sie den geänderten Patch hochladen, ersetzt er das Original sowohl auf Gerrit als auch in Ihrem lokalen Git-Verlauf.
Synchronisierungskonflikte lösen
Wenn andere Patches an den Quellbaum übermittelt werden, die mit Ihrem in Konflikt stehen, rebasieren Sie Ihren Patch auf dem neuen HEAD
des Quell-Repositorys. Führen Sie dazu diesen Befehl aus:
repo sync
Der repo sync
ruft die Aktualisierungen vom Quellserver ab und versucht dann, Ihren HEAD
automatisch auf den neuen Remote- HEAD
umzubasieren.
Wenn das automatische Rebase nicht erfolgreich ist, führen Sie ein manuelles Rebase durch.
repo rebase
Ein weiteres Tool zur Bewältigung des Rebase-Konflikts ist git mergetool
. Wenn Sie die in Konflikt stehenden Dateien erfolgreich zusammengeführt haben, führen Sie diesen Befehl aus:
git rebase --continue
Nachdem die automatische oder manuelle Neubasierung abgeschlossen ist, führen Sie repo upload
aus, um Ihren neubasierten Patch einzureichen.
Nachdem eine Einreichung genehmigt wurde
Nachdem eine Einreichung den Überprüfungs- und Verifizierungsprozess durchlaufen hat, führt Gerrit die Änderung automatisch in das öffentliche Repository ein. Andere Benutzer können repo sync
ausführen, um das Update auf ihre jeweiligen lokalen Clients zu übertragen.
Für vorgelagerte Projekte
Android nutzt eine Reihe anderer Open-Source-Projekte wie den Linux-Kernel und WebKit, wie in Android Software Management beschrieben. Nehmen Sie bei den meisten Projekten, die sich unter external/
befinden, die Änderungen im Upstream vor und informieren Sie dann die Android-Betreuer über die neue Upstream-Version, die Ihre Änderungen enthält.
Sie können auch Patches hochladen, die dazu führen, dass eine neue Upstream-Version nachverfolgt wird. Beachten Sie, dass es schwierig sein kann, diese Änderungen vorzunehmen, wenn das Projekt häufig in Android verwendet wird, wie die meisten der unten aufgeführten größeren Projekte, die normalerweise mit jeder Veröffentlichung aktualisiert werden.
Ein interessanter Sonderfall ist Bionic. Ein großer Teil des dortigen Codes stammt von BSD. Wenn es sich also nicht um Code handelt, der für Bionic neu ist, nehmen Sie bitte einen Upstream-Fix vor und ziehen Sie dann eine ganz neue Datei aus dem entsprechenden BSD.
Android-Kernel
Nehmen Sie alle Änderungen vorab vor. Allgemeine Hinweise finden Sie in den Beitragsrichtlinien zum Android-Kernel und auf der Seite Kernelcode für GKI entwickeln .
Intensivstation
Nehmen Sie alle Änderungen am ICU-Projekt unter external/icu
(Ordner icu4c/
und icu4j/
) auf der ICU-TC-Homepage vor . Weitere Informationen finden Sie unter Einreichen von ICU-Bugs und Funktionsanfragen . Fügen Sie allen Upstream-Jira-Anfragen die Bezeichnung „android“ hinzu.
CLDR
Die meisten Sprachdaten auf der Intensivstation stammen aus dem Unicode CLDR-Projekt . Senden Sie alle Anfragen gemäß „Mitwirken an CLDR“ vorab und fügen Sie die Bezeichnung „android“ hinzu.
LLVM/Clang/Compiler-rt
Nehmen Sie alle Änderungen an LLVM-bezogenen Projekten ( external/clang
, external/compiler-rt
, external/llvm
) auf der Seite „LLVM-Compiler-Infrastruktur“ vor.
mksh
Nehmen Sie alle Änderungen am MirBSD Korn Shell-Projekt unter external/mksh
vor, indem Sie entweder eine E-Mail an miros-mksh
auf der Domäne mirbsd.org
senden (für die Übermittlung dort ist kein Abonnement erforderlich) oder an Launchpad .
OpenSSL
Nehmen Sie alle Änderungen am OpenSSL-Projekt unter external/openssl
auf der OpenSSL-Seite vor.
V8
Senden Sie alle Änderungen am V8-Projekt unter external/v8
auf der V8-Problemseite . Weitere Informationen finden Sie unter Mitwirken an V8 .
WebKit
Nehmen Sie alle Änderungen am WebKit-Projekt unter external/webkit
auf der WebKit-Seite vor. Starten Sie den Prozess, indem Sie einen WebKit-Fehler melden . Verwenden Sie im Fehlerfall Android
nur dann für die Felder „Plattform“ und „Betriebssystem “, wenn der Fehler spezifisch für Android ist. Es ist weitaus wahrscheinlicher, dass Fehler die Aufmerksamkeit der Prüfer auf sich ziehen, nachdem ein vorgeschlagener Fix hinzugefügt und Tests einbezogen wurden. Weitere Informationen finden Sie unter Code zu WebKit beitragen .
zlib
Nehmen Sie alle Änderungen am zlib-Projekt unter external/zlib
auf der zlib-Homepage vor.