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 fam droid
, oltre a tutto ciò che non ha il tagdroid
. Il server di compilazione esegue questa operazione per assicurarsi che tutto ciò che si trova nell'albero e abbia un fileAndroid.mk
venga compilato. -
m
- Esegue le build dalla cima dell'albero. Ciò è utile perché puoi eseguiremake
dalle sottodirectory. Se hai impostato la variabile d'ambienteTOP
, 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 eseguendom
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 dirm -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:
- Mancata installazione del JDK corretto come specificato nei requisiti JDK . Assicurati di aver seguito i passaggi in Configurazione dell'ambiente e Scelta di una destinazione .
- Un altro JDK precedentemente installato visualizzato nel tuo percorso. Anteponi il JDK corretto all'inizio del percorso o rimuovi il JDK problematico.
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.