Laboratorium programowania dla programistów Androida

Możesz pomóc w opracowaniu najpowszechniej instalowanego systemu operacyjnego w historii Ziemi. Tak, jesteś tutaj, aby rozpocząć przygodę z inżynierem platformy Android.

Chociaż ścieżka jest trudna, zespół Androida stara się uprościć Twoją podróż w każdym wydaniu. Zespół codziennie wprowadza ulepszenia dzięki bezpośredniej pracy w projekcie Android Open Source Project (AOSP).

Usiądź wygodnie, odpal terminal i stwórzmy historię.

Cele

Misja tego laboratorium jest dwojaka:

1. 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).
2. Zachęcam, aby zapewnić informacje zwrotne wokół Android narzędzi, dokumentacji i przepływ pracy programisty.

Warunki wstępne

Lista wymagań dla tej codelab pochodzą od tych, dla ogólnego platformy ( AOSP ) rozwoju. Aby wziąć udział w tym ćwiczeniu z programowania, skonfiguruj następujące elementy:

• Fizyczne Linux Workstation spełniając wszystkie wymagania publicznych .
• Repo i konfiguracja Git edycją Android bazę kodu.

Środowisko

Zazwyczaj użytkownicy budują i rozwijają się bezpośrednio na stacji roboczej. Ponieważ możesz pracować w różnych terminalach, a wiele z używanych poleceń jest specyficznych dla terminala, będziesz musiał je ponownie uruchamiać w każdej sesji terminala. W szczególności, obejmują one source build/envsetup.sh i lunch poleceń.

Skonfiguruj stację roboczą

1. Zainstalować niezbędne pakiety na stacji roboczej.
2. O ile jeszcze w terminalu, zainstalować repo i uzyskanie poświadczenia dla wszystkich repozytoriów Git.

Zainicjuj i zsynchronizuj kod

1. Przejdź do swojego katalogu domowego:

   cd ~
   

2. Utwórz w nim lokalny podkatalog roboczy:

   mkdir aosp
   

3. Przejdź do katalogu:

   cd aosp
   

4. Zainicjuj gałąź główną kodu źródłowego repozytorium AOSP (domyślnie):

   repo init -u https://android.googlesource.com/platform/manifest
   

5. Wprowadź lub zaakceptuj swoje dane logowania do Git (imię i nazwisko, adres e-mail).

6. Zsynchronizuj kod źródłowy:

   repo sync -j8
   

Początkowe synchronizacje mogą potrwać godzinę lub dłużej. Zobacz instrukcje pobierania do powiązanych informacji na poczekaniu.

Każda kasa repo jest reprezentowany przez pliku manifestu . Dozwolone jest posiadanie więcej niż 1 kasy repo na raz, o ile znajdują się one w odrębnych katalogach. Pamiętaj jednak, że każde wymeldowanie 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ć Android, należy wybrać docelowy typ urządzenia, aby zbudować z lunch polecenia. Cel to permutacja urządzenia, taka jak określony model lub współczynnik kształtu.

Docelowa urządzenie włączone poniżej aosp_cf_x86_64_phone-userdebug , pozwala budować Mątwy wirtualnego urządzenia z Androidem do testowania bez fizycznego urządzenia.

Aby zbudować i zamiast zaktualizować fizycznego urządzenia, wybrać inny cel i postępuj zgodnie z instrukcjami urządzenia miga .

1. Skonfiguruj środowisko do kompilowania urządzeń z systemem Android, uruchamiając następujące polecenie w katalogu głównym kodu źródłowego:

   source build/envsetup.sh
   

2. Przekaż cel kompilacji do polecenia lunch w następujący sposób:

   lunch aosp_cf_x86_64_phone-userdebug
   

3. Budowanie kod z dowolnego miejsca w kasie z:

   m
   

Spodziewaj się, że pierwsza kompilacja zajmie kilka godzin. Kolejne kompilacje zajmują znacznie mniej czasu.

Utwórz instancję Acloud

Acloud jest narzędziem wiersza polecenia w AOSP który pomaga użytkownikom w tworzeniu wirtualnych urządzeń z Androidem, w tym przypadku Mątwy.

Jeśli jesteś w tej samej sesji terminala użytego do budowy kodu postępować. W przeciwnym razie uruchom ponownie envsetup.sh skrypt i ten sam lunch polecenie użyte tam pierwszy. Następnie

1. Utwórz lokalną instancję Acloud za pomocą:

   acloud create --local-image --local-instance
   

