Codelab per sviluppatori Android

Puoi aiutare a sviluppare il sistema operativo più installato nella storia della Terra. Sì, sei qui per intraprendere il viaggio per diventare un ingegnere di piattaforma Android.

Sebbene il percorso sia impegnativo, il team di Android si impegna a semplificare il tuo viaggio, ogni versione. E il team apporta miglioramenti ogni giorno attraverso il lavoro diretto nell'Android Open Source Project (AOSP).

Quindi siediti, accendi un terminale e facciamo la storia.

Obiettivi

La missione di questo codelab è duplice:

  1. Per darti un piccolo assaggio di come è il flusso di lavoro degli sviluppatori per gli ingegneri Android che lavorano sulla piattaforma (il sistema operativo).
  2. Ti incoraggia a fornire feedback sugli strumenti, la documentazione e il flusso di lavoro degli sviluppatori di Android.

Prerequisiti

L'elenco dei requisiti per questo codelab deriva da quelli per lo sviluppo di piattaforme generali ( AOSP ). Per prendere questo codelab, imposta quanto segue:

Ambiente

In genere, gli utenti creano e sviluppano direttamente sulla workstation. Poiché potresti lavorare in vari terminali e molti dei comandi utilizzati sono specifici del terminale, dovrai eseguirli nuovamente in ciascuna sessione del terminale. In particolare, questi includono i comandi source build/envsetup.sh e lunch di origine.

Configurare la postazione di lavoro

  1. Installa i pacchetti necessari sulla tua workstation.
  2. Mentre sei ancora in un terminale, installa Repo e ottieni le credenziali per tutti i repository Git.

Inizializza e sincronizza il codice

  1. Naviga nella tua home directory:

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

    mkdir aosp
    
  3. Naviga nella directory:

    cd aosp
    
  4. Inizializza il ramo principale del codice sorgente del repository AOSP (impostazione predefinita):

    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 checkout del repository è rappresentato da un file manifest . È consentito avere più di 1 checkout di repository alla volta, purché esistano in directory distinte. Ma tieni presente che ogni checkout e build ammonta a circa 300 GB di utilizzo (e in crescita), quindi limitati a 2 checkout repo o aumenta il tuo sistema con un'unità secondaria.

Costruisci il codice

Per creare Android, devi selezionare un tipo di dispositivo di destinazione da creare con il comando lunch . Una destinazione è una permutazione del dispositivo, ad esempio un modello o un fattore di forma specifico.

La destinazione del dispositivo inclusa di seguito, aosp_cf_x86_64_phone-userdebug , consente di creare il dispositivo Android virtuale Cuttlefish per il test senza un dispositivo fisico.

Per creare e aggiornare invece un dispositivo fisico, scegli un'altra destinazione e segui le istruzioni per il flashing dei dispositivi .

  1. Configura il tuo ambiente per la creazione di dispositivi Android eseguendo il comando seguente dalla radice del checkout del codice sorgente:

    source build/envsetup.sh
    
  2. Passa la destinazione di compilazione al comando pranzo, in questo modo:

    lunch aosp_cf_x86_64_phone-userdebug
    
  3. Crea il codice da qualsiasi punto del tuo checkout con:

    m
    

Aspettati che la prima build richieda ore. Le build successive richiedono molto meno tempo.

Crea un'istanza Acloud

Acloud è uno strumento da riga di comando in AOSP che assiste gli utenti nella creazione di dispositivi Android virtuali, in questo caso Cuttlefish.

Se ti trovi nella stessa sessione del terminale utilizzata per creare il codice , procedi. Altrimenti, esegui nuovamente lo script envsetup.sh e lo stesso comando lunch che hai usato per primo. Quindi

  1. Crea un'istanza locale Acloud con:

    acloud create --local-image --local-instance
    
  2. Accetta gli aggiornamenti ai pacchetti richiesti.

  3. Se richiesto, riavviare la workstation per rendere effettive tutte le modifiche.

  4. Seleziona il dispositivo Seppie.

Dovresti essere accolto con una sessione VNC contenente un dispositivo Android!

