Costruire Android

Segui queste istruzioni per iniziare a creare Android.

Allestimento dell'ambiente

Inizializzare 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 i target dei dispositivi e le tapas per la creazione di app disaggregate, come l' app TV di riferimento .

È necessario emettere nuovamente questo comando dopo ogni repo sync per rilevare eventuali modifiche a quello script. Nota che sostituendo source con . (un singolo punto) salva alcuni caratteri e la forma abbreviata è più comunemente usata nella documentazione.

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

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

hmm

La scelta di un obiettivo

il pranzo

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

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

lunch aosp_arm-eng

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

Tutti i target 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	Uso
utente	Accesso limitato; adatto per la produzione
utentedebug	Come utente ma con accesso root e capacità di debug; preferito per il debug
ing	Configurazione di sviluppo con strumenti di debug aggiuntivi

La build userdebug dovrebbe comportarsi allo stesso modo della build utente, con la possibilità di abilitare un debug aggiuntivo che normalmente viola il modello di sicurezza della piattaforma. Ciò rende la build userdebug adatta per i test degli utenti con maggiori capacità di diagnosi. Durante lo sviluppo con la build userdebug, seguire le linee guida userdebug .

La build eng dà la priorità alla produttività ingegneristica per gli ingegneri che lavorano sulla piattaforma. La build inglese 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 ulteriori informazioni sulla creazione e l'esecuzione su hardware effettivo, vedere dispositivi di flashing .

tapas

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

Esegui la guida di tapas help per ulteriori informazioni sul comando.

Costruire il codice

Questa sezione è un rapido riepilogo per garantire che l'installazione sia completa.

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

m

Come spiegato sopra, puoi creare moduli specifici invece dell'intera immagine del dispositivo elencando i loro nomi nella tua 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 build 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 dalle sottodirectory. Se hai impostato la variabile di 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 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/ .

Esegui m help per vedere quali altri pseudotarget m fornisce.

Esecuzione della build

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.

Nota: ricorda di ottenere binari proprietari o la tua build non si avvierà correttamente sull'hardware di destinazione. A volte il codice sorgente potrebbe avere binari differenti per build e branch differenti. Se a questo punto ottieni BLOB binari, devi decomprimerli, m installclean e ricostruire. Per ulteriori informazioni su questo processo, vedere Come ottenere file binari proprietari .

Lampeggiante con avvio rapido

Per eseguire il flashing di un dispositivo, usa fastboot , che dovrebbe essere incluso nel tuo percorso dopo una build riuscita. Vedere Flashing di un dispositivo per 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 di costruzione

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 univoca, leggibile dall'uomo, contenente le informazioni sul produttore emesse per ciascuna build. Per la sintassi precisa, vedere la descrizione dell'impronta digitale all'interno della sezione Parametri di build del documento di definizione della compatibilità Android (CDD).

L'impronta digitale della build rappresenta una particolare implementazione e revisione di Android. Questa chiave univoca consente agli sviluppatori di app e ad altri utenti di segnalare problemi con versioni firmware specifiche. Vedere 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 di sistema
• Requisiti di compatibilità e sicurezza definiti nel CDD
• Specifiche del prodotto e impostazione delle funzioni di utilizzo impiegate 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 di comuni errori di compilazione

Versione Java errata

Se stai tentando di creare una versione di Android 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 una destinazione .
• Un altro JDK precedentemente installato che appare 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 senza privilegi non possono accedere alle porte USB. Se viene visualizzato un errore di autorizzazione negata, segui le istruzioni in Configurazione dell'accesso USB .

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