Laboratorium kodu programisty Androida

Możesz pomóc w opracowaniu najczęściej instalowanego systemu operacyjnego w historii Ziemi. Tak, jesteś tutaj, aby rozpocząć przygodę z inżynierem platformy Android.

Chociaż ścieżka jest trudna, zespół Androida stara się uprościć Twoją podróż w każdej wersji. Zespół każdego dnia wprowadza ulepszenia poprzez bezpośrednią pracę w projekcie Android Open Source Project (AOSP).

Więc usiądź wygodnie, uruchom terminal i stwórzmy historię.

Cele

Misja tego laboratorium kodów jest dwojaka:

1. Aby dać ci mały przedsmak tego, jak wygląda przepływ pracy programisty dla inżynierów Androida pracujących nad platformą (systemem operacyjnym).
2. Zachęcamy do wyrażania opinii na temat narzędzi Androida, dokumentacji i przepływu pracy dla programistów.

Wymagania wstępne

Lista wymagań dla tego laboratorium kodów pochodzi od tych dla rozwoju platformy ogólnej ( AOSP ). Aby wziąć udział w tym laboratorium kodowania, skonfiguruj następujące elementy:

• Fizyczna stacja robocza z systemem Linux spełniająca wszystkie wymagania publiczne .
• Repo i konfiguracja Git wymagana do edycji bazy kodu Androida.

Środowisko

Zazwyczaj użytkownicy budują i rozwijają bezpośrednio na stacji roboczej. Ponieważ możesz pracować w różnych terminalach, a wiele używanych poleceń jest specyficznych dla terminala, będziesz musiał je ponownie uruchamiać w każdej sesji terminala. W szczególności obejmują one polecenia source build/envsetup.sh i lunch .

Skonfiguruj stację roboczą

1. Zainstaluj niezbędne pakiety na swojej stacji roboczej.
2. Będąc nadal w terminalu, zainstaluj Repo i uzyskaj poświadczenia do wszystkich repozytoriów Git.

Zainicjuj i zsynchronizuj kod

1. Przejdź do swojego katalogu domowego:

   cd ~
   

2. Utwórz w nim lokalny podkatalog roboczy:

   mkdir aosp
   

3. Przejdź do katalogu:

   cd aosp
   

4. Zainicjuj główną gałąź kodu źródłowego repozytorium AOSP (domyślnie):

   repo init -u https://android.googlesource.com/platform/manifest
   

5. Wprowadź lub zaakceptuj swoje dane uwierzytelniające Git (imię i nazwisko, adres e-mail).

6. Synchronizuj kod źródłowy:

   repo sync -j8
   

Początkowa synchronizacja może potrwać godzinę lub dłużej.

Każde wyewidencjonowanie repozytorium jest reprezentowane przez plik manifestu . Dopuszczalne jest posiadanie więcej niż 1 kasy repo na raz, o ile istnieją one w różnych katalogach. Pamiętaj jednak, że każda kasa i kompilacja to około 300 GB wykorzystania (i rośnie), więc albo ogranicz się do 2 transakcji repo, albo powiększ swój system o dodatkowy dysk.

Zbuduj kod

Aby zbudować Androida, musisz wybrać typ urządzenia docelowego do zbudowania za pomocą polecenia lunch . Cel to permutacja urządzenia, taka jak określony model lub współczynnik kształtu.

Podane poniżej urządzenie docelowe, aosp_cf_x86_64_phone-userdebug , umożliwia zbudowanie wirtualnego urządzenia z systemem Android mątwy do testowania bez fizycznego urządzenia.

Aby zamiast tego zbudować i zaktualizować urządzenie fizyczne, wybierz inny cel i postępuj zgodnie z instrukcjami dotyczącymi flashowania urządzeń .

1. Skonfiguruj swoje środowisko do budowania urządzeń z systemem Android, uruchamiając następujące polecenie z katalogu głównego pobierania kodu źródłowego:

   source build/envsetup.sh
   

2. Przekaż cel kompilacji do komendy lunch, w ten sposób:

   lunch aosp_cf_x86_64_phone-userdebug
   

3. Zbuduj kod z dowolnego miejsca w kasie za pomocą:

   m
   

Spodziewaj się, że pierwsza kompilacja zajmie wiele godzin. Kolejne kompilacje zajmują znacznie mniej czasu.

Utwórz instancję Cloud

Acloud to narzędzie wiersza poleceń w AOSP, które pomaga użytkownikom w tworzeniu wirtualnych urządzeń z Androidem, w tym przypadku mątwy.

Jeśli jesteś w tej samej sesji terminala, która została użyta do zbudowania kodu , kontynuuj. W przeciwnym razie ponownie uruchom skrypt envsetup.sh i to samo polecenie lunch , którego użyłeś tam jako pierwszy. Następnie

1. Utwórz lokalną instancję Cloud za pomocą:

   acloud create --local-image --local-instance
   

2. Zaakceptuj aktualizacje wymaganych pakietów.

3. Jeśli pojawi się monit, uruchom ponownie stację roboczą, aby wszystkie zmiany zaczęły obowiązywać.

4. Wybierz urządzenie mątwy.

Powinieneś zostać powitany sesją VNC zawierającą urządzenie z Androidem!

Możesz wchodzić w interakcje z urządzeniem wirtualnym na swojej stacji roboczej za pomocą myszy i klawiatury. Możesz także śledzić aktywność w dziennikach podczas korzystania z urządzenia, korzystając z polecenia logcat Android Debug Bridge (adb):

adb logcat

Dokonaj zmiany

Zaktualizuj kod źródłowy zgodnie z tą przykładową listą zmian .

