Ćwiczenie z programowania dla programistów aplikacji na Androida

Możesz pomóc stworzyć najpopularniejszy system operacyjny w historii Earth. Tak, możesz stać się inżynierem platformy Androida.

Choć jest to trudne, zespół Androida stara się uprościć każdą wersję aplikacji. Nasz zespół codziennie wprowadza ulepszenia dzięki bezpośredniej pracy w projekcie Android Open Source Project (AOSP).

Usiądź wygodnie, uruchom terminal i zacznij tworzyć historię.

Cele

Cele tego ćwiczenia z programowania są 2 elementy:

  1. Aby dać Wam przedsmak tego, jak wygląda przepływ pracy w programie dla inżynierów Androida pracujących nad platformą (systemem operacyjnym).
  2. Zachęcamy do dzielenia się opiniami na temat narzędzi Androida, dokumentacji i procesu programowania.

Wymagania wstępne

Lista wymagań tego ćwiczenia z programowania pochodzi od wymagań dotyczących ogólnego programowania platform (AOSP). Aby wykonać to ćwiczenie w Codelabs, skonfiguruj te elementy:

Środowisko

Zwykle użytkownicy tworzą i programują bezpośrednio na stacji roboczej. Ponieważ możesz używać różnych terminali, a wiele z poleceń jest związanych z konkretnymi terminalami, musisz je ponownie uruchamiać w każdej sesji terminala. Chodzi konkretnie o polecenia source build/envsetup.sh i lunch.

Skonfiguruj stację roboczą

  1. Zainstaluj niezbędne pakiety na stacji roboczej.
  2. Nie wychodząc z terminala, zainstaluj Repo i uzyskaj dane logowania do wszystkich repozytoriów Git.

Inicjowanie i synchronizowanie kodu

  1. Przejdź do katalogu głównego:

    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. Wpisz lub zaakceptuj swoje dane logowania Git (nazwę, adres e-mail).

  6. Zsynchronizuj kod źródłowy:

    repo sync -j8
    

Wstępna synchronizacja może potrwać godzinę lub dłużej.

Każda transakcja w repozytorium jest reprezentowana przez plik manifestu. Dozwolone jest używanie więcej niż 1 repozytorium jednocześnie, o ile znajdują się one w różnych katalogach. Pamiętaj jednak, że każda transakcja i kompilacja zajmują około 300 GB wykorzystania (i rosną), więc ogranicz się do 2 procesów płatności w repozytorium lub uzupełnij swój system o dysk dodatkowy.

Kompilowanie kodu

Aby utworzyć Androida, musisz wybrać docelowy typ urządzenia za pomocą polecenia lunch. Cel to permutacja urządzenia, np. konkretny model lub format.

Urządzenie docelowe aosp_cf_x86_64_phone-userdebug umożliwia utworzenie wirtualnego urządzenia z Androidem Cuttlefish na potrzeby testowania bez urządzenia fizycznego.

Aby skompilować i zaktualizować urządzenie fizyczne, wybierz inne środowisko docelowe i postępuj zgodnie z instrukcjami dotyczącymi urządzeń Flash.

  1. Skonfiguruj środowisko do tworzenia urządzeń z Androidem, uruchamiając to polecenie w katalogu głównym procesu płatności za pomocą kodu źródłowego:

    source build/envsetup.sh
    
  2. Przekaż cel kompilacji do polecenia lunchowego w ten sposób:

    lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
    
  3. Utwórz kod z dowolnego miejsca na stronie płatności za pomocą:

    m
    

Pierwsza kompilacja może potrwać kilka godzin. Kolejne kompilacje wymagają znacznie mniej czasu.

Wystrzel mątwy

Cuttlefish to emulator Androida używany do testowania kompilacji.

  1. Jeśli mątwy nie masz jeszcze zainstalowanego, musisz zainstalować niezbędne zależności mątwy. W oknie terminala uruchom następujące polecenia, aby pobrać, skompilować i zainstalować zainstalowane pakiety Debiana:

    sudo apt install -y git devscripts equivs config-package-dev debhelper-compat golang curl
    git clone https://github.com/google/android-cuttlefish
    cd android-cuttlefish
    for dir in base frontend; do
    pushd $dir
    # Install build dependencies
    sudo mk-build-deps -i
    dpkg-buildpackage -uc -us
    popd
    done
    sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f
    sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f
    sudo usermod -aG kvm,cvdnetwork,render $USER
    sudo reboot
    

    Ponowne uruchomienie aktywuje instalację dodatkowych modułów jądra i stosuje reguły udev.

  2. Uruchom Cuttlefish:

    launch_cvd --daemon
    
  3. Połącz się z urządzeniem Cuttlefish, otwierając stronę https://localhost:8443 w przeglądarce. Zobaczysz strumień wideo swojego właśnie urządzenia z Androidem.

