Laboratorium programisty Androida

Możesz pomóc w opracowaniu najszerzej instalowanego systemu operacyjnego w historii Ziemi. Tak, jesteś tutaj, aby rozpocząć karierę inżyniera platformy Android.

Chociaż ścieżka jest trudna, zespół Androida stara się upraszczać Twoją podróż w każdym wydaniu. Zespół codziennie wprowadza ulepszenia dzięki bezpośredniej pracy w projekcie Android Open Source Project (AOSP).

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

Cele

Misja tego laboratorium kodowania jest dwojaka:

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

Warunki wstępne

Lista wymagań dla tego ćwiczenia z kodowania pochodzi z wymagań dotyczących programowania platformy ogólnej ( AOSP ). Aby wziąć udział w tych ćwiczeniach z kodowania, skonfiguruj następujące elementy:

Środowisko

Zazwyczaj użytkownicy tworzą i rozwijają oprogramowanie bezpośrednio na stacji roboczej. Ponieważ możesz pracować na różnych terminalach i 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 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 działający podkatalog:

    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. Zsynchronizuj kod źródłowy:

    repo sync -j8

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

Każde pobranie repo jest reprezentowane przez plik manifestu . Dopuszczalne jest posiadanie więcej niż 1 transakcji repo na raz, o ile istnieją one w różnych katalogach. Należy jednak pamiętać, że każde pobranie i kompilacja zużywają w przybliżeniu 300 GB (i rośnie), więc albo ogranicz się do 2 pobrań repo, albo rozszerz swój system o dodatkowy dysk.

Zbuduj kod

Aby zbudować system Android, musisz wybrać typ urządzenia docelowego do zbudowania za pomocą polecenia lunch . Element docelowy to permutacja urządzenia, na przykład określony model lub obudowa.

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

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 tworzenia urządzeń z systemem Android, uruchamiając następujące polecenie w katalogu głównym pobierania 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. Utwórz kod z dowolnego miejsca w kasie, korzystając z:

    m

Spodziewaj się, że pierwsza kompilacja zajmie wiele 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 mątwy.

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

  1. Zainstaluj zależności umożliwiające lokalne uruchomienie urządzenia wirtualnego Mątwy za pomocą:

    acloud setup

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

  3. Utwórz instancję lokalną acloud za pomocą:

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

  4. Wybierz urządzenie mątwy.

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, 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 katalogu głównego kasy (katalog aosp/ ) przejdź do frameworks/native projektu Git:

    cd frameworks/native

  2. Rozpocznij projekt tymczasowy 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ącą:

    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 zostanie wyświetlony monit o wybranie urządzenia, wybierz to, które pokazuje najkrótszy czas, który upłynął. (To prawdopodobnie ostatnia pozycja na liście, którą widzisz.) Aby zobaczyć wszystkie instancje urządzeń wirtualnych, użyj poleceń acloud list i acloud list -v .

Sprawdź, czy na wybranym urządzeniu widzisz zmianę koloru podobną do pokazanej na rysunku 1.

Example of a successful color change

Rysunek 1. Wygląd ekranu po udanej zmianie koloru

Przetestuj swój kod

W tej części ćwiczeń z programowania wykorzystano przykładowy test znajdujący się w drzewie źródłowym, który zakończył się niepowodzeniem. Wykorzystuje to Atest do lokalnego uruchamiania testu i testowania kodu.

Aby skorzystać z testu, postępuj zgodnie z poniższą instrukcją:

  1. Uruchomić:

    atest DevCodelabTest

  2. Test zakończy się niepowodzeniem. 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 uzyskać plik do edycji, weź nazwę testu w android.test.example.devcodelab.DevCodelabTest i zamień . 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 rozwiązałeś problem:

    atest DevCodelabTest

Prześlij swój kod do sprawdzenia

Repo upraszcza korzystanie z Git poprzez łączenie poleceń, takich 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ądem Git i Repo wraz z łączami 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 projektów w Git będziesz używać 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 o zatwierdzeniu wpisz:

    Android codelab change
Test: manual atest

  3. Prześlij swoją zmianę:

    repo upload

Jeśli 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, podobnego do tego:

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

To kończy początkowe ćwiczenia z programowania dotyczące programowania platformy Android. Dalsze kroki opisano w sekcji Przesyłanie poprawek , a szczegółowe informacje na temat tworzenia systemu Android można znaleźć w dalszej części tej witryny.

Cofnij zmianę

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

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

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

repo abandon codelab .

Pamiętaj także o przywróceniu zmian dokonanych w pliku testowym. Ponieważ nie wykonałeś repo start , git commit i repo upload zmiany, możesz zresetować sam plik. Zakładając, że jesteś w aosp/platform_testing directory , użyj poniższej komendy, aby zresetować plik:

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

W tym momencie gotowe! Dobra robota!

Sprowadź pomoc

Jeśli podczas zajęć z programowania napotkasz błędy, zgłoś je, korzystając z łącza do śledzenia problemów na dole dowolnej strony. Wyślij pytania do grupy zajmującej się budowaniem Androida .