Laboratorium programowania dla programistów Androida

Możesz pomóc w opracowaniu najpowszechniej instalowanego systemu operacyjnego w historii Ziemi. Tak, jesteś tutaj, aby rozpocząć podróż i zostać inżynierem platformy Android.

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

Usiądź wygodnie, odpal terminal i stwórzmy historię.

Cele

Misja tego laboratorium jest dwojaka:

1. Aby dać ci mały przedsmak tego, jak wygląda przepływ pracy dewelopera dla inżynierów Androida pracujących na platformie (systemie operacyjnym).
2. Zachęć do przekazywania opinii na temat narzędzi, dokumentacji i przepływu pracy programistów Androida.

Warunki wstępne

Lista wymagań dla tego ćwiczenia z programowania jest wyprowadzona z wymagań dotyczących rozwoju platformy ogólnej ( AOSP ). Aby wziąć udział w tym ćwiczeniu z programowania, 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ą się 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 uruchomić w każdej sesji terminala. W szczególności są to polecenia source build/envsetup.sh i lunch .

Skonfiguruj stację roboczą

1. Zainstaluj niezbędne pakiety na swojej stacji roboczej.
2. Pozostając w terminalu, zainstaluj Repo i uzyskaj dane uwierzytelniające 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 gałąź główną kodu źródłowego repozytorium AOSP (domyślnie):

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

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

6. Zsynchronizuj kod źródłowy:

   repo sync -j8
   

Początkowe synchronizacje mogą potrwać godzinę lub dłużej.

Każde wyewidencjonowanie repo jest reprezentowane przez plik manifestu . Dozwolone jest posiadanie więcej niż 1 kasy repo na raz, o ile istnieją one w odrębnych katalogach. Pamiętaj jednak, że każde wyewidencjonowanie i kompilacja zużywa około 300 GB (i rośnie), więc albo ogranicz się do 2 kas repo, albo rozszerz swój system o dodatkowy dysk.

Zbuduj kod

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

Zawarte poniżej urządzenie docelowe, aosp_cf_x86_64_phone-userdebug , umożliwia zbudowanie wirtualnego urządzenia Cuttlefish z systemem Android 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 urządzeń flashujących .

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

   source build/envsetup.sh
   

2. Przekaż cel kompilacji do polecenia lunch w następujący 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 kilka godzin. Kolejne kompilacje zajmują znacznie mniej czasu.

Utwórz instancję Acloud

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

Jeśli jesteś w tej samej sesji terminala, w której skompilowano kod , kontynuuj. W przeciwnym razie uruchom ponownie skrypt envsetup.sh i to samo polecenie lunch , którego użyłeś jako pierwszy. Następnie

1. Utwórz lokalną instancję Acloud 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 odniosły skutek.

4. Wybierz urządzenie Mątwa.

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

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

adb logcat

Zmienić coś

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

1. Z katalogu głównego kasy (katalog aosp/ ) przejdź do frameworks/native projektu 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ź te dwie linie:

   postFrame();
   postComposition();
   

5. Zastąp te dwie linie następującymi:

   postFrame();
   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ął. (Jest to prawdopodobnie ostatnia na liście, którą widzisz.) Aby zobaczyć wszystkie instancje urządzeń wirtualnych, użyj acloud list i acloud list -v .

Sprawdź, czy widzisz zmianę koloru na wybranym urządzeniu, podobnie jak na rysunku 1.

Rysunek 1. Wygląd ekranu po udanej zmianie koloru

Przetestuj swój kod

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

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

1. Biegać:

   atest DevCodelabTest
   

2. Test się nie powiedzie. Aby to naprawić, znajdź kod źródłowy nieudanego testu:

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

3. Więc spójrz tutaj

   platform_testing/tests/example/devcodelab
   

4. Aby pobrać plik do edycji, weź nazwę testu w android.test.example.devcodelab.DevCodelabTest i zastąp . 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. Uruchom test ponownie, 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 Git (lub projektach).

Zobacz Narzędzia kontroli źródła , aby zapoznać się z przeglądami Git i Repo, z łączami do pełnej dokumentacji dotyczącej pracy z kodem źródłowym systemu Android. Zobacz repozytorium AOSP , aby zapoznać się z 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 projektów w Git użyjesz internetowego systemu przeglądu kodu Gerrit .

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

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

2. W wiadomości o zatwierdzeniu wprowadź następujące informacje:

   Android codelab change
   Test: manual atest
   

3. Prześlij swoją zmianę:

   repo upload
   

Jeśli Ci się uda, zobaczysz komunikat podobny do tego:

Upload project frameworks/native/ to remote branch master:
  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/master

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. Zobacz Przesyłanie łatek , aby zapoznać się z kolejnymi krokami, a pełne informacje na temat tworzenia systemu Android można znaleźć w pozostałej części tej witryny.

Cofnij zmianę

Zwykle, po testowaniu, po przeglądzie i zatwierdzeniu, przesyłasz swoją zmianę w Gerrit i łączysz ją z repozytorium.

Zamiast tego, na potrzeby tego ćwiczenia z programowania, przywróć listę zmian, klikając opcję Porzuć w Gerrit.

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

repo abandon codelab .

Pamiętaj również o cofnięciu zmian dokonanych w pliku testowym. Ponieważ nie repo start , git commit i repo upload zmiany, możesz zresetować sam plik. Zakładając, że znajdujesz się w katalogu aosp/platform_testing directory , wykonaj następujące czynności, aby zresetować plik:

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

W tym momencie gotowe! Dobra robota!

Wezwać pomoc

Jeśli podczas tego ćwiczenia z programowania napotkasz błędy, zgłoś je, korzystając z linku do śledzenia problemów na dole dowolnej strony. Wysyłaj pytania do grupy budującej androidy .