Ajout d'un nouvel appareil

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Utilisez les informations de cette page pour créer les makefiles pour votre appareil et votre produit.

Chaque nouveau module Android doit avoir un fichier de configuration pour diriger le système de génération avec les métadonnées du module, les dépendances au moment de la compilation et les instructions d'empaquetage. Android utilise le système de construction Soong . Voir Création d'Android pour plus d'informations sur le système de génération d'Android.

Comprendre les couches de construction

La hiérarchie de construction comprend les couches d'abstraction qui correspondent à la constitution physique d'un appareil. Ces couches sont décrites dans le tableau ci-dessous. Chaque couche est liée à celle qui la surplombe dans une relation un-à-plusieurs. Par exemple, une architecture peut avoir plus d'une carte et chaque carte peut avoir plus d'un produit. Vous pouvez définir un élément dans une couche donnée comme une spécialisation d'un élément dans la même couche, ce qui élimine la copie et simplifie la maintenance.

Couche Exemple La description
Produit monProduit, monProduit_eu, monProduit_eu_fr, j2, sdk La couche de produit définit la spécification des fonctionnalités d'un produit de livraison, telles que les modules à créer, les paramètres régionaux pris en charge et la configuration des différents paramètres régionaux. En d'autres termes, c'est le nom du produit global. Les variables spécifiques au produit sont définies dans les makefiles de définition de produit. Un produit peut hériter d'autres définitions de produits, ce qui simplifie la maintenance. Une méthode courante consiste à créer un produit de base contenant des fonctionnalités qui s'appliquent à tous les produits, puis à créer des variantes de produit basées sur ce produit de base. Par exemple, deux produits qui ne diffèrent que par leurs radios (CDMA versus GSM) peuvent hériter d'un même produit de base qui ne définit pas de radio.
Carte/appareil marlin, ligne bleue, corail La couche carte/dispositif représente la couche physique de plastique sur le dispositif (c'est-à-dire la conception industrielle du dispositif). Cette couche représente également les schémas nus d'un produit. Ceux-ci incluent les périphériques sur la carte et leur configuration. Les noms utilisés sont simplement des codes pour différentes configurations de cartes/dispositifs.
Cambre bras, x86, arm64, x86_64 La couche d'architecture décrit la configuration du processeur et l'interface binaire d'application (ABI) exécutée sur la carte.

Utiliser des variantes de construction

Lors de la construction d'un produit particulier, il est utile d'avoir des variations mineures sur la version finale. Dans une définition de module, le module peut spécifier des balises avec LOCAL_MODULE_TAGS , qui peuvent être une ou plusieurs valeurs optional (par défaut), debug et eng .

Si un module ne spécifie pas de balise (par LOCAL_MODULE_TAGS ), sa balise par défaut est optional . Un module facultatif est installé uniquement s'il est requis par la configuration du produit avec PRODUCT_PACKAGES .

Ce sont les variantes de construction actuellement définies.

Une variante La description
eng C'est la saveur par défaut.
  • Installe les modules étiquetés avec eng ou debug .
  • Installe les modules conformément aux fichiers de définition de produit, en plus des modules balisés.
  • ro.secure=0
  • ro.debuggable=1
  • ro.kernel.android.checkjni=1
  • adb est activé par défaut.
user La variante destinée à être les bits de version finale.
  • Installe les modules marqués avec user .
  • Installe les modules conformément aux fichiers de définition de produit, en plus des modules balisés.
  • ro.secure=1
  • ro.debuggable=0
  • adb est désactivé par défaut.
userdebug Identique à user , à ces exceptions près :
  • Installe également les modules marqués avec debug .
  • ro.debuggable=1
  • adb est activé par défaut.

Lignes directrices pour userdebug

L'exécution de builds userdebug dans les tests aide les développeurs d'appareils à comprendre les performances et la puissance des versions en cours de développement. Pour maintenir la cohérence entre les versions user et userdebug, et pour obtenir des métriques fiables dans les versions utilisées pour le débogage, les développeurs d'appareils doivent suivre ces directives :

  • userdebug est défini comme une construction utilisateur avec un accès root activé, sauf :
    • applications userdebug uniquement qui sont exécutées uniquement à la demande par l'utilisateur
    • Opérations qui s'exécutent uniquement pendant la maintenance inactive (sur chargeur/complètement chargée), telles que l'utilisation de dex2oatd par rapport à dex2oat pour les compilations en arrière-plan
  • N'incluez pas les fonctionnalités activées/désactivées par défaut en fonction du type de build. Les développeurs sont découragés d'utiliser toute forme de journalisation qui affecte la durée de vie de la batterie, telle que la journalisation de débogage ou le vidage de tas.
  • Toutes les fonctionnalités de débogage activées par défaut dans userdebug doivent être clairement définies et partagées avec tous les développeurs travaillant sur le projet. Vous ne devez activer les fonctionnalités de débogage que pour une durée limitée jusqu'à ce que le problème que vous essayez de déboguer soit résolu.

Personnalisation de la construction avec des superpositions de ressources

Le système de génération Android utilise des superpositions de ressources pour personnaliser un produit au moment de la génération. Les superpositions de ressources spécifient les fichiers de ressources qui sont appliqués en plus des valeurs par défaut. Pour utiliser les superpositions de ressources, modifiez le fichier de construction du projet pour définir PRODUCT_PACKAGE_OVERLAYS sur un chemin relatif à votre répertoire de niveau supérieur. Ce chemin devient une racine fantôme recherchée avec la racine actuelle lorsque le système de génération recherche des ressources.

Les paramètres les plus couramment personnalisés sont contenus dans le fichier frameworks/base/core/res/res/values/config.xml .

Pour configurer une superposition de ressources sur ce fichier, ajoutez le répertoire de superposition au fichier de construction du projet en utilisant l'une des méthodes suivantes :

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

ou

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

Ensuite, ajoutez un fichier de superposition au répertoire, par exemple :

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

Toutes les chaînes ou tableaux de chaînes trouvés dans le fichier de superposition config.xml remplacent ceux trouvés dans le fichier d'origine.

Construire un produit

Vous pouvez organiser les fichiers source de votre appareil de différentes manières. Voici une brève description d'une façon d'organiser une implémentation Pixel.

Pixel est implémenté avec une configuration d'appareil principale nommée marlin . À partir de cette configuration de périphérique, un produit est créé avec un fichier makefile de définition de produit qui déclare des informations spécifiques au produit sur le périphérique, telles que le nom et le modèle. Vous pouvez consulter le répertoire device/google/marlin pour voir comment tout cela est configuré.

Rédaction de makefiles de produits

Les étapes suivantes décrivent comment configurer les makefiles des produits d'une manière similaire à celle de la gamme de produits Pixel :

  1. Créez un répertoire device/ <company-name> / <device-name> pour votre produit. Par exemple, device/google/marlin . Ce répertoire contiendra le code source de votre appareil ainsi que les makefiles pour les construire.
  2. Créez un makefile device.mk qui déclare les fichiers et les modules nécessaires pour le périphérique. Pour un exemple, voir device/google/marlin/device-marlin.mk .
  3. Créez un fichier makefile de définition de produit pour créer un produit spécifique basé sur l'appareil. Le makefile suivant est tiré de device/google/marlin/aosp_marlin.mk à titre d'exemple. Notez que le produit hérite des fichiers device/google/marlin/device-marlin.mk et vendor/google/marlin/device-vendor-marlin.mk via le makefile tout en déclarant également les informations spécifiques au produit telles que le nom, la marque, et modèle.
    # 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
    

    Voir Définition des variables de définition de produit pour des variables supplémentaires spécifiques au produit que vous pouvez ajouter à vos makefiles.

  4. Créez un fichier AndroidProducts.mk qui pointe vers les makefiles du produit. Dans cet exemple, seul le makefile de définition de produit est nécessaire. L'exemple ci-dessous provient de device/google/marlin/AndroidProducts.mk (qui contient à la fois le marlin, le Pixel, et le voilier, le Pixel XL, qui partageait la plupart des configurations) :
    PRODUCT_MAKEFILES := \
    	$(LOCAL_DIR)/aosp_marlin.mk \
    	$(LOCAL_DIR)/aosp_sailfish.mk
    
    COMMON_LUNCH_CHOICES := \
    	aosp_marlin-userdebug \
    	aosp_sailfish-userdebug
    
  5. Créez un fichier makefile BoardConfig.mk qui contient des configurations spécifiques à la carte. Pour un exemple, voir device/google/marlin/BoardConfig.mk .
  6. Pour Android 9 et versions antérieures uniquement , créez un fichier vendorsetup.sh pour ajouter votre produit (un "combo déjeuner") à la version avec une variante de version séparée par un tiret. Par exemple :
    add_lunch_combo <product-name>-userdebug
    
  7. À ce stade, vous pouvez créer plus de variantes de produits basées sur le même appareil.

Définition des variables de définition de produit

Les variables spécifiques au produit sont définies dans le makefile du produit. Le tableau montre certaines des variables gérées dans un fichier de définition de produit.

Variable La description Exemple
PRODUCT_AAPT_CONFIG aapt configurations à utiliser lors de la création de packages.
PRODUCT_BRAND La marque (par exemple, l'opérateur) pour laquelle le logiciel est personnalisé, le cas échéant.
PRODUCT_CHARACTERISTICS aapt caractéristiques pour permettre l'ajout de ressources spécifiques à une variante à un package. tablet , nosdcard
PRODUCT_COPY_FILES Liste de mots comme source_path:destination_path . Le fichier du chemin source doit être copié dans le chemin de destination lors de la création de ce produit. Les règles pour les étapes de copie sont définies dans config/makefile .
PRODUCT_DEVICE Nom du dessin ou modèle industriel. Il s'agit également du nom de la carte et le système de construction l'utilise pour localiser BoardConfig.mk . tuna
PRODUCT_LOCALES Une liste séparée par des espaces de code de langue à deux lettres et de paires de codes de pays à deux lettres décrivant plusieurs paramètres pour l'utilisateur, tels que la langue de l'interface utilisateur et le formatage de l'heure, de la date et de la devise. Le premier paramètre régional répertorié dans PRODUCT_LOCALES est utilisé comme paramètre régional par défaut du produit. en_GB , de_DE , es_ES , fr_CA
PRODUCT_MANUFACTURER Nom du fabricant. acme
PRODUCT_MODEL Nom visible par l'utilisateur final pour le produit final.
PRODUCT_NAME Nom visible par l'utilisateur final pour le produit global. Apparaît dans l'écran Paramètres > À propos .
PRODUCT_OTA_PUBLIC_KEYS Liste des clés publiques OTA (over-the-air) pour le produit.
PRODUCT_PACKAGES Liste des APK et modules à installer. Contacts du calendrier
PRODUCT_PACKAGE_OVERLAYS Indique s'il faut utiliser les ressources par défaut ou ajouter des superpositions spécifiques au produit. vendor/acme/overlay
PRODUCT_SYSTEM_PROPERTIES Liste des affectations de propriétés système au format "key=value" pour la partition système. Les propriétés système des autres partitions peuvent être définies via PRODUCT_<PARTITION>_PROPERTIES comme dans PRODUCT_VENDOR_PROPERTIES pour la partition fournisseur. Noms de partition pris en charge : SYSTEM , VENDOR , ODM , SYSTEM_EXT et PRODUCT .

Configuration de la langue système par défaut et du filtre de paramètres régionaux

Utilisez ces informations pour configurer la langue par défaut et le filtre de paramètres régionaux du système, puis activez le filtre de paramètres régionaux pour un nouveau type de périphérique.

Propriétés

Configurez à la fois la langue par défaut et le filtre de paramètres régionaux du système à l'aide des propriétés système dédiées :

  • ro.product.locale : pour définir les paramètres régionaux par défaut. Ceci est initialement défini sur la première locale dans la variable PRODUCT_LOCALES ; vous pouvez remplacer cette valeur. (Pour plus d'informations, consultez le tableau Définition des variables de définition de produit .)
  • ro.localization.locale_filter : pour définir un filtre de locale, en utilisant une expression régulière appliquée aux noms de locale. Par exemple:
    • Filtre inclusif : ^(de-AT|de-DE|en|uk).* - n'autorise que l'allemand (variantes autrichienne et allemande), toutes les variantes anglaises de l'anglais et l'ukrainien
    • Filtre exclusif : ^(?!de-IT|es).* - exclut l'allemand (variante italienne) et toutes les variantes de l'espagnol.

Activer le filtre de paramètres régionaux

Pour activer le filtre, définissez la valeur de chaîne de la propriété système ro.localization.locale_filter .

En définissant la valeur de la propriété du filtre et la langue par défaut via oem/oem.prop lors de l'étalonnage en usine, vous pouvez configurer des restrictions sans intégrer le filtre dans l'image système. Vous vous assurez que ces propriétés sont extraites de la partition OEM en les ajoutant à la variable PRODUCT_OEM_PROPERTIES comme indiqué ci-dessous :

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

Ensuite, en production, les valeurs réelles sont écrites dans oem/oem.prop , pour refléter les exigences cibles. Avec cette approche, les valeurs par défaut sont conservées lors de la réinitialisation d'usine, de sorte que les paramètres initiaux ressemblent exactement à une première configuration pour l'utilisateur.

Configuration de ADB_VENDOR_KEYS pour se connecter via USB

La variable d'environnement ADB_VENDOR_KEYS permet aux fabricants d'appareils d'accéder aux versions débogables (-userdebug et -eng, mais pas -user) via adb sans autorisation manuelle. Normalement, adb génère une clé d'authentification RSA unique pour chaque ordinateur client, qu'il enverra à tout appareil connecté. Il s'agit de la clé RSA affichée dans la boîte de dialogue d'autorisation adb. Comme alternative, vous pouvez créer des clés connues dans l'image système et les partager avec le client adb. Ceci est utile pour le développement du système d'exploitation et en particulier pour les tests, car cela évite d'avoir à interagir manuellement avec la boîte de dialogue d'autorisation adb.

Pour créer des clés de fournisseur, une personne (généralement un gestionnaire de version) doit :

  1. Générez une paire de clés en utilisant adb keygen . Pour les appareils Google, Google génère une nouvelle paire de clés pour chaque nouvelle version du système d'exploitation.
  2. Vérifiez les paires de clés quelque part dans l'arborescence des sources. Google les stocke dans vendor/google/security/adb/ , par exemple.
  3. Définissez la variable de construction PRODUCT_ADB_KEYS pour qu'elle pointe vers votre répertoire de clés. Pour ce faire, Google ajoute un fichier Android.mk dans le répertoire de clés qui indique PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub , ce qui permet de s'assurer que nous nous souvenons de générer une nouvelle paire de clés pour chaque version du système d'exploitation.

Voici le makefile que Google utilise dans le répertoire où nous stockons nos paires de clés enregistrées pour chaque version :

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

Pour utiliser ces clés de fournisseur, un ingénieur n'a qu'à définir la variable d'environnement ADB_VENDOR_KEYS pour qu'elle pointe vers le répertoire dans lequel les paires de clés sont stockées. Cela indique à adb d'essayer d'abord ces clés canoniques, avant de revenir à la clé hôte générée qui nécessite une autorisation manuelle. Lorsque adb ne peut pas se connecter à un appareil non autorisé, le message d'erreur vous suggérera de définir ADB_VENDOR_KEYS s'il n'est pas déjà défini.