Système de construction Soong

Avant la version Android 7.0, Android utilisait exclusivement GNU Make pour décrire et exécuter ses règles de construction. Le système de build 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 build Soong offre la flexibilité requise pour les builds Android.

Pour cette raison, les développeurs de plates-formes devraient abandonner Make et adopter Soong dès que possible. Envoyez vos questions au groupe Google chargé de la création d'Android pour recevoir de l'aide.

Qu’est-ce que Soong ?

Le système de construction Soong a été introduit dans Android 7.0 (Nougat) pour remplacer Make. Il exploite l'outil de clonage Kati GNU Make et le composant du système de build Ninja pour accélérer les builds d'Android.

Consultez la description du système Android Make Build dans le projet Android Open Source (AOSP) pour obtenir des instructions générales et les modifications du système de construction pour les écrivains Android.mk pour en savoir plus sur les modifications nécessaires pour s'adapter de Make à Soong.

Consultez les entrées liées à la construction dans le glossaire pour les définitions des termes clés et les fichiers de référence Soong pour des détails complets.

Comparaison Make et Soong

Voici une comparaison de la configuration Make avec Soong accomplissant la même chose dans un fichier de configuration Soong (Blueprint ou .bp ).

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 bientôt

cc_library_shared {
     name: "libxmlrpc++",

     rtti: true,
     cppflags: [
           "-Wall",
           "-Werror",
           "-fexceptions",
     ],
     export_include_dirs: ["src"],
     srcs: ["src/**/*.cpp"],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

Pour des exemples de configuration Soong spécifiques aux tests, voir Configuration de construction simple .

Pour une explication des champs d'un fichier Android.bp, reportez-vous au format de fichier Android.bp .

Modules spéciaux

Certains groupes de modules spéciaux ont des caractéristiques uniques.

Modules par défaut

Un module de valeurs 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 alors qu'il existe déjà un cc_binary du même nom. Cela donne aux développeurs la possibilité de choisir la version à inclure dans leur produit final. Si une configuration de build contient les deux versions, la valeur de l'indicateur prefer dans la définition du module prédéfini indique quelle version a la priorité. Notez que certains modules prédéfinis ont des noms qui ne commencent pas par prebuilt , comme android_app_import .

Modules d'espace de noms

Jusqu'à ce qu'Android soit complètement converti de Make en Soong, la configuration du produit Make doit spécifier une valeur PRODUCT_SOONG_NAMESPACES . Sa valeur doit être une liste d'espaces de noms séparés par des espaces que Soong exporte vers Make pour être construits par la commande m . Une fois la conversion d'Android vers Soong terminée, les détails de l'activation des espaces de noms pourraient changer.

Soong offre la possibilité aux modules de différents répertoires de spécifier le même nom, à condition que chaque module soit 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 attribué comme 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 se trouvant dans l'espace de noms défini par le soong_namespace trouvé dans un fichier Android.bp dans le répertoire actuel ou le répertoire ancêtre le plus proche. Si aucun module soong_namespace n'est trouvé, le module est considéré comme étant 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…

  1. Ensuite, si D est un nom complet de la forme //namespace:module , seul l'espace de noms spécifié est recherché pour le nom de module spécifié.
  2. Sinon, Soong recherche d'abord un module nommé D déclaré dans l'espace de noms N.
  3. Si ce module n'existe pas, Soong recherche un module nommé D dans les espaces de noms I1, I2, I3…
  4. Enfin, Soong regarde dans l'espace de noms racine.