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 construction 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 bâtiment Android pour plus d' informations sur le système de construction Android.

Comprendre les couches de construction

La hiérarchie de construction comprend les couches d'abstraction qui correspondent à la constitution physique d'un périphérique. Ces couches sont décrites dans le tableau ci-dessous. Chaque couche est liée à celle au-dessus dans une relation un-à-plusieurs. Par exemple, une architecture peut avoir plusieurs cartes et chaque carte peut avoir plusieurs produits. 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 produit définit les spécifications des fonctionnalités d'un produit d'expédition, telles que les modules à créer, les paramètres régionaux pris en charge et la configuration pour divers paramètres régionaux. En d' autres termes, c'est le nom du produit dans son ensemble. 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 produit, ce qui simplifie la maintenance. Une méthode courante consiste à créer un produit de base qui contient 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 du même produit de base qui ne définit pas de radio.
Carte/appareil marlin, ligne bleue, corail La couche carte/appareil représente la couche physique de plastique sur l'appareil (c'est-à-dire la conception industrielle de l'appareil). 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 ne sont que des codes pour différentes configurations de carte/dispositif.
Cambre bras, x86, bras64, 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 build

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

Si un module ne spécifie pas de balise (par LOCAL_MODULE_TAGS ), ses paramètres par défaut d'étiquette à optional . Un module optionnel est installé que si elle est requise par la configuration du produit avec PRODUCT_PACKAGES .

Ce sont les variantes de build actuellement définies.

Une variante La description
eng C'est la saveur par défaut.
  • Installe modules étiquetés avec eng ou debug .
  • Installe les modules en fonction des fichiers de définition du 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 la version finale.
  • Installer les modules étiquetés avec l' user .
  • Installe les modules conformément aux fichiers de définition du produit, en plus des modules balisés.
  • ro.secure=1
  • ro.debuggable=0
  • adb est désactivé par défaut.
userdebug La même chose que l' user , avec ces exceptions:
  • Installe également les modules marqués avec debug .
  • ro.debuggable=1
  • adb est activé par défaut.

Instructions 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 développement. Pour maintenir la cohérence entre les builds user et userdebug, et pour obtenir des métriques fiables dans les builds utilisées pour le débogage, les développeurs d'appareils doivent suivre ces instructions :

  • userdebug est défini comme une version utilisateur avec accès root activé, sauf :
    • les applications userdebug uniquement qui sont exécutées uniquement à la demande par l'utilisateur
    • Les opérations qui ne fonctionnent que pendant la maintenance au ralenti, comme l' utilisation (sur le chargeur / complètement chargé) dex2oatd par rapport dex2oat pour compiles de fond
  • 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.

Personnaliser le build 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, modifier le projet de buildfile ensemble PRODUCT_PACKAGE_OVERLAYS à un chemin relatif au répertoire de haut niveau. 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 fréquemment sur mesure sont contenus dans le fichier cadres / base / core / res / res / valeurs / config.xml .

Pour configurer une superposition de ressources sur ce fichier, ajoutez le répertoire de superposition au fichier de construction du projet à l'aide de l'un des éléments suivants :

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 des tableaux de chaînes trouvées dans la superposition config.xml fichier remplacent celles figurant 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 mis en œuvre avec une configuration principale de l' appareil nommé 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 voir le device/google/marlin répertoire pour voir comment tout cela est mis en place.

