Application.mk

Ce document décrit le fichier de compilation Application.mk utilisé par ndk-build.

Nous vous recommandons de lire la page Concepts avant celle-ci.

Présentation

Le fichier Application.mk spécifie les paramètres du projet ndk-build. Par défaut, il se trouve à l'emplacement jni/Application.mk, dans le répertoire de projet de votre application.

Remarque : Un grand nombre de ces paramètres ont également un équivalent par module. Par exemple, APP_CFLAGS correspond à LOCAL_CFLAGS. Dans tous les cas, l'option spécifique au module prévaut sur l'option à l'échelle de l'application. Pour les indicateurs, les deux sont utilisées, mais les indicateurs spécifiques aux modules apparaîtront plus tard dans la ligne de commande afin de remplacer les paramètres à l'échelle du projet.

Variables

APP_ABI

Par défaut, le système de compilation du NDK génère du code pour toutes les ABI non obsolètes. Vous pouvez utiliser le paramètre APP_ABI afin de générer du code pour des ABI spécifiques. Le tableau 1 présente les paramètres APP_ABI pour différents ensembles d'instructions.

Tableau 1. Paramètres APP_ABI pour différents ensembles d'instructions

Ensemble d'instructions	Valeur
ARMv7 32 bits	APP_ABI := armeabi-v7a
ARMv8 64 bits (AArch64)	APP_ABI := arm64-v8a
x86	APP_ABI := x86
x86-64	APP_ABI := x86_64
Tous les ABI compatibles (par défaut)	APP_ABI := all

Vous pouvez également spécifier plusieurs valeurs en les plaçant sur la même ligne et en les séparant par des espaces. Par exemple :

APP_ABI := armeabi-v7a arm64-v8a x86

Remarque : APP_ABI est ignoré par l'objet externalNativeBuild de Gradle. Utilisez plutôt un bloc abiFilters ou (si vous utilisez plusieurs APK) un bloc abi au sein d'un bloc splits.

Pour obtenir la liste de toutes les ABI compatibles ainsi que des détails sur leur utilisation et leurs limites, consultez la section ABI Android.

APP_ASFLAGS

Indicateurs à transmettre à l'assembleur pour chaque fichier source d'assemblage (fichiers .s et .S) dans le projet.

Remarque :ASFLAGS est différent d'ASMFLAGS. Ce dernier s'applique spécifiquement aux fichiers sources YAML (consultez la section sur APP_ASMFLAGS).

APP_ASMFLAGS

Indicateurs à transmettre à YASM pour tous les fichiers sources YASM (.asm, x86/x86_64 uniquement).

APP_BUILD_SCRIPT

Par défaut, ndk-build suppose que le fichier Android.mk est situé sous le chemin jni/Android.mk par rapport à la racine du projet.

Pour charger un fichier Android.mk depuis un autre emplacement, définissez APP_BUILD_SCRIPT sur le chemin absolu du fichier Android.mk.

Remarque : La commande externalNativeBuild de Gradle effectue cette configuration automatiquement en fonction de la variable externalNativeBuild.ndkBuild.path.

APP_CFLAGS

Indicateurs à transmettre pour toutes les compilations C/C++ du projet.

Remarque : Les chemins d'inclusion doivent utiliser LOCAL_C_INCLUDES plutôt que les indicateurs -I explicites.

Voir aussi : APP_CONLYFLAGS, APP_CPPFLAGS.

APP_CLANG_TIDY

Définissez cette valeur sur "true" pour activer clang-tidy pour tous les modules du projet. Désactivée par défaut.

APP_CLANG_TIDY_FLAGS

Indicateurs à transmettre pour toutes les exécutions clang-tidy dans le projet.

APP_CONLYFLAGS

Indicateurs à transmettre pour toutes les compilations C du projet. Ces indicateurs ne sont pas utilisés pour le code C++.

Voir aussi : APP_CFLAGS, APP_CPPFLAGS.

APP_CPPFLAGS

Indicateurs à transmettre pour toutes les compilations C++ du projet. Ces indicateurs ne sont pas utilisés pour le code C.

Voir aussi : APP_CFLAGS, APP_CONLYFLAGS.

APP_CXXFLAGS

Remarque :APP_CPPFLAGS est préférable à APP_CXXFLAGS.

Identique à APP_CPPFLAGS, mais apparaît après APP_CPPFLAGS dans la commande de compilation. Par exemple :

APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR

La configuration ci-dessus génère une commande de compilation semblable à clang++ -DFOO -DBAR au lieu de clang++ -DBAR -DFOO.

APP_DEBUG

Définissez cette valeur sur "true" pour créer une application pouvant être déboguée.

APP_LDFLAGS

Indicateurs à transmettre lors de l'association de fichiers exécutables et de bibliothèques partagées.

Remarque : Ces options n'ont aucun effet sur les bibliothèques statiques. Les bibliothèques statiques ne sont pas associées.

APP_MANIFEST

Chemin absolu vers un fichier AndroidManifest.xml.

Par défaut, $(APP_PROJECT_PATH)/AndroidManifest.xml) est utilisé s'il existe.

Remarque : Lorsque vous utilisez externalNativeBuild, cette valeur n'est pas définie par Gradle.

APP_MODULES

Liste explicite de modules à créer. Les éléments de cette liste sont les noms des modules tels qu'ils apparaissent dans LOCAL_MODULE, dans le fichier Android.mk.

