Wypróbuj tworzenie aplikacji na Androida

W tym samouczku możesz po raz pierwszy spróbować swych sił w programowaniu systemu operacyjnego Android.

Konfigurowanie środowiska programistycznego na potrzeby tworzenia aplikacji 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ż znać te terminy:

Git
Git to bezpłatny system kontroli wersji typu open source. Android używa Git do operacji lokalnych, takich jak rozgałęzianie, zatwierdzanie, porównywanie i edytowanie. 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. Repo nie zastępuje Git w przypadku wszystkich operacji związanych z kontrolą wersji, ale ułatwia wykonywanie złożonych operacji Git. Repozytorium używa plików manifestu do agregowania projektów Git w superprojekt Androida.
plik manifestu
Plik manifestu to plik XML określający, gdzie w drzewie źródeł AOSP znajdują się różne projekty Git w źródłach Androida.

Wymagania sprzętowe Meet

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

  • 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 tej konfiguracji sprzętowej pełne kompilowanie Androida zajmuje około 40 minut, a kompilowanie przyrostowe – tylko 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

Stacja robocza dewelopera musi działać na dowolnej 64-bitowej dystrybucji systemu Linux 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

Zanim zaczniesz korzystać z AOSP, musisz zainstalować OpenJDK, Make, Python 3 i Repo. Główna gałąź AOSP Androida zawiera wstępnie skompilowane wersje OpenJDK, Make i Python 3, więc nie trzeba wykonywać dodatkowych czynności instalacyjnych. W następnej sekcji znajdziesz instrukcje instalacji 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) Ręcznie zainstaluj Repo, wykonując te polecenia:

    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 się powiedzie, 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ę kodu źródłowego Androida, w tym zmiany w źródle i czas ich wprowadzenia. Aby pobrać kod źródłowy Androida:

  1. Otwórz katalog główny:

    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 --partial-clone -b main -u https://android.googlesource.com/platform/manifest

  5. Wpisz lub zaakceptuj dane logowania do Git (nazwę i 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 skompilować 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. Docelowy element 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ę w panelu $OUT_DIR.

Uruchamianie Cuttlefish

Cuttlefish to emulator Androida używany do testowania wersji.

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

  2. Uruchom Cuttlefish:

    launch_cvd --daemon

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

Wprowadź zmianę

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

  1. W katalogu głównym checkoutu (katalogu 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 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. 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 na rysunku 1.

    Przykład udanego zmiany koloru

    Rysunek 1. Wygląd ekranu po zmianie koloru

Popraw test

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

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łań zawiera test, który się nie udał (testHelloWorld). Ten test znajduje się w pliku 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ę 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) tekstem 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 Git, ponieważ pozwala na użycie poleceń takich jak git clone do pracy w wielu repozytoriach Git (lub projektach) jednocześnie.

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, wykonaj 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 zmian 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ę

Po przetestowaniu i sprawdzeniu zmian oraz zatwierdzeniu ich przesyłasz je do Gerrita i zgrywasz do repozytorium. Zamiast tego, na potrzeby tego samouczka 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 crosvm jest już uruchomiona. Jeśli proces crossvm jest uruchomiony, wpisz stop_cvd || true lub kill crosvm z identyfikatorem procesu PID.