With this change, you can install a shared library with module name foo
as bar.so to the system.img with:
LOCAL_INSTALLED_MODULE_STEM := bar.so
Note that we in general still disallow a static/shared library to
specify LOCAL_MODULE_STEM or LOCAL_BUILT_MODULE_STEM, because the build
system uses LOCAL_MODULE to compute build time dependencies, such as
export_includes, the -l linker flag etc.
Also, if you use LOCAL_INSTALLED_MODULE_STEM to change the installed
file name and if any other module links against this library, you may
run into runtime error: the library name baked in to the binary is not
the same as file name in the system image.
Change-Id: I55b571c8139c3bda07a4a0e50cea0f20d8d6c168
The new option WITH_STATIC_ANALYZER=1 instructs build system to
run static analyzer via "clang --analyze" on a successful build.
If analyzer finds any issue, instruction to open report is displayed.
See http://clang-analyzer.llvm.org/scan-build.html for details.
WITH_STATIC_ANALYZER trumps WITH_SYNTAX_CHECK if both exist.
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_STATIC_ANALYZER:=true
Change-Id: I9970560560bd52ce5f0fd7129c3488629627c735
The new option WITH_SYNTAX_CHECK=1 instructs build system to invoke
"clang -fsyntax-only" to utilize clang's better diagnostics before calling
LOCAL_CC/LOCAL_CXX for code generation. The compilation time is slightly
longer, and the generated object file should be the same as w/o WITH_SYNTAX_CHECK
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_SYNTAX_CHECK:=true
Change-Id: I5689586788ef049bd967364f71f31f1e359bd121
The new option WITH_SYNTAX_CHECK=1 instructs build system to invoke
"clang -fsyntax-only" to utilize clang's better diagnostics before calling
LOCAL_CC/LOCAL_CXX for code generation. The compilation time is slightly
longer, and the generated object file should be the same as w/o WITH_SYNTAX_CHECK
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_SYNTAX_CHECK:=true
Change-Id: Iaeedd07d5719f9df9675ab57e307e28a9c855c1b
The issues:
- The size increase from utilizing FDO is quite large while
utilizing runtime profiles in build.
- By default, FDO is utilized globally if the target arch variant
profiles exist.
- Not all modules can show statistical significance in
performance comparison, yet still suffer the size increase.
The solution:
- Only enable FDO locally with LOCAL_FDO_SUPPORT
for modules which may benefit enough to justify the size
tradeoff.
Solution notes:
- I've noted statistical significance in libwebcore and libskia
thus far from utilizing FDO.
- Analysis included sunspider, drawcanvas benchmarks, as
well as gooda analysis on both arm and x86
- To support runtime profile generation in modules which have
LOCAL_FDO_SUPPORT specified,
BUILD_FDO_INSTRUMENTATION is still used. Otherwise,
if the target arch variant profiles exist, FDO is utilized for
specified modules.
Change-Id: I7e95266943ff47c7d82b02e6200fd09911d0bb57
With this change, use:
* LOCAL_PROGUARD_ENABLED := obfuscation # to enable obfuscation
* LOCAL_PROGUARD_ENABLED := optimization # to enable optimization
* LOCAL_PROGUARD_ENABLED := obfuscation optimization # to enable both
Now the meaning of the LOCAL_PROGUARD_ENABLED options:
* full:
Use the build system's default configurations:
with shrink but no obfuscation or optimization,
global proguard flags in build/core/proguard.flags
are applied.
* custom:
The same as "full" except no aapt-generated resource-related
proguard flags.
* nosystem:
Don't use any build system's default configurations; but
aapt-generated proguard flags are still applied. You are
responsible for any other flags.
* disabled:
Disable proguard.
* obfuscation:
The same as "full" but with obfuscation enabled.
* optimization:
The same as "full" but with optimization enabled.
* no value (the default):
The build system chooses the proper value: "full" if it's an
app; "disabled" if it's a library.
You can use more than 1 of them in a meaningful combination,
for example:
LOCAL_PROGUARD_ENABLED := obfuscation optimization
Bug: 10307372
Change-Id: Id248caca3048e99547f16559fae74f4afe85c354
Now you can have a board config variable BOARD_HAL_STATIC_LIBRARIES,
which is a list of board-specific HAL static library names with pattern
"lib<library_name>.<board_specific_suffix>". LOCAL_HAL_STATIC_LIBRARIES
is a list of "lib<library_name>" and any matched
BOARD_HAL_STATIC_LIBRARIES will be added to the LOCAL_STATIC_LIBRARIES;
if no match is found, lib<library_name>.default will be used.
Bug: 10262105
Change-Id: Ic89d8d417d1dd65a227e4187a157fd3b77c4af34
This reverts commit 28b46fc16c.
Speculative fix for master builds. I cannot repro the break the bots
are seeing locally, but it seems related to building protobufs and this
CL was in the first broken build.
Also source files which have dependencies need to be bundled together
(at least the way the build system is set up now). Move
--proto_path=$(TOP) to the end so that it does not take precedence
over user-supplied --proto_path flags.
Change-Id: Ia532647fe8811d39230a23ba3671685b0388cbe0
Usage:
LOCAL_DIST_BUNDLED_BINARIES := true
The dist files will include the jni shared libraries and the apk with
jni libraries stripped.
Bug: 8181626
Change-Id: I4a047d786ad35b948b4ad7a51adf37321dbe395c
This allows you to build apks that link against other
apks using the framework's new shared library apk feature.
Also if you are using LOCAL_APK_LIBRARIES, then LOCAL_DEX_PREOPT
will not be allowed. This is because using preopt means the
apk is stripped of its dex file, so the pre-installed apk can't
be redexed if its associated library changes. (Even if the build
system didn't strip the dex, Dalvik still has issues because it
assumes a pre-odex file is always valid.)
Change-Id: I952c0d24f8975f75aff67f78b5faeec91144c3e7
With this support, you can piggy-back some symlinks when a module gets
installed.
This is especially helpful if the target of the symlink doesn't exist on
the build machine.
Change-Id: I48af7a90ce67475bc49b72f94a8753b94da98edd
With this change, you can easily switch between building from source
code and prebuilt.
Set LOCAL_PREBUILT_MODULE_FILE to the path of the prebuilt file,
relative to the top of the source tree, in the usual module definition.
The prebuilt will be used unless any of the followings satisfied:
1) ANDROID_BUILD_FROM_SOURCE is "true", which disable prebuilt globally;
2) The module name is in ANDROID_NO_PREBUILT_MODULES;
3) The LOCAL_PATH is prefixed by any of ANDROID_NO_PREBUILT_PATHS.
A developer can set ANDROID_NO_PREBUILT_MODULES or
ANDROID_NO_PREBUILT_PATHS to build only his own module(s) from source,
while build other modules from prebuilts.
You can set ANDROID_BUILD_FROM_SOURCE to true to build everything from
source.
Those variables can be set with shell environmental variable or in your
buildspec.mk.
Sometimes module B is able to be built from source only if module A is
also
built from source, for example, if B is the test apk of A.
In that case, you can use the macro include-if-build-from-source to
include B's Android.mk only if A is built from source too, or
if-build-from-source to conditionally include the definition of module
B,
if their module definitions are in the same Android.mk.
Support host-executable-hook and host-shared-library-hook.
Change-Id: Icab7cf028c87eaba0dd7efc2a7749fd6f32b44e4
Bug: 6987838
- With this change, use "EMMA_INSTRUMENT=true" to enable emma in full or
unbundled build.
- You don't need to add "LOCAL_STATIC_JAVA_LIBRARIES += emma" any more for
unbundled apps.
- Now a single var LOCAL_EMMA_INSTRUMENT replaces the previous
LOCAL_NO_EMMA_INSTRUMENT and LOCAL_NO_EMMA_COMPILE.
- By default, if EMMA_INSTRUMENT is true, emma is enabled for only
non-test apps.
- A new global var EMMA_INSTRUMENT_STATIC. It enables EMMA_INSTRUMENT
and builds emma into apk/jar as static library, instead of using emma
as part of shared library core.jar.
Change-Id: I0aa219e83074879ececc159b5b07c39eb07ccc00
To pass compiler flags
LOCAL_CFLAGS: to both C and C++ files;
LOCAL_CONLYFLAGS: to only C files but not C++ files;
LOCAL_CPPFLAGS: to only C++ file.
LOCAL_CPPFLAGS and LOCAL_CONLYFLAGS can override flags in LOCAL_CFLAGS.
Bug: 6967573
Change-Id: I88d9de0980e451b94bc7ae8c741ea2030eada3e1
We are now unifying the NDK versions of unbundled native code to always
use the latest NDK.
We don't need the variable LOCAL_NDK_VERSION now.
To build native code with NDK, you need set just LOCAL_SDK_VERSION.
Bug: 6932421
Change-Id: I86f05a264249cda6bae97b4b1616f03700cd9dfa
We are now unifying the NDK versions of unbundled native code to always
use the latest NDK.
We don't need the variable LOCAL_NDK_VERSION now.
To build native code with NDK, you need set just LOCAL_SDK_VERSION.
Bug: 6932421
Change-Id: I86f05a264249cda6bae97b4b1616f03700cd9dfa
