Wypróbuj tworzenie aplikacji na Androida

W tym samouczku możesz po raz pierwszy spróbować stworzyć system operacyjny Android.

Konfigurowanie środowiska programistycznego na potrzeby tworzenia aplikacji na Androida

Zanim pobierzesz i skompilujesz gałąź pliku manifestu android-latest-release 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.

Spełnianie wymagań systemu operacyjnego

Na stacji roboczej dewelopera musi być zainstalowana dowolna 64-bitowa dystrybucja 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

Aby korzystać z AOSP, musisz mieć zainstalowane OpenJDK, Make, Python 3 i Repo. Najnowsza gałąź Androida zawiera wstępnie skompilowane wersje OpenJDK, Make i Pythona 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, używając tej sekwencji 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 kluczem. Jeśli te polecenia zadziałają, ostatnie polecenie zainstaluje program uruchamiający Repo.

  4. Sprawdź wersję uruchamiacza 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. Przejdź do katalogu domowego:

    cd ~

  2. Utwórz w nim lokalny podkatalog roboczy:

    mkdir aosp

  3. Przejdź do katalogu:

    cd aosp

  4. Inicjalizacja najnowszej gałęzi wersji kodu źródłowego w 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 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 typ urządzenia to jego permutacja, np. konkretny model lub format. Określ tę grupę docelową:

    lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug

    Powinien pojawić się podsumowanie środowiska docelowego i 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 panelu $OUT_DIR.

Uruchamianie Cuttlefish

Cuttlefish to emulator Androida używany do testowania wersji.

  1. Aby pobrać, skompilować i zainstalować pakiety Debiana na hoście, 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. Kompilowanie kodu:

    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

Poprawianie testu

W tej części tego Codelab wykorzystano 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łania podaje 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, 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 android16-release:
 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/android16-release

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 należy przesyłać do grupy android-building.

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