Ajout d'un nouvel appareil

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.

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.

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.

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.