| 2902d4585f2a60a91084e96d00f2ee8d8301bf65 |
|
29-Oct-2014 |
Ying Wang <wangying@google.com> |
Add support for prebuilt AARs.
- You can give a .aar as source file to a prebuilt static Java library
module. The build system will set up dependencies and rules to extract
classes.jar and other resource files.
- To build against a prebuilt AAR module, use:
LOCAL_STATIC_JAVA_AAR_LIBRARIES := <module names of aar prebuilt AARs>
The build system will set up rules to merge the library's
AndroidManifest.xml with the main AndroidManifest.xml, add the AAR's
resource dirs and link/merge the AAR's classes.jar.
Bug: 18168693
Change-Id: Ic2c1d20572a93bd98dbc72f8a39e26b459e442c2
(cherry picked from commit e9dd9f2bfceed3b5f630b0edbe3feb7f34548d8b)
|
| 60686586a5f9c8f78b9ad16e19782da85e89a760 |
|
10-Dec-2014 |
Ying Wang <wangying@google.com> |
Add product variable PRODUCT_AAPT_PREBUILT_DPI
We use search LOCAL_DPI_VARIANTS in the list of
"$(PRODUCT_AAPT_PREF_CONFIG) $(PRODUCT_AAPT_PREBUILT_DPI)"
and the first takes precedence.
That way if we don't have a best match, we fall back to the second best,
the way how it worked with PRODUCT_AAPT_CONFIG previously.
Bug: 18388705
Change-Id: I8bd646c52215c65cc6e38c728857af9b64d13469
|
| 43f7a3226afd3439b9e83c05606d14e3766381cc |
|
18-Nov-2014 |
Ying Wang <wangying@google.com> |
Support prebuilt apk source selection based on PRODUCT_AAPT_PREF_CONFIG
Two new LOCAL variables are added to support dpi-specific prebuilt apk
selection:
- LOCAL_DPI_VARIANTS: specify a list of dpis the module provides with
specific prebuilt.
Example: LOCAL_DPI_VARIANTS := xxhdpi xhdpi hdpi mdpi
- LOCAL_DPI_FILE_STEM: specify the dpi-specific source file name
pattern.
Example: LOCAL_DPI_FILE_STEM := MyApp-%.apk
"%" will be substitued by $(PRODUCT_AAPT_PREF_CONFIG) in the core
build system.
If you don't set up LOCAL_DPI_FILE_STEM, the default is
$(LOCAL_MODULE)_%.apk.
The build system searches $(PRODUCT_AAPT_PREF_CONFIG) in a prebuilt apk
module's $(LOCAL_DPI_VARIANTS). If not found, use whatever
$(LOCAL_SRC_FILES) as the source file; Otherwise use $(LOCAL_DPI_FILE_STEM)
to construct the dpi-specific apk's source file name, and use whatever
directory name of $(LOCAL_SRC_FILES).
Bug: 18388705
Change-Id: I63cae73f1b6f880302142abc476b3ce1fb5500b5
|
| 5e0dbe0c3769031b4785ef54a89554cd5c75cba7 |
|
02-Oct-2014 |
Andreas Gampe <agampe@google.com> |
Conditionally skip dex-preopting prebuilts.
To skip dex-preopting prebuilts (to save system image space),
set "DONT_DEXPREOPT_PREBUILTS := true".
Bug: 17772057
Change-Id: I13f10e2a9c251366f29606158f8c2fb54f8ee8b1
|
| 00fe587974565b110813b22ac12451758be0037d |
|
23-Jul-2014 |
Ying Wang <wangying@google.com> |
Support to install prebuilt split APKs with LOCAL_PACKAGE_SPLITS
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
|
| af9757e84940a3d3f4a4b88d2f1ed259d4f43c02 |
|
18-Jul-2014 |
Ying Wang <wangying@google.com> |
New installation path for apks and their JNIs.
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
|
| 8e20ef6205b3c96135b1c1e4484d523dbecb1b98 |
|
25-Jun-2014 |
Ying Wang <wangying@google.com> |
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
|
| e1b867dde77d59bb35f366c2e3d65fe37c696880 |
|
10-Jun-2014 |
Ying Wang <wangying@google.com> |
Fix loophole in module expansion.
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
|
| 36142f64aef3da56a6e70589dad634b5babc0c31 |
|
22-May-2014 |
Ying Wang <wangying@google.com> |
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
|
| 7cf9f28b5f064f309a5023eb73234cecb5cf3de9 |
|
19-Apr-2014 |
Ying Wang <wangying@google.com> |
Support to extract JNI libs from prebuilt APK
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
|
| b9aa5d43de114cecdf94fabb23d3f61f147b627d |
|
13-May-2014 |
Ying Wang <wangying@google.com> |
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
|
| 34d5f1b27e862bf0653d89b9111d38f7de1f9c95 |
|
16-May-2014 |
Ying Wang <wangying@google.com> |
Real "LOCAL_MULTILIB := both" for prebuilts
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
|
| 6feb6d5607ce86a446645564212043964628f540 |
|
17-Apr-2014 |
Ying Wang <wangying@google.com> |
Support host multilib build
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
|
| 74eb6600b4973c8773255fe9bafc44dfb6aca2aa |
|
19-Apr-2014 |
Ying Wang <wangying@google.com> |
Support to extract JNI libs from prebuilt APK
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
|
| 695e826a0cc1da05a0d7bedf73c031cb8ead97c0 |
|
17-Apr-2014 |
Ying Wang <wangying@google.com> |
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
|
| 96bcad49f4c1d33f183dc9ad04eec3a4b8ab0b5e |
|
17-Apr-2014 |
Ying Wang <wangying@google.com> |
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
|
| f0534c289786d6a6c98cc5550f5027e13a5a8bff |
|
15-Apr-2014 |
Ying Wang <wangying@google.com> |
LOCAL_CERTIFICATE only applies to APPS.
Change-Id: Iae8c62f1686736f3ce21a2eb6b82fedc9fd12125
|
| 6c930fc1c954b1eee163ae49206406b40614f356 |
|
27-Feb-2014 |
Ying Wang <wangying@google.com> |
Select src arch for prebuilts.
Change-Id: I2d08f923d28d59cfef93ff0bd9893352baaee60b
|
| c0adfb76cdae425b4c03d85de184364edc33338f |
|
27-Feb-2014 |
Ying Wang <wangying@google.com> |
Select src arch for prebuilts.
Change-Id: I2d08f923d28d59cfef93ff0bd9893352baaee60b
|
| 58f462fccf4a0a1e20abd3dba2f63a42b0f0fdc3 |
|
26-Feb-2014 |
Ying Wang <wangying@google.com> |
Fix prebuilt library dependency for multilib build
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
|
| e18cb93e48bb4dc250e30f5bd22df9590d0b60e8 |
|
14-Feb-2014 |
Colin Cross <ccross@android.com> |
support LOCAL_MODULE_TARGET_ARCH for prebuilts
Prebuilts often support only a single architecture, allow them to
use LOCAL_MODULE_TARGET_ARCH to specify it.
Change-Id: I2514f66f682ef267bbf1a1ab78510faff0a18b64
|