Avant la sortie Android 7.0, Android utilisé Marque GNU exclusivement pour décrire et exécuter ses règles de construction. Le système de construction Make est largement pris en charge et utilisé, mais à l'échelle d'Android, il est devenu lent, sujet aux erreurs, non évolutif et difficile à tester. Le système de construction Soong offre la flexibilité nécessaire pour Android construit.
Pour cette raison, les développeurs de plateformes devraient passer de Make et adopter Soong dès que possible. Envoyez vos questions à l' android-construction du groupe Google pour bénéficier d'un soutien.
Qu'est-ce que Soong ?
Le système de construction Soong a été introduit dans Android 7.0 (Nougat) pour remplacer Marque. Il tire parti de l' Kati outil clone GNU Make et Ninja composants système de construction pour accélérer construit d'Android.
Voir le Android Faire construire le système de description dans le Android Open Source Project (AOSP de) pour général des instructions et construire Modifications du système pour Android.mk Writers pour en savoir plus sur les modifications nécessaires à l' adaptation d' une marque à Soong.
Voir les entrées relatives à la construction dans le glossaire des définitions des termes clés et les fichiers de référence Soong pour tous les détails.
Comparaison Make et Soong
Voici une comparaison de configuration avec Soong Faire accomplir la même chose dans une configuration Soong (Blueprint ou .bp fichier).
Faire un exemple
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libxmlrpc++
LOCAL_MODULE_HOST_OS := linux
LOCAL_RTTI_FLAG := -frtti
LOCAL_CPPFLAGS := -Wall -Werror -fexceptions
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/src
LOCAL_SRC_FILES := $(call \
all-cpp-files-under,src)
include $(BUILD_SHARED_LIBRARY)
Exemple de soong
cc_library_shared {
name: “libxmlrpc++”,
rtti: true,
cppflags: [
“-Wall”,
“-Werror”,
“-fexceptions”,
],
export_include_dirs: [“src”],
srcs: [“src/**/*.cpp”],
target: {
darwin: {
enabled: false,
},
},
}
Voir Configuration simple de construction pour Soong test spécifique des exemples de configuration.
Format de fichier Android.bp
De par sa conception, Android.bp fichiers sont simples. Ils ne contiennent pas d'instructions conditionnelles ou de flux de contrôle ; toute la complexité est gérée par une logique de construction écrite en Go. Lorsque cela est possible, la syntaxe et la sémantique des Android.bp fichiers sont similaires à des fichiers BUILD Bazel .
Modules
Un module dans un Android.bp commence fichier avec un type de module suivi d'un ensemble de propriétés dans le name: "value", Format:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Chaque module doit avoir un name propriété et la valeur doit être unique dans tous Android.bp fichiers, à l' exception des name valeurs de propriété dans les espaces de noms et des modules préconstruits, qui peut répéter.
Les srcs propriété spécifie les fichiers source utilisés pour construire le module, comme une liste de chaînes. Vous pouvez faire référence à la sortie d'autres modules qui produisent des fichiers source, comme genrule ou filegroup de ":<module-name>" filegroup , en utilisant la syntaxe de référence du module ":<module-name>" .
Pour une liste des types de modules valides et leurs propriétés, consultez les modules Soong de référence .
Les types
Les variables et les propriétés sont fortement typées, avec des variables basées dynamiquement sur la première affectation et des propriétés définies statiquement par le type de module. Les types pris en charge sont :
- Booléens (
trueoufalse) - Les entiers (
int) - Cordes (
"string") - Des listes de chaînes (
["string1", "string2"]) - Cartes (
{key1: "value1", key2: ["value2"]})
Les cartes peuvent contenir des valeurs de tout type, y compris des cartes imbriquées. Les listes et les cartes peuvent avoir des virgules de fin après la dernière valeur.
Globes
Les propriétés qui prennent une liste de fichiers, tels que srcs , peuvent également utiliser des motifs de glob. Les modèles de Glob peuvent contenir le caractère générique UNIX normale * , par exemple *.java . Les modèles de Glob peuvent également contenir un seul ** générique comme un élément de trajet, qui correspond à zéro ou plusieurs éléments de chemin. Par exemple, java/**/*.java correspond à la fois la java/Main.java et java/com/android/Main.java modèles.
Variables
Un Android.bp fichier peut contenir des affectations de variables de niveau supérieur:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
Les variables sont étendues au reste du fichier dans lequel elles sont déclarées, ainsi qu'à tous les fichiers Blueprint enfants. Les variables sont immuables à une exception près: ils peuvent être ajoutés à un += affectation, mais seulement avant qu'ils aient été référencés.
commentaires
Android.bp fichiers peuvent contenir C style multiligne /* */ et le style C ++ une seule ligne // commentaires.
Les opérateurs
Les chaînes, les listes de chaînes et les cartes peuvent être ajoutées à l'aide de l'opérateur +. Entiers peut se résumer à l' aide du + opérateur. L'ajout d'une carte produit l'union des clés dans les deux cartes, en ajoutant les valeurs de toutes les clés présentes dans les deux cartes.
Conditionnels
Soong ne supporte pas les conditions dans les Android.bp fichiers. Au lieu de cela, la complexité des règles de construction qui nécessiteraient des conditions est gérée dans Go, où les fonctionnalités de langage de haut niveau peuvent être utilisées et les dépendances implicites introduites par les conditions peuvent être suivies. La plupart des conditions sont converties en une propriété de carte, où l'une des valeurs de la carte est sélectionnée et ajoutée aux propriétés de niveau supérieur.
Par exemple, pour prendre en charge les fichiers spécifiques à l'architecture :
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
Formateur
Soong comprend un formatter canonique pour les fichiers du Plan directeur, semblable à gofmt . Pour récursive reformater tous Android.bp fichiers dans le répertoire courant, exécutez:
bpfmt -w .
Le format canonique comprend des retraits à quatre espaces, de nouvelles lignes après chaque élément d'une liste à plusieurs éléments et une virgule de fin dans les listes et les cartes.
Modules spéciaux
Certains groupes de modules spéciaux ont des caractéristiques uniques.
Modules par défaut
Un module par défaut peut être utilisé pour répéter les mêmes propriétés dans plusieurs modules. Par exemple:
cc_defaults {
name: "gzip_defaults",
shared_libs: ["libz"],
stl: "none",
}
cc_binary {
name: "gzip",
defaults: ["gzip_defaults"],
srcs: ["src/test/minigzip.c"],
}
Modules pré-construits
Certains types de modules prédéfinis permettent à un module d'avoir le même nom que ses homologues basés sur la source. Par exemple, il peut y avoir un cc_prebuilt_binary nommé foo quand il y a déjà un cc_binary avec le même nom. Cela donne aux développeurs la possibilité de choisir la version à inclure dans leur produit final. Si une configuration de construction contient les deux versions, la prefer valeur de l' indicateur dans la définition du module de préconstruit dicte la version a la priorité. Notez que certains modules préconstruits ont des noms qui ne commencent pas par prebuilt , comme android_app_import .
Modules d'espace de noms
Jusqu'à Android convertit pleinement à Make Soong, la Marque configuration du produit doit spécifier une PRODUCT_SOONG_NAMESPACES valeur. Sa valeur doit être une liste séparée par des espaces namespaces que les exportations Soong à livrerai pour être construit par la m commande. Une fois la conversion d'Android en Soong terminée, les détails de l'activation des espaces de noms pourraient changer.
Soong permet aux modules de différents répertoires de spécifier le même nom, tant que chaque module est déclaré dans un espace de noms distinct. Un espace de noms peut être déclaré comme ceci :
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
Notez qu'un espace de noms n'a pas de propriété name ; son chemin est automatiquement assigné comme son nom.
Chaque module Soong se voit attribuer un espace de noms en fonction de son emplacement dans l'arborescence. Chaque module Soong est considéré comme dans l'espace défini par le soong_namespace trouvé dans un Android.bp fichier dans le répertoire en cours ou le plus proche répertoire des ancêtres. Si un tel soong_namespace module est trouvé, le module est considéré comme dans l'espace de noms racine implicite.
Voici un exemple : Soong tente de résoudre la dépendance D déclarée par le module M dans l'espace de noms N qui importe les espaces de noms I1, I2, I3…
- Ensuite , si D est un nom complet de la forme
//namespace:modulede//namespace:modulele//namespace:module, seul l'espace de noms spécifié est recherché le nom du module spécifié. - Sinon, Soong recherche d'abord un module nommé D déclaré dans l'espace de noms N.
- Si ce module n'existe pas, Soong recherche un module nommé D dans les espaces de noms I1, I2, I3…
- Enfin, Soong regarde dans l'espace de noms racine.