Cette page a été traduite par l'API Cloud Translation.

Ajouter un appareil

Utilisez les informations de cette page pour créer les fichiers makefile de votre appareil et 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 Song. Pour en savoir plus sur la console Android, consultez l'article Building Android (Concevoir pour Android). du système de compilation.

Comprendre les couches de compilation

La hiérarchie de compilation inclut les couches d'abstraction qui correspondent la composition physique d'un appareil. Ces couches sont décrites dans le tableau ci-dessous. Chaque couche se rapporte à celle qui la précède dans une relation de type un à plusieurs. Pour Par exemple, une architecture peut avoir plusieurs cartes et chaque carte peut avoir plusieurs produits. Vous pouvez définir un élément d'un calque donné en tant que d'un élément de la même couche, ce qui élimine la copie la maintenance est simplifiée.

Calque	Exemple	Description
Produit	myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk	Le calque produit définit les spécifications d'une livraison comme les modules à compiler, les paramètres régionaux pris en charge et configuration pour différents paramètres régionaux. En d'autres termes, il s'agit du name du produit dans son ensemble. Les variables spécifiques au produit sont définies des fichiers de définition de produits. Un produit peut hériter d'autres les définitions de produit, ce qui simplifie la maintenance. Une méthode courante est de créer un produit de base qui contient des caractéristiques qui s'appliquent à tous les produits, puis créer des variantes de produits en fonction de cette base produit. Par exemple, deux produits qui ne diffèrent que par leurs signaux radio (CDMA ou GSM) peuvent hériter du même produit de base que ne définit pas de radio.
Carte/Appareil	marlin, ligne bleue, corail	La couche du tableau/appareil représente la couche physique de plastique sur le (de conception industrielle de l'appareil). Cette couche représente également des schémas d'un produit. Ceux-ci incluent les périphériques du tableau et leurs configuration. Les noms utilisés sont simplement des codes pour différentes cartes/appareils. de configuration.
Arche	arm, x86, arm64, x86_64	La couche d'architecture décrit la configuration du processeur une interface binaire d'application (ABI) s'exécutant sur la carte.

Utiliser des variantes de compilation

Lors de la construction d'un produit particulier, il est utile d'avoir des sur le build final. Dans un 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), son par défaut est optional. Un module facultatif n'est installé que si requise par la configuration du produit avec PRODUCT_PACKAGES.

Voici les variantes de compilation actuellement définies.

Variant	Description
`eng`	Il s'agit du type de produit par défaut. Installe les modules dotés des tags `eng` ou `debug`. Installe les modules conformément aux fichiers de définition de produit, dans en plus des modules tagués. `ro.secure=0` `ro.debuggable=1` `ro.kernel.android.checkjni=1` `adb` est activé par défaut.
`user`	Variante destinée à constituer les bits de version finaux. Installe les modules dotés de la balise `user`. Installe les modules conformément aux fichiers de définition de produit, dans en plus des modules tagués. `ro.secure=1` `ro.debuggable=0` `adb` est désactivé par défaut.
`userdebug`	Identique à `user`, à quelques exceptions près: <ph type="x-smartling-placeholder"> </ph> Installe également les modules associés au tag `debug`. `ro.debuggable=1` `adb` est activé par défaut.

Consignes pour le débogage utilisateur

