Questa pagina è stata tradotta dall'API Cloud Translation.

Aggiungi un nuovo dispositivo

Utilizza le informazioni in questa pagina per creare i file per il tuo dispositivo e prodotto.

Ogni nuovo modulo Android deve avere un file di configurazione per indirizzare il sistema di compilazione con metadati dei moduli, dipendenze del tempo di compilazione e istruzioni di pacchettizzazione. Android utilizza Sistema di sviluppo Soong. Consulta la sezione Sviluppare Android per ulteriori informazioni su Android. di un sistema di compilazione.

Informazioni sui livelli di build

La gerarchia di compilazione include i livelli di astrazione che corrispondono composizione fisica di un dispositivo. Questi livelli sono descritti nella tabella di seguito. Ogni livello è correlato a quello superiore in una relazione di tipo one-to-many. Per Ad esempio, un'architettura può avere più di una scheda e ognuna può avere più di un prodotto. In un determinato livello, puoi definire un elemento come nella specializzazione di un elemento nello stesso livello, eliminando così la possibilità di copiare semplifica la manutenzione.

Livello	Esempio	Descrizione
Prodotto	myProduct, myProduct_eu, myProduct_eu_fr, j2, SDK	Il livello di prodotto definisce le specifiche delle caratteristiche di una spedizione prodotto come i moduli da creare, le impostazioni internazionali supportate e per le varie impostazioni internazionali. In altre parole, questo è il nome del prodotto nel complesso. Le variabili specifiche del prodotto sono definite rendere i file di definizione del prodotto. Un prodotto può ereditare da altri definizioni di prodotto, il che semplifica la manutenzione. Un metodo comune è creare un prodotto di base che contenga caratteristiche applicabili a tutti i prodotti, quindi crea varianti di prodotto basate su questa base. prodotto. Ad esempio, due prodotti che si differenziano solo per i loro segnali radio (CDMA e GSM) possono ereditare dallo stesso prodotto di base non definisce una radio.
Lavagna/dispositivo	marlin, linea blu, corallo	Il livello scheda/dispositivo rappresenta lo strato fisico di plastica sulla dispositivo (ovvero il design industriale). Questo livello rappresenta anche degli schemi di un prodotto. Queste includono le periferiche sulla scheda e i relativi configurazione. I nomi utilizzati sono solo codici di una diversa scheda/dispositivo configurazioni.
Arco	arm, x86, arm64, x86_64	Il livello dell'architettura descrive la configurazione del processore l'ABI (Application Binary Interface) in esecuzione sulla scheda.

Utilizza le varianti di build

Quando crei un particolare prodotto, è utile avere minori varianti presenti nella build della release finale. In un modulo definizione, il modulo può specificare tag con LOCAL_MODULE_TAGS, che può essere uno o più valori di optional (valore predefinito), debug e eng.

Se un modulo non specifica un tag (di LOCAL_MODULE_TAGS), il relativo il valore predefinito del tag è optional. Un modulo facoltativo 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 gusto predefinito. Installa moduli contrassegnati con `eng` o `debug`. Installa i moduli in base ai file di definizione dei prodotti, in oltre a moduli con tag. `ro.secure=0` `ro.debuggable=1` `ro.kernel.android.checkjni=1` `adb` è abilitato per impostazione predefinita.
`user`	La variante da utilizzare come bit di rilascio finali. Installa moduli contrassegnati con `user`. Installa i moduli in base ai file di definizione dei prodotti, in oltre a moduli con tag. `ro.secure=1` `ro.debuggable=0` `adb` è disattivato per impostazione predefinita.
`userdebug`	Uguale a `user`, con le seguenti eccezioni: Installa anche i moduli taggati con `debug`. `ro.debuggable=1` `adb` è abilitato per impostazione predefinita.

Linee guida per il debug degli utenti

L'esecuzione di build di debug degli utenti nei test aiuta gli sviluppatori di dispositivi a capire le prestazioni e la potenza delle release in fase di sviluppo. Per mantenere la coerenza tra le build di debug degli utenti e utenti e per ottenere metriche affidabili nelle build utilizzati per il debug, gli sviluppatori di dispositivi devono seguire queste linee guida:

userdebug è definito come una build utente con accesso root abilitato, tranne che:
- App solo debug dell'utente eseguite solo on demand dall'utente
- Operazioni eseguite soltanto durante la manutenzione in caso di inattività (al caricabatterie/completamente addebitato), ad esempio utilizzando dex2oatd anziché dex2oat per le compilazioni in background
Non includere funzionalità attivate/disattivate per impostazione predefinita in base al tipo di build. Si sconsiglia agli sviluppatori di utilizzare qualsiasi forma di registrazione che abbia impatto sulla durata della batteria, ad esempio: il logging di debug o il dump dell'heap.
Tutte le funzionalità di debug attivate per impostazione predefinita in userdebug devono essere definite in modo chiaro e condiviso con tutti gli sviluppatori che lavorano al progetto. Devi attivare le funzionalità di debug solo per un periodo di tempo limitato fino a quando il problema di cui stai tentando di eseguire il debug non viene risolto.

