Costruire Android

Segui queste istruzioni per iniziare a creare Android.

Allestimento dell'ambiente

Inizializza l'ambiente con lo script envsetup.sh :

source build/envsetup.sh

O

. build/envsetup.sh

Vedere lo script in platform/build/envsetup.sh per le descrizioni dei comandi correlati, tra cui lunch per la selezione dei target del dispositivo e tapas per la creazione di app non raggruppate, come l' app TV di riferimento .

È necessario emettere nuovamente questo comando dopo ogni repo sync per raccogliere eventuali modifiche a quello script. Si noti che la sostituzione di source con . (un singolo punto) consente di risparmiare pochi caratteri e la forma abbreviata è 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

Scelta di un obiettivo

pranzo

Scegli quale obiettivo costruire con lunch . lunch product_name - build_variant seleziona product_name come prodotto da costruire e build_variant come variante da costruire e memorizza quelle 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à. Vedere Selezione di una build di dispositivo per le configurazioni di build di tutti i dispositivi supportati in AOSP o parlare con i membri del team del pranzo corretto per il dispositivo su cui si sta lavorando.

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

La build userdebug dovrebbe comportarsi allo stesso modo della build user , con la possibilità di abilitare un debugging aggiuntivo che normalmente viola il modello di sicurezza della piattaforma. Ciò rende la build userdebug adatta per i test utente con maggiori capacità di diagnosi. Quando sviluppi con la build userdebug , segui le linee guida userdebug .

La build eng dà la priorità alla produttività ingegneristica per gli ingegneri che lavorano sulla piattaforma. La build eng disattiva varie ottimizzazioni utilizzate per fornire una buona esperienza utente. Altrimenti, la build eng ha un comportamento simile alle build user e userdebug in modo che gli sviluppatori di dispositivi possano vedere come si comporta il codice in quegli ambienti.

Per vedere le impostazioni correnti del pranzo, eseguire il comando:

echo "$TARGET_PRODUCT-$TARGET_BUILD_VARIANT"

Per ulteriori informazioni sulla compilazione e l'esecuzione su hardware effettivo, consulta Dispositivi lampeggianti .

tapas

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

Eseguire tapas help per ulteriori informazioni sul comando.

Costruire il codice

Questa sezione è un breve riepilogo per garantire che l'installazione 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 numero 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 pseudotarget per scopi speciali. Alcuni esempi sono:

• droid - m droid è la build normale. Questa destinazione è qui perché la destinazione predefinita 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 lo esegue per assicurarsi che tutto ciò che è nell'albero e abbia un file Android.mk venga compilato.
• m - Esegue le build dalla cima dell'albero. Questo è utile perché puoi eseguire make dall'interno delle sottodirectory. Se hai impostato la variabile d'ambiente TOP , la usa. Se non lo fai, cerca l'albero dalla directory corrente, cercando di trovare la cima dell'albero. Puoi creare l'intero albero del codice sorgente eseguendo m senza argomenti o creare obiettivi specifici specificandone i nomi.
• mma - Crea tutti i moduli nella directory corrente e le loro dipendenze.
• mmma - Crea 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. Questo è lo stesso di rm -rf out/ .

Eseguire m help per vedere quali altri pseudotarget fornisce m .

Esecuzione della compilazione

Puoi eseguire la tua 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 avvio rapido

Per eseguire il flashing di un dispositivo, utilizzare fastboot , che dovrebbe essere incluso nel percorso dopo una build riuscita. Vedere Eseguire il flashing di un dispositivo per le istruzioni.

Emulazione di un dispositivo Android

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

emulator

Comprensione delle impronte digitali della build

Per tenere traccia e segnalare i problemi legati a una particolare build di Android, è importante comprendere l'impronta digitale della build. L'impronta digitale della build è una stringa univoca leggibile dall'uomo contenente le informazioni del produttore fornite a ciascuna build. Vedere la descrizione di FINGERPRINT all'interno della sezione Parametri di compilazione del documento di definizione della compatibilità Android (CDD) 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. Consulta Segnalazione di bug per il processo di segnalazione dei problemi di Android.

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

• API: Android e native, nonché comportamenti API soft
• API di base e alcuni comportamenti dell'interfaccia utente del sistema
• Compatibilità e requisiti di sicurezza definiti nel CDD
• Le specifiche del prodotto e l'impostazione delle funzionalità di utilizzo 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 le istruzioni sulla creazione di un dispositivo Android completamente nuovo.

Risoluzione dei problemi 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 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 un obiettivo .
• Un altro JDK precedentemente installato appare nel tuo percorso. Anteponi il JDK corretto all'inizio del tuo percorso o rimuovi il JDK problematico.

Nessuna autorizzazione USB

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

Se ADB era già in esecuzione e non è possibile connettersi al dispositivo dopo aver impostato tali regole, è possibile terminarlo con adb kill-server . Tale comando fa sì che ADB si riavvii con la nuova configurazione.