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 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-trunk_staging-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 scalasz 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ższego polecenia, 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 .