This uses the fact that unsetting LOCAL_MULTILIB equals "either".
It's useful to build for both 32-bit and 64-bit in the same prebuilt
module definition.
Bug: 13751317
Change-Id: I4f1625a83e13f22f807039afebae73f69ed35918
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
LOCAL_MULTILIB replaces LOCAL_32_BIT_ONLY and
LOCAL_NO_2ND_ARCH, although both are still supported.
Set LOCAL_MULTILIB := 32 to always build a module 32-bit.
This is the same as specifying LOCAL_32_BIT_ONLY.
Set LOCAL_MULTILIB := first to always build a module for
the first architecture (64-bit on a 64-bit target, 32-bit on a
32-bit target). This is the same as specifying LOCAL_NO_2ND_ARCH.
Set LOCAL_MULTILIB := both to build for both architectures
on a mulitlib (64-bit) target.
If LOCAL_MULTILIB is not set libraries will default to "both",
and executables, packages, and prebuilts will default to building
for the first architecture if supported by the module, otherwise
the second.
Executables that set LOCAL_MULTILIB := both must set either
LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64 or
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to specify how to
differentiate the install locations of the two versions.
Change-Id: I22ab6aa342b231c307b1d8a86cea4fd91eea39f5
Prebuilts often support only a single architecture, allow them to
use LOCAL_MODULE_TARGET_ARCH to specify it.
Change-Id: I2514f66f682ef267bbf1a1ab78510faff0a18b64
This is needed because the linker command line uses -rpath-link with
built module path ($(*_OUT_INTERMEDIATE_LIBRARIES)) to search for indirect
dependency libraries.
Change-Id: I21d537c7c697dfb18df25d3d2bb7bffe2f9d370f
(cherry picked from commit ada8f29657)
This is needed because the linker command line uses -rpath-link with
built module path ($(*_OUT_INTERMEDIATE_LIBRARIES)) to search for indirect
dependency libraries.
Change-Id: I21d537c7c697dfb18df25d3d2bb7bffe2f9d370f
Since commit 6c86a1 we have split LOCAL_SHARED_LIBRARIES out of
LOCAL_REQUIRED_MODULES and the vendor check does no longer cover the
installed modules introduced by LOCAL_SHARED_LIBRARIES.
This change brings back the coverage.
Change-Id: Ie78692e48f173a3350792eb2fee8127ff9433caa
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
To pick up a NOTICE file in LOCAL_PATH and attach it to
/system/lib/libfoo.so, use the following syntax:
include $(CLEAR_VARS)
LOCAL_MODULE_CLASS := NOTICE_FILES
LOCAL_INSTALLED_MODULE := $(PRODUCT_OUT)/system/lib/libfoo.so
include $(BUILD_NOTICE_FILE)
Bug: 7460213
Change-Id: Ie692be72deab37be04d1b578578c131a0885a090
Bug: 5573756
With this change, we can set LOCAL_EXPORT_C_INCLUDE_DIRS in the module
definition to export include dir paths.
Paths in LOCAL_EXPORT_C_INCLUDE_DIRS should be relative to the top dir
of the source tree.
If a library (shared or static) exports some include paths, any module
using it will import the include paths and add them to the compiler
command line.
Change-Id: I49aabc589d2cf214044d13ccd5532ef68209adf0
Since dev keys can now vary per device, we can't assume they are
checked in with the correct signature.
Change-Id: I7577a3a6bd98d005c15936c99b2944acc4412798
So that prebuilt shared libraries can be referenced with the module name
in other module's Android.mk.
Change-Id: I4c4b471696642694b805b71dd7605b91724ad924
Currently, prebuilt binaries with debug symbols are installed unstripped.
There are only a few of prebuilt shared library (that I'm trying to fix),
so I can do this manually by making intermediate target and applying
TARGET_STRIP, each of them, one by one.
But dynamic_binary.mk has more features than stripping binaries
(like copying unstripped binaries to symbols directory)
and if I do it manually, they will lose all the benefits.
Note that this doesn't change anything when LOCAL_STRIP_MODULE is not set.
I actually tried to force strip every BUILD_PREBUILT'ed modules,
but there were a few problems:
- Some packages are not installed (i.e. not in PRODUCT_PACAKGES)
but are built (i.e. in ALL_MODULES). And some of them are built in spite
that they do not have appropriate prebuilt shared library for TARGET_ARCH.
Stripping them causes "unknown format".
- Some prebuilt modules set LOCAL_MODULE_CLASS incorrectly.
Example is default.supp of external/valgrind/main, which should be ETC,
not SHARED_LIBRARY.
Both are better fixed, but I concluded that it's better to be conservative.
Bug: 4585734
Change-Id: If71723b1d76007d45b02429ea5161a8265dd5b6d
For target Java libraries, now the LOCAL_BUILT_MODULE includes both javalib.jar
and the .odex file, if dexpreopt is enabled.
These 2 files are moved to a product-specific dir in this change.
For target Java Libraries, $(intermediates) now points to the product-specific dir.
There is still a javalib.jar in the $(intermediates.COMMON) dir, which is used as dependency.
Nothing is changed for host Java libraries.
Change-Id: I2546dbb940c74537864ca002d1acb49bb731fbbc
Setting LOCAL_CERTIFICATE to "EXTERNAL" now marks an apk (either a
prebuilt or otherwise) as needing the default test key within the
system, but one that should be signed after the target_files is
produced but before sign_target_files_apks does the rest of the
signing. (We use this to ship apps on the system that are signed by
third parties, like Facebook.)
Require people who check in new prebuilts to decide what keys they
should be signed with, rather than having a fire drill every time we
go to sign a build and discover new prebuilts.
If a prebuilt specifies a LOCAL_CERTIFICATE, stick it in the
PACKAGES.* collection so that the predexopt process can work on the
file (which only works if the new .apk can be signed).
Change things so that when $(LOCAL_PREBUILT_STRIP_COMMENTS) is
nonempty, we copy the source file using sed to strip out all the "#
line"-style comments and blank lines, saving considerable system image
space in the case of some wifi configurations.
Bug: 2036961
