Utilisez les informations de cette page pour créer les fichiers Make 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 build Soong . Voir Créer Android pour plus d'informations sur le système de build Android.
Comprendre les couches de construction
La hiérarchie de construction comprend les couches d'abstraction qui correspondent à la composition physique d'un appareil. Ces couches sont décrites dans le tableau ci-dessous. Chaque couche est liée à celle située 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 | Description |
---|---|---|
Produit | monProduit, monProduit_eu, monProduit_eu_fr, j2, sdk | La couche produit définit les spécifications des fonctionnalités d'un produit livré, 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 applicables à tous les produits, puis à créer des variantes de produit basées sur ce produit de base. Par exemple, deux produits qui diffèrent uniquement 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 bruts d’un produit. Ceux-ci incluent les périphériques de la carte et leur configuration. Les noms utilisés sont simplement des codes pour différentes configurations de carte/appareil. |
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 création d'un produit particulier, il est utile d'avoir des variations mineures par rapport à 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 build actuellement définies.
Une variante | Description |
---|---|
eng | C'est la saveur par défaut.
|
user | La variante destinée à être la version finale.
|
userdebug | Identique à user , avec ces exceptions :
|
Lignes directrices pour le débogage utilisateur
L’exécution des 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 maintenir la cohérence entre les builds utilisateur 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 directives :
- userdebug est défini comme un build utilisateur avec l'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é), comme l'utilisation
dex2oatd
contredex2oat
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. Il est déconseillé aux développeurs d'utiliser toute forme de journalisation affectant 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 devez activer les fonctionnalités de débogage uniquement sur une durée limitée jusqu'à ce que le problème que vous essayez de déboguer soit résolu.
Personnalisez la construction avec des superpositions de ressources
Le système de build Android utilise des superpositions de ressources pour personnaliser un produit au moment de la build. 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 build 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 sources 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 de périphérique 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é.
Écrire des 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 :
- 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 créer. - Créez un makefile
device.mk
qui déclare les fichiers et modules nécessaires au périphérique. Pour un exemple, consultezdevice/google/marlin/device-marlin.mk
. - Créez un fichier Make 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 fichiersdevice/google/marlin/device-marlin.mk
etvendor/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.
- Créez un fichier
AndroidProducts.mk
qui pointe vers les makefiles du produit. Dans cet exemple, seul le makefile de définition du produit est nécessaire. L'exemple ci-dessous provient dedevice/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
- Créez un makefile
BoardConfig.mk
contenant des configurations spécifiques à la carte. Pour un exemple, consultezdevice/google/marlin/BoardConfig.mk
. - 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
- À ce stade, vous pouvez créer davantage de variantes de produits basées sur le même appareil.
Définir les variables de définition du 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 | 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é. | |
PRODUCT_CHARACTERISTICS | Caractéristiques aapt 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 situé sur le chemin source doit être copié vers 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 build l'utilise pour localiser BoardConfig.mk . | tuna |
PRODUCT_LOCALES | 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. Les premiers paramètres régionaux répertoriés dans PRODUCT_LOCALES sont utilisés comme paramètres régionaux 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 du fournisseur. Noms de partition pris en charge : SYSTEM , VENDOR , ODM , SYSTEM_EXT et PRODUCT . |
Configurer la langue du système par défaut et le 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 variablePRODUCT_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 paramètres régionaux, en utilisant une expression régulière appliquée aux noms de paramètres régionaux. Par exemple:- Filtre inclus :
^(de-AT|de-DE|en|uk).*
- autorise uniquement l'allemand (variantes d'Autriche et d'Allemagne), 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.
- Filtre inclus :
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 récupérées 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.
Définissez ADB_VENDOR_KEYS pour vous connecter via USB
La variable d'environnement ADB_VENDOR_KEYS
permet aux fabricants de périphériques d'accéder aux versions déboguables (-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 versions) doit :
- Générez 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. - Vérifiez les paires de clés, quelque part dans l'arborescence source. Google les stocke dans
vendor/google/security/adb/
, par exemple. - Définissez la variable de construction
PRODUCT_ADB_KEYS
pour qu'elle pointe vers votre répertoire de clés. Google le fait en ajoutant un fichierAndroid.mk
dans le répertoire de clés indiquantPRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub
, ce qui permet de garantir que nous n'oublions pas 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é d'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.