1. Z głównego katalogu kasy (katalog aosp/ ) przejdź do projektu frameworks/native Git:

   cd frameworks/native
   

2. Rozpocznij tymczasowy projekt za pomocą tego polecenia:

   repo start <some-name> .
   

3. Edytuj SurfaceFlinger.cpp , aby uwzględnić aktualizacje z listy zmian w następującej lokalizacji:

   aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
   

4. Znajdź tę linię:

   postComposition();
   

5. Zamień te dwie linie na następujące:

   postComposition();
   mClientColorMatrix = mat4(vec4{1.0f, 0.0f, 0.0f, 0.0f}, vec4{0.0f, -1.0f, 0.0f, 0.0f},
                             vec4{0.0f, 0.0f, -1.0f, 0.0f}, vec4{0.0f, 1.0f, 1.0f, 1.0f});
   updateColorMatrixLocked();
   

6. Zbuduj kod:

   m
   

7. Zaktualizuj kompilację na urządzeniu:

   adb root
   adb remount
   adb sync
   adb reboot
   acloud reconnect
   

8. Jeśli pojawi się monit o wybranie urządzenia, wybierz to, które pokazuje najkrótszy czas, jaki upłynął. (Prawdopodobnie jest to ostatnia pozycja na liście, którą widzisz). Aby wyświetlić wszystkie wystąpienia urządzeń wirtualnych, użyj poleceń acloud list i acloud list -v .

Sprawdź, czy na wybranym urządzeniu widać zmianę koloru podobną do tej na rysunku 1.

Rysunek 1. Wygląd ekranu po pomyślnej zmianie koloru

Przetestuj swój kod

Ta część laboratorium kodowania wykorzystuje przykładowy test, który znajduje się w drzewie źródłowym i kończy się niepowodzeniem. Wykorzystuje to Atest do lokalnego uruchamiania testu i testowania kodu.

Aby skorzystać z testu, postępuj zgodnie z poniższymi instrukcjami:

1. Uruchomić:

   atest DevCodelabTest
   

2. Test zakończy się niepowodzeniem. Aby to naprawić, znajdź kod źródłowy testu, który zakończył się niepowodzeniem:

   atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
   

3. Następnie spójrz tutaj

   platform_testing/tests/example/devcodelab
   

4. Aby uzyskać plik do edycji, weź nazwę testu w android.test.example.devcodelab.DevCodelabTest i zastąp plik . z / , aby uzyskać ten wynik:

   src/android/test/example/devcodelab/DevCodelabTest.java
   

5. Następnie edytuj

   platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
   

   zamienić

   Assert.assertTrue(false)
   

   z

   Assert.assertTrue(true)
   

6. Ponownie uruchom test, aby sprawdzić, czy problem został rozwiązany:

   atest DevCodelabTest
   

Prześlij swój kod do sprawdzenia

Repo upraszcza korzystanie z Git, łącząc polecenia, takie jak git clone w celu jednoczesnej pracy w wielu repozytoriach (lub projektach) Git.

Zobacz Narzędzia kontroli źródła , aby zapoznać się z omówieniem Git i Repo, z linkami do pełnej dokumentacji dotyczącej pracy z kodem źródłowym Androida. Zobacz repozytorium AOSP , aby uzyskać pełną listę projektów Git i poszczególnych projektów (ścieżek) dla gałęzi powiązanych z każdym projektem.

Do przeglądu kodu swoich projektów w Git użyjesz internetowego systemu przeglądu kodu Gerrit .

1. Zakładając, że dokonałeś zmian w frameworks/native , uruchom te polecenia, aby je przesłać:

   cd frameworks/native
   repo start codelab .
   git add .
   git commit
   

2. W wiadomości zatwierdzenia wpisz następujące informacje:

   Android codelab change
   Test: manual atest
   

3. Prześlij swoją zmianę:

   repo upload
   

Jeśli ci się powiedzie, zobaczysz komunikat podobny do tego:

Upload project frameworks/native/ to remote branch main:
  branch codelab ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
         ff46b36d android codelab change
to https://android-review.googlesource.com/ (y/N)? y
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote:   https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432 android codelab change [NEW]
remote:
To https://android-review.googlesource.com/platform/frameworks/native
 * [new branch]          codelab -> refs/for/main

Zobacz swoją zmianę w Gerrit

Przejdź do linku wydrukowanego w terminalu, który przypomina ten:

https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432

Na tym kończy się początkowe laboratorium kodowania dla rozwoju platformy Android. Więcej informacji na temat kolejnych kroków można znaleźć w sekcji Przesyłanie poprawek , a szczegółowe informacje na temat tworzenia systemu Android można znaleźć w pozostałej części tej witryny.

Cofnij swoją zmianę

Zwykle po testach oraz po sprawdzeniu i zatwierdzeniu przesyłasz swoją zmianę w Gerrit i włączasz ją do repozytorium.

Zamiast tego, na potrzeby tego laboratorium kodu, przywróć swoją listę zmian, klikając Porzuć w Gerrit.

Następnie porzuć powiązaną tymczasową gałąź w katalogu frameworks/native project (lub jego podkatalogach):

repo abandon codelab .

Pamiętaj również o cofnięciu zmian wprowadzonych w pliku testowym. Ponieważ nie zrobiłeś repo start , git commit i repo upload zmianę, możesz zresetować sam plik. Zakładając, że jesteś w aosp/platform_testing directory , użyj następujących opcji, aby zresetować plik:

git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .

W tym momencie skończyłeś! Dobra robota!

Sprowadź pomoc

Jeśli podczas tego laboratorium kodowego napotkasz błędy, zgłoś je, korzystając z łącza do śledzenia problemów na dole dowolnej strony. Wyślij pytania do grupy Android-building .