Aggiungere un nuovo dispositivo

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

Ogni nuovo modulo Android deve avere un file di configurazione per indirizzare il sistema di compilazione con i metadati del modulo, le dipendenze in fase di compilazione e le istruzioni di imballaggio. Android utilizza il sistema di compilazione Soong. Per ulteriori informazioni sul sistema di compilazione di Android, consulta Compilare Android.

Informazioni sui livelli di compilazione

La gerarchia di build include i livelli di astrazione che corrispondono alla composizione fisica di un dispositivo. Questi livelli sono descritti nella tabella seguente. Ogni livello è correlato a quello soprastante in una relazione uno a molti. Ad esempio, un'architettura può avere più schede e ogni scheda può avere più prodotti. Puoi definire un elemento in un determinato livello come una specializzazione di un elemento nello stesso livello, il che elimina la copia e semplifica la manutenzione.

Utilizzare le varianti di build

Quando esegui la compilazione per un determinato prodotto, è utile avere piccole variazioni nella build della release finale. In una definizione di modulo, il modulo può specificare i tag con LOCAL_MODULE_TAGS, che può essere uno o più valori di optional (predefinito), debug e eng.

Se un modulo non specifica un tag (per LOCAL_MODULE_TAGS), il suo tag predefinito è optional. Un modulo facoltativo viene installato solo se richiesto dalla configurazione del prodotto con PRODUCT_PACKAGES.

Queste sono le varianti di build attualmente definite.

Linee guida per userdebug

L'esecuzione di build userdebug durante i test aiuta gli sviluppatori di dispositivi a comprendere il rendimento e la potenza delle release in fase di sviluppo. Per mantenere la coerenza tra le build user e userdebug e ottenere metriche affidabili nelle build utilizzate per il debug, gli sviluppatori di dispositivi devono seguire queste linee guida:

• userdebug è definito come una build utente con accesso root abilitato, ad eccezione di:
  • App solo per userdebug che vengono eseguite solo su richiesta dall'utente
  • Operazioni che vengono eseguite solo durante la manutenzione inattiva (sul caricabatterie/caricata completamente), ad esempio l'utilizzo di dex2oatd anziché dex2oat per le compilazioni in background
• Non includere funzionalità attivate/disattivate per impostazione predefinita in base al tipo di compilazione. Sconsigliamo agli sviluppatori di utilizzare qualsiasi forma di registrazione che influisca sulla durata della batteria, ad esempio la registrazione di debug o il dumping dell'heap.
• Eventuali funzionalità di debug abilitate per impostazione predefinita in userdebug devono essere chiaramente definite e condivise con tutti gli sviluppatori che lavorano al progetto. Devi attivare le funzionalità di debug solo per un periodo di tempo limitato finché il problema che stai cercando di risolvere non viene risolto.

Personalizzare la compilazione con gli overlay delle risorse

Il sistema di compilazione di Android utilizza gli overlay delle risorse per personalizzare un prodotto in fase di compilazione. Gli overlay delle risorse specificano i file di risorse da applicare sopra quelli predefiniti. Per utilizzare gli overlay delle risorse, modifica il file di compilazione del progetto per impostare PRODUCT_PACKAGE_OVERLAYS su un percorso relativo alla tua directory di primo livello. Questo percorso diventa una radice virtuale cercata insieme alla radice corrente quando il sistema di compilazione cerca le risorse.

Le impostazioni più comunemente personalizzate 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 file di build del progetto utilizzando una delle seguenti opzioni:

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

oppure

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

Aggiungi un file overlay alla directory, ad esempio:

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

Eventuali stringhe o array di stringhe trovati nel file dell'overlay config.xml sostituiscono quelle trovate nel file originale.

Creare un prodotto

Puoi organizzare i file di origine per il tuo dispositivo in molti modi diversi. Ecco una breve descrizione di un modo per organizzare un'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 del prodotto sul dispositivo, come il nome e il modello. Puoi visualizzare la directory device/google/marlin per scoprire come è configurato tutto.

Scrivere makefile dei prodotti

I passaggi riportati di seguito descrivono come configurare i file make dei prodotti in modo simile alla linea di prodotti Pixel:

1. 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 file make per compilarlo.
2. Crea un file make device.mk che dichiari i file e i moduli necessari per il dispositivo. Per un esempio, vedi device/google/marlin/device-marlin.mk.
3. Crea un file make per la definizione del prodotto per creare un prodotto specifico in base al dispositivo. Il seguente file make è preso da device/google/marlin/aosp_marlin.mk come esempio. Tieni presente che il prodotto eredita i file device/google/marlin/device-marlin.mk e vendor/google/marlin/device-vendor-marlin.mk tramite il file makefile, dichiarando al contempo 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 Impostare le variabili di definizione del prodotto per altre variabili specifiche del prodotto che puoi aggiungere ai file make.