Puoi interagire con il dispositivo virtuale sulla tua workstation utilizzando il mouse e la tastiera. Puoi anche seguire l'attività all'interno dei log mentre usi il tuo dispositivo utilizzando il comando logcat di Android Debug Bridge (adb):

adb logcat

Fare un cambiamento

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

  1. Dalla radice del tuo checkout ( aosp/ directory), vai al frameworks/native :

    cd frameworks/native
    
  2. Avvia un progetto temporaneo con questo comando:

    repo start <some-name> .
    
  3. Modifica SurfaceFlinger.cpp per includere gli aggiornamenti dall'elenco delle modifiche nella posizione seguente:

    aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
    
  4. Trova queste due righe:

    postFrame();
    postComposition();
    
  5. Sostituisci queste due righe con le seguenti:

    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. Costruisci il codice:

    m
    
  7. Aggiorna la build sul dispositivo:

    adb root
    adb remount
    adb sync
    adb reboot
    acloud reconnect
    
  8. Se ti viene chiesto di selezionare un dispositivo, scegli quello che mostra il tempo trascorso più breve. (Questo è probabilmente l'ultimo nell'elenco che vedi.) Per vedere tutte le istanze del dispositivo virtuale, usa i acloud list e acloud list -v .

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

Example of a successful color change

Figura 1. Aspetto dello schermo dopo il cambio colore riuscito

Metti alla prova il tuo codice

Questa parte del codelab utilizza un test di esempio che si trova nell'albero dei sorgenti e non riesce. Questo utilizza Atest per eseguire il test in locale e testare il codice.

Per utilizzare il test, segui queste istruzioni:

  1. Correre:

    atest DevCodelabTest
    
  2. Il test fallirà. Per risolverlo, trova il codice sorgente del test non riuscito:

    atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
    
  3. Allora guarda qui

    platform_testing/tests/example/devcodelab
    
  4. Per ottenere il file da modificare, prendi il nome del test in android.test.example.devcodelab.DevCodelabTest e sostituisci il file . 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
    

    Rimpiazzare

    Assert.assertTrue(false)
    

    insieme a

    Assert.assertTrue(true)
    
  6. Esegui nuovamente il test per verificare di aver risolto il problema:

    atest DevCodelabTest
    

Carica il tuo codice per la revisione

Repo semplifica l'utilizzo di Git raggruppando comandi come git clone per funzionare su numerosi repository (o progetti) Git contemporaneamente.

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

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

  1. Supponendo che tu abbia apportato le modifiche al frameworks/native , esegui questi comandi per caricarli:

    cd frameworks/native
    repo start codelab .
    git add .
    git commit
    
  2. Per il tuo messaggio di commit, inserisci quanto segue:

    Android codelab change
    Test: manual atest
    
  3. Carica la tua modifica:

    repo upload
    

Se hai successo, vedrai un messaggio simile a questo:

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

Visualizza la tua modifica in Gerrit

Vai al link, stampato nel terminale, che assomiglia a questo:

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

Questo completa il codelab di partenza per lo sviluppo della piattaforma Android. Vedere Invio di patch per i passaggi successivi e per i dettagli completi sullo sviluppo di Android, vedere il resto di questo sito.

Annulla la modifica

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

Invece, ai fini di questo codelab, ripristina la tua lista delle modifiche facendo clic su Abbandona in Gerrit.

Quindi abbandona il ramo temporaneo associato nella directory frameworks/native project (o nelle sue sottodirectory):

repo abandon codelab .

Ricorda inoltre di ripristinare le modifiche apportate al file di prova. Dal momento che non hai repo start , git commit e repo upload la modifica, puoi reimpostare il file stesso. Supponendo che ti trovi nella aosp/platform_testing directory , usa quanto segue per ripristinare il file:

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

A questo punto il gioco è fatto! Bel lavoro!

Ottenere aiuto

Se riscontri errori durante questo codelab, segnalali utilizzando il link Issue Tracker nella parte inferiore di qualsiasi pagina. Invia domande al gruppo di costruzione di Android .