Par défaut, ndk-build crée l'ensemble des bibliothèques partagées, des exécutables, ainsi que leurs dépendances. Les bibliothèques statiques ne sont créées que si elles sont utilisées par le projet, si le projet ne contient que des bibliothèques statiques ou si elles sont nommées dans APP_MODULES.

Remarque : Les modules importés (ceux définis dans les scripts de compilation importés avec $(call import-module)) ne sont pas compilés, sauf s'ils sont dépendants d'un module à compiler ou à spécifier dans APP_MODULES.

APP_OPTIM

Définissez cette variable facultative comme release (publication) ou debug (débogage). Des binaires de publication sont créés par défaut.

Le mode publication active les optimisations et peut produire des binaires qui ne sont pas utilisables avec un débogueur. Le mode débogage désactive les optimisations afin de pouvoir utiliser les débogueurs.

Notez que vous pouvez déboguer des binaires de publication ou de débogage. Toutefois, les binaires de publication fournissent moins d'informations lors du débogage. Par exemple, les variables peuvent être optimisées pour empêcher l'inspection. La réorganisation du code peut également rendre plus difficile son exploration. Les traces de la pile peuvent manquer de fiabilité.

Si vous déclarez android:debuggable dans la balise <application> du fichier manifeste de votre application, cette variable sera définie par défaut sur debug au lieu de release. Remplacez cette valeur par défaut en définissant APP_OPTIM sur release.

Remarque : Lorsque vous effectuez la compilation avec externalNativeBuild, Android Studio définit cet indicateur de manière appropriée en fonction de votre type de compilation.

APP_PLATFORM

APP_PLATFORM déclare le niveau d'API Android sur lequel est basée cette application et correspond à l'objet minSdkVersion de l'application.

S'il n'est pas spécifié, ndk-build cible le niveau d'API minimal accepté par le NDK. Le niveau d'API minimal compatible avec la dernière version du NDK sera toujours suffisamment bas pour prendre en charge presque tous les appareils actifs.

Avertissement : Si vous définissez une valeur APP_PLATFORM supérieure à la valeur minSdkVersion d'une application, cette dernière risque de ne pas s'exécuter sur les appareils plus anciens. Dans la plupart des cas, les bibliothèques ne se chargeront pas, car elles font référence à des symboles qui ne sont pas disponibles sur les anciens appareils.

Par exemple, la valeur android-16 indique que votre bibliothèque utilise des API qui ne sont pas disponibles sous Android 4.1 (niveau d'API 16) et qui ne peuvent pas être utilisées sur des appareils exécutant une version de plate-forme inférieure. Pour obtenir la liste complète des noms de plates-formes et des images système Android correspondantes, consultez la section API natives du NDK Android.

Lorsque vous utilisez Gradle et externalNativeBuild, ce paramètre ne doit pas être défini directement. Définissez plutôt la propriété minSdkVersion dans les blocs defaultConfig ou productFlavors de votre fichier build.gradle au niveau du module. Cela garantit que votre bibliothèque n'est utilisée que par des applications installées sur des appareils exécutant une version d'Android appropriée.

Notez que le NDK ne contient pas de bibliothèques pour chaque niveau d'API d'Android. Les versions qui n'incluaient pas de nouvelles API natives sont omises pour économiser de l'espace dans le NDK. ndk-build utilise les éléments suivants, par ordre décroissant de préférence :

1. Version de la plate-forme correspondant à APP_PLATFORM
2. Prochain niveau d'API disponible en dessous de APP_PLATFORM (par exemple, android-19 est utilisé quand APP_PLATFORM indique android-20, car il n'existe pas de nouvelles API natives dans android-20)
3. Niveau d'API minimal accepté par le NDK

APP_PROJECT_PATH

Chemin absolu du répertoire racine du projet.

APP_SHORT_COMMANDS

Équivalent de LOCAL_SHORT_COMMANDS au niveau du projet. Pour en savoir plus, consultez la documentation sur LOCAL_SHORT_COMMANDS dans Android.mk.

APP_STL

Bibliothèque standard C++ à utiliser pour cette application.

La STL system est utilisée par défaut. Les autres options possibles sont c++_shared, c++_static et none. Consultez la section Environnements d'exécution C++ du NDK et fonctionnalités associées.

APP_STRIP_MODE

Argument à transmettre à strip pour les modules de cette application. La valeur par défaut est --strip-unneeded. Pour éviter de supprimer tous les binaires du module, définissez la valeur sur none. Pour les autres modes de suppression, consultez cette documentation.

APP_THIN_ARCHIVE

Définissez cette valeur sur "true" pour utiliser des archives fines pour toutes les bibliothèques statiques du projet. Pour en savoir plus, consultez la documentation sur LOCAL_THIN_ARCHIVE dans Android.mk.

APP_WRAP_SH

Chemin d'accès au fichier wrap.sh à inclure dans cette application.

Il existe une variante de cette variable pour chaque ABI, tout comme une variante générique d'ABI :

• APP_WRAP_SH
• APP_WRAP_SH_armeabi-v7a
• APP_WRAP_SH_arm64-v8a
• APP_WRAP_SH_x86
• APP_WRAP_SH_x86_64

Remarque : APP_WRAP_SH_<abi> ne peut pas être associé à APP_WRAP_SH. Si une ABI utilise un fichier wrap.sh spécifique à l'ABI, toutes les ABI doivent l'utiliser également.