4. Crea un file AndroidProducts.mk che indichi i file make del prodotto. In questo esempio è necessario solo il file makefile di definizione del prodotto. L'esempio riportato di seguito è tratto da device/google/marlin/AndroidProducts.mk (che contiene sia marlin, il Pixel, sia sailfish, il Pixel XL, che condividevano 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
   

5. Crea un file makefile BoardConfig.mk contenente configurazioni specifiche della scheda. Per un esempio, vedi device/google/marlin/BoardConfig.mk.
6. Solo per Android 9 e versioni precedenti, crea un file vendorsetup.sh per aggiungere il tuo prodotto (un "menu del giorno") alla compilation insieme a una variante di compilazione distinta da un trattino. Ad esempio:

   add_lunch_combo <product-name>-userdebug
   

7. A questo punto, puoi creare altre varianti del prodotto in base allo stesso dispositivo.

Impostare le variabili di definizione del prodotto

Le variabili specifiche del prodotto sono definite nel file make del prodotto. La tabella mostra alcune delle variabili gestite in un file di definizione del prodotto.

Configurare il filtro della lingua e delle impostazioni internazionali predefinite del sistema

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

Proprietà

Configura sia la lingua predefinita sia il filtro della lingua di sistema utilizzando le proprietà di sistema dedicate:

• ro.product.locale: per impostare le impostazioni internazionali predefinite. Inizialmente è impostato sulla prima lingua nella variabile PRODUCT_LOCALES. Puoi sostituire questo valore. Per ulteriori informazioni, consulta la tabella Impostare le 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 tedesco (varianti di Austria e Germania), tutte le varianti dell'inglese e ucraino
  • Filtro esclusivo: ^(?!de-IT|es).* - esclude il tedesco (variante italiana) e tutte le varianti dello spagnolo.

Attivare il filtro per le impostazioni internazionali

Per attivare il filtro, imposta il valore della stringa della proprietà di sistema ro.localization.locale_filter.

Impostando il valore della proprietà filtro e la lingua predefinita tramite oem/oem.prop durante la calibratura di fabbrica, puoi configurare le limitazioni senza incorporare il filtro nell'immagine di sistema. Per assicurarti che queste proprietà vengano rilevate dalla partizione OEM, aggiungile alla variabile PRODUCT_OEM_PROPERTIES come indicato di seguito:

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

In produzione, i valori effettivi vengono scritti in oem/oem.prop per riflettere i requisiti di destinazione. Con questo approccio, i valori predefiniti vengono mantenuti durante il ripristino dei dati di fabbrica, pertanto le impostazioni iniziali sono esattamente come quelle di una prima configurazione 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 alle build di debug (-userdebug e -eng, ma non -user) tramite adb senza autorizzazione manuale. Normalmente adb genera una chiave di autenticazione RSA univoca per ogni computer client, che invierà a qualsiasi dispositivo connesso. Questa è la chiave RSA mostrata nella finestra di dialogo di autorizzazione adb. Come alternativa, puoi creare chiavi note nell'immagine di sistema e condividerle con il client adb. Questo è utile per lo sviluppo del sistema operativo e in particolare per i test, in quanto evita di dover interagire manualmente con la finestra di dialogo di autorizzazione adb.

Per creare le chiavi del fornitore, una persona (di solito un gestore delle release) deve:

1. 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.
2. Controlla le coppie di chiavi da qualche parte nell'albero di origine. Google li memorizza ad esempio in vendor/google/security/adb/.
3. Imposta la variabile di compilazione PRODUCT_ADB_KEYS in modo che rimandi alla directory delle chiavi. Google esegue questa operazione aggiungendo un file Android.mk nella directory delle chiavi con il valore PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub, che ci aiuta a ricordare di generare una nuova coppia di chiavi per ogni versione del sistema operativo.

Ecco il file makefile utilizzato da Google nella directory in cui memorizziamo le coppie di chiavi sottoposte a check-in 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 utilizzare queste chiavi del fornitore, un ingegnere deve solo impostare la variabile di ambiente ADB_VENDOR_KEYS in modo che punti alla directory in cui sono memorizzate le coppie di chiavi. Questo indica a adb di provare prima queste chiavi canoniche, prima di ricorrere alla chiave dell'host generata che richiede l'autorizzazione manuale. Quando adb non riesce a connettersi a un dispositivo non autorizzato, il messaggio di errore ti suggerisce di impostare ADB_VENDOR_KEYS se non è già impostato.