Wypróbuj tworzenie aplikacji na Androida

Ten samouczek pozwoli Ci po raz pierwszy spróbować programowania systemu operacyjnego Android.

Konfigurowanie środowiska programistycznego na Androida

Zanim pobierzesz i skompilujesz gałąź manifestu android-latest-release kodu źródłowego Androida, upewnij się, że Twój sprzęt spełnia niezbędne wymagania i że wymagane oprogramowanie jest prawidłowo zainstalowane. Powinny być Ci też znane te pojęcia:

Git
Git to bezpłatny, rozproszony system kontroli wersji typu open source. Android używa Gita do operacji lokalnych, takich jak rozgałęzianie, zatwierdzanie, porównywanie i edytowanie. Jeśli potrzebujesz pomocy w nauce Gita, zapoznaj się z dokumentacją Gita.
Repo
Repo to nakładka Pythona na Gita, która upraszcza wykonywanie złożonych operacji w wielu repozytoriach Git. Repo nie zastępuje Gita we wszystkich operacjach kontroli wersji, ale ułatwia wykonywanie złożonych operacji Gita. Repo używa plików manifestu do agregowania projektów Git w superprojekcie Androida.
pliku manifestu
Plik manifestu to plik XML, który określa, gdzie w drzewie źródłowym AOSP znajdują się różne projekty Git w źródle Androida.

Wymagania dotyczące urządzenia Google Meet

Stacja robocza programisty powinna spełniać te wymagania sprzętowe:

  • 64-bitowy system x86.

  • co najmniej 400 GB wolnego miejsca na dysku na pobranie i skompilowanie kodu (250 GB na pobranie i 150 GB na skompilowanie);

  • Co najmniej 64 GB pamięci RAM. Do kompilowania Androida Google używa maszyn z 72 rdzeniami i 64 GB pamięci RAM. Przy tej konfiguracji sprzętowej pełna kompilacja Androida zajmuje około 40 minut, a kompilacja przyrostowa – tylko kilka minut. Dla porównania, pełna kompilacja na maszynie z 6 rdzeniami i 64 GB pamięci RAM zajmuje około 6 godzin.

Spełnianie wymagań dotyczących systemu operacyjnego

Na stacji roboczej programisty musi być zainstalowana dowolna 64-bitowa dystrybucja Linuksa z biblioteką GNU C (glibc) w wersji 2.17 lub nowszej.

Instalowanie wymaganych pakietów

Aby zainstalować wymagane pakiety dla Ubuntu 18.04 lub nowszego, uruchom to polecenie:

sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig

Instalowanie wymaganego oprogramowania

Zanim zaczniesz pracować z AOSP, musisz zainstalować OpenJDK, Make, Pythona 3 i Repo. Najnowsza gałąź wersji Androida zawiera gotowe wersje OpenJDK, Make i Pythona 3, więc nie trzeba wykonywać dodatkowych czynności instalacyjnych. W sekcji poniżej znajdziesz instrukcje instalowania Repo.

Repozytorium instalacji

Aby zainstalować Repo, wykonaj te czynności:

  1. Pobierz informacje o bieżącym pakiecie:

    sudo apt-get update

  2. Aby zainstalować program uruchamiający Repo, uruchom to polecenie:

    sudo apt-get install repo

    Program uruchamiający Repo udostępnia skrypt w Pythonie, który inicjuje proces pobierania i pobiera całe narzędzie Repo.

    Jeśli się uda, przejdź do kroku 4.

  3. Opcjonalnie: zainstaluj Repo ręcznie, używając tej serii poleceń:

    export REPO=$(mktemp /tmp/repo.XXXXXXXXX)
