Commit graph

7 commits

Author SHA1 Message Date
Ying Wang
8e20ef6205 Support to add JNI of both archs in multilib build.
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
2014-06-25 09:07:01 -07:00
Ying Wang
994c226b91 Fix pattern rules for $(installed_odex) for libdvm.
When the VM is libdvm, we don't put the odex files in an arch specific
subdirectory. The previous pattern rules don't work because of the extra
"/". With this change, % evaluates to empty string when it's built for
libdvm; % evaluates to "<arch_name>/" when it's built for libart.
Also removed use of $(create-empty-package), which may causes file name
(dummy) conflict with the rule of package.apk.

Bug: 15311527
Change-Id: I9f9089bc1896b78c1f47834afdb28a3a51d34480
2014-05-28 14:23:26 -07:00
Ying Wang
36142f64ae Split the rules to build the odex file
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
2014-05-21 16:24:59 -07:00
Ying Wang
b9aa5d43de Multilib support for odex
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
2014-05-18 22:04:58 -07:00
Ying Wang
695e826a0c Update rules to install JNI libraries.
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
2014-04-18 16:36:19 -07:00
Andrew Hsieh
73d800e519 Add LOCAL_NDK_STL_VARIANT:=c++_static and c++_shared
Add llvm libc++ static and shared libraries

Change-Id: I92af9b6ab21cbf8ea82e014a4c11aeb5455920f9
2014-03-17 20:30:45 +08:00
Colin Cross
8e4041271d add support for module supported or unsupported target architectures
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
2014-02-12 12:17:55 -08:00