Ćwiczenie z programowania dla programistów aplikacji na Androida

Możesz pomóc stworzyć najpopularniejszy system operacyjny w historii całej Ziemi. Tak, możesz dołączyć do grona użytkowników Androida inżynierem platformy.

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 nad narzędziami, dokumentacją i przepływem pracy programistycznym 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

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. 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 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 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.

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 proces płatności:

    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 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ć 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 Cuttlefish:

    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, postępując zgodnie z tą przykładową listą zmian.

  1. Z poziomu głównego strony 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 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 zmiana koloru jest podobna do tego, co widać na ekranie na rys. 1.

Przykład udanej 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. 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 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 jeszcze raz, 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 weryfikacji kodu projektów w Git użyjesz narzędzia Gerrit internetowego systemu weryfikacji kodu.

  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 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ę

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. 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 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.