Możesz pomóc stworzyć najpopularniejszy system operacyjny w historii całej Ziemi. Tak, jesteś tu, aby rozpocząć swoją przygodę z stanowiskiem inżyniera platformy Android.
Choć jest to trudne, zespół Androida stara się przy każdej publikacji. Zespół codziennie wprowadza ulepszenia w ramach Projektu Android Open Source (AOSP).
Usiądź wygodnie, uruchom terminal i zostań częścią historii.
Cele
Celem tego ćwiczenia jest:
- Aby pokazać Ci, jak wygląda proces programowania w przypadku inżynierów Androida pracujących nad platformą (systemem operacyjnym).
- Zachęcamy do przesyłania opinii na temat narzędzi, dokumentacji i przepływu pracy dewelopera na Androidzie.
Wymagania wstępne
Lista wymagań tego ćwiczenia z programowania pochodzi od wymagań ogólnych (AOSP). Aby wykonać to ćwiczenie z programowania, skonfiguruj te elementy:
- stacja robocza z systemem Linux spełniająca wszystkie wymagania dotyczące dostępności;
- Repozytorium i konfiguracja Git wymagane do edycji dla bazy kodu Androida.
Środowisko
Zazwyczaj użytkownicy budują i rozwijają aplikacje bezpośrednio na stacji roboczej. Ponieważ możesz pracować w różnych terminalach, a wiele poleceń jest specyficznych dla danego terminala, musisz je ponownie uruchomić w każdej sesji terminala. Konkretnie:
w tym polecenia source build/envsetup.sh
i lunch
.
Konfigurowanie stacji roboczej
- Zainstaluj niezbędne pakiety na stacji roboczej.
- Nie opuszczając terminala, zainstaluj Repo i zyskaj dane logowania. do wszystkich repozytoriów Git.
Inicjowanie i synchronizacja 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 dane logowania do Git (nazwę i adres e-mail).
Zsynchronizuj kod źródłowy:
repo sync -j8
Pierwsza synchronizacja może potrwać godzinę lub dłużej.
Każde pobranie repozytorium jest reprezentowane przez plik manifestu. Dozwolone jest używanie więcej niż 1 płatności w repozytorium jednocześnie, pod warunkiem że które istnieją w osobnych katalogach. Pamiętaj jednak, że każda płatność i kompilacja równa się wykorzystanie około 300 GB (i rosną), więc ogranicz do 2 procesów płatności repozytorium, lub rozbudowywać system za pomocą dysku dodatkowego.
Kompilowanie kodu
Aby utworzyć Androida, musisz wybrać wartość docelową
typu urządzeń, które chcesz utworzyć za pomocą polecenia lunch
. Cel to permutacja urządzenia,
na przykład konkretnego modelu lub formatu.
Docelowe urządzenie aosp_cf_x86_64_phone-userdebug
umożliwia tworzenie wirtualnego urządzenia z Androidem Cuttlefish na potrzeby testowania bez fizycznego urządzenia.
Aby zbudować i zaktualizować fizyczne urządzenie, wybierz inny cel i postępuj zgodnie z instrukcjami dotyczącymi aktualizowania urządzeń.
Skonfiguruj środowisko do kompilowania aplikacji na urządzenia z Androidem, uruchamiając to polecenie w katalogu głównym pobranej wersji kodu źródłowego:
source build/envsetup.sh
Przekaż docelowe środowisko kompilacji do polecenia lunch, na przykład:
lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
Utwórz kod z dowolnego miejsca zapłać za pomocą:
m
Pierwsza kompilacja może potrwać kilka godzin. Kolejne kompilacje zajmują znacznie mniej czasu.
Wystrzel mątwy
Cuttlefish to emulator Androida używany do testowania kompilacji.
Jeśli aplikacja Cuttlefish nie została nigdy przez Ciebie zainstalowana, musisz zainstalować niezbędne Zależności mątwy. W oknie terminala uruchom te polecenia, aby pobrać, skompilować i zainstalować hostowe 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 zasadę
udev
. reguł.Uruchom Mątwę:
launch_cvd --daemon
Połącz się z urządzeniem mątwy, przechodząc na stronę
https://localhost:8443
w przeglądarki. Pojawi się strumień wideo z urządzenia z Androidem, które właśnie zbudowałeś/zbudowałaś.
Wprowadź zmianę
Zaktualizuj kod źródłowy, postępując zgodnie z tą przykładową listą zmian.
W katalogu głównym checkoutu (katalogu
aosp/
) przejdź do projektu Gitframeworks/native
:cd frameworks/native
Uruchom projekt tymczasowy za pomocą tego polecenia:
repo start <some-name> .
Kliknij Edytuj
SurfaceFlinger.cpp
, aby uwzględnić aktualizacje z listy zmian w tym miejscu:aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
Znajdź ten wiersz:
void SurfaceFlinger::updateColorMatrixLocked() {
Dodaj te 2 wiersze na początku funkcji 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 wersję na urządzeniu:
adb root
adb remount
adb sync
adb reboot
Sprawdź, czy na wybranym urządzeniu widzisz zmianę koloru podobną do tej na rysunku 1.
Rysunek 1. Wygląd ekranu po pomyślnej zmianie kolorów
Testowanie kodu
W tej części tego Codelab wykorzystano przykładowy test, który znajduje się w drzewie źródłowym i nie przechodzi. W tym celu użyjesz narzędzia Atest do przeprowadzania testów lokalnie i testowania kodu.
Aby skorzystać z testu, postępuj zgodnie z tymi instrukcjami:
Uruchom:
atest DevCodelabTest
Test się nie powiedzie. Sprawdź zrzut stosu niezaliczonego 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)
Następnie spójrz tutaj
platform_testing/tests/example/devcodelab
Aby pobrać plik do edycji, wpisz nazwę testu w
android.test.example.devcodelab.DevCodelabTest
i zastąp.
elementem/
, aby uzyskać ten wynik: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 ponownie, aby sprawdzić, czy problem został rozwiązany:
atest DevCodelabTest
Przesyłanie kodu do sprawdzenia
Repozytorium upraszcza korzystanie z Git, dzięki łączeniu poleceń w pakiecie, takich jak git clone
, w celu ich działania
w wielu repozytoriach Git (lub projektach) jednocześnie.
Zapoznaj się z artykułami Source Control Tools, aby zapoznać się z omówieniem Git i Repo oraz linki do pełnej dokumentacji pracy z kodem źródłowym Androida. Zobacz repozytorium AOSP pełnej listy projektów Git i poszczególnych projektów (ścieżek) gałęzie powiązane z każdym projektem.
Do sprawdzania kodu w projektach w Git będziesz używać internetowego systemu sprawdzania kodu Gerrit.
Przy założeniu, że zmiany zostały wprowadzone w projekcie
frameworks/native
, uruchom polecenie za pomocą tych poleceń: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 tego podstawowego ćwiczenia na temat tworzenia aplikacji na platformę Android. Zobacz Przesyłanie poprawek , a szczegółowe informacje o tworzeniu Androida znajdziesz w pozostałych tę witrynę.
Cofnij zmianę
Zazwyczaj po przeprowadzeniu testów, a także po sprawdzeniu i zatwierdzeniu przez użytkownika należy przesłać zmiany w Zaszyfruj plik i scal go z repozytorium.
Na potrzeby tego ćwiczenia z programowania cofnij listę zmian, klikając Porzuć w Gerrit.
Następnie porzuć powiązaną tymczasową gałąź w projekcie frameworks/native
(lub jego podkatalogi):
repo abandon codelab .
Pamiętaj też, by cofnąć zmiany wprowadzone w pliku testowym. Ponieważ nie udało Ci się
repo start
, git commit
i repo upload
tę zmianę, możesz zresetować
pliku. Zakładając, że używasz wersji 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 .
To już wszystko. Dobra robota!
Pomoc
Jeśli podczas tych ćwiczeń w programie wystąpią błędy, zgłoś je za pomocą Narzędzie do śledzenia problemów na dole dowolnej strony. Wyślij pytania do tworzenie Androida grupy reklam.