L'exécution des versions userdebug dans les tests aide les développeurs d'appareils à comprendre les performances et la puissance des versions en 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 d'utilisateur avec l'accès root activé, sauf: <ph type="x-smartling-placeholder">
- Applications userdebug uniquement exécutées uniquement à la demande par l'utilisateur
- Opérations uniquement en cas de maintenance inactive (sur le chargeur/entièrement (par exemple, en utilisant dex2oatd ou 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 compilation. Les développeurs sont déconseillés aux développeurs d'utiliser toute forme de journalisation qui affecte l'autonomie de la batterie, par exemple la journalisation du débogage ou l'empreinte de la mémoire.
Toutes les fonctionnalités de débogage activées par défaut dans userdebug doivent être clairement définies. et partagé avec tous les développeurs travaillant sur le projet. Vous 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 compilation Android utilise les superpositions de ressources pour personnaliser un produit au moment de la compilation. Les superpositions de ressources spécifient de fichiers qui sont appliqués en plus des valeurs par défaut. Pour utiliser les superpositions de ressources, modifiez le projet buildfile pour définir PRODUCT_PACKAGE_OVERLAYS sur chemin relatif à votre répertoire de premier niveau. 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 souvent 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 à l'aide de l'un des éléments suivants:

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

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 tous les tableaux de chaînes trouvés dans le fichier de superposition config.xml 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 un récapitulatif description d'une façon d'organiser l'implémentation d'un Pixel.

Le Pixel est implémenté avec une configuration d'appareil principale nommée marlin À partir de cette configuration d'appareil, un produit est créé avec un le fichier makefile de la définition de produit qui déclare des informations spécifiques sur le produit l'appareil, comme son nom et son modèle. Vous pouvez consulter device/google/marlin pour voir comment tout cela est configuré.

Écrire des fichiers de création de produits

Les étapes suivantes décrivent comment configurer les fichiers makefile des produits de la même manière par rapport à celle de la gamme de produits Pixel:

Créer un device/<company-name>/<device-name> pour votre produit. Par exemple, device/google/marlin. Ce répertoire contiendra le code source pour votre appareil ainsi que les fichiers makefile pour les compiler.
Créez un fichier makefile device.mk qui déclare les fichiers et les modules nécessaires à la appareil. Pour obtenir un exemple, consultez device/google/marlin/device-marlin.mk.

Créez un fichier makefile de définition de produit pour créer un produit spécifique en fonction de l'appareil. La Le fichier makefile suivant est tiré de 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 via le fichier makefile déclarer également 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, consultez la section Définir des variables de définition de produit des variables spécifiques au produit que vous pouvez ajouter à vos fichiers makefiles.

Créez un fichier AndroidProducts.mk qui pointe vers les fichiers makefile du produit. Dans cet exemple, seul le fichier makefile de la définition de produit est nécessaire. L'exemple ci-dessous provient device/google/marlin/AndroidProducts.mk (qui contient à la fois du marlin, le Pixel, et sailfish, le Pixel XL, qui partageait le plus de configuration):
```
PRODUCT_MAKEFILES := \
	$(LOCAL_DIR)/aosp_marlin.mk \
	$(LOCAL_DIR)/aosp_sailfish.mk

COMMON_LUNCH_CHOICES := \
	aosp_marlin-userdebug \
	aosp_sailfish-userdebug
```
Créez un fichier makefile BoardConfig.mk contenant les configurations spécifiques à une carte. Pour obtenir un exemple, consultez device/google/marlin/BoardConfig.mk.
Pour Android 9 et versions antérieures uniquement, créez un vendorsetup.sh pour ajouter votre produit (une "combo déjeuner") à la compilation avec une variante de compilation séparés par un tiret. Par exemple:
```
add_lunch_combo <product-name>-userdebug
```
À ce stade, vous pouvez créer d'autres variantes de produits pour le même appareil.

Définir des variables de définition de produit

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

Variable	Description	Exemple
`PRODUCT_AAPT_CONFIG`	Configurations `aapt` à utiliser lors de la création de packages.
`PRODUCT_BRAND`	Marque (par exemple, l'opérateur) pour laquelle le logiciel est personnalisé.
`PRODUCT_CHARACTERISTICS`	Les caractéristiques `aapt` permettent d'ajouter des ressources spécifiques aux variantes à un package.	`tablet`, `nosdcard`
`PRODUCT_COPY_FILES`	Liste de mots tels que `source_path:destination_path`. Fichier dans le chemin d'accès source doit être copié dans le chemin de destination lors de la création de ce produit. Règles concernant la copie les étapes sont définies dans `config/makefile`.
`PRODUCT_DEVICE`	Nom du design industriel. Il s'agit également du nom de la carte, et le système de compilation l'utilise. pour localiser `BoardConfig.mk`.	`tuna`
`PRODUCT_LOCALES`	Liste de codes de langue à deux lettres, séparés par un espace, décrire plusieurs paramètres pour l'utilisateur, tels que la langue et l'heure de l'interface utilisateur, la date et la mise en forme des devises. La première langue répertoriée dans `PRODUCT_LOCALES` est utilisée comme les 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 du produit final visible par l'utilisateur final.
`PRODUCT_NAME`	Nom du produit visible par l'utilisateur final. Cette option apparaît dans Paramètres > À propos.
`PRODUCT_OTA_PUBLIC_KEYS`	Liste des clés publiques Over The Air (OTA) du produit.
`PRODUCT_PACKAGES`	Liste des APK et des modules à installer.	Contacts de l'agenda
`PRODUCT_PACKAGE_OVERLAYS`	Indique s'il faut utiliser des ressources par défaut ou ajouter des superpositions spécifiques au produit.	`vendor/acme/overlay`
`PRODUCT_SYSTEM_PROPERTIES`	Liste des attributions de propriétés système au format `"key=value"` pour la valeur 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 des fournisseurs. Partition compatible noms: `SYSTEM`, `VENDOR`, `ODM`, `SYSTEM_EXT` et `PRODUCT`.

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

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

Propriétés

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

ro.product.locale: permet de définir les paramètres régionaux par défaut. Il est initialement défini dans la variable PRODUCT_LOCALES. vous pouvez remplacer cette valeur. Pour en savoir plus, consultez les Définir 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 des paramètres régionaux. Par exemple: <ph type="x-smartling-placeholder">
- Filtre inclusif : ^(de-AT|de-DE|en|uk).* : seul l'allemand (Allemagne et Autriche) est autorisé. variantes anglaises), toutes les variantes anglaises de l'anglais et l'ukrainien
- Filtre exclusif: ^(?!de-IT|es).* - exclut l'allemand (variante de l'Italie) et tous des variantes de l'espagnol.

Activer le filtre des 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é de filtre et la langue par défaut via oem/oem.prop pendant calibrage 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 dans la partition OEM en les ajoutant au 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 la cible exigences. 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 exactement à une première configuration pour l'utilisateur.

Configurer ADB_VENDOR_KEYS pour une connexion USB

La variable d'environnement ADB_VENDOR_KEYS permet aux fabricants d'appareils d'accéder 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 enverra à n'importe quel appareil connecté. Il s'agit de la clé RSA affichée dans la boîte de dialogue d'autorisation adb. En tant que vous pouvez 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 de systèmes d'exploitation et en particulier pour les tests, car il évite d'avoir à interagissent 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:

Générez une paire de clés à l'aide de adb keygen. Pour les appareils Google, Google génère un nouveau 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 compilation PRODUCT_ADB_KEYS de sorte qu'elle pointe vers le répertoire de votre clé. Pour ce faire, Google ajoute un fichier Android.mk dans le répertoire de la clé, qui indique PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub, 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 fichier makefile que Google utilise dans le répertoire où nous stockons les paires de clés enregistrées pour chaque sortie:

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, il suffit à un ingénieur de définir ADB_VENDOR_KEYS variable d'environnement pour indiquer 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 aux clés générées qui nécessite une autorisation manuelle. Lorsque adb ne parvient pas à se connecter à un réseau non autorisé appareil, le message d'erreur vous suggère de définir ADB_VENDOR_KEYS si ce n'est pas déjà défini.