Auf dieser Seite wird der vollständige Prozess zum Einreichen eines Patches an das Android Open Source Project (AOSP) beschrieben, einschließlich der Frage, wie Sie eine Überprüfung anfordern und Ihre Änderungen mit Gerrit nachverfolgen können.
Voraussetzungen
Stellen Sie zunächst sicher, dass Sie Folgendes getan haben:
- Ihre Build-Umgebung initialisiert
- Habe die Quelle heruntergeladen
- Mit dem Passwortgenerator ein Passwort erstellt .
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 .
- Lizenzierungsinformationen zum Beitragen von Code zur Android-Plattform finden Sie auf der Seite Lizenzen .
Für Mitwirkende
Authentifizierung beim Server
Wenn Sie eine IP-Adresse mit anderen Benutzern teilen, können Kontingente sogar für regelmäßige Nutzungsmuster ausgelöst werden. Dies kann beispielsweise passieren, wenn viele Benutzer innerhalb kurzer Zeit neue Clients von derselben IP-Adresse synchronisieren. Der authentifizierte Zugriff verwendet unabhängig von der IP-Adresse ein separates Kontingent für jeden Benutzer. Informationen zum Aktivieren des authentifizierten Zugriffs finden Sie unter Authentifizierung verwenden .
Starten eines Repo-Zweigs
Starten Sie für jede Änderung, die Sie vornehmen möchten, einen neuen Zweig innerhalb des relevanten Git-Repositorys:
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
Beschreibungen ändern
- Zeile 1: Überschrift
Geben Sie eine einzeilige Zusammenfassung ( maximal 50 Zeichen) an.
Dieses Format wird von Git und Gerrit für verschiedene Anzeigen 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 z. B. dieser, der
ui
als Präfix hat: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 maximal 72 Zeichen umfassen. Beschreiben Sie, welches Problem durch die Änderung gelöst wird und wie. Obwohl dies bei der Implementierung neuer Funktionen optional ist, ist es für andere später sehr hilfreich, wenn sie sich auf diese Änderung beziehen, insbesondere zum Debuggen.
Fügen Sie eine kurze Notiz zu Annahmen oder Hintergrundinformationen hinzu, 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
bereitgestellt werden, werden Ihrer Commit-Nachricht automatisch 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.
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
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 den neuen HEAD
des Quell-Repositorys. Führen Sie dazu diesen Befehl aus:
repo sync
Der Befehl repo sync
ruft die Aktualisierungen vom Quellserver ab und versucht dann, Ihren HEAD
automatisch auf den neuen Remote- HEAD
zu rebasen.
Wenn die automatische Neubasierung nicht erfolgreich ist, führen Sie eine manuelle Neubasierung durch.
repo rebase
Ein weiteres Tool zum Umgang mit dem Rebase-Konflikt ist git mergetool
. Wenn Sie die widersprüchlichen Dateien erfolgreich zusammengeführt haben, führen Sie diesen Befehl aus:
git rebase --continue
Nachdem die automatische oder manuelle Rebase abgeschlossen ist, führen Sie repo upload
aus, um Ihren rebasierten Patch zu übermitteln.
Nachdem eine Einreichung genehmigt wurde
Nachdem eine Übermittlung den Überprüfungs- und Verifizierungsprozess durchlaufen hat, fügt Gerrit die Änderung automatisch in das öffentliche Repository ein. Andere Benutzer können repo sync
ausführen, um das Update in ihre jeweiligen lokalen Clients zu ziehen.
Für Upstream-Projekte
Android nutzt eine Reihe anderer Open-Source-Projekte wie den Linux-Kernel und WebKit, wie in Android Software Management beschrieben. Nehmen Sie für die meisten Projekte, 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 diese Änderungen schwierig sein können, wenn das Projekt in Android weit verbreitet ist, wie die meisten der unten genannten größeren, die normalerweise mit jeder Version aktualisiert werden.
Ein interessanter Spezialfall ist Bionic. Ein Großteil des dortigen Codes stammt von BSD. Wenn die Änderung also nicht in Code geändert wird, der neu für Bionic ist, nehmen Sie bitte eine Upstream-Korrektur vor und ziehen Sie dann eine ganz neue Datei aus dem entsprechenden BSD.
Android-Kernel
Nehmen Sie alle Änderungen stromaufwärts vor. Als allgemeine Anleitung folgen Sie den Android Kernel Contribution Guidelines und der Seite Develop Kernel Code for GKI .
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-Fehlern und Funktionsanfragen . Fügen Sie allen Upstream-Jira-Anfragen das Label „Android“ hinzu.
CLDR
Die meisten Sprachdaten in ICU stammen aus dem Unicode CLDR-Projekt . Senden Sie alle Anfragen gemäß Contributing to CLDR upstream und fügen Sie das Label „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.
mksch
Nehmen Sie alle Änderungen am MirBSD-Korn-Shell-Projekt unter external/mksh
vor, indem Sie entweder eine E-Mail an miros-mksh
in der Domain mirbsd.org
senden (kein Abonnement erforderlich, um dort einzureichen) oder unter 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 . Einzelheiten finden Sie unter Mitwirken an V8 .
WebKit
Nehmen Sie alle Änderungen am WebKit-Projekt unter external/webkit
auf der WebKit-Seite vor. Beginnen Sie den Prozess, indem Sie einen WebKit-Fehler melden . Verwenden Sie im Fehler Android
nur dann für die Felder Plattform und Betriebssystem , wenn der Fehler für Android spezifisch ist. Es ist viel wahrscheinlicher, dass Fehler die Aufmerksamkeit der Prüfer auf sich ziehen, nachdem ein vorgeschlagener Fix hinzugefügt und Tests aufgenommen wurden. Weitere Informationen finden Sie unter Beitragen von Code zu WebKit .
zlib
Nehmen Sie alle Änderungen am zlib-Projekt unter external/zlib
auf der zlib-Homepage vor.