Codelab per sviluppatori Android

Puoi contribuire a sviluppare il sistema operativo più installato nella storia dalla Terra. Sì, sei qui per intraprendere il viaggio per diventare un Android Platform Engineer.

Nonostante il percorso sia impegnativo, il team di Android si impegna a semplificare durante il loro percorso, in ogni versione. Il team apporta miglioramenti ogni giorno attraverso lavorare nell'Android Open Source Project (AOSP).

Quindi siediti, accendi un terminale e facciamo la storia.

Obiettivi

Lo scopo di questo codelab è duplice:

1. Per farti un'idea di come funziona il flusso di lavoro degli sviluppatori per gli ingegneri Android che lavorano sulla piattaforma (il sistema operativo).
2. Ti invitiamo a inviare un feedback sugli strumenti, sulla documentazione e sul flusso di lavoro degli sviluppatori di Android.

Prerequisiti

L'elenco dei requisiti per questo codelab deriva da quelli per uso generico di Google Cloud (AOSP). Per partecipare a questo codelab, configura quanto segue:

• Workstation Linux fisica che soddisfi tutti i requisiti pubblici.
• Repo e configurazione Git richiesti per la modifica il codebase Android.

Ambiente

In genere, gli utenti creano e sviluppano direttamente sulla workstation. Poiché potresti funzionare su vari terminali e molti dei comandi utilizzati sono specifici dovrai eseguirli nuovamente in ogni sessione del terminale. In particolare, sono inclusi i comandi source build/envsetup.sh e lunch.

Configurare la workstation

1. Installa i pacchetti necessari sul tuo la workstation.
2. Sempre in un terminale, installa Repo e ottieni le credenziali per tutti i repository Git.

Inizializza e sincronizza il codice

1. Passa alla tua home directory:

   cd ~

2. Crea una sottodirectory di lavoro locale al suo interno:

   mkdir aosp

3. Passa alla directory:

   cd aosp

4. Inizializza il ramo principale del codice sorgente del repository AOSP (predefinito):

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

5. Inserisci o accetta le tue credenziali Git (nome, indirizzo email).

6. Sincronizza il codice sorgente:

   repo sync -j8

Le sincronizzazioni iniziali possono richiedere un'ora o più.

Ogni pagamento dei repository è rappresentato da un file manifest. È consentito effettuare più di un pagamento dei repository alla volta, purché vengano esistono in directory distinte. Tuttavia, tieni presente che ogni pagamento e creazione di utilizzo di circa 300 GB (in continuo aumento), quindi limitarti a 2 pagamenti dei repository o arricchire il sistema con un'unità secondaria.

Crea il codice

Per compilare Android, devi selezionare un tipo di dispositivo target da compilare con il comando lunch. Un target è una permutazione di un dispositivo, ad esempio un modello o un fattore di forma specifico.

Il dispositivo target aosp_cf_x86_64_phone-userdebug ti consente per creare il dispositivo virtuale Android Cuttlefish senza un dispositivo fisico.

Per creare e aggiornare un dispositivo fisico, scegli un altro target e segui le istruzioni per i dispositivi lampeggianti.

1. Configura l'ambiente per la creazione di dispositivi Android eseguendo questo comando dalla radice di pagamento del codice sorgente:

   source build/envsetup.sh

2. Passa il target di build al comando pranzo in questo modo:

   lunch aosp_cf_x86_64_phone-trunk_staging-userdebug

3. Crea il codice da qualsiasi punto del tuo paga con:

   m

La prima build richiede ore. Le build successive richiedono significativamente in meno tempo.

Lancia seppia

Cuttlefish è l'emulatore Android utilizzato per testare le build.

1. Se non hai mai installato Seppia, devi installare l'app Dipendenze Cuttlefish. In una finestra del terminale, esegui questi comandi per scaricare, creare e installare i pacchetti Debian host:

   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

   Il riavvio attiva l'installazione di moduli kernel aggiuntivi e applica udev le regole del caso.

2. Avvia seppia:

   launch_cvd --daemon
   

3. Connettiti al dispositivo Seppia andando su https://localhost:8443 in nel browser web. Verrai accolto con un video stream del dispositivo che hai appena creato.

