Ć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 Androidem i zostać inżynierem platformy Android.

Choć jest to trudne, zespół Androida stara się przy każdej publikacji. Nasz zespół codziennie wprowadza ulepszenia, dzięki bezpośrednim w ramach 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ć Ci przedsmak tego, jak wygląda przepływ pracy w programie np. dla inżynierów Androida pracujących nad platformą (systemem operacyjnym).
  2. Zachęcamy do przesyłania opinii dotyczącej narzędzi, dokumentacji i przepływu pracy programistów na Androida.

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

Zwykle użytkownicy tworzą i programują bezpośrednio na stacji roboczej. Ponieważ być może działają w różnych terminalach, a wiele z nich jest ściśle związanych z terminalem, musisz je uruchamiać ponownie po każdej sesji terminala. Konkretnie: w tym polecenia source build/envsetup.sh i lunch.

Skonfiguruj stację roboczą

  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 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. Wstępnie skonfiguruj 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 płatności w repozytorium jednocześnie, pod warunkiem że są one 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 skompilować Androida, musisz wybrać docelowy typ urządzenia, na którym chcesz skompilować aplikację za pomocą polecenia lunch. Cel to permutacja urządzenia, na przykład konkretnego modelu lub formatu.

aosp_cf_x86_64_phone-userdebug pozwala na: aby stworzyć wirtualne urządzenie z Androidem mątwy bez fizycznego urządzenia.

Aby utworzyć i zaktualizować urządzenie fizyczne, wybierz inny cel i wykonaj te czynności: instrukcje flashowania urządzeń.

  1. Skonfiguruj środowisko do tworzenia urządzeń z Androidem, uruchamiając następujące polecenie z poziomu głównego katalogu 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 zapłać 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 Cuttlefish nie jest jeszcze zainstalowany, musisz zainstalować niezbędne zależności Cuttlefish. W oknie terminala uruchom następujące polecenia aby pobrać, skompilować i zainstalować hostujące 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. Zobaczysz strumień wideo przygotowany przez system Android Twojego nowego urządzenia.

Wprowadź zmianę

Zaktualizuj kod źródłowy zgodnie z tym przykładem changelist.

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

    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 ta lokalizacja:

    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. Kompilowanie kodu:

    m

  7. Zaktualizuj kompilację na urządzeniu:

    adb root
adb remount
adb sync
adb reboot

Sprawdź, czy na wybranym urządzeniu widzisz zmianę kolorów, która jest podobna do tego, co widać na ekranie na rys. 1.

Przykład udanego zmiany koloru

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

Testowanie kodu

W tej części ćwiczeń z programowania wykorzystywany jest przykładowy test, który znajduje się w drzewie źródłowym i kończy się niepowodzeniem. Używana jest właściwość Atest dla: lokalnego uruchomienia testu 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 uzyskać plik do edycji, weź nazwę testu z android.test.example.devcodelab.DevCodelabTest i zastąp ją wartością /, aby uzyskać taki 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 jeszcze raz, aby sprawdzić, czy problem został rozwiązany:

    atest DevCodelabTest

Przesyłanie kodu do sprawdzenia

Repo upraszcza korzystanie z Git, ponieważ pozwala na łączenie poleceń takich jak git clone, aby jednocześnie pracować w wielu repozytoriach Git (lub projektach).

Informacje o Git i Repo, w tym linki do pełnej dokumentacji dotyczącej pracy z kodem źródłowym Androida, znajdziesz w narzędziach do kontroli wersji. 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 weryfikacji kodu projektów w Git użyjesz narzędzia Gerrit internetowego systemu weryfikacji kodu.

  1. Zakładając, że zmiany zostały wprowadzone w projekcie frameworks/native, wykonaj 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. Zobacz Przesyłanie poprawek , a szczegółowe informacje o tworzeniu Androida znajdziesz w pozostałych tę witrynę.

Cofnij zmianę

Po przetestowaniu i sprawdzeniu zmian oraz zatwierdzeniu ich przesyłasz je do Gerrita i zgrywasz do repozytorium.

W ramach tego ćwiczenia zamiast tego cofnij listę zmian, klikając Porzucić 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. Jeśli jesteś w lokalizacji aosp/platform_testing directory, użyj następujące polecenie, 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!

Pomoc

Jeśli podczas pracy z tym ćwiczeniem napotkasz błędy, zgłoś je, korzystając z linku Problem Tracker na dole dowolnej strony. Wyślij pytania do tworzenie Androida grupy reklam.