Costruire Android

Segui queste istruzioni per iniziare a creare Android.

Impostazione dell'ambiente

Inizializza l'ambiente con lo script envsetup.sh :

source build/envsetup.sh

O

. build/envsetup.sh

Consulta lo script su platform/build/envsetup.sh per le descrizioni dei comandi correlati, incluso il pranzo per selezionare le destinazioni del dispositivo e i tapas per creare app non raggruppate, come l' app TV di riferimento .

È necessario emettere nuovamente questo comando dopo ogni repo sync per acquisire eventuali modifiche allo script. Tieni presente che sostituendo source con . (un singolo punto) consente di risparmiare alcuni caratteri e la forma breve è più comunemente utilizzata nella documentazione.

Lo script envsetup.sh importa diversi comandi che consentono di lavorare con il codice sorgente Android, inclusi i comandi utilizzati in questo esercizio.

Per visualizzare l'elenco completo dei comandi disponibili, eseguire:

hmm

Scegliere un obiettivo

pranzo

Scegli quale target costruire con lunch . lunch product_name - build_variant seleziona product_name come prodotto da creare e build_variant come variante da creare e memorizza tali selezioni nell'ambiente per essere lette dalle successive invocazioni di m e altri comandi simili.

La configurazione esatta può essere passata come argomento. Ad esempio, il seguente comando si riferisce a una build completa per l'emulatore, con tutto il debug abilitato:

lunch aosp_arm-eng

Se eseguito senza argomenti, lunch ti chiede di scegliere un obiettivo dal menu, ma tieni presente che il menu non include tutte le possibilità. Vedi Selezione di una build di dispositivo per le configurazioni di build di tutti i dispositivi supportati in AOSP oppure parla con le persone del tuo team del pranzo corretto per il dispositivo su cui stai lavorando.

Tutti gli obiettivi di build assumono la forma BUILD-BUILDTYPE , dove BUILD è un nome in codice che si riferisce alla particolare combinazione di funzionalità. BUILDTYPE è uno dei seguenti.

Tipo di costruzione Utilizzo
utente Accesso limitato; adatto alla produzione
userdebug Come utente ma con accesso root e funzionalità di debug; molto vicino alle prestazioni di produzione
ing Configurazione di sviluppo con tempi di compilazione più rapidi; più adatto allo sviluppo quotidiano

La build userdebug dovrebbe comportarsi allo stesso modo della build user , con la possibilità di abilitare un debug aggiuntivo che normalmente viola il modello di sicurezza della piattaforma. Ciò rende la build userdebug utile per comprendere le prestazioni e la potenza utilizzata dal rilascio. Quando sviluppi con la build userdebug , segui le linee guida userdebug .

La build eng dà priorità alla produttività ingegneristica per gli ingegneri che lavorano sulla piattaforma. La build eng disattiva varie ottimizzazioni utilizzate per massimizzare le prestazioni di runtime. Per il resto, la build eng è molto simile alle build user e userdebug in modo che gli sviluppatori di dispositivi possano vedere come si comporta il codice in quegli ambienti.

Per visualizzare le impostazioni correnti del pranzo, esegui il comando:

echo "$TARGET_PRODUCT-$TARGET_BUILD_VARIANT"

Per ulteriori informazioni sulla creazione e sull'esecuzione su hardware reale, vedere Dispositivi flashing .

tapas

Il comando tapas configura la creazione di app disaggregate. Seleziona le singole app che devono essere create dal sistema di build Android. A differenza lunch , tapas non richiedono la creazione di immagini per un dispositivo.

Esegui tapas help per ulteriori informazioni sul comando.

Costruire il codice

Questa sezione è un breve riepilogo per garantire che la configurazione sia completa.

Costruisci tutto con m . m può gestire attività parallele con un argomento -jN . Se non fornisci un argomento -j , il sistema di compilazione seleziona automaticamente un conteggio di attività parallele che ritiene ottimale per il tuo sistema.

m