Rédaction de makefiles de produits

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

  1. Créer un device/ <company-name> / <device-name> répertoire pour votre produit. Par exemple, l' device/google/marlin . Ce répertoire contiendra le code source de votre appareil ainsi que les makefiles pour les construire.
  2. Créer un device.mk makefile qui déclare les fichiers et les modules nécessaires à l'appareil. Pour un exemple, voir l' device/google/marlin/device-marlin.mk .
  3. Créez un makefile de définition de produit pour créer un produit spécifique basé sur l'appareil. Le makefile suivant est extrait du device/google/marlin/aosp_marlin.mk à titre d'exemple. Notez que le produit hérite du device/google/marlin/device-marlin.mk et vendor/google/marlin/device-vendor-marlin.mk fichiers par le makefile tout en déclarant les informations produits spécifiques tels 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 les variables supplémentaires spécifiques de produits que vous pouvez ajouter à votre makefile.

  4. Créer un AndroidProducts.mk fichier qui pointe vers les makefiles du produit. Dans cet exemple, seul le fichier makefile de définition de produit est nécessaire. L'exemple ci - dessous est de device/google/marlin/AndroidProducts.mk (qui contient à la fois Marlin, le pixel, et le voilier, le pixel XL, qui partage la plupart configuration):
    PRODUCT_MAKEFILES := \
    	$(LOCAL_DIR)/aosp_marlin.mk \
    	$(LOCAL_DIR)/aosp_sailfish.mk
    
    COMMON_LUNCH_CHOICES := \
    	aosp_marlin-userdebug \
    	aosp_sailfish-userdebug
    
  5. Créer un BoardConfig.mk makefile qui contient des configurations spécifiques du conseil d'administration. Pour un exemple, voir l' device/google/marlin/BoardConfig.mk .
  6. Pour Android 9 et seulement réduire, créez un vendorsetup.sh fichier pour ajouter votre produit (un « combo déjeuner ») à la construction avec une variante de construction séparés 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 conservé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 variant à un package. tablet , nosdcard
PRODUCT_COPY_FILES Liste des 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 industriel. Ceci est également le nom du conseil d'administration, et le système de construction utilise pour localiser BoardConfig.mk . tuna
PRODUCT_LOCALES Une liste séparée par des espaces de codes de langue à deux lettres et de paires de codes de pays à deux lettres qui décrivent 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. La première dans la liste locale PRODUCT_LOCALES est utilisée comme langue 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 l'ensemble du produit. Apparaît dans les Paramètres> À propos de l' écran.
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 du système dans le format "key=value" pour la partition système. Propriétés système pour d' autres partitions peuvent être réglées via PRODUCT_<PARTITION>_PROPERTIES comme dans PRODUCT_VENDOR_PROPERTIES pour la partition du fournisseur. Noms de partitions pris en charge: SYSTEM , VENDOR , ODM , SYSTEM_EXT et PRODUCT .

Configuration de la langue du 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 régler les paramètres régionaux par défaut. Ceci est initialement fixé à la première locale dans la PRODUCT_LOCALES variable; vous pouvez remplacer cette valeur. (Pour plus d' informations, voir les variables de définition des produits de réglage table.)
  • ro.localization.locale_filter : pour régler un filtre de paramètres régionaux, en utilisant une expression régulière appliquée aux noms locaux. Par exemple:
    • Filtre inclusif: ^(de-AT|de-DE|en|uk).* - permet que l' allemand (Autriche et Allemagne variantes), toutes les variantes anglaise de l' anglais, et ukrainien
    • Filtre exclusif: ^(?!de-IT|es).* - exclut 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 ro.localization.locale_filter valeur de chaîne de propriété système.

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

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

Puis , en production , les valeurs réelles sont écrites oem/oem.prop , pour tenir compte des 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.

Paramétrer ADB_VENDOR_KEYS pour se connecter via USB

La ADB_VENDOR_KEYS variable d'environnement permet aux fabricants de périphériques d'accès débogable construit (-userdebug et -fr, mais pas -user) sur 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 responsable des versions) doit :

  1. Générer une paire de clés à l' aide 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 stocke eux dans vendor/google/security/adb/ , par exemple.
  3. Définissez les variables de construction PRODUCT_ADB_KEYS pour pointer vers votre répertoire clé. Google fait cela en ajoutant un Android.mk fichier dans le répertoire clé qui dit PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub , ce qui contribue à faire en sorte 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 vendeur, un ingénieur doit seulement définir la ADB_VENDOR_KEYS variable d'environnement pour pointer vers le répertoire dans lequel les paires de clés sont stockées. Cela dit adb d'essayer ces clés canoniques d' abord, avant de retomber à la clé d'hôte généré qui requiert une autorisation manuelle. Lorsque adb ne peut pas se connecter à un périphérique non autorisé, le message d'erreur suggère que vous définissez ADB_VENDOR_KEYS si elle est pas déjà défini.