Puoi contribuire a sviluppare il sistema operativo più installato nella storia della Terra. Sì, sei qui per intraprendere il viaggio per diventare un Android Platform Engineer.
Anche se il percorso è impegnativo, il team di Android si impegna a semplificare il tuo percorso, a ogni release. 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:
- Per farti un'idea di come funziona il flusso di lavoro degli sviluppatori per gli ingegneri Android che lavorano sulla piattaforma (il sistema operativo).
- Ti invitiamo a fornire feedback su strumenti, documentazione e flusso di lavoro per sviluppatori di Android.
Prerequisiti
L'elenco dei requisiti per questo codelab deriva da quelli per uso generico di Google Cloud (AOSP). Per seguire questo codelab, configura quanto segue:
- Workstation Linux fisica che soddisfi tutti i requisiti pubblici.
- Repository e configurazione Git necessari per modificare il codebase di Android.
Ambiente
In genere, gli utenti creano e sviluppano direttamente sulla workstation. Poiché potresti lavorare su vari terminali e molti dei comandi utilizzati sono specifici del terminale, dovrai eseguirli di nuovo in ogni sessione del terminale. In particolare,
sono inclusi i comandi source build/envsetup.sh
e lunch
.
Configura workstation
- Installa i pacchetti necessari sulla tuaworkstation.
- Sempre in un terminale, installa Repo e ottieni le credenziali per tutti i repository Git.
Inizializza e sincronizza il codice
Vai alla tua home directory:
cd ~
Crea una sottodirectory di lavoro locale al suo interno:
mkdir aosp
Passa alla directory:
cd aosp
Inizializza il ramo principale del codice sorgente del repository AOSP (predefinito):
repo init -u https://android.googlesource.com/platform/manifest
Inserisci o accetta le tue credenziali Git (nome, indirizzo email).
Sincronizza il codice sorgente:
repo sync -j8
Le sincronizzazioni iniziali possono richiedere un'ora o più.
Ogni controllo del repo è rappresentato da un file manifest. È consentito avere più di un controllo del repository alla volta, a condizione che esistano 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.
Compila il codice
Per sviluppare Android, devi selezionare un target
tipo di dispositivo da creare 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 il flashing dei dispositivi.
Configura l'ambiente per la creazione di dispositivi Android eseguendo questo comando dalla radice di pagamento del codice sorgente:
source build/envsetup.sh
Passa il target di build al comando pranzo in questo modo:
lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
Crea il codice da qualsiasi punto del tuo paga con:
m
La prima compilazione potrebbe richiedere ore. Le build successive richiedono moltissimo in meno tempo.
Lancia seppia
Cuttlefish è l'emulatore Android utilizzato per testare le build.
Se non hai mai installato Cuttlefish, devi installare le dipendenze di Cuttlefish necessarie. In una finestra del terminale, esegui i seguenti comandi per scaricare, compilare e installare i pacchetti Debian dell'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 del kernel aggiuntivi e applica le regole
udev
.Avvia Seppia:
launch_cvd --daemon
Connettiti al dispositivo Seppia andando su
https://localhost:8443
in nel browser web. Viene visualizzato uno stream video del dispositivo Android appena creato.
Effettua una modifica
Aggiorna il codice sorgente seguendo questo esempio di elenco di modifiche.
Dalla directory principale del checkout (directory
aosp/
), vai al progetto Gitframeworks/native
:cd frameworks/native
Avvia un progetto temporaneo con questo comando:
repo start <some-name> .
Modifica
SurfaceFlinger.cpp
per includere gli aggiornamenti dell'elenco modifiche nel seguente luogo:aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
Trova questa riga:
void SurfaceFlinger::updateColorMatrixLocked() {
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});
Crea il codice:
m
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 la modifica del colore
Testa il codice
Questa parte del codelab utilizza un test di esempio che si trova nella struttura ad albero della sorgente e non va a buon fine. Viene utilizzato Atest per eseguire il test localmente e testare il codice.
Per utilizzare il test, segui queste istruzioni:
Corsa:
atest DevCodelabTest
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)
Quindi guarda qui
platform_testing/tests/example/devcodelab
Per ottenere il file da modificare, prendi il nome del test in
android.test.example.devcodelab.DevCodelabTest
e sostituisci.
con/
, per ottenere questo risultato:src/android/test/example/devcodelab/DevCodelabTest.java
Quindi modifica
platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
per sostituire
Assert.assertTrue(false)
con
Assert.assertTrue(true)
Esegui di nuovo il test per verificare di aver risolto il problema:
atest DevCodelabTest
Carica il codice per la revisione
Repo semplifica l'utilizzo di Git raggruppando comandi come git clone
per lavorare su 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 l'elenco completo dei progetti Git e dei singoli progetti (percorsi) per i branch associati a ciascun progetto.
Per la revisione del codice dei tuoi progetti in Git, utilizzerai il sistema di revisione del codice basato su web Gerrit.
Supponendo che tu abbia apportato le modifiche al progetto
frameworks/native
, esegui questi comandi per caricarli:cd frameworks/native
repo start codelab .
git add .
git commit
Per il messaggio di commit, inserisci quanto segue:
Android codelab change Test: manual atest
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
Visualizzare la modifica in Gerrit
Vai al link stampato nel terminale, simile a questo:
https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432
Questo completa il codelab introduttivo 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.
Per gli scopi di questo codelab, ripristina il tuo elenco di modifiche facendo clic su Abbandona in Gerrit.
Quindi, abbandona il ramo temporaneo associato nella directory del progetto frameworks/native
(o nelle relative sottodirectory):
repo abandon codelab .
Ricorda anche di ripristinare le modifiche apportate al file di test. Poiché non
repo start
, git commit
e repo upload
la modifica, puoi reimpostare
. Se ti trovi in aosp/platform_testing directory
, usa
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 riscontri errori durante questo codelab, segnalali utilizzando il link al tracker dei problemi in fondo a qualsiasi pagina. Invia domande al costruire-android gruppo.