Wypróbuj tworzenie aplikacji na Androida

Z tego samouczka dowiesz się, jak po raz pierwszy tworzyć aplikacje na Androida.

Konfigurowanie środowiska programistycznego na Androida

Zanim pobierzesz i skompilujesz android-latest-releasegałąź manifestu źródła Androida, upewnij się, że Twój sprzęt spełnia niezbędne wymagania i że 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 tworzenie gałęzi, zatwierdzanie zmian, porównywanie różnic i edycja. Aby dowiedzieć się więcej o Git, zapoznaj się z dokumentacją Git.
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 Gita. 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.

Wymagania dotyczące sprzętu do Google Meet

Twoja stacja robocza do programowania powinna spełniać te wymagania sprzętowe lub je przewyższać:

  • 64-bitowy system x86.

  • Co najmniej 400 GB wolnego miejsca na dysku, aby pobrać i skompilować kod (250 GB na pobieranie i 150 GB na kompilację).

  • co najmniej 64 GB pamięci RAM; Do tworzenia Androida Google używa maszyn z 72 rdzeniami i 64 GB pamięci RAM. W tej konfiguracji sprzętowej pełna kompilacja Androida trwa około 40 minut, a kompilacja przyrostowa – tylko kilka minut. Natomiast pełna kompilacja na 6-rdzeniowym komputerze z 64 GB pamięci RAM trwa około 6 godzin.

Spełnianie wymagań dotyczących 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ć 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łąź Androida zawiera wstępnie skompilowane wersje OpenJDK, Make i Pythona 3, więc nie są wymagane żadne dodatkowe kroki instalacji. W sekcji poniżej znajdziesz instrukcje instalacji narzędzia Repo.

Instalowanie repozytorium

Aby zainstalować Repo, wykonaj te czynności:

  1. Pobierz aktualne informacje o 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 pobieranie i pobiera pełną wersję narzędzia Repo.

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

  3. (opcjonalnie) Ręcznie zainstaluj Repo, 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 pasuje do wymaganego klucza. Jeśli te polecenia zostaną wykonane prawidłowo, 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ą, np.:

    repo launcher version 2.45

Pobieranie źródła Androida

Kod źródłowy Androida znajduje się w kolekcji repozytoriów Git hostowanych przez Google. Każde repozytorium Git zawiera całą historię źródeł 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 najnowszą gałąź 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, aby utworzyć kompilację za pomocą polecenia lunch. Cel to permutacja urządzenia, np. konkretny model lub typ. Określ ten cel:

    lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug

    Powinien pojawić się opis ś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 element docelowy:

    m

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

Uruchom Cuttlefish

Cuttlefish to emulator Androida używany do testowania kompilacji.

  1. Aby pobrać, utworzyć i zainstalować pakiety hosta Debian, 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 udevzasad.

  2. Uruchom Cuttlefish:

    launch_cvd --daemon

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

Wprowadź zmianę

Zaktualizuj kod źródłowy zgodnie z tym zestawem zmian.

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

    cd frameworks/native

  2. Aby rozpocząć projekt tymczasowy, użyj tego polecenia:

    repo start <some-name> .

  3. Użyj edytora, aby edytować 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. Utwórz 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, która jest pokazana na rysunku 1.

    Przykład udanej zmiany koloru

    Rysunek 1. Wygląd ekranu po zmianie koloru

Rozwiązywanie problemów z testem

W tej części laboratorium wykorzystamy przykładowy test, który znajduje się w drzewie źródłowym i nie przechodzi.

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

  1. Uruchom:

    atest DevCodelabTest

    Test zakończy się niepowodzeniem.

  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 poprawienia, dodaj WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/ do ostatniego wiersza śladu stosu aż do nazwy pliku testowego włącznie. W takim przypadku 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. Ponownie uruchom test, aby sprawdzić, czy problem został rozwiązany:

    atest DevCodelabTest

Prześlij kod do sprawdzenia

Repo upraszcza korzystanie z Gita, łącząc polecenia takie jak git clone, aby działać w wielu repozytoriach Git (lub projektach) jednocześnie.

Do sprawdzania kodu projektów w Git używaj internetowego systemu sprawdzania kodu Gerrit.

  1. Załóżmy, że zmiany zostały wprowadzone w projekcie frameworks/native. Aby przesłać zmiany, uruchom te polecenia:

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

  2. Wpisz ten komunikat zatwierdzenia:

    Android codelab 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 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 Gerrit, kliknij link w terminalu. Link jest podobny do tego:

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

Cofnij zmianę

Zwykle po przeprowadzeniu testów, sprawdzeniu i zatwierdzeniu przesyłasz zmianę w Gerrit i scalasz ją z repozytorium. Zamiast tego na potrzeby tego samouczka cofnij zmiany:

  1. W Gerrit kliknij Abandon (Porzuć).

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

    repo abandon codelab .

  3. Cofnij zmiany wprowadzone w pliku testowym. Ponieważ nie przeprowadzono testu zmiany w przypadku plików repo start, git commit i repo upload, możesz zresetować sam plik. Zakładając, że jesteś w katalogu 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 .

W ten sposób zakończysz ćwiczenie dotyczące tworzenia platformy Android.

Pomoc

Jeśli podczas wykonywania tego samouczka napotkasz błędy, zgłoś je, korzystając z linku do narzędzia do śledzenia problemów u dołu dowolnej strony. Wysyłaj pytania 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 z identyfikatorem PID procesu.