Aggiungere un nuovo dispositivo

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 packaging. Android utilizza il sistema di compilazione Soong. Per saperne di più sul sistema di build di Android, consulta la sezione Building Android.

Informazioni sui livelli di build

La gerarchia delle 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 sopra in una relazione one-to-many. Ad esempio, un'architettura può avere più di una scheda e ogni scheda può avere più di un prodotto. Puoi definire un elemento in un determinato livello come specializzazione di un elemento nello stesso livello, il che elimina la copia e semplifica la manutenzione.

Utilizzare le varianti di build

Quando crei una build per un prodotto specifico, è utile avere piccole variazioni sulla build di rilascio 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 (tramite LOCAL_MODULE_TAGS), il 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 nei test aiuta gli sviluppatori di dispositivi a comprendere le prestazioni e il consumo energetico delle release in fase di sviluppo. Per mantenere la coerenza tra le build user e userdebug e per 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, tranne:
  • app solo per il debug utente eseguite solo on demand dall'utente
  • Operazioni eseguite solo durante la manutenzione inattiva (durante la ricarica/a batteria completamente carica), ad esempio l'utilizzo di dex2oatd anziché di dex2oat per le compilazioni in background
• Non includere funzionalità attivate/disattivate per impostazione predefinita in base al tipo di build. Gli sviluppatori sono invitati a non utilizzare alcuna forma di logging che influisca sulla durata della batteria, ad esempio il logging di debug o il dump dell'heap.
• Tutte le funzionalità di debug abilitate per impostazione predefinita in userdebug devono essere definite chiaramente 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 build con le sovrapposizioni delle risorse

Il sistema di compilazione Android utilizza le sovrapposizioni di risorse per personalizzare un prodotto in fase di compilazione. Gli overlay delle risorse specificano i file di risorse che vengono applicati sopra i valori predefiniti. Per utilizzare le sovrapposizioni delle risorse, modifica il file di build del progetto per impostare PRODUCT_PACKAGE_OVERLAYS su un percorso relativo alla directory di primo livello. Questo percorso diventa una radice ombra in cui viene eseguita la ricerca insieme alla radice corrente quando il sistema di compilazione cerca le risorse.

Le impostazioni personalizzate più comuni sono contenute nel file frameworks/base/core/res/res/values/config.xml.

Per configurare una sovrapposizione di risorse su questo file, aggiungi la directory di sovrapposizione al file di build del progetto utilizzando uno dei seguenti metodi:

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

o

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

Qualsiasi stringa o array di stringhe trovato nel file config.xml di sovrapposizione sostituisce quelli trovati 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 nome e modello. Puoi visualizzare la directory device/google/marlin per vedere come è configurato tutto.

Scrivere makefile di prodotto

I passaggi seguenti descrivono come configurare i makefile dei prodotti in modo simile a quello della 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 makefile per compilarli.
2. Crea un makefile 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 makefile di definizione del prodotto per creare un prodotto specifico in base al dispositivo. Il seguente makefile è tratto da device/google/marlin/aosp_marlin.mk come esempio. Tieni presente che il prodotto eredita dai file device/google/marlin/device-marlin.mk e vendor/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 altre variabili specifiche del prodotto che puoi aggiungere ai tuoi makefile.

4. Crea un file AndroidProducts.mk che rimandi ai makefile del prodotto. In questo esempio, è necessario solo il makefile di definizione del prodotto. L'esempio riportato di seguito è tratto da device/google/marlin/AndroidProducts.mk (che contiene sia marlin, Pixel, sia sailfish, Pixel XL, che condividevano la maggior parte della configurazioni):

   PRODUCT_MAKEFILES := \
   	$(LOCAL_DIR)/aosp_marlin.mk \
   	$(LOCAL_DIR)/aosp_sailfish.mk
   
   COMMON_LUNCH_CHOICES := \
   	aosp_marlin-userdebug \
   	aosp_sailfish-userdebug
   

5. Crea un makefile BoardConfig.mk che contenga configurazioni specifiche per la scheda. Per un esempio, vedi device/google/marlin/BoardConfig.mk.
6. Per Android 9 e versioni precedenti solo, crea un file vendorsetup.sh per aggiungere il tuo prodotto (un "menu pranzo") alla build insieme a una variante di build separata da un trattino. Ad esempio:

   add_lunch_combo <product-name>-userdebug
   

7. A questo punto, puoi creare altre 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 mantenute in un file di definizione del prodotto.

Configurare il filtro predefinito per la lingua e le impostazioni internazionali del sistema

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

Proprietà

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

• ro.product.locale: per impostare le impostazioni internazionali predefinite. Inizialmente, questo valore è impostato sul primo locale nella variabile PRODUCT_LOCALES; puoi sostituire questo valore. Per ulteriori informazioni, consulta la tabella 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 (varianti di Austria e Germania), tutte le varianti di inglese e l'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à del filtro e la lingua predefinita tramite oem/oem.prop durante la calibrazione di fabbrica, puoi configurare le limitazioni senza incorporare il filtro nell'immagine di sistema. Assicurati che queste proprietà vengano recuperate 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

Poi, 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, quindi le impostazioni iniziali appaiono esattamente come 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 a build di cui è possibile eseguire il 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 invia a qualsiasi dispositivo connesso. Questa è la chiave RSA mostrata nella finestra di dialogo di autorizzazione adb. In alternativa, puoi incorporare 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, perché evita la necessità di interagire manualmente con la finestra di dialogo di autorizzazione adb.

Per creare le chiavi del fornitore, una persona (di solito un responsabile 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 in un punto qualsiasi dell'albero delle origini. Google li memorizza in vendor/google/security/adb/, ad esempio.
3. Imposta la variabile di build PRODUCT_ADB_KEYS in modo che rimandi alla directory delle chiavi. Google lo fa aggiungendo un file Android.mk nella directory delle chiavi che indica PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub, il che contribuisce a garantire che venga generata una nuova coppia di chiavi per ogni versione del sistema operativo.

Ecco il makefile che Google utilizza nella directory in cui archiviamo le coppie di chiavi archiviate 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 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. In questo modo, adb proverà 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 ti suggerisce di impostare ADB_VENDOR_KEYS, se non è già impostato.