2. Zaakceptuj aktualizacje wymaganych pakietów.

3. Jeśli pojawi się monit, uruchom ponownie stację roboczą, aby wszystkie zmiany odniosły skutek.

4. 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żna również śledzić aktywność w dziennikach podczas korzystania z urządzenia poprzez zastosowanie Android Debug Bridge (ADB) logcat polecenie:

adb logcat

Zmienić coś

Aktualizacja kodu źródłowego zgodnie z następującym przykładem listy zmian .

1. Z korzenia swojej kasie ( aosp/ katalog), przejdź do frameworks/native projektu Git:

   cd frameworks/native
   

2. Rozpocznij tymczasowy projekt za pomocą tego polecenia:

   repo start <some-name> .
   

3. Edycja SurfaceFlinger.cpp zawierać aktualizacje z listy zmian w następującej lokalizacji:

   aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
   

4. Znajdź te dwie linie:

   postFrame();
   postComposition();
   

5. 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();
   

6. Zbuduj kod:

   m
   

7. Zaktualizuj kompilację na urządzeniu:

   adb root
   adb remount
   adb sync
   adb reboot
   acloud reconnect
   

8. 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 widać). Aby zobaczyć wszystkie instancje wirtualne urządzenie, użyj acloud list i acloud list -v poleceń.

Sprawdź, czy widzisz zmianę koloru na wybranym urządzeniu, podobnie jak na rysunku 1.

Rysunek 1. Wygląd ekranu po udanej zmianie kolorów

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. To zatrudnia ATEST za prowadzenie testów lokalnie i testowanie kodu.

Aby skorzystać z testu, postępuj zgodnie z poniższymi instrukcjami:

1. Biegać:

   atest DevCodelabTest
   

2. Test się nie powiedzie. Aby to naprawić, znajdź kod źródłowy nieudanego testu:

   atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
   

3. Więc spójrz tutaj

   platform_testing/tests/example/devcodelab
   

4. Aby pobrać plik do edycji, wziąć nazwę testu w android.test.example.devcodelab.DevCodelabTest i wymienić . z / , aby uzyskać ten wynik:

   src/android/test/example/devcodelab/DevCodelabTest.java
   

5. Następnie edytuj

   platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
   

   zamienić

   Assert.assertTrue(false)
   

   z

   Assert.assertTrue(true)
   

6. Uruchom test ponownie, aby sprawdzić, czy problem został rozwiązany:

   atest DevCodelabTest
   

Prześlij swój kod do sprawdzenia

Repo Git upraszcza wykorzystanie przez łączenie poleceń takich jak git clone do pracy w całej wielu repozytoriów Git (lub projektów) naraz.

Zobacz Narzędzia kontroli źródła dla przeglądów i Git repo z linkami do pełnej dokumentacji na temat pracy z kodem źródłowym Androida. Zobacz repozytorium AOSP dla pełnej listy projektów Git i poszczególnych projektów (ścieżki) dla branż związanych z każdym projektem.

Dla przeglądu kodu swoich projektów w Git, będziesz używać Gerrit internetowy system oceny kod.

1. Zakładając, że dokonane zmiany w frameworks/native projektu, uruchom następujące polecenia, aby je przesłać:

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

2. W wiadomości o zatwierdzeniu wprowadź następujące informacje:

   Android codelab change
   Test: manual atest
   

3. 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 zgłaszając łatki do kolejnych etapów, a dla pełnych szczegółów na rozwijanie android, zobaczyć resztę tej strony.

Cofnij zmianę

Zwykle, po testach, po przeglądzie i zatwierdzeniu, przesyłasz swoją zmianę w Gerrit i łączysz ją z repozytorium.

Zamiast tego, dla celów niniejszego codelab, przywrócić swoje listy zmian, klikając Abandon w Gerrit.

Następnie porzucić powiązanych tymczasowy oddział w frameworks/native katalogu projektu (lub jego podkatalogów):

repo abandon codelab .

Pamiętaj również o cofnięciu zmian dokonanych w pliku testowym. Ponieważ nie repo start , git commit i repo upload zmianę, można zresetować sam plik. Zakładając, że jesteś w aosp/platform_testing directory użyć następujących czynności, aby przywrócić plik:

git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .

W tym momencie gotowe! Dobra robota!

Uzyskać pomoc

W przypadku napotkania błędów podczas tej codelab, zgłoś je za pomocą Issue Tracker link na dole każdej strony. Wyślij zapytanie do android-budowlanej grupy.