Personalizza la build con gli overlay delle risorse

Il sistema di build Android utilizza gli overlay di risorse per personalizzare di un prodotto in fase di creazione. Gli overlay risorsa specificano la risorsa che vengono applicati in aggiunta ai valori predefiniti. Per utilizzare gli overlay delle risorse, modifica il progetto del file di build per impostare PRODUCT_PACKAGE_OVERLAYS su un un percorso relativo alla directory di primo livello. Il percorso diventa una radice ombra cercata insieme la radice attuale 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 configurare un overlay di risorse su questo file, aggiungi la directory dell'overlay al buildfile del progetto utilizzando uno dei seguenti elementi:

PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay

oppure

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

Quindi, aggiungi un file di overlay alla directory, ad esempio:

vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml

Eventuali stringhe o array di stringhe trovati nell'overlay config.xml sostituiscono il file presenti nel file originale.

Crea un prodotto

Puoi organizzare i file di origine per il tuo dispositivo in molti modi diversi. Ecco un riepilogo descrizione di un modo per organizzare l'implementazione di 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 sul prodotto del dispositivo, ad esempio nome e modello. Puoi visualizzare device/google/marlin per vedere la configurazione.

Scrittura dei makefile dei prodotti

I passaggi seguenti spiegano come configurare i makefile dei prodotti in modo simile a quella della linea di prodotti Pixel:

Crea un device/<company-name>/<device-name> per il tuo prodotto. Ad esempio, device/google/marlin. Questa directory contiene il codice sorgente per il dispositivo insieme ai makefile per crearli.
Crea un makefile device.mk che dichiara i file e i moduli necessari per dispositivo. Per un esempio, vedi device/google/marlin/device-marlin.mk.

Crea un makefile di definizione del prodotto per creare un prodotto specifico in base al dispositivo. La Il seguente makefile è tratto da device/google/marlin/aosp_marlin.mk come esempio. Tieni presente che il prodotto eredita device/google/marlin/device-marlin.mk e vendor/google/marlin/device-vendor-marlin.mk file attraverso il makefile, mentre dichiarando anche le informazioni specifiche del prodotto, come nome, brand 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 Impostare le variabili di definizione del prodotto per ulteriori informazioni variabili specifiche del prodotto che puoi aggiungere ai tuoi file makefile.

Crea un file AndroidProducts.mk che rimandi ai makefile del prodotto. Nella in questo esempio, è necessario solo il makefile della definizione del prodotto. L'esempio che segue è device/google/marlin/AndroidProducts.mk (che contiene sia marlin, Pixel, e sailfish, Pixel XL con 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 contenente configurazioni specifiche per la scheda. Per un esempio, vedi device/google/marlin/BoardConfig.mk.
Solo per Android 9 e versioni precedenti solo, crea un File vendorsetup.sh per aggiungere il tuo prodotto (una "combo pranzo") a della build insieme a una variante della build separate da un trattino. Ad esempio:
```
add_lunch_combo <product-name>-userdebug
```
A questo punto, puoi creare altre varianti di prodotto in base allo stesso dispositivo.

Impostare le variabili di definizione del prodotto

Le variabili specifiche del prodotto sono definite nel makefile del prodotto. La tabella mostra alcuni dei le variabili gestite in un file di definizione del prodotto.

Variabile	Descrizione	Esempio
`PRODUCT_AAPT_CONFIG`	`aapt` configurazioni da utilizzare durante la creazione di pacchetti.
`PRODUCT_BRAND`	Il brand (ad es. operatore) per cui il software è personalizzato.
`PRODUCT_CHARACTERISTICS`	`aapt` per consentire l'aggiunta a un pacchetto di risorse specifiche per le varianti.	`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 la copia passaggi sono definiti in `config/makefile`.
`PRODUCT_DEVICE`	Nome del design industriale. Si tratta anche del nome della scheda, che viene utilizzato dal sistema di compilazione per individuare `BoardConfig.mk`.	`tuna`
`PRODUCT_LOCALES`	Un elenco separato da spazi di codici lingua di due lettere, coppie di codici paese di due lettere che descrivere diverse impostazioni dell'utente, ad esempio lingua e ora dell'interfaccia utente, data e la formattazione della valuta. La prima lingua elencata in `PRODUCT_LOCALES` viene usata come le impostazioni internazionali predefinite del prodotto.	`en_GB`, `de_DE`, `es_ES`, `fr_CA`
`PRODUCT_MANUFACTURER`	Nome del produttore.	`acme`
`PRODUCT_MODEL`	Nome visibile all'utente finale del prodotto finale.
`PRODUCT_NAME`	Nome visibile all'utente finale per il prodotto in generale. Viene visualizzata in Impostazioni > Informazioni.
`PRODUCT_OTA_PUBLIC_KEYS`	Elenco di chiavi pubbliche over-the-air (OTA) per il prodotto.
`PRODUCT_PACKAGES`	Elenco di APK e moduli da installare.	Contatti calendario
`PRODUCT_PACKAGE_OVERLAYS`	Indica se utilizzare le risorse predefinite o aggiungere overlay specifici per i prodotti.	`vendor/acme/overlay`
`PRODUCT_SYSTEM_PROPERTIES`	Elenco delle assegnazioni delle proprietà di sistema nel formato `"key=value"` per 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. Partizione supportata nomi: `SYSTEM`, `VENDOR`, `ODM`, `SYSTEM_EXT` e `PRODUCT`.