curl -o ${REPO} https://storage.googleapis.com/git-repo-downloads/repo
gpg --recv-keys 8BB9AD793E8E6153AF0F9A4416530D5E920F5C65
curl -s https://storage.googleapis.com/git-repo-downloads/repo.asc | gpg --verify - ${REPO} && install -m 755 ${REPO} ~/bin/repo

    Pierwsze 3 polecenia konfigurują plik tymczasowy, pobierają do niego Repo i sprawdzają, czy podany klucz jest zgodny z wymaganym. Jeśli te polecenia zostaną wykonane pomyślnie, ostatnie polecenie zainstaluje program uruchamiający Repo.

  4. Sprawdź wersję programu uruchamiającego Repo:

    repo version

    Dane wyjściowe powinny wskazywać wersję 2.4 lub nowszą, na przykład:

    repo launcher version 2.45

Pobieranie kodu źródłowego Androida

Kod źródłowy Androida znajduje się w zbiorze repozytoriów Git hostowanych przez Google. Każde repozytorium Git zawiera całą historię kodu źródłowego Androida, w tym zmiany w kodzie źródłowym i daty ich wprowadzenia. Aby pobrać źródło Androida:

  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 gałąź najnowszej wersji kodu źródłowego repozytorium AOSP (android-latest-release):

    repo init --partial-clone -b android-latest-release -u https://android.googlesource.com/platform/manifest

  5. Wpisz lub zaakceptuj dane logowania Git (nazwę, adres e-mail).

  6. Zsynchronizuj kod źródłowy:

    repo sync -c -j8

    Jeśli podczas pobierania wystąpią problemy, zapoznaj się z artykułem Rozwiązywanie problemów z synchronizacją.

Tworzenie kodu

Aby utworzyć kod:

  1. W katalogu roboczym uruchom skrypt envsetup.sh, aby skonfigurować środowisko kompilacji:

    source build/envsetup.sh

  2. Określ docelowy typ urządzenia, na którym chcesz przeprowadzić kompilację za pomocą polecenia lunch. Cel to permutacja urządzenia, np. konkretny model lub format. Określ ten cel:

    lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug

    Powinno pojawić się podsumowanie środowiska docelowego i środowiska kompilacji:

    ============================================
PLATFORM_VERSION_CODENAME=Baklava
PLATFORM_VERSION=Baklava
TARGET_PRODUCT=aosp_cf_x86_64_only_phone
TARGET_BUILD_VARIANT=userdebug
TARGET_ARCH=x86_64
TARGET_ARCH_VARIANT=silvermont
HOST_OS=linux
HOST_OS_EXTRA=Linux-6.10.11-1rodete2-amd64-x86_64-Debian-GNU/Linux-rodete
HOST_CROSS_OS=windows
BUILD_ID=BP1A.250305.020
OUT_DIR=out
============================================

  3. Utwórz środowisko docelowe:

    m

Pierwsza kompilacja może potrwać kilka godzin. Kolejne kompilacje zajmują znacznie mniej czasu. Dane wyjściowe kompilacji pojawią się w $OUT_DIR.

Uruchamianie Cuttlefish

Cuttlefish to Android Emulator używany do testowania kompilacji.

  1. Uruchom te polecenia, aby pobrać, utworzyć i zainstalować pakiety Debiana hosta:

    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
tools/buildutils/build_packages.sh
sudo apt install -y ./cuttlefish-base_*.deb ./cuttlefish-user_*.deb
sudo usermod -aG kvm,cvdnetwork,render $USER
sudo reboot

    Ponowne uruchomienie powoduje zainstalowanie dodatkowych modułów jądra systemu i zastosowanie reguł udev.

  2. Po ponownym uruchomieniu stacji roboczej przejdź do katalogu aosp, skonfiguruj środowisko kompilacji i uruchom Cuttlefish:

    cd ~/aosp
source build/envsetup.sh
lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug
launch_cvd --daemon

  3. Połącz się z urządzeniem Cuttlefish, otwierając https://localhost:8443 w przeglądarce. Wyświetli się wirtualne urządzenie z Androidem.

Wprowadzanie zmiany

