Możesz pomóc w opracowaniu najpowszechniej instalowanego systemu operacyjnego w historii Ziemi. Tak, jesteś tutaj, aby rozpocząć podróż i zostać inżynierem platformy Android.
Chociaż ścieżka jest trudna, zespół Androida stara się uprościć Twoją podróż w każdym wydaniu. A zespół codziennie wprowadza ulepszenia poprzez bezpośrednią pracę w projekcie Android Open Source Project (AOSP).
Usiądź wygodnie, odpal terminal i stwórzmy historię.
Cele
Misja tego laboratorium jest dwojaka:
- Aby dać ci mały przedsmak tego, jak wygląda przepływ pracy dewelopera dla inżynierów Androida pracujących na platformie (systemie operacyjnym).
- Zachęć do przekazywania opinii na temat narzędzi, dokumentacji i przepływu pracy programistów Androida.
Warunki wstępne
Lista wymagań dla tego ćwiczenia z programowania jest wyprowadzona z wymagań dotyczących rozwoju platformy ogólnej ( AOSP ). Aby wziąć udział w tym ćwiczeniu z programowania, skonfiguruj następujące elementy:
- Fizyczna stacja robocza z systemem Linux spełniająca wszystkie wymagania publiczne .
- Repo i konfiguracja Git wymagana do edycji bazy kodu Androida.
Środowisko
Zazwyczaj użytkownicy budują i rozwijają się bezpośrednio na stacji roboczej. Ponieważ możesz pracować w różnych terminalach, a wiele używanych poleceń jest specyficznych dla terminala, będziesz musiał je ponownie uruchomić w każdej sesji terminala. W szczególności są to polecenia source build/envsetup.sh
i lunch
.
Skonfiguruj stację roboczą
- Zainstaluj niezbędne pakiety na swojej stacji roboczej.
- Pozostając w terminalu, zainstaluj Repo i uzyskaj dane uwierzytelniające do wszystkich repozytoriów Git.
Zainicjuj i zsynchronizuj kod
Przejdź do swojego katalogu domowego:
cd ~
Utwórz w nim lokalny podkatalog roboczy:
mkdir aosp
Przejdź do katalogu:
cd aosp
Zainicjuj gałąź główną kodu źródłowego repozytorium AOSP (domyślnie):
repo init -u https://android.googlesource.com/platform/manifest
Wprowadź lub zaakceptuj swoje dane logowania do Git (imię i nazwisko, adres e-mail).
Zsynchronizuj kod źródłowy:
repo sync -j8
Początkowe synchronizacje mogą potrwać godzinę lub dłużej.
Każde wyewidencjonowanie repo jest reprezentowane przez plik manifestu . Dozwolone jest posiadanie więcej niż 1 kasy repo na raz, o ile istnieją one w odrębnych katalogach. Pamiętaj jednak, że każde wyewidencjonowanie i kompilacja zużywa około 300 GB (i rośnie), więc albo ogranicz się do 2 kas repo, albo rozszerz swój system o dodatkowy dysk.
Zbuduj kod
Aby zbudować system Android, musisz wybrać typ urządzenia docelowego do skompilowania za pomocą polecenia lunch
. Cel to permutacja urządzenia, taka jak określony model lub współczynnik kształtu.
Zawarte poniżej urządzenie docelowe, aosp_cf_x86_64_phone-userdebug
, umożliwia zbudowanie wirtualnego urządzenia Cuttlefish z systemem Android do testowania bez fizycznego urządzenia.
Aby zamiast tego zbudować i zaktualizować urządzenie fizyczne, wybierz inny cel i postępuj zgodnie z instrukcjami dotyczącymi urządzeń flashujących .
Skonfiguruj środowisko do kompilowania urządzeń z systemem Android, uruchamiając następujące polecenie z katalogu głównego kodu źródłowego:
source build/envsetup.sh
Przekaż cel kompilacji do polecenia lunch w następujący sposób:
lunch aosp_cf_x86_64_phone-userdebug
Zbuduj kod z dowolnego miejsca w kasie za pomocą:
m
Spodziewaj się, że pierwsza kompilacja zajmie kilka godzin. Kolejne kompilacje zajmują znacznie mniej czasu.
Utwórz instancję Acloud
Acloud to narzędzie wiersza poleceń w AOSP, które pomaga użytkownikom w tworzeniu wirtualnych urządzeń z Androidem, w tym przypadku Cuttlefish.
Jeśli jesteś w tej samej sesji terminala, w której skompilowano kod , kontynuuj. W przeciwnym razie uruchom ponownie skrypt envsetup.sh
i to samo polecenie lunch
, którego użyłeś jako pierwszy. Następnie
Utwórz lokalną instancję Acloud za pomocą:
acloud create --local-image --local-instance
Zaakceptuj aktualizacje wymaganych pakietów.
Jeśli pojawi się monit, uruchom ponownie stację roboczą, aby wszystkie zmiany odniosły skutek.
Wybierz urządzenie Mątwa.
Powinieneś zostać powitany sesją VNC zawierającą urządzenie z Androidem!
Możesz wchodzić w interakcję z urządzeniem wirtualnym na stacji roboczej za pomocą myszy i klawiatury. Możesz także śledzić aktywność w dziennikach podczas korzystania z urządzenia, używając polecenia logcat
Android Debug Bridge (adb):
adb logcat
Zmienić coś
Zaktualizuj kod źródłowy zgodnie z przykładową listą zmian .
Z katalogu głównego kasy (katalog
aosp/
) przejdź doframeworks/native
projektu Git:cd frameworks/native
Rozpocznij tymczasowy projekt za pomocą tego polecenia:
repo start <some-name> .
Edytuj
SurfaceFlinger.cpp
, aby uwzględnić aktualizacje z listy zmian w następującej lokalizacji:aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
Znajdź te dwie linie:
postFrame(); postComposition();
Zastąp te dwie linie następującymi:
postFrame(); postComposition(); 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}); updateColorMatrixLocked();
Zbuduj kod:
m
Zaktualizuj kompilację na urządzeniu:
adb root
adb remount
adb sync
adb reboot
acloud reconnect
Jeśli pojawi się monit o wybranie urządzenia, wybierz to, które pokazuje najkrótszy czas, jaki upłynął. (Jest to prawdopodobnie ostatnia na liście, którą widzisz.) Aby zobaczyć wszystkie instancje urządzeń wirtualnych, użyj
acloud list
iacloud list -v
.
Sprawdź, czy widzisz zmianę koloru na wybranym urządzeniu, podobnie jak na rysunku 1.
Rysunek 1. Wygląd ekranu po udanej zmianie koloru
Przetestuj swój kod
Ta część ćwiczenia z kodowania wykorzystuje przykładowy test, który znajduje się w drzewie źródłowym i kończy się niepowodzeniem. Zatrudnia to Atest do uruchamiania testu lokalnie i testowania kodu.
Aby skorzystać z testu, postępuj zgodnie z poniższymi instrukcjami:
Biegać:
atest DevCodelabTest
Test się nie powiedzie. Aby to naprawić, znajdź kod źródłowy nieudanego testu:
atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
Więc spójrz tutaj
platform_testing/tests/example/devcodelab
Aby pobrać plik do edycji, weź nazwę testu w
android.test.example.devcodelab.DevCodelabTest
i zastąp.
z/
, 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
zamienić
Assert.assertTrue(false)
z
Assert.assertTrue(true)
Uruchom test ponownie, aby sprawdzić, czy problem został rozwiązany:
atest DevCodelabTest
Prześlij swój kod do sprawdzenia
Repo upraszcza korzystanie z Git, łącząc polecenia, takie jak git clone
, w celu jednoczesnej pracy w wielu repozytoriach Git (lub projektach).
Zobacz Narzędzia kontroli źródła , aby zapoznać się z przeglądami Git i Repo, z łączami do pełnej dokumentacji dotyczącej pracy z kodem źródłowym systemu Android. Zobacz repozytorium AOSP , aby zapoznać się z pełną listą projektów Git i poszczególnych projektów (ścieżek) dla gałęzi powiązanych z każdym projektem.
Do przeglądu kodu projektów w Git użyjesz internetowego systemu przeglądu kodu Gerrit .
Zakładając, że dokonałeś zmian we
frameworks/native
, uruchom te polecenia, aby je przesłać:cd frameworks/native
repo start codelab .
git add .
git commit
W wiadomości o zatwierdzeniu wprowadź następujące informacje:
Android codelab change Test: manual atest
Prześlij swoją zmianę:
repo upload
Jeśli Ci się uda, zobaczysz komunikat podobny do tego:
Upload project frameworks/native/ to remote branch master:
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/master
Zobacz swoją zmianę w Gerrit
Przejdź do linku wydrukowanego w terminalu, który przypomina ten:
https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432
Na tym kończy się początkowe laboratorium kodowania dla rozwoju platformy Android. Zobacz Przesyłanie łatek , aby zapoznać się z kolejnymi krokami, a pełne informacje na temat tworzenia systemu Android można znaleźć w pozostałej części tej witryny.
Cofnij zmianę
Zwykle, po testowaniu, po przeglądzie i zatwierdzeniu, przesyłasz swoją zmianę w Gerrit i łączysz ją z repozytorium.
Zamiast tego, na potrzeby tego ćwiczenia z programowania, przywróć listę zmian, klikając opcję Porzuć w Gerrit.
Następnie porzuć powiązaną gałąź tymczasową w katalogu frameworks/native
projekt (lub jego podkatalogach):
repo abandon codelab .
Pamiętaj również o cofnięciu zmian dokonanych w pliku testowym. Ponieważ nie repo start
, git commit
i repo upload
zmiany, możesz zresetować sam plik. Zakładając, że znajdujesz się w katalogu aosp/platform_testing directory
, wykonaj następujące czynności, aby zresetować plik:
git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .
W tym momencie gotowe! Dobra robota!
Wezwać pomoc
Jeśli podczas tego ćwiczenia z programowania napotkasz błędy, zgłoś je, korzystając z linku do śledzenia problemów na dole dowolnej strony. Wysyłaj pytania do grupy budującej androidy .