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
Otherwise we may end up conflict between LOCAL_MODULE_HOST_ARCH and the
default multilib mode.
Also removed the unneeded variants of LOCAL_MODULE_HOST_ARCH.
Change-Id: I9e5a0144da3cb6310be0ddf098738987e51305de
Allow LOCAL_JAR_PACKAGES to work on subpackages. Previously it
only worked on top-level packages due to a bug in how the directories
were recursively deleted.
Add LOCAL_JAR_EXCLUDE_PACKAGES to allow specific subpackages to
be excluded. This rule applies after LOCAL_JAR_PACKAGES has
selected which packages to include. It may also be used independently.
Change-Id: Ibd0e495be1a20c84b59c9da132e92100ef3f8705
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 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
With this change, you can package up modules while avoiding installing
them to the system.img or userdata.img.
- build/core/tasks/tools/package-modules.mk
You can use this template to package up modules into a zip file and
preserve the installed file paths.
- LOCAL_PICKUP_FILES, you can use this variable to package up extra
files/directories.
Bug: 13585955
Change-Id: I103042b24ccf17cf5dc90c016d97ed1dd293e50b
With this change, you can package up modules while avoiding installing
them to the system.img or userdata.img.
- build/core/tasks/tools/package-modules.mk
You can use this template to package up modules into a zip file and
preserve the installed file paths.
- LOCAL_PICKUP_FILES, you can use this variable to package up extra
files/directories.
Bug: 13585955
Change-Id: I103042b24ccf17cf5dc90c016d97ed1dd293e50b
To build oem.img:
- You must define BOARD_OEMIMAGE_PARTITION_SIZE in your BoardConfig.mk
- The file system type will be the same as system.img and userdata.img.
- To install a module to oem.img, use "LOCAL_OEM_MODULE := true"
- run "make -j48 showcommands oem_image dist". By default it's not
built.
Bug: 13367676
Change-Id: I1a26d4d0c61b72ecffe60279667b1b3de050780d
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
Delete LOCAL_NO_2ND_ARCH, it is no longer used. Equivalent
functionality is available with LOCAL_MULTILIB := first.
Change-Id: I36838a8a7e10b0a59ca0022c4c8a3a190e782c71
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
* commit '8295d6cd62ba73ea66e64204d2d0ea27b4b34889':
add support for LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64
add support for LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64
* commit 'ce08741397e0468185457f5c7e8aee08272e6752':
add support for LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64
add support for LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64
Some executables will need to be built for both 32-bit and 64-bit.
For linker/linker64, debuggerd/debuggerd64, and a few more, they
will be installed in the same path (/system/bin), but with different
filenames. Allow the module to specify LOCAL_MODULE_STEM_32 and
LOCAL_MODULE_STEM_64 to name the two versions.
Change-Id: I573e8678c7332245a064f31246be0a05f0a9e25f
Some executables will need to be built for both 32-bit and 64-bit.
For tests, it will be convienient to keep the name of the executable
the same, but install them in a different location. Add
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to allow a module
to specify different paths for 32-bit and 64-bit executables.
Change-Id: I3be830e899c6d485fe55c25c66b20b3fe64c795e
Add four new variables for module makefiles:
LOCAL_MODULE_TARGET_ARCH specifies that a module is only supported for
one or more architectures. Any architecture not in the list will be
not attempt to build the module. The expected use case is prebuilts
that are only suitable for a single architecture, or modules like llvm
that need per-architecture support.
LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH specifies that a module cannot be
built for one or more architectures.
LOCAL_MODULE_TARGET_ARCH_WARN and LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN
are the same, but warn that the arch is not supported, which is useful
for modules that are critical but not yet working.
The logic for whether or not to build an architecture is fairly
complicated, so this patch consolidates it into module_arch_supported.mk
Change-Id: I120caf4a375f484e1fd6017b60c2f53882ae01e6
Ying Wang