Przesyłanie poprawek

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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 .

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 uwzględniona ani w Gerrit, ani w ostatecznym drzewie źródłowym.

Dokonywanie zmiany

Zmodyfikuj pliki źródłowe i zatwierdź 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 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.
Aby przeczytać blog o dobrych opisach zatwierdzeń (z przykładami), zobacz How to Write a Git Commit Message autorstwa Chrisa Beamsa.

Przesyłanie do Gerrita

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

repo upload

Jeśli uruchomiłeś wiele oddziałów w tym samym repozytorium, zostaniesz poproszony o wybranie, które z nich chcesz przesłać.

Po pomyślnym przesłaniu Repo udostępnia adres URL nowej strony na Gerrit . Kliknij link, który udostępnia Repo, aby wyświetlić poprawkę na serwerze recenzji, dodać komentarze lub poprosić o konkretnych recenzentów Twojej łatki.

Prośba o recenzję

Po przesłaniu zmian do Gerrit poprawka musi zostać sprawdzona 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 SUGGEST OWNERS w interfejsie użytkownika Gerrit, aby zobaczyć listę właścicieli kodu dla plików w Twojej łatce.

    zasugeruj właścicielom link w Gerrit
    Rysunek 1. Link Sugeruj właścicieli w Gerrit

  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.

  • (ikona znacznika wyboru): Zatwierdzone przez właściciela kodu
  • (ikona krzyżyka): niezatwierdzone przez właściciela kodu
  • (ikona zegara): oczekuje na zatwierdzenie przez właściciela kodu
Rysunek 2. Przykład plików z ikonami pokazującymi status zatwierdzenia właściciela kodu

Przesyłanie zastępczej poprawki

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

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

CLDR

Większość danych lingwistycznych w ICU pochodzi z projektu Unicode CLDR . Prześlij wszystkie prośby wcześniej, korzystając z żądań zmiany 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

Dokonaj wszystkich zmian w projekcie MirBSD Korn Shell na external/mksh , wysyłając wiadomość e-mail do miros-mksh w domenie mirbsd.org (nie jest wymagana subskrypcja 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 .