Ajouter un 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 fichiers de compilation de votre appareil et de votre produit.

Chaque nouveau module Android doit disposer d'un fichier de configuration pour diriger le système de compilation avec les métadonnées du module, les dépendances au moment de la compilation et les instructions de packaging. Android utilise le système de compilation Soong. Pour en savoir plus sur le système de compilation Android, consultez Créer Android.

Comprendre les couches de compilation

La hiérarchie de compilation inclut les couches d'abstraction qui correspondent à la composition physique d'un appareil. Ces calques sont décrits dans le tableau ci-dessous. Chaque couche est liée à celle qui la précède dans une relation de type un à plusieurs. Par exemple, une architecture peut comporter plusieurs cartes, et chaque carte peut comporter plusieurs produits. Vous pouvez définir un élément d'une couche donnée comme une spécialisation d'un élément de la même couche, ce qui élimine la copie et simplifie la maintenance.

Utiliser des variantes de compilation

Lorsque vous créez un build pour 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 peut être une ou plusieurs valeurs de optional (par défaut), debug et eng.

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

Voici les variantes de compilation actuellement définies.

Consignes concernant userdebug

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

• userdebug est défini comme un build utilisateur avec l'accès racine activé, sauf :
  • Applications userdebug uniquement exécutées à la demande par l'utilisateur
  • Opérations qui ne s'exécutent que pendant la maintenance inactive (sur le chargeur/complètement chargée), par exemple en utilisant dex2oatd au lieu de dex2oat pour les compilations en arrière-plan
• N'incluez pas de fonctionnalités activées/désactivées par défaut en fonction du type de compilation. Les développeurs sont invités à ne pas utiliser de forme de journalisation qui affecte l'autonomie de la batterie, comme 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 pendant une durée limitée, jusqu'à ce que le problème que vous essayez de déboguer soit résolu.

Personnaliser le build avec des superpositions de ressources

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

Les paramètres les plus couramment personnalisés se trouvent 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 compilation du projet à l'aide de l'une des méthodes suivantes:

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

ou

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

Ajoutez ensuite 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 les tableaux de chaînes trouvés dans le fichier config.xml de superposition remplacent celles trouvées dans le fichier d'origine.

Créer un produit

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

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

Écrire des fichiers de compilation de produits

Les étapes suivantes décrivent comment configurer les fichiers de compilation de produits de manière semblable à 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 fichiers de compilation permettant de le compiler.
2. Créez un fichier makefile device.mk qui déclare les fichiers et les modules nécessaires à l'appareil. Pour obtenir un exemple, consultez device/google/marlin/device-marlin.mk.
3. Créez un fichier makefile de définition de produit pour créer un produit spécifique en fonction de l'appareil. Le fichier makefile suivant est extrait 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 fichier de compilation, tout en déclarant les informations spécifiques au produit, telles que le nom, la marque et le 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
   

   Pour en savoir plus sur les variables spécifiques aux produits que vous pouvez ajouter à vos fichiers de compilation, consultez Définir des variables de définition de produit.

4. Créez un fichier AndroidProducts.mk qui pointe vers les fichiers make du produit. Dans cet exemple, seul le fichier makefile de définition du produit est nécessaire. L'exemple ci-dessous provient de device/google/marlin/AndroidProducts.mk (qui contient à la fois marlin, le Pixel, et sailfish, 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 contenant des configurations spécifiques à la carte. Pour obtenir un exemple, consultez 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 repas") à la compilation, ainsi qu'une variante de compilation séparée par un tiret. Exemple :

   add_lunch_combo <product-name>-userdebug
   

7. À ce stade, vous pouvez créer d'autres variantes de produits basées sur le même appareil.

Définir des variables de définition des produits

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

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

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

Propriétés

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

• ro.product.locale: pour définir les paramètres régionaux par défaut. Cette valeur est initialement définie sur la première locale de la variable PRODUCT_LOCALES. Vous pouvez remplacer cette valeur. (Pour en savoir plus, consultez le tableau Définir des variables de définition des produits.)
• ro.localization.locale_filter: pour définir un filtre de paramètres régionaux, à l'aide d'une expression régulière appliquée aux noms de paramètres régionaux. Par exemple :
  • Filtre inclusif : ^(de-AT|de-DE|en|uk).* : n'autorise que l'allemand (variantes de l'Allemagne et de l'Autriche), toutes les variantes de l'anglais et l'ukrainien
  • Filtre exclusif : ^(?!de-IT|es).* : exclut l'allemand (variante Italie) et toutes les variantes de l'espagnol.

Activer le filtre de paramètres régionaux

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

En définissant la valeur de la propriété de filtre et la langue par défaut via oem/oem.prop lors du calibrage en usine, vous pouvez configurer des restrictions sans intégrer le filtre à l'image système. Pour vous assurer que ces propriétés sont récupérées à partir de la partition OEM, ajoutez-les à la variable PRODUCT_OEM_PROPERTIES, comme indiqué ci-dessous:

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

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 du rétablissement de la configuration d'usine. Les paramètres initiaux ressemblent donc exactement à une première configuration pour l'utilisateur.

Définir ADB_VENDOR_KEYS pour se connecter via USB

La variable d'environnement ADB_VENDOR_KEYS permet aux fabricants d'appareils d'accéder aux builds 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 envoie à tous les appareils connectés. Il s'agit de la clé RSA affichée dans la boîte de dialogue d'autorisation adb. Vous pouvez également créer des clés connues dans l'image système et les partager avec le client adb. Cela est utile pour le développement d'OS et surtout pour les tests, car cela évite d'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 responsable de la publication) doit:

1. Générez une paire de clés à l'aide de adb keygen. Pour les appareils Google, Google génère une nouvelle paire de clés pour chaque nouvelle version d'OS.
2. Vérifiez les paires de clés dans l'arborescence source. Google les stocke dans vendor/google/security/adb/, par exemple.
3. Définissez la variable de compilation 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 avec la valeur PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub, ce qui permet de s'assurer de générer une nouvelle paire de clés pour chaque version d'OS.

Voici le fichier 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 parvient pas à se connecter à un appareil non autorisé, le message d'erreur vous suggère de définir ADB_VENDOR_KEYS s'il n'est pas déjà défini.