Utilizza le informazioni contenute in questa pagina per creare i makefile per il tuo dispositivo e prodotto.
Ogni nuovo modulo Android deve avere un file di configurazione per indirizzare il sistema di compilazione con metadati del modulo, dipendenze in fase di compilazione e istruzioni di confezionamento. Android utilizza il sistema di build Soong . Vedi Creazione di Android per ulteriori informazioni sul sistema di compilazione Android.
Comprendere i livelli di creazione
La gerarchia di build include i livelli di astrazione che corrispondono alla composizione fisica di un dispositivo. Questi strati sono descritti nella tabella seguente. Ogni livello è correlato a quello superiore in una relazione uno-a-molti. Ad esempio, un'architettura può avere più di una scheda e ciascuna scheda può avere più di un prodotto. Puoi definire un elemento in un dato livello come una specializzazione di un elemento nello stesso livello, il che elimina la copia e semplifica la manutenzione.
Strato | Esempio | Descrizione |
---|---|---|
Prodotto | mioProdotto, mioProdotto_eu, mioProdotto_eu_fr, j2, sdk | Il livello del prodotto definisce le specifiche delle funzionalità di un prodotto spedito, ad esempio i moduli da creare, le versioni locali supportate e la configurazione per varie versioni locali. In altre parole, questo è il nome del prodotto complessivo. Le variabili specifiche del prodotto sono definite nei makefile di definizione del prodotto. Un prodotto può ereditare da altre definizioni di prodotto, il che semplifica la manutenzione. Un metodo comune consiste nel creare un prodotto di base che contenga funzionalità applicabili a tutti i prodotti, quindi creare varianti di prodotto basate su quel prodotto di base. Ad esempio, due prodotti che differiscono solo per la radio (CDMA contro GSM) possono ereditare dallo stesso prodotto di base che non definisce una radio. |
Scheda/dispositivo | marlin, linea blu, corallo | Lo strato scheda/dispositivo rappresenta lo strato fisico di plastica sul dispositivo (ovvero, il design industriale del dispositivo). Questo livello rappresenta anche gli schemi semplici di un prodotto. Questi includono le periferiche sulla scheda e la loro configurazione. I nomi utilizzati sono semplicemente codici per diverse configurazioni di scheda/dispositivo. |
Arco | braccio, x86, braccio64, x86_64 | Il livello dell'architettura descrive la configurazione del processore e l'interfaccia binaria dell'applicazione (ABI) in esecuzione sulla scheda. |
Utilizza varianti di build
Quando si crea per un particolare prodotto, è utile avere piccole variazioni sulla build della versione finale. In una definizione di modulo, il modulo può specificare tag con LOCAL_MODULE_TAGS
, che possono essere uno o più valori di optional
(predefinito), debug
e eng
.
Se un modulo non specifica un tag (tramite LOCAL_MODULE_TAGS
), il suo tag predefinito è optional
. Un modulo opzionale viene installato solo se richiesto dalla configurazione del prodotto con PRODUCT_PACKAGES
.
Queste sono le varianti di build attualmente definite.
Variante | Descrizione |
---|---|
eng | Questo è il sapore predefinito.
|
user | La variante doveva essere la versione finale.
|
userdebug | Uguale a user , con queste eccezioni:
|
Linee guida per il debug utente
L'esecuzione delle build userdebug durante i test aiuta gli sviluppatori di dispositivi a comprendere le prestazioni e la potenza delle versioni in fase di sviluppo. Per mantenere la coerenza tra le build utente e userdebug e per ottenere metriche affidabili nelle build utilizzate per il debug, gli sviluppatori di dispositivi dovrebbero seguire queste linee guida:
- userdebug è definito come una build utente con accesso root abilitato, tranne:
- app di solo userdebug eseguite solo su richiesta dall'utente
- Operazioni eseguite solo durante la manutenzione inattiva (sul caricatore/completamente carico), come l'utilizzo di
dex2oatd
rispetto adex2oat
per le compilazioni in background
- Non includere funzionalità abilitate/disabilitate per impostazione predefinita in base al tipo di build. Si sconsiglia agli sviluppatori di utilizzare qualsiasi forma di registrazione che influenzi la durata della batteria, come la registrazione del debug o il dumping dell'heap.
- Qualsiasi funzionalità di debug abilitata per impostazione predefinita in userdebug dovrebbe essere chiaramente definita e condivisa con tutti gli sviluppatori che lavorano sul progetto. Dovresti abilitare le funzionalità di debug solo per un periodo di tempo limitato finché il problema di cui stai tentando di eseguire il debug non viene risolto.
Personalizza la build con sovrapposizioni di risorse
Il sistema di compilazione Android utilizza sovrapposizioni di risorse per personalizzare un prodotto in fase di compilazione. Le sovrapposizioni di risorse specificano i file di risorse che vengono applicati sopra i valori predefiniti. Per utilizzare le sovrapposizioni di risorse, modifica il file di build del progetto per impostare PRODUCT_PACKAGE_OVERLAYS
su un percorso relativo alla directory di livello superiore. Quel percorso diventa una radice ombra cercata insieme alla radice corrente quando il sistema di compilazione cerca le risorse.
Le impostazioni personalizzate più comunemente sono contenute nel file frameworks/base/core/res/res/values/config.xml .
Per impostare una sovrapposizione di risorse su questo file, aggiungi la directory di sovrapposizione al file di build del progetto utilizzando uno dei seguenti:
PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay
O
PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay
Quindi, aggiungi un file di sovrapposizione alla directory, ad esempio:
vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml
Qualsiasi stringa o array di stringhe trovato nel file config.xml
di sovrapposizione sostituisce quelli trovati nel file originale.
Costruisci un prodotto
Puoi organizzare i file sorgente per il tuo dispositivo in molti modi diversi. Ecco una breve descrizione di un modo per organizzare un'implementazione Pixel.
Pixel è implementato con una configurazione del dispositivo principale denominata marlin
. Da questa configurazione del dispositivo, viene creato un prodotto con un makefile di definizione del prodotto che dichiara informazioni specifiche del prodotto sul dispositivo, ad esempio il nome e il modello. Puoi visualizzare la directory device/google/marlin
per vedere come è impostato tutto questo.
Scrivi makefile di prodotto
I seguenti passaggi descrivono come impostare i makefile del prodotto in modo simile a quello della linea di prodotti Pixel:
- Crea una directory
device/ <company-name> / <device-name>
per il tuo prodotto. Ad esempio,device/google/marlin
. Questa directory conterrà il codice sorgente per il tuo dispositivo insieme ai makefile per crearli. - Crea un makefile
device.mk
che dichiari i file e i moduli necessari per il dispositivo. Per un esempio, vedidevice/google/marlin/device-marlin.mk
. - Crea un makefile di definizione del prodotto per creare un prodotto specifico in base al dispositivo. Il seguente makefile è preso come esempio da
device/google/marlin/aosp_marlin.mk
. Tieni presente che il prodotto eredita dai filedevice/google/marlin/device-marlin.mk
evendor/google/marlin/device-vendor-marlin.mk
tramite il makefile dichiarando anche le informazioni specifiche del prodotto come nome, marca, e modello.# Inherit from the common Open Source product configuration $(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk) $(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk) PRODUCT_NAME := aosp_marlin PRODUCT_DEVICE := marlin PRODUCT_BRAND := Android PRODUCT_MODEL := AOSP on msm8996 PRODUCT_MANUFACTURER := Google PRODUCT_RESTRICT_VENDOR_FILES := true PRODUCT_COPY_FILES += device/google/marlin/fstab.common:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.marlin $(call inherit-product, device/google/marlin/device-marlin.mk) $(call inherit-product-if-exists, vendor/google_devices/marlin/device-vendor-marlin.mk) PRODUCT_PACKAGES += \ Launcher3QuickStep \ WallpaperPicker
Consulta Impostazione delle variabili di definizione del prodotto per ulteriori variabili specifiche del prodotto che puoi aggiungere ai tuoi makefile.
- Crea un file
AndroidProducts.mk
che punti ai makefile del prodotto. In questo esempio è necessario solo il makefile di definizione del prodotto. L'esempio seguente proviene dadevice/google/marlin/AndroidProducts.mk
(che contiene sia marlin, Pixel, sia sailfish, Pixel XL, che condivide la maggior parte della configurazione):PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/aosp_marlin.mk \ $(LOCAL_DIR)/aosp_sailfish.mk COMMON_LUNCH_CHOICES := \ aosp_marlin-userdebug \ aosp_sailfish-userdebug
- Crea un makefile
BoardConfig.mk
che contenga configurazioni specifiche della scheda. Per un esempio, vederedevice/google/marlin/BoardConfig.mk
. - Solo per Android 9 e versioni precedenti , crea un file
vendorsetup.sh
per aggiungere il tuo prodotto (una "combinazione pranzo") alla build insieme a una variante di build separata da un trattino. Ad esempio:add_lunch_combo <product-name>-userdebug
- A questo punto puoi creare più varianti di prodotto basate sullo stesso dispositivo.
Imposta le variabili di definizione del prodotto
Le variabili specifiche del prodotto sono definite nel makefile del prodotto. La tabella mostra alcune delle variabili gestite in un file di definizione del prodotto.
Variabile | Descrizione | Esempio |
---|---|---|
PRODUCT_AAPT_CONFIG | configurazioni aapt da utilizzare durante la creazione dei pacchetti. | |
PRODUCT_BRAND | Il marchio (ad esempio, l'operatore telefonico) per cui è personalizzato il software. | |
PRODUCT_CHARACTERISTICS | caratteristiche aapt per consentire l'aggiunta di risorse specifiche della variante a un pacchetto. | tablet , nosdcard |
PRODUCT_COPY_FILES | Elenco di parole come source_path:destination_path . Il file nel percorso di origine deve essere copiato nel percorso di destinazione durante la creazione di questo prodotto. Le regole per i passaggi di copia sono definite in config/makefile . | |
PRODUCT_DEVICE | Nome del disegno industriale. Questo è anche il nome della scheda e il sistema di compilazione lo utilizza per individuare BoardConfig.mk . | tuna |
PRODUCT_LOCALES | Un elenco separato da spazi di codici lingua a due lettere e coppie di codici paese a due lettere che descrivono diverse impostazioni per l'utente, ad esempio la lingua dell'interfaccia utente e la formattazione di ora, data e valuta. La prima lingua elencata in PRODUCT_LOCALES viene utilizzata come lingua predefinita del prodotto. | en_GB , de_DE , es_ES , fr_CA |
PRODUCT_MANUFACTURER | Nome del produttore. | acme |
PRODUCT_MODEL | Nome visibile all'utente finale per il prodotto finale. | |
PRODUCT_NAME | Nome visibile all'utente finale per il prodotto complessivo. Appare nella schermata Impostazioni > Informazioni . | |
PRODUCT_OTA_PUBLIC_KEYS | Elenco delle chiavi pubbliche OTA (over-the-air) per il prodotto. | |
PRODUCT_PACKAGES | Elenco degli APK e dei moduli da installare. | Contatti del calendario |
PRODUCT_PACKAGE_OVERLAYS | Indica se utilizzare le risorse predefinite o aggiungere eventuali sovrapposizioni specifiche del prodotto. | vendor/acme/overlay |
PRODUCT_SYSTEM_PROPERTIES | Elenco delle assegnazioni delle proprietà di sistema nel formato "key=value" per la partizione di sistema. Le proprietà di sistema per altre partizioni possono essere impostate tramite PRODUCT_<PARTITION>_PROPERTIES come in PRODUCT_VENDOR_PROPERTIES per la partizione del fornitore. Nomi delle partizioni supportate: SYSTEM , VENDOR , ODM , SYSTEM_EXT e PRODUCT . |
Configura la lingua di sistema predefinita e il filtro locale
Utilizzare queste informazioni per configurare la lingua predefinita e il filtro locale del sistema, quindi abilitare il filtro locale per un nuovo tipo di dispositivo.
Proprietà
Configura sia la lingua predefinita che il filtro locale del sistema utilizzando le proprietà di sistema dedicate:
-
ro.product.locale
: per impostare la locale predefinita. Inizialmente è impostato sulla prima locale nella variabilePRODUCT_LOCALES
; puoi sovrascrivere quel valore. (Per ulteriori informazioni, vedere la tabella Impostazione delle variabili di definizione del prodotto .) -
ro.localization.locale_filter
: per impostare un filtro locale, utilizzando un'espressione regolare applicata ai nomi locali. Per esempio:- Filtro inclusivo:
^(de-AT|de-DE|en|uk).*
- consente solo il tedesco (varianti di Austria e Germania), tutte le varianti inglesi dell'inglese e l'ucraino - Filtro esclusivo:
^(?!de-IT|es).*
- esclude il tedesco (variante italiana) e tutte le varianti dello spagnolo.
- Filtro inclusivo:
Abilita il filtro locale
Per abilitare il filtro, impostare il valore della stringa della proprietà di sistema ro.localization.locale_filter
.
Impostando il valore della proprietà del filtro e la lingua predefinita tramite oem/oem.prop
durante la calibrazione di fabbrica è possibile configurare le restrizioni senza inserire il filtro nell'immagine del sistema. Ti assicuri che queste proprietà vengano prelevate dalla partizione OEM aggiungendole alla variabile PRODUCT_OEM_PROPERTIES
come indicato di seguito:
# Delegation for OEM customization PRODUCT_OEM_PROPERTIES += \ ro.product.locale \ ro.localization.locale_filter
Quindi in produzione i valori effettivi vengono scritti in oem/oem.prop
, per riflettere i requisiti target. Con questo approccio, i valori predefiniti vengono mantenuti durante il ripristino delle impostazioni di fabbrica, quindi le impostazioni iniziali appaiono esattamente come una prima configurazione per l'utente.
Imposta ADB_VENDOR_KEYS per la connessione tramite USB
La variabile d'ambiente ADB_VENDOR_KEYS
consente ai produttori di dispositivi di accedere a build di cui è possibile eseguire il debug (-userdebug e -eng, ma non -user) su adb senza autorizzazione manuale. Normalmente adb genera una chiave di autenticazione RSA univoca per ciascun computer client, che invierà a qualsiasi dispositivo connesso. Questa è la chiave RSA mostrata nella finestra di dialogo di autorizzazione adb. In alternativa puoi creare chiavi conosciute nell'immagine di sistema e condividerle con il client adb. Ciò è utile per lo sviluppo del sistema operativo e soprattutto per i test perché evita la necessità di interagire manualmente con la finestra di dialogo di autorizzazione adb.
Per creare le chiavi del fornitore, una persona (solitamente un responsabile del rilascio) dovrebbe:
- Genera una coppia di chiavi utilizzando
adb keygen
. Per i dispositivi Google, Google genera una nuova coppia di chiavi per ogni nuova versione del sistema operativo. - Controlla le coppie di chiavi da qualche parte nell'albero dei sorgenti. Google li memorizza, ad esempio, in
vendor/google/security/adb/
. - Imposta la variabile di build
PRODUCT_ADB_KEYS
in modo che punti alla directory delle chiavi. Google lo fa aggiungendo un fileAndroid.mk
nella directory delle chiavi che dicePRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub
, che aiuta a garantire che ci ricordiamo di generare una nuova coppia di chiavi per ogni versione del sistema operativo.
Ecco il makefile utilizzato da Google nella directory in cui memorizziamo le coppie di chiavi archiviate per ogni versione:
PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub ifeq ($(wildcard $(PRODUCT_ADB_KEYS)),) $(warning ========================) $(warning The adb key for this release) $(warning ) $(warning $(PRODUCT_ADB_KEYS)) $(warning ) $(warning does not exist. Most likely PLATFORM_VERSION in build/core/version_defaults.mk) $(warning has changed and a new adb key needs to be generated.) $(warning ) $(warning Please run the following commands to create a new key:) $(warning ) $(warning make -j8 adb) $(warning LOGNAME=android-eng HOSTNAME=google.com adb keygen $(patsubst %.pub,%,$(PRODUCT_ADB_KEYS))) $(warning ) $(warning and upload/review/submit the changes) $(warning ========================) $(error done) endif
Per utilizzare queste chiavi del fornitore, un tecnico deve solo impostare la variabile di ambiente ADB_VENDOR_KEYS
in modo che punti alla directory in cui sono archiviate le coppie di chiavi. Questo dice adb
di provare prima queste chiavi canoniche, prima di ricorrere alla chiave host generata che richiede l'autorizzazione manuale. Quando adb
non riesce a connettersi a un dispositivo non autorizzato, il messaggio di errore suggerirà di impostare ADB_VENDOR_KEYS
se non è già impostato.