Wprowadź zmianę

Zaktualizuj kod źródłowy, postępując zgodnie z tą przykładową listą zmian.

  1. Z poziomu głównego procesu płatności (katalog aosp/) przejdź do projektu Git frameworks/native:

    cd frameworks/native
    
  2. Uruchom projekt tymczasowy za pomocą tego polecenia:

    repo start <some-name> .
    
  3. Edytuj pole SurfaceFlinger.cpp, aby uwzględnić aktualizacje z listy zmian w tej lokalizacji:

    aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
    
  4. Znajdź ten wiersz:

    void SurfaceFlinger::updateColorMatrixLocked() {
    
  5. Dodaj te dwa wiersze na początku metody updateColorMatrixLocked():

    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});
    
  6. Skompiluj kod:

    m
    
  7. Zaktualizuj kompilację na urządzeniu:

    adb root
    adb remount
    adb sync
    adb reboot
    

Sprawdź, czy na wybranym urządzeniu zmienił się kolor podobny do tego na ilustracji 1.

Przykład udanej zmiany koloru

Rysunek 1. Wygląd ekranu po pomyślnej zmianie kolorów

Testowanie kodu

W tej części ćwiczenia w Codelabs wykorzystywany jest przykładowy test, który znajduje się w drzewie źródłowym, i kończy się niepowodzeniem. W tym celu wykorzystywane jest narzędzie Atest do lokalnego uruchamiania testu i testowania kodu.

Aby skorzystać z testu, postępuj zgodnie z tymi instrukcjami:

  1. Uruchom:

    atest DevCodelabTest
    
  2. Test się nie powiedzie. Aby rozwiązać ten problem, znajdź kod źródłowy nieudanego testu:

    atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
    
  3. Następnie spójrz tutaj

    platform_testing/tests/example/devcodelab
    
  4. Aby uzyskać ten wynik, użyj nazwy testu w pliku android.test.example.devcodelab.DevCodelabTest i zastąp . ciągiem /:

    src/android/test/example/devcodelab/DevCodelabTest.java
    
  5. Następnie edytuj

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

    aby zastąpić

    Assert.assertTrue(false)
    

    z

    Assert.assertTrue(true)
    
  6. Uruchom test jeszcze raz, aby sprawdzić, czy problem został rozwiązany:

    atest DevCodelabTest
    

Przesyłanie kodu do sprawdzenia

Repo upraszcza korzystanie z Git przez połączenie poleceń, takich jak git clone, w celu pracy w wielu repozytoriach Git (lub projektach) jednocześnie.

Omówienie usług Git i Repo znajdziesz w sekcji Source Control Tools (Narzędzia kontroli źródeł) wraz z linkami do pełnej dokumentacji pracy z kodem źródłowym Androida. Pełną listę projektów Git oraz poszczególnych projektów (ścieżek) gałęzi powiązanych z każdym projektem znajdziesz w repozytorium AOSP.

Do weryfikacji kodu projektów w Git będziesz używać internetowego systemu weryfikacji kodu Gerrit.

  1. Zakładając, że zmiany zostały wprowadzone w projekcie frameworks/native, uruchom te polecenia, aby je przesłać:

    cd frameworks/native
    repo start codelab .
    git add .
    git commit
    
  2. W komunikacie zatwierdzenia wpisz:

    Android codelab change
    Test: manual atest
    
  3. Prześlij zmianę:

    repo upload
    

W takim przypadku 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

Wyświetlanie zmiany w Gerrit

Kliknij link podobny do tego:

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

To już koniec podstawowego ćwiczenia w programowaniu dotyczącego programowania platformy Androida. Informacje o kolejnych krokach znajdziesz w artykule Przesyłanie poprawek. Szczegółowe informacje na temat programowania na Androida znajdziesz w pozostałej części tej strony.

Cofnij zmianę

Zwykle po przeprowadzeniu testów, a potem po sprawdzeniu i zatwierdzeniu zmiany przesyła się ją do Gerrit i scala z repozytorium.

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

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

repo abandon codelab .

Pamiętaj też, by cofnąć zmiany wprowadzone w pliku testowym. Zmiany nie zostały wprowadzone przez repo start, git commit i repo upload, więc możesz zresetować sam plik. Jeśli jesteś w domenie aosp/platform_testing directory, wykonaj te czynności, aby zresetować plik:

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

Na tym etapie to wszystko. Dobra robota!

Uzyskaj pomoc

Jeśli podczas tych ćwiczeń w programie wystąpią błędy, zgłoś je, korzystając z linku Issue Tracker u dołu dowolnej strony. Wyślij pytania do grupy android-building.