Przesyłanie łatek

Na tej stronie opisano pełny proces przesyłania poprawki do projektu Android Open Source Project (AOSP), w tym sposób zgłaszania prośby o sprawdzenie i śledzenia zmian za pomocą Gerrit .

Warunki wstępne

Na początek upewnij się, że wykonałeś następujące czynności:

• Zainicjuj swoje środowisko kompilacji
• Pobrano źródło
• Utworzono hasło za pomocą generatora haseł.

Zasoby

• Aby uzyskać szczegółowe informacje na temat Repo i 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 projektu .
• Aby uzyskać informacje licencyjne dotyczące wnoszenia kodu na platformę Android, zobacz stronę Licencje .

Dla współtwórców

Uwierzytelnianie z serwerem

Jeśli udostępnisz 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 czasie. Dostęp uwierzytelniony wykorzystuje osobny przydział dla każdego użytkownika, niezależnie od adresu IP. Aby przeczytać o aktywowaniu dostępu uwierzytelnionego, zobacz Korzystanie z uwierzytelniania .

Rozpoczęcie oddziału Repo

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

repo start NAME .

Możesz uruchomić kilka niezależnych oddziałów jednocześnie w tym samym repozytorium. Gałąź NAME jest lokalna w Twoim obszarze roboczym i nie jest zawarta ani w Gerrit, ani w końcowym drzewie źródłowym.

Dokonywanie zmian

Zmodyfikuj pliki źródłowe i zweryfikuj swoje zmiany.

Zatwierdź zmiany w lokalnym repozytorium za pomocą tych poleceń:

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 dla różnych wyświetlaczy. Jest to najważniejsza, najgęstsza część Twojego komunikatu o zatwierdzeniu. Rozważ użycie prefiksów do opisania zmienionego obszaru, a następnie opisu zmiany, którą wprowadziłeś w tym zatwierdzeniu, na przykład tej, która ma ui jako prefiks:

  ui: Removes deprecated widget

• Linia 2: Pusta

  Zawsze pozostaw tę linię pustą.

• Linia 3: Ciało

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

  Musi to trwać maksymalnie 72 znaki. Opisz, jaki problem rozwiązuje zmiana i jak. 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 podstawowych informacjach, które mogą być ważne, gdy inny współtwórca 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 Twojej wiadomości o zatwierdzeniu.

Oto przykładowy komunikat dotyczący 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.

Aby przeczytać blog o dobrych opisach zmian (z przykładami), zobacz How to Write a Git Commit Message autorstwa Chrisa Beamsa.

Przesyłanie do Gerrit

Po zatwierdzeniu zmiany w swojej osobistej historii prześlij ją do Gerrit za pomocą tego polecenia:

repo upload

Jeśli uruchomiłeś wiele gałęzi w tym samym repozytorium, zostaniesz poproszony o wybranie tych do przesłania.

Po pomyślnym przesłaniu Repo udostępnia adres URL nowej strony w Gerrit . Kliknij łącze, które udostępnia Repo, aby wyświetlić swoją poprawkę na serwerze recenzji, dodać komentarze lub poprosić określonych recenzentów o poprawkę.

Prośba o recenzję

Po przesłaniu zmian do Gerrit poprawka musi zostać przejrzana i zatwierdzona przez odpowiednich właścicieli kodu. Znajdź właścicieli kodu w plikach OWNERS .

Aby znaleźć odpowiednich właścicieli kodu i dodać ich jako recenzentów zmiany, wykonaj następujące kroki.

1. Wybierz link ZASUGERUJ WŁAŚCICIELI w interfejsie Gerrit, aby zobaczyć listę właścicieli kodu dla plików w twojej łatce.

   

2. Dodaj właścicieli kodu z listy jako recenzentów swojej poprawki.

Aby określić stan plików w łatce, sprawdź następujące ikony obok plików w łatce.

