Senden Sie Patches

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 .

Voraussetzungen

Stellen Sie zunächst sicher, dass Sie Folgendes getan haben:

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

Für Mitwirkende

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 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 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 von Ihnen geänderten Bereich zu beschreiben, 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.

Sign contributor license agreement

Before you can upload a change to Gerrit, you must sign an Individual Contributor License Agreement. If you work for a corporation, you might also need your coproration to sign a Corporation Contributor License Agreement. For more information on these agreements, including links to each, see Contributor license agreements.

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.

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

    suggest owners link in Gerrit
    Figure 1. Suggest owners link in Gerrit

  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.

  • (checkmark icon): Approved by code owner
  • (cross icon): Not approved by code owner
  • (clock icon): Pending approval by code owner
Figure 2. Example of files with icons showing code owner approval status

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