Możesz pomóc stworzyć najpopularniejszy system operacyjny w historii Earth. Tak, możesz stać się inżynierem platformy Androida.
Choć jest to trudne, zespół Androida stara się uprościć każdą wersję aplikacji. Nasz zespół codziennie wprowadza ulepszenia dzięki bezpośredniej pracy w projekcie Android Open Source Project (AOSP).
Usiądź wygodnie, uruchom terminal i zacznij tworzyć historię.
Cele
Cele tego ćwiczenia z programowania są 2 elementy:
- Aby dać Wam przedsmak tego, jak wygląda przepływ pracy w programie dla inżynierów Androida pracujących nad platformą (systemem operacyjnym).
- Zachęcamy do dzielenia się opiniami na temat narzędzi Androida, dokumentacji i procesu programowania.
Wymagania wstępne
Lista wymagań tego ćwiczenia z programowania pochodzi od wymagań dotyczących ogólnego programowania platform (AOSP). Aby wykonać to ćwiczenie w Codelabs, skonfiguruj te elementy:
- Fizyczna stacja robocza z systemem Linux spełniająca wszystkie wymagania publiczne.
- Repo i konfiguracja Git wymagane do edytowania bazy kodu Androida.
Środowisko
Zwykle użytkownicy tworzą i programują bezpośrednio na stacji roboczej. Ponieważ możesz używać różnych terminali, a wiele z poleceń jest związanych z konkretnymi terminalami, musisz je ponownie uruchamiać w każdej sesji terminala. Chodzi konkretnie o polecenia source build/envsetup.sh
i lunch
.
Skonfiguruj stację roboczą
- Zainstaluj niezbędne pakiety na stacji roboczej.
- Nie wychodząc z terminala, zainstaluj Repo i uzyskaj dane logowania do wszystkich repozytoriów Git.
Inicjowanie i synchronizowanie kodu
Przejdź do katalogu głównego:
cd ~
Utwórz w nim lokalny podkatalog roboczy:
mkdir aosp
Przejdź do katalogu:
cd aosp
Zainicjuj główną gałąź kodu źródłowego repozytorium AOSP (domyślnie):
repo init -u https://android.googlesource.com/platform/manifest
Wpisz lub zaakceptuj swoje dane logowania Git (nazwę, adres e-mail).
Zsynchronizuj kod źródłowy:
repo sync -j8
Wstępna synchronizacja może potrwać godzinę lub dłużej.
Każda transakcja w repozytorium jest reprezentowana przez plik manifestu. Dozwolone jest używanie więcej niż 1 repozytorium jednocześnie, o ile znajdują się one w różnych katalogach. Pamiętaj jednak, że każda transakcja i kompilacja zajmują około 300 GB wykorzystania (i rosną), więc ogranicz się do 2 procesów płatności w repozytorium lub uzupełnij swój system o dysk dodatkowy.
Kompilowanie kodu
Aby utworzyć Androida, musisz wybrać docelowy typ urządzenia za pomocą polecenia lunch
. Cel to permutacja urządzenia,
np. konkretny model lub format.
Urządzenie docelowe aosp_cf_x86_64_phone-userdebug
umożliwia utworzenie wirtualnego urządzenia z Androidem Cuttlefish na potrzeby testowania bez urządzenia fizycznego.
Aby skompilować i zaktualizować urządzenie fizyczne, wybierz inne środowisko docelowe i postępuj zgodnie z instrukcjami dotyczącymi urządzeń Flash.
Skonfiguruj środowisko do tworzenia urządzeń z Androidem, uruchamiając to polecenie w katalogu głównym procesu płatności za pomocą kodu źródłowego:
source build/envsetup.sh
Przekaż cel kompilacji do polecenia lunchowego w ten sposób:
lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
Utwórz kod z dowolnego miejsca na stronie płatności za pomocą:
m
Pierwsza kompilacja może potrwać kilka godzin. Kolejne kompilacje wymagają znacznie mniej czasu.
Wystrzel mątwy
Cuttlefish to emulator Androida używany do testowania kompilacji.
Jeśli mątwy nie masz jeszcze zainstalowanego, musisz zainstalować niezbędne zależności mątwy. W oknie terminala uruchom następujące polecenia, aby pobrać, skompilować i zainstalować zainstalowane pakiety Debiana:
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 aktywuje instalację dodatkowych modułów jądra i stosuje reguły
udev
.Uruchom Cuttlefish:
launch_cvd --daemon
Połącz się z urządzeniem Cuttlefish, otwierając stronę
https://localhost:8443
w przeglądarce. Zobaczysz strumień wideo swojego właśnie urządzenia z Androidem.
Wprowadź zmianę
Zaktualizuj kod źródłowy, postępując zgodnie z tą przykładową listą zmian.
Z poziomu głównego procesu płatności (katalog
aosp/
) przejdź do projektu Gitframeworks/native
:cd frameworks/native
Uruchom projekt tymczasowy za pomocą tego polecenia:
repo start <some-name> .
Edytuj pole
SurfaceFlinger.cpp
, aby uwzględnić aktualizacje z listy zmian w tej lokalizacji:aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
Znajdź ten wiersz:
void SurfaceFlinger::updateColorMatrixLocked() {
Dodaj te dwa wiersze na początku metody 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});
Skompiluj kod:
m
Zaktualizuj kompilację na urządzeniu:
adb root
adb remount
adb sync
adb reboot
Sprawdź, czy na wybranym urządzeniu zmienił się kolor podobny do tego na ilustracji 1.
Rysunek 1. Wygląd ekranu po pomyślnej zmianie kolorów
Testowanie kodu
W tej części ćwiczenia w Codelabs wykorzystywany jest przykładowy test, który znajduje się w drzewie źródłowym, i kończy się niepowodzeniem. W tym celu wykorzystywane jest narzędzie Atest do lokalnego uruchamiania testu i testowania kodu.
Aby skorzystać z testu, postępuj zgodnie z tymi instrukcjami:
Uruchom:
atest DevCodelabTest
Test się nie powiedzie. Aby rozwiązać ten problem, znajdź kod źródłowy nieudanego testu:
atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
Następnie spójrz tutaj
platform_testing/tests/example/devcodelab
Aby uzyskać ten wynik, użyj nazwy testu w pliku
android.test.example.devcodelab.DevCodelabTest
i zastąp.
ciągiem/
:src/android/test/example/devcodelab/DevCodelabTest.java
Następnie edytuj
platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
aby zastąpić
Assert.assertTrue(false)
z
Assert.assertTrue(true)
Uruchom test jeszcze raz, aby sprawdzić, czy problem został rozwiązany:
atest DevCodelabTest
Przesyłanie kodu do sprawdzenia
Repo upraszcza korzystanie z Git przez połączenie poleceń, takich jak git clone
, w celu pracy w wielu repozytoriach Git (lub projektach) jednocześnie.
Omówienie usług Git i Repo znajdziesz w sekcji Source Control Tools (Narzędzia kontroli źródeł) wraz z linkami do pełnej dokumentacji pracy z kodem źródłowym Androida. Pełną listę projektów Git oraz poszczególnych projektów (ścieżek) gałęzi powiązanych z każdym projektem znajdziesz w repozytorium AOSP.
Do weryfikacji kodu projektów w Git będziesz używać internetowego systemu weryfikacji kodu Gerrit.
Zakładając, że zmiany zostały wprowadzone w projekcie
frameworks/native
, uruchom te polecenia, aby je przesłać:cd frameworks/native
repo start codelab .
git add .
git commit
W komunikacie zatwierdzenia wpisz:
Android codelab change Test: manual atest
Prześlij zmianę:
repo upload
W takim przypadku 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
Kliknij link podobny do tego:
https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432
To już koniec podstawowego ćwiczenia w programowaniu dotyczącego programowania platformy Androida. Informacje o kolejnych krokach znajdziesz w artykule Przesyłanie poprawek. Szczegółowe informacje na temat programowania na Androida znajdziesz w pozostałej części tej strony.
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 ćwiczenia z programowania cofnij listę zmian, klikając Porzuć w Gerrit.
Następnie porzuć powiązaną tymczasową gałąź w katalogu projektu frameworks/native
(lub jego podkatalogach):
repo abandon codelab .
Pamiętaj też, by cofnąć zmiany wprowadzone w pliku testowym. Zmiany nie zostały wprowadzone przez repo start
, git commit
i repo upload
, więc możesz zresetować sam plik. Jeśli jesteś w domenie aosp/platform_testing directory
, wykonaj te czynności, aby zresetować plik:
git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .
Na tym etapie to wszystko. Dobra robota!
Uzyskaj pomoc
Jeśli podczas tych ćwiczeń w programie wystąpią błędy, zgłoś je, korzystając z linku Issue Tracker u dołu dowolnej strony. Wyślij pytania do grupy android-building.