Effettua una modifica

Aggiorna il codice sorgente seguendo questo esempio di elenco di modifiche.

1. Dalla directory principale della procedura di pagamento (directory aosp/), vai alla sezione Progetto Git frameworks/native:

   cd frameworks/native

2. Avvia un progetto temporaneo con questo comando:

   repo start <some-name> .

3. Modifica SurfaceFlinger.cpp in modo da includere gli aggiornamenti del file changelist nella seguente posizione:

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

4. Trova questa riga:

   void SurfaceFlinger::updateColorMatrixLocked() {
   

5. Aggiungi queste due righe all'inizio di 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. Crea il codice:

   m

7. Aggiorna la build sul dispositivo:

   adb root
   adb remount
   adb sync
   adb reboot

Verifica che sul dispositivo selezionato appaia un cambiamento di colore simile a quello mostrato come mostrato nella Figura 1.

Figura 1. Aspetto dello schermo dopo una corretta modifica del colore

Testa il codice

Questa parte del codelab utilizza un test di esempio presente nell'albero del codice sorgente e non riesce. Viene utilizzato Atest per il test in locale e testare il codice.

Per utilizzare il test, segui queste istruzioni:

1. Corsa:

   atest DevCodelabTest

2. Il test avrà esito negativo. Esamina l'analisi dello stack del test non riuscito:

   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)

3. Quindi guarda qui

   platform_testing/tests/example/devcodelab
   

4. Per richiedere la modifica del file, inserisci il nome del test in android.test.example.devcodelab.DevCodelabTest e sostituisci . con /, per ottenere questo risultato:

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

5. Quindi modifica

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

   per sostituire

   Assert.assertTrue(false)
   

   con

   Assert.assertTrue(true)
   

6. Esegui di nuovo il test per verificare di aver risolto il problema:

   atest DevCodelabTest

Carica il codice per la revisione

Il repository semplifica l'utilizzo di Git raggruppando i comandi come git clone in modo che funzionino in numerosi repository (o progetti) Git contemporaneamente.

Consulta la sezione Strumenti di controllo del codice sorgente per una panoramica di Git e Repo, con link alla documentazione completa per l'utilizzo del codice sorgente di Android. Consulta il repository AOSP per visualizzare l'elenco completo dei progetti Git e i singoli progetti (percorsi) e i rami associati a ogni progetto.

Per la revisione del codice dei tuoi progetti in Git, utilizzerai il comando Gerrit di revisione del codice basato sul web.

1. Supponendo che tu abbia apportato le modifiche nel progetto frameworks/native, esegui questi comandi per caricarle:

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

2. Inserisci quanto segue per il messaggio di commit:

   Android codelab change
   Test: manual atest
   

3. Carica la modifica:

   repo upload

Se l'operazione è andata a buon fine, verrà visualizzato un messaggio simile a questo:

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

Visualizza la tua modifica in Gerrit

Vai al link, stampato nel terminale, simile a questo:

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

Qui si completa il codelab iniziale per lo sviluppo della piattaforma Android. Consulta Inviare patch per i passaggi successivi e per i dettagli completi sullo sviluppo di Android, guarda il resto del questo sito.

Ripristina la modifica

Normalmente, dopo il test e dopo la revisione e l'approvazione, invii la modifica in Gerrit e la unisci al repository.

Ai fini di questo codelab, ripristina l'elenco modifiche facendo clic su Abbandona in Gerrit.

Abbandona il ramo temporaneo associato nel progetto frameworks/native (o relative sottodirectory):

repo abandon codelab .

Ricorda di ripristinare le modifiche apportate al file di test. Poiché non repo start, git commit e repo upload la modifica, puoi reimpostare . Supponendo che tu stia utilizzando aosp/platform_testing directory, procedi come segue per reimpostare il file:

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

A questo punto, hai finito. Ben fatto!

Ricevi assistenza

Se si verificano errori durante questo codelab, segnalali utilizzando il Issue Tracker nella parte inferiore di qualsiasi pagina. Invia domande al costruire-android gruppo.