Przesyłanie poprawek

Ta strona opisuje pełny proces przesyłania poprawki do Android Open Source Project (AOSP), w tym jak poprosić o sprawdzenie i śledzić zmiany za pomocą Gerrita .

Wymagania wstępne

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

Zasoby

  • Aby uzyskać szczegółowe informacje na temat repozytorium i usługi Git, zobacz stronę Narzędzia kontroli źródła .
  • Aby uzyskać informacje o różnych rolach w społeczności Android Open Source, zobacz stronę Role w projekcie .
  • Aby uzyskać informacje na temat licencjonowania dotyczącego udostępniania kodu na platformę Android, zobacz stronę Licencje .

Dla współtwórców

Uwierzytelnianie z serwerem

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

Uruchomienie oddziału Repo

Dla każdej zmiany, którą zamierzasz wprowadzić, uruchom 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.

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

Zmień opisy

  • Linia 1: Nagłówek

    Podaj jednowierszowe 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 dotyczącej zatwierdzenia. Rozważ użycie przedrostków do opisania zmienionego obszaru, a następnie opisu zmiany wprowadzonej w tym zatwierdzeniu, takiej jak ta, która ma przedrostek ui :

    ui: Removes deprecated widget

  • Linia 2: pusta

    Pozostaw tę linię pustą, zawsze.

  • Linia 3: Ciało

    Napisz dłuższy opis, zaczynając od tego wiersza.

    To musi mieć maksymalnie 72 znaki. Opisz, jaki problem rozwiązuje zmiana i w jaki sposób. Chociaż jest to opcjonalne podczas wdrażania nowych funkcji, jest to bardzo pomocne dla innych później, jeśli odwołują się do tej zmiany, szczególnie w przypadku debugowania.

    Dołącz krótką notatkę o wszelkich założeniach lub ogólnych informacjach, które mogą być ważne, gdy inny współpracownik 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ładowa wiadomość 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.

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.

    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

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

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

Rozwiązywanie konfliktów synchronizacji

Jeśli inne łatki są przesłane do drzewa źródłowego, które kolidują z twoim, zmień bazę łatki na nowy 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 zmienić bazę HEAD na nową zdalną HEAD .

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

repo rebase

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

git rebase --continue

Po zakończeniu automatycznej lub ręcznej rebase uruchom repo upload , aby przesłać poprawkę rebase.

Po zatwierdzeniu zgłoszenia

Po tym, jak zgłoszenie przejdzie przez proces recenzji 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 upstream

Android korzysta z wielu innych projektów open source, takich jak jądro Linuksa i WebKit, jak opisano w Android Software Management . W przypadku większości projektów, które znajdują się w katalogu external/ , wprowadź zmiany w górę, a następnie poinformuj opiekunów Androida o nowej wersji, która zawiera twoje zmiany.

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

Ciekawym przypadkiem specjalnym jest Bionic. Znaczna część kodu pochodzi z BSD, więc jeśli zmiana nie dotyczy kodu, który jest nowy w Bionic, proszę wprowadzić poprawkę, a następnie pobrać cały nowy plik z odpowiedniego BSD.

Jądro Androida

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

OIOM

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

CLDR

Większość danych lingwistycznych w ICU pochodzi z projektu Unicode CLDR . Prześlij wszystkie prośby na 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 Infrastruktura kompilatora LLVM .

mksz

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

OpenSSL

Wprowadź wszystkie zmiany w projekcie OpenSSL pod 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 Przyczynianie się do V8 .

WebKit

Wprowadź wszystkie zmiany w projekcie WebKit pod external/webkit na stronie WebKit . Rozpocznij proces, zgłaszając błąd WebKit . W błędzie użyj Android dla pól Platforma i OS tylko wtedy, gdy błąd jest specyficzny dla Androida. Błędy znacznie częściej zwracają uwagę recenzentów po dodaniu proponowanej poprawki i dołączeniu testów. Zobacz Przekazywanie kodu do WebKit, aby uzyskać szczegółowe informacje.

zlib

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