• done (ikona zaznaczenia): Zatwierdzone przez właściciela kodu
• clear (ikona z krzyżykiem): niezatwierdzone przez właściciela kodu
• access_time (ikona zegara): Oczekuje na zatwierdzenie przez właściciela kodu

Przesyłanie poprawki zastępczej

Załóżmy, że recenzent spojrzał na twoją łatkę i poprosił o małą modyfikację. Możesz zmienić swoje zatwierdzenie w Git, co skutkuje powstaniem nowej łatki na Gerrit, która ma taki sam identyfikator zmiany jak oryginał.

git add -A
git commit --amend

Kiedy prześlesz poprawioną łatkę, zastąpi ona oryginał zarówno na Gerrit, jak i w Twojej lokalnej historii Git.

Rozwiązywanie konfliktów synchronizacji

Jeśli do drzewa źródłowego zostaną przesłane inne łaty, które są w konflikcie z twoim, zmień bazę łat 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 nowy zdalny 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 zmiany bazy uruchom repo upload , aby przesłać poprawkę ze zmienioną bazą.

Po zatwierdzeniu zgłoszenia

Po przejściu zgłoszenia 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 klientów lokalnych.

Dla projektów upstream

Android korzysta z wielu innych projektów open source, takich jak jądro Linux i WebKit, zgodnie z opisem w Android Software Management . W przypadku większości projektów, które znajdują się w external/ , wprowadź zmiany na zewnątrz, a następnie poinformuj opiekunów systemu Android o nowej wersji nadrzędnej zawierającej zmiany.

Możesz także przesłać łatki, które powodują śledzenie nowej wersji nadrzędnej. Pamiętaj, że mogą to być trudne zmiany, jeśli projekt jest powszechnie używany w systemie Android, tak jak większość większych wymienionych poniżej, które są zwykle aktualizowane przy każdym wydaniu.

Ciekawym przypadkiem specjalnym jest Bionic. Większość kodu pochodzi z BSD, więc o ile zmiana nie dotyczy kodu, który jest nowy w Bionic, prosimy o wprowadzenie poprawki, a następnie ściągnięcie całego nowego pliku z odpowiedniego BSD.

Jądro Androida

Wolę dokonywać wszystkich zmian wcześniej. Aby uzyskać ogólne wskazówki, postępuj zgodnie z wytycznymi dotyczącymi wkładu jądra systemu Android .

OIOM

Wprowadź wszystkie zmiany w projekcie ICU w external/icu ( icu4c/ i icu4j/ ) na stronie głównej ICU-TC . Zobacz Zgłaszanie błędów ICU i prośby o nowe funkcje, aby uzyskać więcej informacji.

CLDR

Większość danych językowych w ICU pochodzi z projektu Unicode CLDR . Prześlij wszystkie prośby w górę, korzystając z prośby o zmianę 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

Dokonaj wszystkich zmian w projekcie MirBSD Korn Shell w external/mksh albo wysyłając e-mail do miros-mksh w domenie mirbsd.org (do przesłania tam nie jest wymagana subskrypcja) lub na Launchpad .

OpenSSL

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

V8

Prześlij wszystkie zmiany w projekcie V8 na stronie external/v8 na stronie wydania V8 . Zobacz Wkład w V8, aby uzyskać szczegółowe informacje.

WebKit

Wprowadź wszystkie zmiany w projekcie WebKit w external/webkit na stronie WebKit . Rozpocznij proces, zgłaszając błąd WebKit . W przypadku błędu użyj Android w polach Platforma i OS tylko wtedy, gdy błąd dotyczy tylko Androida. Błędy znacznie częściej zwracają uwagę recenzentów po dodaniu proponowanej poprawki i włączeniu testów. Aby uzyskać szczegółowe informacje, zobacz Współtworzenie kodu do oprogramowania WebKit .

zlib

Dokonaj wszystkich zmian w projekcie zlib w external/zlib na stronie głównej zlib .