Come spiegato sopra, puoi creare moduli specifici invece dell'immagine completa del dispositivo elencando i loro nomi nella riga di comando m . Inoltre, m fornisce alcuni pseudobersagli per scopi speciali. Alcuni esempi sono:

  • droid - m droid è la build normale. Questo target è qui perché il target predefinito richiede un nome.
  • all - m all costruisce tutto ciò che fa m droid , oltre a tutto ciò che non ha il tag droid . Il server di compilazione esegue questa operazione per assicurarsi che tutto ciò che si trova nell'albero e abbia un file Android.mk venga compilato.
  • m - Esegue le build dalla cima dell'albero. Ciò è utile perché puoi eseguire make dalle sottodirectory. Se hai impostato la variabile d'ambiente TOP , la usa. In caso contrario, cerca l'albero dalla directory corrente, cercando di trovare la parte superiore dell'albero. Puoi creare l'intero albero del codice sorgente eseguendo m senza argomenti o creare target specifici specificando i loro nomi.
  • mma : crea tutti i moduli nella directory corrente e le relative dipendenze.
  • mmma - Costruisce tutti i moduli nelle directory fornite e le loro dipendenze.
  • croot : cd in cima all'albero.
  • clean - m clean elimina tutti i file di output e intermedi per questa configurazione. È lo stesso di rm -rf out/ .

Esegui m help per vedere quali altri pseudotarget fornisce m .

Esecuzione della compilazione

Puoi eseguire la build su un emulatore o eseguirne il flashing su un dispositivo. Poiché hai già selezionato il tuo target di build con lunch , è improbabile che venga eseguito su un target diverso da quello per cui è stato creato.

Lampeggiante con fastboot

Per eseguire il flashing di un dispositivo, utilizza fastboot , che dovrebbe essere incluso nel percorso dopo una compilazione riuscita. Vedi Lampeggiamento di un dispositivo per istruzioni.

Emulazione di un dispositivo Android

L'emulatore viene aggiunto automaticamente al percorso dal processo di compilazione. Per eseguire l'emulatore, digitare:

emulator

Comprendere le impronte digitali della build

Per tenere traccia e segnalare problemi legati a una particolare build Android, è importante comprendere l'impronta digitale della build. L'impronta digitale della build è una stringa unica e leggibile contenente le informazioni del produttore rilasciate per ciascuna build. Consulta la descrizione FINGERPRINT nella sezione Parametri di creazione del documento CDD (Android Compatibility Definition Document) per la sintassi precisa.

L'impronta digitale della build rappresenta una particolare implementazione e revisione di Android. Questa chiave univoca consente agli sviluppatori di app e ad altri di segnalare problemi con versioni firmware specifiche. Vedi Segnalazione di bug per il processo di segnalazione dei problemi Android.

Un'impronta digitale di build incapsula tutti i dettagli di implementazione di Android:

  • API: Android e native, nonché comportamenti API soft
  • API core e alcuni comportamenti dell'interfaccia utente del sistema
  • Requisiti di compatibilità e sicurezza definiti nella CDD
  • Specifiche del prodotto e impostazione delle funzionalità utilizzate dalle app per indirizzare i dispositivi che soddisfano i requisiti previsti
  • Implementazioni di componenti hardware e software

Consulta il CDD per i dettagli completi e Aggiunta di un nuovo dispositivo per istruzioni sulla creazione di un dispositivo Android completamente nuovo.

Risoluzione dei problemi relativi agli errori di compilazione comuni

Versione Java errata

Se stai tentando di creare una versione di Android che non è coerente con la tua versione di Java, make l'operazione con un messaggio come:

************************************************************
You are attempting to build with the incorrect version
of java.

Your version is: WRONG_VERSION.
The correct version is: RIGHT_VERSION.

Please follow the machine setup instructions at
    https://source.android.com/source/initializing.html
************************************************************

Ecco le probabili cause e soluzioni:

Nessuna autorizzazione USB

Per impostazione predefinita sulla maggior parte dei sistemi Linux, gli utenti non privilegiati non possono accedere alle porte USB. Se viene visualizzato un errore di autorizzazione negata, seguire le istruzioni in Configurazione dell'accesso USB .

Se ADB era già in esecuzione e non riesce a connettersi al dispositivo dopo aver impostato le regole, puoi terminarlo con adb kill-server . Questo comando fa riavviare ADB con la nuova configurazione.