Where is Android.mk supposed to be?

Question

In the documentation for Android NDK, the following statement is present:

The Android.mk file resides in a subdirectory of your project\'s jni/ directory

Answer 1

I can answer at least some of your questions. You are right about the documentation being a little confusing. If you are using a single native module, indeed the Application.mk may seem redundant - but, there are a few things that can only be set by the Application.mk (you can look here: Application.mk). The Application.mk is meant for settings that apply for all modules, whereas the Android.mk is for specific module settings. Indeed, usually simple projects have a single Android.mk and it resides on the same folder as the Application.mk.

You can define where to put them, it also depends how you build your code - for example, if you are using a task for building ndk using 'ndk-build' and commandLine command, you pass the folder path as an argument. Usually, according to my experience, they reside under the jni folder.

Answer 2

Expected project structure

<project>/
 |
 +-- jni/
 |    |
 |    +-- Android.mk
 |    +-- [Application.mk] (optionally)
 |    +-- main.c
 |
 +-- AndroidManifest.xml

According to a short guide from here: https://developer.android.com/ndk/guides/concepts

8. Create an Android.mk file in the jni/ directory of your project
9. ... compile your native code using the ndk-build

   $ cd <path>/<to>/<project>
   $ <ndk>/ndk-build
   

However, there is a way to define custom NDK project structures using ndk-build with arguments.

Plain structure

<mylib>/
 |
 +-- Android.mk
 +-- [Application.mk]
 +-- main.c

$ cd <mylib>
$ ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=Android.mk

Android.mk vs Application.mk

why there is a need for multiple makefiles when Android.mk will contain the definitions for all modules anyway-that could just as well be placed in Application.mk.

1. Android.mk is mandatory and Application.mk is not.
2. Android.mk contains module definitions and Application.mk describes architecture, compiler options, and other "global" options.
3. Android.mk is orthogonal to Application.mk by design. If Android.mk contains 3 modules, and Application.mk 2 ABIs (e.g. arm and x86), then NDK will build (3 * 2) artifacts.
4. Variables from Application.mk appears in Android.mk, so you can use, for instance, APP_ABI in Android.mk to link architecture dependent libraries.
5. There are complex projects with a lot of makefiles and keeping common options in Application.mk is a clean way.
6. But still Application.mk is just a design decision, it could've been done differently.