Prześlij poprawki

Na tej stronie opisano pełny proces przesyłania łatki do projektu Android Open Source Project (AOSP), w tym sposób żądania sprawdzenia i śledzenia zmian za pomocą Gerrita .

Warunki wstępne

Aby rozpocząć, upewnij się, że wykonałeś następujące czynności:

Zasoby

  • Aby uzyskać szczegółowe informacje na temat Repo i Git, zobacz stronę Narzędzia kontroli źródła .
  • Aby uzyskać informacje na temat różnych ról w społeczności Android Open Source, zobacz stronę ról w projekcie .
  • Informacje o licencjach na temat udostępniania kodu na platformę Android można znaleźć na stronie Licencje .

Dla autorów

Uwierzytelnij się na serwerze

Jeśli udostępniasz adres IP innym użytkownikom, limity mogą zostać uruchomione nawet w przypadku regularnych wzorców użytkowania. Może się to zdarzyć, gdy na przykład wielu użytkowników synchronizuje nowych klientów z tego samego adresu IP w krótkim czasie. Dostęp uwierzytelniony wykorzystuje oddzielny limit dla każdego użytkownika, niezależnie od adresu IP. Aby przeczytać o aktywowaniu uwierzytelnionego dostępu, zobacz Korzystanie z uwierzytelniania .

Uruchom oddział Repo

Dla każdej zmiany, którą zamierzasz wprowadzić, rozpocznij nową gałąź w odpowiednim repozytorium Git:

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

Zmień opisy

  • Wiersz 1: Nagłówek

    Podaj jednoliniowe podsumowanie ( maksymalnie 50 znaków)

    Ten format jest używany przez Git i Gerrit do różnych wyświetlaczy. To najważniejsza, najgęstsza część wiadomości o zatwierdzeniu. Rozważ użycie przedrostków do opisania zmienionego obszaru, po którym należy podać opis zmiany wprowadzonej w tym zatwierdzeniu, na przykład ten, który ma przedrostek ui :

    ui: Removes deprecated widget

  • Linia 2: Pusta

    Zawsze pozostawiaj tę linię pustą.

  • Linia 3: Ciało

    Napisz dłuższy opis, zaczynając od tej linijki.

    Musi to być zawinięte na stałe i mieć maksymalnie 72 znaki. Opisz, jaki problem rozwiązuje ta zmiana i w jaki sposób. Chociaż jest to opcjonalne przy wdrażaniu nowych funkcji, jest bardzo pomocne dla innych osób później, jeśli odwołują się do tej zmiany, szczególnie w przypadku debugowania.

    Dołącz krótką notatkę na temat wszelkich założeń lub informacji ogólnych, które mogą być ważne, gdy inny współautor pracuje nad tą funkcją.

Unikalny identyfikator zmiany oraz Twoje imię i nazwisko oraz adres e-mail, które są podawane podczas repo init , są automatycznie dodawane do wiadomości zatwierdzenia.

Oto przykładowy komunikat zatwierdzenia:

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

Gdy prześlesz poprawioną łatkę, zastępuje ona oryginał zarówno w Gerrit, jak i w lokalnej historii Git.

Rozwiązuj konflikty synchronizacji

Jeśli do drzewa źródłowego przesłane zostaną inne łatki, które kolidują z twoim, ponownie oprzyj łatkę na nowym HEAD repozytorium źródłowego. Aby to zrobić, uruchom to polecenie:

repo sync

Polecenie repo sync pobiera aktualizacje z serwera źródłowego, a następnie próbuje automatycznie ponownie bazować HEAD na nowym zdalnym HEAD .

Jeśli automatyczna zmiana bazy nie powiedzie się, wykonaj ręczną zmianę bazy.

repo rebase

Innym narzędziem do radzenia sobie z konfliktem rebase jest git mergetool . Po pomyślnym połączeniu plików będących w konflikcie uruchom to polecenie:

git rebase --continue

Po zakończeniu automatycznej lub ręcznej zmiany bazy uruchom repo upload , aby przesłać łatkę ponownie opartą.

Po zatwierdzeniu zgłoszenia

Gdy zgłoszenie przejdzie przez proces przeglądu i weryfikacji, Gerrit automatycznie łączy zmianę z publicznym repozytorium. Inni użytkownicy mogą uruchomić repo sync , aby pobrać aktualizację do swoich lokalnych klientów.

Dla projektów typu upstream

Android korzysta z wielu innych projektów open source, takich jak jądro Linuksa i WebKit, jak opisano w Zarządzanie oprogramowaniem Androida . W przypadku większości projektów znajdujących się w folderze external/ wprowadź zmiany wcześniej, a następnie poinformuj opiekunów Androida o nowej wersji źródłowej, która zawiera Twoje zmiany.

Możesz także przesłać poprawki, które umożliwią śledzenie nowej wersji źródłowej. Pamiętaj, że wprowadzenie tych zmian może być trudne, jeśli projekt jest szeroko używany w systemie Android, jak większość większych projektów wymienionych poniżej, które zwykle są aktualizowane z każdą wersją.

Ciekawym przypadkiem specjalnym jest Bionic. Duża część kodu pochodzi z BSD, więc jeśli zmiana nie dotyczy kodu, który jest nowy dla Bionic, proszę dokonać wcześniejszej poprawki, a następnie pobrać zupełnie nowy plik z odpowiedniego BSD.

Jądro Androida

Wprowadź wszystkie zmiany powyżej. Aby uzyskać ogólne wskazówki, postępuj zgodnie z wytycznymi dotyczącymi wkładu jądra systemu Android i stroną opracowywania kodu jądra dla GKI .

OIOM

Wprowadź wszystkie zmiany w projekcie ICU w external/icu (foldery icu4c/ i icu4j/ ) na stronie głównej ICU-TC . Aby uzyskać więcej informacji, zobacz Przesyłanie błędów ICU i próśb o nowe funkcje . Dodaj etykietę „Android” do wszystkich nadrzędnych żądań Jira.

CLDR

Większość danych językowych w ICU pochodzi z projektu Unicode CLDR . Prześlij wszystkie żądania w górę zgodnie z częścią „Wkład w CLDR ” i dodaj etykietę „Android”.

LLVM/Clang/Compiler-rt

Wprowadź wszystkie zmiany w projektach związanych z LLVM ( external/clang , external/compiler-rt , external/llvm ) na stronie infrastruktury kompilatora LLVM .

mksz

Wprowadź wszystkie zmiany w projekcie MirBSD Korn Shell na external/mksh , wysyłając wiadomość e-mail na adres miros-mksh w domenie mirbsd.org (do przesłania nie jest wymagana subskrypcja) lub na Launchpad .

OtwórzSSL

Wprowadź wszystkie zmiany w projekcie OpenSSL w pliku external/openssl na stronie OpenSSL .

V8

Prześlij wszystkie zmiany do projektu V8 na external/v8 na stronie wydania V8 . Aby uzyskać szczegółowe informacje, zobacz Wkład w V8 .

WebKita

Wprowadź wszystkie zmiany w projekcie WebKit w lokalizacji external/webkit na stronie WebKit . Rozpocznij proces od zgłoszenia błędu WebKit . W przypadku błędu użyj Android w polach Platforma i System operacyjny tylko wtedy, gdy błąd jest specyficzny dla Androida. Błędy są znacznie bardziej prawdopodobne, że zwrócą uwagę recenzentów po dodaniu proponowanej poprawki i uwzględnieniu testów. Aby uzyskać szczegółowe informacje, zobacz Współtworzenie kodu do WebKit .

zlib

Wprowadź wszystkie zmiany w projekcie zlib w katalogu external/zlib na stronie głównej zlib .