Zaktualizuj kod źródłowy zgodnie z tą przykładową listą zmian.

  1. Z poziomu katalogu głównego wyewidencjonowania (katalog aosp/) przejdź do projektu Git frameworks/native:

    cd frameworks/native

  2. Uruchom gałąź tymczasową za pomocą tego polecenia:

    repo start BRANCH_NAME .

  3. Użyj edytora, aby zmodyfikować plik SurfaceFlinger.cpp w tej lokalizacji:

    aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp

  4. Znajdź ten wiersz:

    void SurfaceFlinger::updateColorMatrixLocked() {

  5. Dodaj ten wiersz na początku pliku 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 -R
adb root
adb sync
adb reboot

  8. Sprawdź, czy na wybranym urządzeniu zmienił się kolor.

Naprawianie testu

W tej części ćwiczenia używamy przykładowego testu, który znajduje się w drzewie źródłowym i kończy się niepowodzeniem. Aby uruchomić, debugować i naprawić test, wykonaj te czynności:

  1. Uruchomienie:

    atest DevCodelabTest

    Test się nie powiedzie.

  2. Przeanalizuj zrzut stosu nieudanego 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)

    Ostatni wiersz zrzutu stosu pokazuje test, który się nie powiódł (testHelloWorld). Ten test znajduje się w pliku o nazwie DevCodelabTest.java.

  3. Aby określić lokalizację testu, który chcesz naprawić, dołącz WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/ do ostatniego wiersza zrzutu stosu, aż do nazwy pliku testowego (włącznie). Czyli android.test.example.devcodelab.DevCodelabTest zmienia się w WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java.

  4. Edytuj platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java i zastąp Assert.assertTrue(false) wartością Assert.assertTrue(true).

  5. Aby sprawdzić, czy problem został rozwiązany, uruchom test jeszcze raz:

    atest DevCodelabTest

Przesyłanie kodu do sprawdzenia

Repo upraszcza korzystanie z Gita, łącząc polecenia takie jak git clone, aby działały jednocześnie w wielu repozytoriach (lub projektach) Gita. Do weryfikacji kodu projektów w Git używaj internetowego systemu weryfikacji kodu Gerrit.

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

    cd frameworks/native
repo start BRANCH_NAME .
git add .
git commit

  2. Wpisz ten komunikat zatwierdzenia:

    Android BRANCH_NAME change
Test: manual atest

  3. Prześlij zmianę:

    repo upload

    Jeśli się uda, zobaczysz komunikat podobny do tego:

    Upload project frameworks/native/ to remote branch android17-release:
  branch BRANCH_NAME ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
         ff46b36d Android BRANCH_NAME 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 BRANCH_NAME change [NEW]
remote:
To https://android-review.googlesource.com/platform/frameworks/native
* [new branch]          BRANCH_NAME -> refs/for/android17-release

Wyświetlanie zmiany w Gerrit

Aby wyświetlić zmianę w Gerrit, przejdź do linku wyjściowego w terminalu. Link wygląda podobnie do tego:

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

Cofnij zmianę.

Zwykle po zakończeniu testów oraz po sprawdzeniu i zatwierdzeniu przesyłasz zmianę w Gerrit i scalasz ją z repozytorium. Zamiast tego na potrzeby tego ćwiczenia w programowaniu cofnij zmiany:

  1. W Gerrit kliknij Abandon (Porzuć).

  2. Porzuć powiązaną gałąź tymczasową w katalogu projektu frameworks/native (lub jego podkatalogach):

    repo abandon BRANCH_NAME .

  3. Cofnij zmiany wprowadzone w pliku testowym. Ponieważ nie uruchomiono poleceń repo start, git commit i repo upload w przypadku zmiany testowej, możesz zresetować sam plik. Jeśli jesteś w katalogu aosp/platform_testing, użyj tych poleceń, aby zresetować plik:

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

To już koniec ćwiczenia z programowania dotyczącego tworzenia platformy Androida.

Pomoc

Jeśli podczas wykonywania tego ćwiczenia napotkasz błędy, zgłoś je, korzystając z linku do narzędzia Issue Tracker u dołu dowolnej strony. Pytania wysyłaj do grupy android-building.

Wpisz ps -A | grep crosvm, aby sprawdzić, czy usługa crosvm jest już uruchomiona. Jeśli crosvm jest uruchomiony, wpisz stop_cvd || true lub kill crosvm z identyfikatorem PID procesu.