LOCAL_ASSET_DIR may point to a dir generated during the build process.
We have done similiar things to LOCAL_RESOURCE_DIR.
(cherry picked from commit bfcdf060ba)
Bug: 16563899
Change-Id: Iaa72196e1e6350ae0720f8a4e0abc68d8d7ed642
Build odex for both arch in multilib build if an app has
LOCAL_MULTILIB := both.
Refactored the common setup code to a separate file setup_one_odex.mk.
Bug: 17409149
Bug: 14694978
Change-Id: I74c9426cd74fe0b0cb4811368f740a88ac2ae022
- Better messaging if the expected split apk isn't generated by the aapt
command in the base apk rule; Remove the built base apk, so make will
rerun aapt after the user changes the splitting parameters.
- Use cleaner static pattern rules instead of running $(foreach) with
$(eval).
Bug: 16319961
Change-Id: If6ae302e1a39d2e0db8f784d4e1cf292ec855281
Support LOCAL_PACKAGE_SPLITS, which accepts a list of resource lables
and generates multiple apks. The build system sets up rules to sign and
zipalign the split apks.
Bug: 16319961
Change-Id: I344b3d1c7eb158c6d0df879093d666a89870aadd
A module can declare "LOCAL_SDK_VERSION := system_current" to build
against the android system stubs generated from source.
For now this is only supported in platform build.
Change-Id: I1e9bbd159886bc0ea3a02b1dc4cbcb1a56e9cb15
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
This fixes the bug that if an app has no resource at all, we should
still set up the dependency on package-export.apk, because the
AndroidManifest.xml may still reference symbols in package-export.apk.
Change-Id: Idb3f12abf55c04824da5b666fe7c49694e227e2c
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
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
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
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
The rules to build $(resource_export_package) need also the
framework-res's and potentially other shared libraries' package-export.apks.
Change-Id: I9ff10c621917ba7eed2da11a51cd2426845ad9be
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
