Wypróbuj tworzenie aplikacji na Androida

W tym samouczku możesz po raz pierwszy wypróbować programowanie w systemie operacyjnym Android.

Skonfiguruj na potrzeby programowania na Androida

Zanim pobierzesz i skompilujesz gałąź main kodu źródłowego Androida, sprawdź, czy Twój sprzęt spełnia wymagania i czy wymagane oprogramowanie jest prawidłowo zainstalowane. Musisz też zapoznać się z tymi warunkami:

Git
Git to bezpłatny, rozproszony system kontroli wersji typu open source. Android używa Gita do operacji lokalnych, takich jak rozgałęzianie, zatwierdzenia, różnice i zmiany. Aby dowiedzieć się więcej o Git, zapoznaj się z dokumentacją Git.
Repo
Repo to zewnętrzna biblioteka Pythona dla Git, która upraszcza wykonywanie złożonych operacji w wielu repozytoriach Git. Repozytorium nie zastępuje Gita w przypadku wszystkich operacji 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 ze źródła Androida.

Spełnij wymagania sprzętowe

Stacja robocza do programowania powinna spełniać te wymagania dotyczące sprzętu:

  • 64-bitowy system x86.

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

  • co najmniej 64 GB pamięci RAM; Do kompilacji Androida Google używa maszyn z 72 rdzeniami i 64 GB pamięci RAM. Przy takiej konfiguracji sprzętowej pełnej kompilacji Androida zajmuje około 40 minut, a przyrostowa kompilacja Androida – zaledwie kilka minut. W przypadku pełnego kompilowania na maszynie z 6 rdzeniami i 64 GB pamięci RAM trwa to około 6 godzin.

Wymagania dotyczące systemu operacyjnego

Programowa stacja robocza musi obsługiwać dowolną 64-bitową dystrybucję Linuksa z biblioteką GNU C Library (glibc) w wersji 2.17 lub nowszej.

Instalowanie wymaganych pakietów

Aby zainstalować pakiety wymagane 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

Aby korzystać z AOSP, musisz zainstalować OpenJDK, Make, Python 3 i Repo. Główna gałąź Androida AOSP ma gotowe wersje OpenJDK, Make i Pythona 3, więc nie trzeba wykonywać dodatkowych czynności instalacyjnych. W tej sekcji dowiesz się, jak zainstalować Repo.

Instalowanie repozytorium

Aby zainstalować Repo:

  1. Pobierz informacje o bieżącym pakiecie:

    sudo apt-get update

  2. Aby zainstalować uruchamiacz Repo, uruchom to polecenie:

    sudo apt-get install repo

    Uruchamiacz repozytorium udostępnia skrypt Pythona, który inicjuje sprawdzanie i pobiera pełne narzędzie Repo.

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

  3. (Opcjonalnie) Zainstaluj ręcznie Repo, używając 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ą repozytorium do tego pliku i sprawdzają, czy podany klucz jest zgodny z wymaganym. Jeśli te polecenia zadziałają, ostatnie polecenie zainstaluje program uruchamiający Repo.

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

    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 kolekcji repozytoriów Git hostowanych przez Google. Każde repozytorium Git zawiera całą historię źródła Androida, łącznie ze zmianami w źródle i czasem ich wprowadzenia. Aby pobrać aplikację źródłową na 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 główną gałąź kodu źródłowego repozytorium AOSP (domyślnie):

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

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

  6. Synchronizuj 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ą i ich usuwanie.

Kompilowanie kodu

Aby utworzyć kod:

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

    source build/envsetup.sh

  2. Określ typ docelowego urządzenia, które chcesz utworzyć za pomocą polecenia lunch. Cel to permutacja urządzenia, np. konkretny model lub format. Określ tę grupę docelową:

    lunch aosp_cf_x86_64_phone-trunk_staging-userdebug

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

    ============================================
PLATFORM_VERSION_CODENAME=VanillaIceCream
PLATFORM_VERSION=VanillaIceCream
PRODUCT_INCLUDE_TAGS=com.android.mainline
TARGET_PRODUCT=aosp_arm
TARGET_BUILD_VARIANT=eng
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=generic
HOST_OS=linux
HOST_OS_EXTRA=Linux-6.5.13-1rodete2-amd64-x86_64-Debian-GNU/Linux-rodete
HOST_CROSS_OS=windows
BUILD_ID=AOSP.MAIN
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ę tutaj: $OUT_DIR.

Uruchamianie Mątwy

Cuttlefish to emulator Androida używany do testowania wersji.

  1. Aby pobrać, skompilować i zainstalować hostowane pakiety Debiana, uruchom następujące 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 uruchamianie powoduje instalację dodatkowych modułów jądra i zastosuje udevzasad.

  2. Uruchom Mątwę:

    launch_cvd --daemon

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

Wprowadź zmianę

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

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

    cd frameworks/native

  2. Uruchom projekt tymczasowy za pomocą tego polecenia:

    repo start <some-name> .

  3. Użyj edytora, aby edytować SurfaceFlinger.cpp w tym miejscu:

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

  4. Znajdź ten wiersz:

    void SurfaceFlinger::updateColorMatrixLocked() {

  5. Dodaj ten wiersz na początku wiersza 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. Utwórz kod:

    m

  7. Zaktualizuj wersję 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 widocznej na rysunku 1.

    Przykład udanego zmiany koloru

    Rysunek 1. Wygląd ekranu po zmianie koloru

Napraw test

W tej części ćwiczenia w Codelabs używany jest przykładowy test, który znajduje się w drzewie źródłowym, i kończy się niepowodzeniem.

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

  1. Uruchom:

    atest DevCodelabTest

    Test się nie powiedzie.

  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 ścieżki wywołania podaje test, który się nie udał (testHelloWorld). Ten test znajduje się w pliku o nazwie DevCodelabTest.java.

  3. Aby określić lokalizację testu, który należy naprawić, dodaj WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/ do ostatniego wiersza ścieżki sterowania, aż do nazwy pliku testu. android.test.example.devcodelab.DevCodelabTest zmienia się na WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java.

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

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

Aby sprawdzić kod swoich projektów w Git, użyj internetowego systemu Gerrit do sprawdzania 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 codelab .
git add .
git commit

  2. W komunikacie zatwierdzenia wpisz:

    Android codelab change
Test: manual atest

  3. Prześlij zmiany:

    repo upload

    Jeśli się uda, 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

Aby wyświetlić zmiany w Gerricie, przejdź do wyjścia linku w terminalu. Link wygląda mniej więcej tak:

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

Cofnij zmianę

Zwykle po przeprowadzeniu testów, a potem po sprawdzeniu i zatwierdzeniu zmiany przesyła się ją do Gerrit i scala z repozytorium. Zamiast tego, na potrzeby tego Codelab cofnij zmiany:

  1. W Gerrit kliknij Porzuć.

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

    repo abandon codelab .

  3. Cofnij zmiany wprowadzone w pliku testowym. Ponieważ nie uruchomiono testowych zmian w plikach repo start, git commit i repo upload, 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 już koniec ćwiczeń dotyczących tworzenia aplikacji na platformę Android.

Pomoc

Jeśli podczas pracy z tym ćwiczeniem napotkasz błędy, zgłoś je, korzystając z linku Problem Tracker na dole dowolnej strony. Pytania kieruj do grupy android-building.

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