In prebuilt app module, you can use LOCAL_PACKAGE_SPLITS to specify a
list of prebuilt split apks. The build system will sign and zipalign the
apks and install them with the same file names.
Note that you need to put all the source split apks in the same folder.
Bug: 16319961
Change-Id: Id2b6d743c1edc5e436007ec11acece1748adad45
Apk's path is changed to <parent_dir>/MyApp/MyApp.apk;
JNI path is changed to <parent_dir>/MyApp/lib/<arch_name>/libfoo.so.
Symlinks of JNIs are changed accordingly.
Bug: 16319961
Change-Id: Ib3b2309c95fa9aea27837fcc29e28d990b04747b
Use "LOCAL_MULTILIB := both" to install jni libraries of both archs in
multilib build.
The build system will package jni of both archs to the apk, or install
them to the right location on the system image and create symlinks,
extract .so files from prebuilt apk, etc if appropriate.
Bug: 15849902
Change-Id: I7e147b5a47db476584c38250de7b36c75ea40d81
Previously we only expanded product_MODULES with LOCAL_REQUIRED_MODULES,
but not modules introduced by LOCAL_SHARED_LIBRARIES; Later we did a further
shared libary expansion in vendor_module_check.mk.
It couldn't track C in the following case:
A : B, by LOCAL_SHARED_LIBRARIES; B : C, by LOCAL_REQUIRED_MODULES.
With this change, we transformed the LOCAL_SHARED_LIBRARIES dependencies
into LOCAL_REQUIRED_MODULES dependencies before doing the required
module expansion and the loophole is closed.
All module names are now expanded to product_MODULES now and it makes
vendor_module_check.mk simpler.
Change-Id: I8835a478d2ce0ce10601a8449f446f07b01c2b7f
Previously the odex file is byproduct generated by the package.apk rule.
Though we have the odex file depend on the package.apk it doesn't have
its own build recipe. In case package.apk isn't updated but we still
need to update the odex file (such as changed LOCAL_MULTILIB), the odex
file will never be rebuilt.
This change split out the rules to build the odex file and make sure the
build recipe get executed if the odex file needs rebuild.
Change-Id: I60c2f32b536b3d59045301ee863aae1451734aad
Use LOCAL_PREBUILT_JNI_LIBS to install prebuilt JNI libraries extracted
from the prebuilt apk, or prebuilts as source, to the app specific lib path.
LOCAL_PREBUILT_JNI_LIBS accepts 2 kinds of files:
- Files like @path/to/libfoo.so (path inside the apk) are JNI libs
extracted from the prebuilt apk. In this case, all embedded JNI libs
inside the prebuilt apk are stripped.
- Files like path/to/libfoo.so (path relative to LOCAL_PATH) are
prebuilts in the source tree.
Those prebuilt JNI libs are not defined as modules in the build system,
so this works around possible module name conflict.
Bug: 13170859
Change-Id: I91bb844cc11b3621a85733bc7e8910f168957ef0
If the VM is libart and DEXPREOPT is enabled,
- For a Java library and the boot image, we build for both 1st arch and
2nd arch.
- For an app, we build for the multilib arch the module is targeted for.
The odex file will be in <arch_name>/<module_name>.odex inside the same
dir where the jar/apk file gets installed.
Nothing changed if it's built for libdvm.
Bug: 14694978
Change-Id: I45118a83758b41d52d6c9e38f93f0ba2775a6c74
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
Use LOCAL_PREBUILT_JNI_LIBS to install prebuilt JNI libraries extracted
from the prebuilt apk, or prebuilts as source, to the app specific lib path.
LOCAL_PREBUILT_JNI_LIBS accepts 2 kinds of files:
- Files like @path/to/libfoo.so (path inside the apk) are JNI libs
extracted from the prebuilt apk. In this case, all embedded JNI libs
inside the prebuilt apk are stripped.
- Files like path/to/libfoo.so (path relative to LOCAL_PATH) are
prebuilts in the source tree.
Those prebuilt JNI libs are not defined as modules in the build system,
so this works around possible module name conflict.
Bug: 13170859
Change-Id: I91bb844cc11b3621a85733bc7e8910f168957ef0
Previously we have to use LOCAL_REQUIRED_MODULES to install jni
libraries for an apk in bundled build.
With this change, we'll use LOCAL_JNI_SHARED_LIBRARIES alone to
install jni shared libraries.
The new rules are:
- If we are doing unbundled build, or the apk isn't going to be
installed to system partitions, we'll embed the jni libs in the
built apk.
- Otherwise, the jni libraries will be installed to the system
lib path, and symlinks created in the app specific lib path.
Change-Id: Id6bd5301eb632bda3593664acee580f0d8b1d5d4
Previously we have to use LOCAL_REQUIRED_MODULES to install jni
libraries for an apk in bundled build.
With this change, we'll use LOCAL_JNI_SHARED_LIBRARIES alone to
install jni shared libraries.
The new rules are:
- If we are doing unbundled build, or the apk isn't going to be
installed to system partitions, we'll embed the jni libs in the
built apk.
- Otherwise, the jni libraries will be installed to the system
lib path, and symlinks created in the app specific lib path.
Change-Id: Id6bd5301eb632bda3593664acee580f0d8b1d5d4
Also we don't need to include module_arch_supported.mk again, if we are
currently substituting the source build with LOCAL_PREBUILT_MODULE_FILE.
Change-Id: I444b0397d74c3153b398a050b762e49418062a86
Prebuilts often support only a single architecture, allow them to
use LOCAL_MODULE_TARGET_ARCH to specify it.
Change-Id: I2514f66f682ef267bbf1a1ab78510faff0a18b64
Ying Wang