通过分析一个例子来了解NDK makefile文件的生成。例子"hello JNI" ，由NDK提供的例子
A. 目录结构
jni目录：包含本地源文件，eg：'jni/hello-jni.c'，该源文件实现了一个简单的共享库，实现了一个简单的本地方法，返回字符串给java 虚拟机
src目录：包含了工程的java源文件
B. mk源文件
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY)
第一行：
LOCAL_PATH := $(call my-dir)
必须的，调用系统方法，返回当前程序的目录
第二行：
include $(CLEAR_VARS)
必须得，该CLEAR_VARS变量由编译系统提供，指向一些特殊的GNU Makefile文件来清除一些LOCAL_XXX变量除了
LOCAL_PATH。因为所有的编译控制文件被一个单一的GUN Make执行时所有的变量时全局的。
第三行：
LOCAL_MODULE := hello-jni
用来指定你生成的动态库的名字，系统会自动为你添加前缀和后缀，生成后的so为 libhello-jni.so，系统自动添加了前缀“lib”和后缀“.so”
第四行：
LOCAL_SRC_FILES := hello-jni.c
其包含一系列的C or C++源文件，不需要添加.h文件，系统会自动为你添加
第五行：
include $(BUILD_SHARED_LIBRARY)
必须的，其由系统提供，指向一个GUN Makefile脚本，用来负责收集你定义的所有LOCAL_XXX变量，并确定该怎么构建，以及怎样做准确，同时也指定生成一个共享库
第二部分：参考资料
verview:概要
---------
An Android.mk file is written to describe your sources to the
build system. More specifically:具体来说：
- The file is really a tiny GNU Makefile fragment that will be
parsed one or more times by the build system. As such, you
should try to minimize the variables you declare there and
do not assume that anything is not defined during parsing.
- The file syntax is designed to allow you to group your
sources into 'modules'. A module is one of the following:
- a static library
- a shared library
Only shared libraries will be installed/copied to your
application package. Static libraries can be used to generate
shared libraries though.
You can define one or more modules in each Android.mk file,
and you can use the same source file in several modules.
- The build system handles many details for you. For example, you
don't need to list header files or explicit dependencies between
generated files in your Android.mk. The NDK build system will
compute these automatically for you.
This also means that, when updating to newer releases of the NDK,
you should be able to benefit from new toolchain/platform support
without having to touch your Android.mk files.
Note that the syntax is *very* close to the one used in Android.mk files
distributed with the full open-source Android platform sources. While
the build system implementation that uses them is different, this is
an intentional design decision made to allow reuse of 'external' libraries'
source code easier for application developers.
Simple example:
---------------
Before describing the syntax in details, let's consider the simple
"hello JNI" example, i.e. the files under:
apps/hello-jni/project
Here, we can see:
- The 'src' directory containing the Java sources for the
sample Android project.
- The 'jni' directory containing the native source for
the sample, i.e. 'jni/hello-jni.c'
This source file implements a simple shared library that
implements a native method that returns a string to the
VM application.
- The 'jni/Android.mk' file that describes the shared library
to the NDK build system. Its content is:
---------- cut here ------------------
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY)
---------- cut here ------------------
Now, let's explain these lines:
LOCAL_PATH := $(call my-dir)
An Android.mk file must begin with the definition of the LOCAL_PATH variable.
It is used to locate source files in the development tree. In this example,
the macro function 'my-dir', provided by the build system, is used to return
the path of the current directory (i.e. the directory containing the
Android.mk file itself).
include $(CLEAR_VARS)
The CLEAR_VARS variable is provided by the build system and points to a
special GNU Makefile that will clear many LOCAL_XXX variables for you
(e.g. LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, etc...),
with the exception of LOCAL_PATH. This is needed because all build
control files are parsed in a single GNU Make execution context where
all variables are global.
LOCAL_MODULE := hello-jni
The LOCAL_MODULE variable must be defined to identify each module you
describe in your Android.mk. The name must be *unique* and not contain
any spaces. Note that the build system will automatically add proper
prefix and suffix to the corresponding generated file. In other words,
a shared library module named 'foo' will generate 'libfoo.so'.
IMPORTANT NOTE:
If you name your module 'libfoo', the build system will not
add another 'lib' prefix and will generate libfoo.so as well.
This is to support Android.mk files that originate from the
Android platform sources, would you need to use these.
LOCAL_SRC_FILES := hello-jni.c
The LOCAL_SRC_FILES variables must contain a list of C and/or C++ source
files that will be built and assembled into a module. Note that you should
not list header and included files here, because the build system will
compute dependencies automatically for you; just list the source files
that will be passed directly to a compiler, and you should be good.
Note that the default extension for C++ source files is '.cpp'. It is
however possible to specify a different one by defining the variable
LOCAL_DEFAULT_CPP_EXTENSION. Don't forget the initial dot (i.e. '.cxx'
will work, but not 'cxx').
include $(BUILD_SHARED_LIBRARY)
The BUILD_SHARED_LIBRARY is a variable provided by the build system that
points to a GNU Makefile script that is in charge of collecting all the
information you defined in LOCAL_XXX variables since the latest
'include $(CLEAR_VARS)' and determine what to build, and how to do it
exactly. There is also BUILD_STATIC_LIBRARY to generate a static library.
There are more complex examples in the samples directories, with commented
Android.mk files that you can look at.
Reference:
----------
This is the list of variables you should either rely on or define in
an Android.mk. You can define other variables for your own usage, but
the NDK build system reserves the following variable names:
- names that begin with LOCAL_ (e.g. LOCAL_MODULE)
- names that begin with PRIVATE_, NDK_ or APP_ (used internally)
- lower-case names (used internally, e.g. 'my-dir')
If you need to define your own convenience variables in an Android.mk
file, we recommend using the MY_ prefix, for a trivial example:
---------- cut here ------------------
MY_SOURCES := foo.c
ifneq ($(MY_CONFIG_BAR),)
MY_SOURCES += bar.c
endif
LOCAL_SRC_FILES += $(MY_SOURCES)
---------- cut here ------------------
So, here we go:
NDK-provided variables:
- - - - - - - - - - - -
These GNU Make variables are defined by the build system before
your Android.mk file is parsed. Note that under certain circumstances
the NDK might parse your Android.mk several times, each with different
definition for some of these variables.
CLEAR_VARS
Points to a build script that undefines nearly all LOCAL_XXX variables
listed in the "Module-description" section below. You must include
the script before starting a new module, e.g.:
include $(CLEAR_VARS)
BUILD_SHARED_LIBRARY
Points to a build script that collects all the information about the
module you provided in LOCAL_XXX variables and determines how to build
a target shared library from the sources you listed. Note that you
must have LOCAL_MODULE and LOCAL_SRC_FILES defined, at a minimum before
including this file. Example usage:
include $(BUILD_SHARED_LIBRARY)
note that this will generate a file named lib$(LOCAL_MODULE).so
BUILD_STATIC_LIBRARY
A variant of BUILD_SHARED_LIBRARY that is used to build a target static
library instead. Static libraries are not copied into your
project/packages but can be used to build shared libraries (see
LOCAL_STATIC_LIBRARIES and LOCAL_STATIC_WHOLE_LIBRARIES described below).
Example usage:
include $(BUILD_STATIC_LIBRARY)
Note that this will generate a file named lib$(LOCAL_MODULE).a
TARGET_ARCH
Name of the target CPU architecture as it is specified by the
full Android open-source build. This is 'arm' for any ARM-compatible
build, independent of the CPU architecture revision.
TARGET_PLATFORM
Name of the target Android platform when this Android.mk is parsed.
For example, 'android-3' correspond to Android 1.5 system images. For
a complete list of platform names and corresponding Android system
images, read docs/STABLE-APIS.TXT.
TARGET_ARCH_ABI
Name of the target CPU+ABI when this Android.mk is parsed.
Two values are supported at the moment:
armeabi
For Armv5TE
armeabi-v7a
NOTE: Up to Android NDK 1.6_r1, this variable was simply defined
as 'arm'. However, the value has been redefined to better
match what is used internally by the Android platform.
For more details about architecture ABIs and corresponding
compatibility issues, please read docs/CPU-ARCH-ABIS.TXT
Other target ABIs will be introduced in future releases of the NDK
and will have a different name. Note that all ARM-based ABIs will
have 'TARGET_ARCH' defined to 'arm', but may have different
'TARGET_ARCH_ABI'
TARGET_ABI
The concatenation of target platform and abi, it really is defined
as $(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) and is useful when you want
to test against a specific target system image for a real device.
By default, this will be 'android-3-armeabi'
(Up to Android NDK 1.6_r1, this used to be 'android-3-arm' by default)
NDK-provided function macros:
- - - - - - - - - - - - - - -
The following are GNU Make 'function' macros, and must be evaluated
by using '$(call <function>)'. They return textual information.
my-dir
Returns the path of the current Android.mk's directory, relative
to the top of the NDK build system. This is useful to define
LOCAL_PATH at the start of your Android.mk as with:
LOCAL_PATH := $(call my-dir)
all-subdir-makefiles
Returns a list of Android.mk located in all sub-directories of
the current 'my-dir' path. For example, consider the following
hierarchy:
sources/foo/Android.mk
sources/foo/lib1/Android.mk
sources/foo/lib2/Android.mk
If sources/foo/Android.mk contains the single line:
include $(call all-subdir-makefiles)
Then it will include automatically sources/foo/lib1/Android.mk and
sources/foo/lib2/Android.mk
This function can be used to provide deep-nested source directory
hierarchies to the build system. Note that by default, the NDK
will only look for files in sources/*/Android.mk
this-makefile
Returns the path of the current Makefile (i.e. where the function
is called).
parent-makefile
Returns the path of the parent Makefile in the inclusion tree,
i.e. the path of the Makefile that included the current one.
grand-parent-makefile
Guess what...
Module-description variables:
- - - - - - - - - - - - - - -
The following variables are used to describe your module to the build
system. You should define some of them between an 'include $(CLEAR_VARS)'
and an 'include $(BUILD_XXXXX)'. As written previously, $(CLEAR_VARS) is
a script that will undefine/clear all of these variables, unless explicitely
noted in their description.
LOCAL_PATH
This variable is used to give the path of the current file.
You MUST define it at the start of your Android.mk, which can
be done with:
LOCAL_PATH := $(call my-dir)
This variable is *not* cleared by $(CLEAR_VARS) so only one
definition per Android.mk is needed (in case you define several
modules in a single file).
LOCAL_MODULE
This is the name of your module. It must be unique among all
module names, and shall not contain any space. You MUST define
it before including any $(BUILD_XXXX) script.
The module name determines the name of generated files, e.g.
lib<foo>.so for a shared library module named <foo>. However
you should only refer to other modules with their 'normal'
name (e.g. <foo>) in your NDK build files (either Android.mk
or Application.mk)
LOCAL_SRC_FILES
This is a list of source files that will be built for your module.
Only list the files that will be passed to a compiler, since the
build system automatically computes dependencies for you.
Note that source files names are all relative to LOCAL_PATH and
you can use path components, e.g.:
LOCAL_SRC_FILES := foo.c \
toto/bar.c
NOTE: Always use Unix-style forward slashes (/) in build files.
Windows-style back-slashes will not be handled properly.
LOCAL_CPP_EXTENSION
This is an optional variable that can be defined to indicate
the file extension of C++ source files. The default is '.cpp'
but you can change it. For example:
LOCAL_CPP_EXTENSION := .cxx
LOCAL_C_INCLUDES
An optional list of paths, relative to the NDK *root* directory,
which will be appended to the include search path when compiling
all sources (C, C++ and Assembly). For example:
LOCAL_C_INCLUDES := sources/foo
Or even:
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
These are placed before any corresponding inclusion flag in
LOCAL_CFLAGS / LOCAL_CPPFLAGS
LOCAL_CFLAGS
An optional set of compiler flags that will be passed when building
C *and* C++ source files.
This can be useful to specify additionnal macro definitions or
compile options.
IMPORTANT: Try not to change the optimization/debugging level in
your Android.mk, this can be handled automatically for
you by specifying the appropriate information in
your Application.mk, and will let the NDK generate
useful data files used during debugging.
NOTE: In android-ndk-1.5_r1, the corresponding flags only applied
to C source files, not C++ ones. This has been corrected to
match the full Android build system behaviour. (You can use
LOCAL_CPPFLAGS to specify flags for C++ sources only now).
LOCAL_CXXFLAGS
An alias for LOCAL_CPPFLAGS. Note that use of this flag is obsolete
as it may disappear in future releases of the NDK.
LOCAL_CPPFLAGS
An optional set of compiler flags that will be passed when building
C++ source files *only*. They will appear after the LOCAL_CFLAGS
on the compiler's command-line.
NOTE: In android-ndk-1.5_r1, the corresponding flags applied to
both C and C++ sources. This has been corrected to match the
full Android build system. (You can use LOCAL_CFLAGS to specify
flags for both C and C++ sources now).
LOCAL_STATIC_LIBRARIES
The list of static libraries modules (built with BUILD_STATIC_LIBRARY)
that should be linked to this module. This only makes sense in
shared library modules.
LOCAL_SHARED_LIBRARIES
The list of shared libraries *modules* this module depends on at runtime.
This is necessary at link time and to embed the corresponding information
in the generated file.
Note that this does not append the listed modules to the build graph,
i.e. you should still add them to your application's required modules
in your Application.mk
LOCAL_LDLIBS
The list of additional linker flags to be used when building your
module. This is useful to pass the name of specific system libraries
with the "-l" prefix. For example, the following will tell the linker
to generate a module that links to /system/lib/libz.so at load time:
LOCAL_LDLIBS := -lz
See docs/STABLE-APIS.TXT for the list of exposed system libraries you
can linked against with this NDK release.
LOCAL_ALLOW_UNDEFINED_SYMBOLS
By default, any undefined reference encountered when trying to build
a shared library will result in an "undefined symbol" error. This is a
great help to catch bugs in your source code.
However, if for some reason you need to disable this check, set this
variable to 'true'. Note that the corresponding shared library may fail
to load at runtime.
LOCAL_ARM_MODE
By default, ARM target binaries will be generated in 'thumb' mode, where
each instruction are 16-bit wide. You can define this variable to 'arm'
if you want to force the generation of the module's object files in
'arm' (32-bit instructions) mode. E.g.:
LOCAL_ARM_MODE := arm
Note that you can also instruct the build system to only build specific
sources in arm mode by appending an '.arm' suffix to its source file
name. For example, with:
LOCAL_SRC_FILES := foo.c bar.c.arm
Tells the build system to always compile 'bar.c' in arm mode, and to
build foo.c according to the value of LOCAL_ARM_MODE.
NOTE: Setting APP_OPTIM to 'debug' in your Application.mk will also force
the generation of ARM binaries as well. This is due to bugs in the
toolchain debugger that don't deal too well with thumb code.
LOCAL_ARM_NEON
Defining this variable to 'true' allows the use of ARM Advanced SIMD
(a.k.a. NEON) GCC intrinsics in your C and C++ sources, as well as
NEON instructions in Assembly files.
You should only define it when targetting the 'armeabi-v7a' ABI that
corresponds to the ARMv7 instruction set. Note that not all ARMv7
based CPUs support the NEON instruction set extensions and that you
should perform runtime detection to be able to use this code at runtime
safely. To lean more about this, please read the documentation at
docs/CPU-ARM-NEON.TXT and docs/CPU-FEATURES.TXT.
Alternatively, you can also specify that only specific source files
may be compiled with NEON support by using the '.neon' suffix, as
in:
LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
In this example, 'foo.c' will be compiled in thumb+neon mode,
'bar.c' will be compiled in 'thumb' mode, and 'zoo.c' will be
compiled in 'arm+neon' mode.
Note that the '.neon' suffix must appear after the '.arm' suffix
if you use both (i.e. foo.c.arm.neon works, but not foo.c.neon.arm !)
LOCAL_DISABLE_NO_EXECUTE
Android NDK r4 added support for the "NX bit" security feature.
It is enabled by default, but you can disable it if you *really*
need to by setting this variable to 'true'.
NOTE: This feature does not modify the ABI and is only enabled on
kernels targetting ARMv6+ CPU devices. Machine code generated
with this feature enabled will run unmodified on devices
running earlier CPU architectures.
最近在微博上看到不少lbs相关的产品和营销案例，本文就整理了最近一段时间的一些lbs方面营销案例，各位如果对lbs感兴趣，可以关注下面这些分享案例的微博，也欢迎大家继续分享这方面的优秀案例。
《波斯王子》是游戏界一个非常响亮的名字。在DOS年代，她就已经成名。由其改编的电影已经上映。如你还不了解她，没有关系。掏出你的手机，用GPRS定位到其海报灯箱前。你会发现神秘美丽的塔米娜公主出现在你的屏幕上，如果你可以答对她所提出的问题，你将赢得在movieminutes.com上50分钟的电影观看权。
Starbucks 太牛了。新推出Mobile Pour服务：你在路上走着，突然想喝咖啡，通过Mobile Pour APP，允许星巴克知道你的位置，点好你要的咖啡，然后你就接着走你的，走啊走，不一会儿一个星巴克小伙子或者大姑娘就会踩着滑轮车给你送一杯来。目前已经在美国7个大城市开始。我看过的LBS最佳商业应用。
扩展阅读：http://www.starbucks.com/blog/introducing-starbucks-mobile-pour/987
iButterfly，属于日本人的浪漫，是我看过的将AR（延伸现实）和LBS（位置服务）结合的最完美的应用，国内的开发者加油啊，可以给大城市里长大的孩子们创造一个更美好的童年。 http://t.cn/hbxAFd
【每日营销案例】LBS营销：比利时知名啤酒Stella Artois结合AR与LBS技术,做了一个APP#Le Bar Guide#.开启摄像头对着街道,显示离自己最近的酒吧,包括地址名称。最特别的是,将手机往地上拍摄,还会出现箭头符号,引导一步步走到酒吧.如果喝醉了,APP提供叫车服务http://t.cn/htJbo3
http://v.youku.com/v_show/id_XMjUwOTU4NjI0.html
LBS观景台：#LBS营销案例# 伦敦博物馆手机行销案例“时光机器”。这是伦敦博物馆推出的基于iPhone的应用程式。用户可以使用GPS定位，然后把手机对准当前所在的位置，那么系统会帮你匹配当前位置几十年前的样子。LBS的互动营销可以借鉴。http://t.cn/htFl08
LBS观景台：走进一家杂货店，手机响了，提醒你这家店现正提供的优惠券，结账时向收银员出示接收到的手机优惠券即可，你可以自行订制接收哪些商户的提醒，定制触发提示的条件。你会动心吗？采用Location Labs旗下产品Sparkle平台的手机优惠券应用Cellfire正开始将地理位置服务引入人们的日常生活。www.cellfire.com
Mini设计了一个GPS定位地图的程式，显示了一部虚拟的Mini、你的和其他用户的位置。只要你到了虚拟车的50米内，你可以得到那部车。假如别的用户在你50米内，又可以抢了你的车。假如你能够保管你的Mini一周，你就可以得到真的Mini一部！推广期间，上千瑞典人在街头奔跑！http://t.cn/hq0ru7
美国密尔沃基只有400个Foursquare的用户，当地餐厅AJ Bombers发起了一个Party，就是假如有50个人在某一个时间同时出现在该餐厅，大家就可以拿到一个蜂群徽章（Swarm Badge），可以优惠价吃大餐。这消息在推特上被转发了。结果在约定时间160人到达了餐厅，餐厅赚了本来3天才能有的生意！
扩展阅读：http://blog.steffanantonas.com/case-study-how-to-use-foursquare-to-draw-a-crowd-into-your-restaurant.htm
SCVNGR将商家优惠活动引入LBS社交游戏 http://t.cn/hBThSi 位置游戏公司SCVNGR新推出的LevelUp平台把基于地理位置的游戏引入到优惠活动领域。你使用LevelUp越多，你就可以越早进入某个特定商家的新“级别”，从而获得更好的优惠。
【大众汽车】为即将到来的上海车展特别制作了一款手机App，是基于LBS 位置服务的游戏，在上海，苏州，杭州三个城市收集虚拟徽章，就可以免费获得上海车展门票，并且有机会获得限量版大众汽车车模。欢迎下载体验！http://t.cn/hBjej1
《凡客诚品试水LBS营销 已有万人参与》据凡客诚品方面透露，凡是冒泡网的用户，即可利用冒泡网的地理位置服务(LBS)方式，在北京主要公交站点和北京各地铁站等站牌广告位置使用手机“签到”，活动推出当日即吸纳上万人参与。http://t.cn/hbw7sV
BreezeLiving：基于AR和LBS的周边优惠服务http://t.cn/hBMDar 渣打银行 (中国) 也赶时髦啦。
重写：
@Override
protected Dialog onCreateDialog(int id) {
switch (id) {
case 0: {
Dialog dialog = new AlertDialog.Builder(Test.this).setTitle("Question")
.setMessage("Are you sure that you want to quit?") // 设置内容
// .setView(input)//这个view显示在message下面
.setPositiveButton("Yes", // 设置确定按钮
new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int whichButton) {
setResult(RESULT_OK);
finish();
}
}).setNegativeButton("No", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int whichButton) {
}
}).create();// 创建
return dialog;
}
default: {
return null;
}
}
}
在oncreat
showDialog(0);
第二种：
@Override
protected Dialog onCreateDialog(int id) {
switch (id) {
case 0: {
return new AlertDialog.Builder(mima.this)
.setOnKeyListener(new DialogInterface.OnKeyListener() {
@Override
public boolean onKey(DialogInterface dialog, int keyCode, KeyEvent event) {
// TODO Auto-generated method stub
if (event.getKeyCode() == KeyEvent.KEYCODE_SEARCH) {
return true;
}
return false;
}
})
.setTitle("实验：")
.setMessage("这是一个测试")
.setPositiveButton("确定",
new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
removeDialog(0);
}
})
.setNegativeButton("不再显示",
new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
removeDialog(0);
closeShowPwdTip();
}
})
.setNeutralButton("设置", new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
removeDialog(0);
// startSettingActivity();
}
}).create();
}
default: {
return null;
}
}
}