Ćwiczenie z programowania dla programistów aplikacji na Androida

Możesz pomóc stworzyć najpopularniejszy system operacyjny w historii całej Ziemi. Tak, jesteś tu, aby rozpocząć swoją przygodę z stanowiskiem inżyniera platformy Android.

Choć jest to trudne, zespół Androida stara się przy każdej publikacji. Zespół codziennie wprowadza ulepszenia w ramach Projektu Android Open Source (AOSP).

Usiądź wygodnie, uruchom terminal i zostań częścią historii.

Cele

Celem tego ćwiczenia jest:

  1. Aby pokazać Ci, jak wygląda proces programowania w przypadku inżynierów Androida pracujących nad platformą (systemem operacyjnym).
  2. Zachęcamy do przesyłania opinii na temat narzędzi, dokumentacji i przepływu pracy dewelopera na Androidzie.

Wymagania wstępne

Lista wymagań tego ćwiczenia z programowania pochodzi od wymagań ogólnych (AOSP). Aby wykonać to ćwiczenie z programowania, skonfiguruj te elementy:

Środowisko

Zazwyczaj użytkownicy budują i rozwijają aplikacje bezpośrednio na stacji roboczej. Ponieważ możesz pracować w różnych terminalach, a wiele poleceń jest specyficznych dla danego terminala, musisz je ponownie uruchomić w każdej sesji terminala. Konkretnie: w tym polecenia source build/envsetup.sh i lunch.

Konfigurowanie stacji roboczej

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

Inicjowanie i synchronizacja 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 dane logowania do Git (nazwę i adres e-mail).

  6. Zsynchronizuj kod źródłowy:

    repo sync -j8

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

Każde pobranie repozytorium jest reprezentowane przez plik manifestu. Dozwolone jest używanie więcej niż 1 płatności w repozytorium jednocześnie, pod warunkiem że które istnieją w osobnych katalogach. Pamiętaj jednak, że każda płatność i kompilacja równa się wykorzystanie około 300 GB (i rosną), więc ogranicz do 2 procesów płatności repozytorium, lub rozbudowywać system za pomocą dysku dodatkowego.

Kompilowanie kodu

Aby utworzyć Androida, musisz wybrać wartość docelową typu urządzeń, które chcesz utworzyć za pomocą polecenia lunch. Cel to permutacja urządzenia, na przykład konkretnego modelu lub formatu.

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

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

  1. Skonfiguruj środowisko do kompilowania aplikacji na urządzenia z Androidem, uruchamiając to polecenie w katalogu głównym pobranej wersji kodu źródłowego:

    source build/envsetup.sh
  2. Przekaż docelowe środowisko kompilacji do polecenia lunch, na przykład:

    lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
  3. Utwórz kod z dowolnego miejsca zapłać za pomocą:

    m

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

Wystrzel mątwy

Cuttlefish to emulator Androida używany do testowania kompilacji.

  1. Jeśli aplikacja Cuttlefish nie została nigdy przez Ciebie zainstalowana, musisz zainstalować niezbędne Zależności mątwy. W oknie terminala uruchom te polecenia, aby pobrać, skompilować i zainstalować hostowe 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 zasadę udev. reguł.

  2. Uruchom Mątwę:

    launch_cvd --daemon
    
  3. Połącz się z urządzeniem mątwy, przechodząc na stronę https://localhost:8443 w przeglądarki. Pojawi się strumień wideo z urządzenia z Androidem, które właśnie zbudowałeś/zbudowałaś.

Wprowadź zmianę

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

  1. W katalogu głównym checkoutu (katalogu aosp/) przejdź do projektu Git frameworks/native:

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

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

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

    void SurfaceFlinger::updateColorMatrixLocked() {
    
  5. Dodaj te 2 wiersze na początku funkcji 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 wersję na urządzeniu:

    adb root
    adb remount
    adb sync
    adb reboot

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

Przykład udanej zmiany koloru

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

Testowanie kodu

W tej części tego Codelab wykorzystano przykładowy test, który znajduje się w drzewie źródłowym i nie przechodzi. W tym celu użyjesz narzędzia Atest do przeprowadzania testów lokalnie i testowania kodu.

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

  1. Uruchom:

    atest DevCodelabTest
  2. Test się nie powiedzie. Sprawdź zrzut stosu niezaliczonego testu:

    STACKTRACE:
    java.lang.AssertionError
     at org.junit.Assert.fail(Assert.java:87)
     at org.junit.Assert.assertTrue(Assert.java:42)
     at org.junit.Assert.assertTrue(Assert.java:53)
     at android.test.example.devcodelab.DevCodelabTest.testHelloWorld(DevCodelabTest.java:29)
  3. Następnie spójrz tutaj

    platform_testing/tests/example/devcodelab
    
  4. Aby pobrać plik do edycji, wpisz nazwę testu w android.test.example.devcodelab.DevCodelabTest i zastąp . elementem /, 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
    

    aby zastąpić

    Assert.assertTrue(false)
    

    z

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

    atest DevCodelabTest

Przesyłanie kodu do sprawdzenia

Repozytorium upraszcza korzystanie z Git, dzięki łączeniu poleceń w pakiecie, takich jak git clone, w celu ich działania w wielu repozytoriach Git (lub projektach) jednocześnie.

Zapoznaj się z artykułami Source Control Tools, aby zapoznać się z omówieniem Git i Repo oraz linki do pełnej dokumentacji pracy z kodem źródłowym Androida. Zobacz repozytorium AOSP pełnej listy projektów Git i poszczególnych projektów (ścieżek) gałęzie powiązane z każdym projektem.

Do sprawdzania kodu w projektach w Git będziesz używać internetowego systemu sprawdzania kodu Gerrit.

  1. Przy założeniu, że zmiany zostały wprowadzone w projekcie frameworks/native, uruchom polecenie za pomocą tych poleceń:

    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 tego podstawowego ćwiczenia na temat tworzenia aplikacji na platformę Android. Zobacz Przesyłanie poprawek , a szczegółowe informacje o tworzeniu Androida znajdziesz w pozostałych tę witrynę.

Cofnij zmianę

Zazwyczaj po przeprowadzeniu testów, a także po sprawdzeniu i zatwierdzeniu przez użytkownika należy przesłać zmiany w Zaszyfruj plik i scal go z repozytorium.

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

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

repo abandon codelab .

Pamiętaj też, by cofnąć zmiany wprowadzone w pliku testowym. Ponieważ nie udało Ci się repo start, git commit i repo upload tę zmianę, możesz zresetować pliku. Zakładając, że używasz wersji 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 .

To już wszystko. Dobra robota!

Pomoc

Jeśli podczas tych ćwiczeń w programie wystąpią błędy, zgłoś je za pomocą Narzędzie do śledzenia problemów na dole dowolnej strony. Wyślij pytania do tworzenie Androida grupy reklam.