且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

Android.mk应该在哪里?

更新时间:2023-02-06 18:02:03

预期的项目结构

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

根据此处的简短指南: https://developer.android.com/ndk/guides/concepts

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

  1. 在项目的jni/目录中创建一个Android.mk文件
  2. ...使用ndk-build编译您的本机代码
  1. Create an Android.mk file in the jni/ directory of your project
  2. ... compile your native code using the ndk-build
$ cd <path>/<to>/<project>
$ <ndk>/ndk-build

但是,有一种方法可以使用带有参数的ndk-build来定义自定义NDK项目结构.

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

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

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

Android.mk与Application.mk

当Android.mk无论如何都包含所有模块的定义时,为什么需要多个makefile-也可以将它们放置在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是必需的,而Application.mk不是必需的.
  2. Android.mk包含模块定义,并且Application.mk描述体系结构,编译器选项和其他全局"选项.
  3. 根据设计,
  4. Android.mkApplication.mk正交.如果Android.mk包含3个模块,并且Application.mk 2个ABI(例如arm和x86),则NDK将构建(3 * 2)个工件.
  5. Application.mk中的变量出现在Android.mk中,因此,例如,您可以使用Android.mk中的APP_ABI链接与体系结构相关的库.
  6. 有些项目包含很多makefile,因此将它们保存在Application.mk中是一种干净的方法.
  7. 但是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.