Wypróbuj tworzenie aplikacji na Androida

W tym samouczku po raz pierwszy spróbujesz tworzenia systemu operacyjnego Android.

Konfigurowanie środowiska do tworzenia aplikacji na Androida

Zanim pobierzesz i skompilujesz gałąź manifestu android-latest-release źródła Androida, upewnij się, że Twój sprzęt spełnia wymagania i że wymagane oprogramowanie jest prawidłowo zainstalowane. Musisz też znać te terminy:

Git
Git to bezpłatny, rozproszony system kontroli wersji typu open source. Android używa Gita do operacji lokalnych, takich jak tworzenie gałęzi, zatwierdzanie zmian, porównywanie i edytowanie. Aby dowiedzieć się więcej o Gicie, zapoznaj się z dokumentacją Gita.
Repo
Repo to otoka Pythona wokół Gita, która upraszcza wykonywanie złożonych operacji w wielu repozytoriach Git. Repo nie zastępuje Gita we wszystkich operacjach kontroli wersji, tylko ułatwia wykonywanie złożonych operacji Git. Repo używa plików manifestu do agregowania projektów Git w superprojekcie Androida.
plik manifestu
Plik manifestu to plik XML określający, gdzie w drzewie źródłowym AOSP znajdują się różne projekty Git w źródle Androida.

Spełnianie wymagań sprzętowych

Twój komputer do programowania powinien spełniać te wymagania sprzętowe lub je przekraczać:

  • System 64-bitowy x86.

  • Co najmniej 400 GB wolnego miejsca na dysku na pobranie i skompilowanie kodu (250 GB na pobranie + 150 GB na kompilację).

  • Co najmniej 64 GB pamięci RAM. Google używa do kompilowania Androida maszyn z 72 rdzeniami i 64 GB pamięci RAM. Przy takiej konfiguracji sprzętowej pełna kompilacja Androida trwa 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 trwa około 6 godzin.

Spełnianie wymagań systemowych

Na komputerze do programowania musi być zainstalowana dowolna dystrybucja Linuksa 64-bitowego z biblioteką GNU C (glibc) w wersji 2.17 lub nowszej.

Instalowanie wymaganych pakietów

Aby zainstalować wymagane pakiety w Ubuntu 18.04 lub nowszym, 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 korzystać z AOSP, musisz zainstalować OpenJDK, Make, Pythona 3 i Repo. Najnowsza gałąź wersji Androida zawiera wstępnie skompilowane wersje OpenJDK, Make i Pythona 3, więc nie trzeba wykonywać dodatkowych czynności instalacyjnych. W następnej sekcji dowiesz się, jak zainstalować Repo.

Instalowanie Repo

Aby zainstalować Repo:

  1. Pobierz aktualne informacje o pakietach:

    sudo apt-get update

  2. Uruchom to polecenie, aby zainstalować program uruchamiający Repo:

    sudo apt-get install repo

    Program uruchamiający Repo udostępnia skrypt Pythona, który inicjuje pobieranie i pobiera pełne narzędzie Repo.

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

  3. (opcjonalnie) Ręcznie zainstaluj Repo za pomocą tych 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 pasuje do wymaganego klucza. Jeśli te polecenia się powiodą, 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 źródła Androida

Źródło Androida znajduje się w kolekcji repozytoriów Git hostowanych przez Google. Każde repozytorium Git zawiera całą historię źródła Androida, w tym zmiany w źródle 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 najnowszą gałąź 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 do Gita (imię i nazwisko, adres e-mail).

  6. Zsynchronizuj kod źródłowy:

    repo sync -c -j8

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

Kompilowanie kodu

Aby skompilować kod:

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

    source build/envsetup.sh

  2. Określ docelowy typ urządzenia, aby skompilować kod za pomocą polecenia lunch. Docelowy typ urządzenia to permutacja urządzenia, np. konkretny model lub format. Określ ten docelowy typ urządzenia:

    lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug

    Powinien wyświetlić się opis docelowego typu urządzenia 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. Skompiluj docelowy typ urządzenia:

    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 emulator Androida używany do testowania kompilacji.

  1. Aby pobrać, skompilować i zainstalować pakiety hosta Debiana, uruchom te polecenia:

    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 powoduje zainstalowanie dodatkowych modułów jądra i zastosowanie reguł udev.

  2. Uruchom Cuttlefish:

    launch_cvd --daemon

  3. Aby połączyć się z urządzeniem Cuttlefish, w przeglądarce otwórz adres https://localhost:8443. Wyświetli się wirtualne urządzenie z Androidem.

Wprowadzanie zmiany

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

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

    cd frameworks/native

  2. Uruchom tymczasowy projekt za pomocą tego polecenia:

    repo start PROJECT_NAME.

  3. Użyj edytora, aby edytować 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 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 widzisz zmianę koloru podobną do tej na rysunku 1.

    Przykład udanej zmiany koloru

    Rysunek 1. Wygląd ekranu po udanej zmianie koloru

Naprawianie testu

Ta część ćwiczenia wykorzystuje przykładowy test, który znajduje się w drzewie źródłowym i nie przechodzi.

Aby uruchomić, debugować i naprawić test, wykonaj te czynności:

  1. Uruchom:

    atest DevCodelabTest

    Test się nie powiódł.

  2. Sprawdź 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 śladu 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 do naprawienia, do ostatniego wiersza zrzutu stosu dołącz WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/ aż do nazwy pliku testowego włącznie. Zatem android.test.example.devcodelab.DevCodelabTest staje się WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java.

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

  5. Uruchom test ponownie, aby sprawdzić, czy problem został rozwiązany:

    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 Git (lub projektach).

Do inspekcji kodu projektów w Gicie użyj Gerrit internetowego systemu inspekcji kodu.

  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 PROJECT_NAME.
git add .
git commit

  2. W komunikacie zatwierdzenia wpisz:

    Android PROJECT_NAME. change
Test: manual atest

  3. Prześlij zmianę:

    repo upload

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

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

Wyświetlanie zmiany w Gerrit

Aby wyświetlić zmianę w Gerrit, kliknij link w danych wyjściowych terminala. Link jest podobny do tego:

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

Cofanie zmiany

Zwykle po testach oraz sprawdzeniu i zatwierdzeniu przesyłasz zmianę w Gerrit i scalasz ją z repozytorium. Na potrzeby tego ćwiczenia cofnij jednak swoją pracę:

  1. W Gerrit kliknij Porzuć.

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

    repo abandon PROJECT_NAME.

  3. Cofnij zmiany wprowadzone w pliku testowym. Ponieważ nie uruchomiono poleceń repo start, git commit i repo upload w przypadku zmiany testu, możesz zresetować sam plik. Zakładając, że jesteś w aosp/platform_testing directory, użyj tego polecenia, aby zresetować plik:

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

To kończy ćwiczenie dotyczące tworzenia platformy Android.

Pomoc

Jeśli podczas wykonywania tego ćwiczenia napotkasz błędy, zgłoś je za pomocą 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 crosvm jest już uruchomiony. Jeśli crossvm jest uruchomiony, wpisz stop_cvd || true lub kill crosvm proces za pomocą identyfikatora PID procesu.