Configurare il filtro per lingua e lingua di sistema predefinite

Utilizza queste informazioni per configurare il filtro per la lingua predefinita e le impostazioni internazionali di sistema, quindi attiva il filtro delle impostazioni internazionali per un nuovo tipo di dispositivo.

Proprietà

Configura sia la lingua predefinita sia il filtro delle impostazioni internazionali di sistema utilizzando un sistema dedicato proprietà:

ro.product.locale: per impostare le impostazioni internazionali predefinite. È impostato inizialmente sul primo impostazioni internazionali nella variabile PRODUCT_LOCALES; puoi eseguire l'override quel valore. Per ulteriori informazioni, consulta Impostazione delle variabili di definizione del prodotto.)
ro.localization.locale_filter: per impostare un filtro per le impostazioni internazionali, utilizzando un'espressione regolare applicata ai nomi delle impostazioni internazionali. Ad esempio:
- Filtro inclusivo: ^(de-AT|de-DE|en|uk).* - consente solo il tedesco (Austria e Germania) varianti), tutte le varianti inglesi dell'inglese e dell'ucraino
- Filtro esclusivo: ^(?!de-IT|es).*; esclude il tedesco (variante Italia) e tutte varianti dello spagnolo.

Attiva il filtro delle impostazioni internazionali

Per attivare il filtro, imposta 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 puoi configurare le limitazioni senza integrare il filtro nell'immagine di sistema. Ti assicuri che queste proprietà vengano selezionate dalla partizione OEM aggiungendole alla sezione PRODUCT_OEM_PROPERTIES come indicato di seguito:

# Delegation for OEM customization
PRODUCT_OEM_PROPERTIES += \
    ro.product.locale \
    ro.localization.locale_filter

In fase di produzione, i valori effettivi vengono scritti in oem/oem.prop, per riflettere il target i tuoi requisiti. Con questo approccio, i valori predefiniti vengono conservati durante il ripristino dei dati di fabbrica, quindi le impostazioni iniziali sembrano esattamente la configurazione iniziale per l'utente.

Imposta ADB_VENDOR_KEYS per la connessione tramite USB

La variabile di ambiente ADB_VENDOR_KEYS consente ai produttori di dispositivi di accedere 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 ogni computer client, che invia su qualsiasi dispositivo connesso. Si tratta della chiave RSA mostrata nella finestra di dialogo di autorizzazione ADB. Come In alternativa, puoi creare chiavi note nell'immagine di sistema e condividerle con il client adb. Ciò è utile per lo sviluppo del sistema operativo e soprattutto per i test, in quanto evita la necessità di eseguire manualmente a interagire con la finestra di dialogo di autorizzazione ADB.

Per creare le chiavi del fornitore, una persona (di solito un responsabile dei rilasci) deve:

Genera una coppia di chiavi utilizzando adb keygen. Per i dispositivi Google, Google genera una nuova per ogni nuova versione del sistema operativo.
Controlla le coppie di chiavi, da qualche parte nell'albero di origine. Google le memorizza in vendor/google/security/adb/, ad esempio.
Imposta la variabile di build PRODUCT_ADB_KEYS in modo che punti alla directory della chiave. Per farlo, Google aggiunge nella directory della chiave un file Android.mk che dice PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub, che ci consente di ricordarci di generare una nuova coppia di chiavi per ogni versione del sistema operativo.

Ecco il makefile utilizzato da Google nella directory in cui archiviamo le coppie di chiavi registrate per ogni release:

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 usare queste chiavi del fornitore, un tecnico deve solo impostare il ADB_VENDOR_KEYS di ambiente in modo che punti alla directory in cui sono archiviate le coppie di chiavi. Questo indica a adb di provare queste chiavi canoniche, prima di tornare alle chiavi che richiede l'autorizzazione manuale. Quando adb non riesce a connettersi a un dispositivo, il messaggio di errore ti suggerisce di impostare ADB_VENDOR_KEYS se non è è già impostato.