| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With commit 33360dd56925276e4526f5f52c26423e2bb1a670 we moved Java
resource packaging forward to creation of the jar file. But the Java
resource packaging will be skipped if a module has no Java code at all.
(The build system does support building an apk without Java code.)
In this change we add back the Java resources directly to the built apk
when the apk has no Java code.
(cherry-picked from commit 8b27d1879c5692ebe6c5ac85383981fd96dfe2e1)
Bug: 19947218
Change-Id: I0e1a65a9cbe656974f8ef3923b2f15e9efa5feb9
|
|\
| |
| |
| |
| | |
* commit '095c451541765c7efb9d5a8152f8ef15626ccedb':
Remove unused variables.
|
| |
| |
| |
| |
| |
| | |
Follow up from 13e5965306212a9051772ff1d5bc3a88e5fb5.
Change-Id: I370e52acd998ce72b4d7dbf2aba604d4b08bb0cf
|
|\ \
| |/
| |
| |
| | |
* commit '37a44faa7266c8a7e0cc5077a4c028d6f5bfa7f7':
Store native libs aligned to PAGE_SIZE
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Add a new flag to zipalign (-p) that page aligns shared
libraries (zip entries ending with ".so") in the archive.
- Add a new build variable LOCAL_PAGE_ALIGN_SHARED_LIBRARIES
to turn on this behaviour in zipalign.
- Add a new LOCAL_JNI_SHARED_LIBRARIES_ZIP_OPTIONS to control
zip behaviour.
Bug: 8076853
Bug: 19330157
Co-Authored-By: Simon Baldwin <simonb@google.com>
Co-Authored-By: Dimitry Ivanov <dimitry@google.com>
Change-Id: I1aa2c039bb2a590ae72f256acc9ba5401c2c59b1
|
|\ \
| |/
| |
| |
| | |
* commit 'e937ac814c7f4e1989509f94f7ac8ae5b28a3526':
Add new build flag LOCAL_DONT_DELETE_JAR_DIRS.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Normally the build function initialize-package-file will delete all
class files and all directory entries from JAR files, but sometimes
external projects (eg. ICU4J) depend on having directory entries in
their JAR files.
This change adds the flag LOCAL_DONT_DELETE_JAR_DIRS (analogous to the
flag LOCAL_DONT_DELETE_JAR_META_INF) which when set will skip deletion
of directory entries in initialize-package-file.
Change-Id: I4464b947b7528fca23925affa95e4071915f04d4
|
|\ \
| |/
| |
| |
| | |
* commit '29a29875627758aa3c76aa5256641c1782c904bf':
Running jarjar on Java resources.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this change, Java resources are added as a separate step
(add-java-resources-to-package) after dex is run, so jarjar isn't run on
the resource files.
With this change, we add Java resources immediately after we call javac,
so jarjar is run on the resource files (the module's own resource, as
well as resources carried by static Java libraries).
When we generate the final apk/jar, we use the jarjar'ed jar as the
inital pacakge file, with class files and empty folders removed.
(cherry-picked from commit 140274707e31c9585aa28b0de2f1418c64ecd272)
Bug: 18837479
Change-Id: I15ecf282bfb65fd53dd03fbd03dd4c71927c186a
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In commit e9dd9f2bf we moved "include $(BUILD_SYSTEM)/android_manifest.mk"
forward before the variable intermediates.COMMON gets defined. That's a
mistake.
This change replaced the tentative variables
package_expected_intermediates_COMMON and guessed_intermediates with
their proper counterparts defined in base_rules.mk.
If their values differ in the two file, that's an error and we should
fix.
Bug: 18168693
Change-Id: I2bf17b0476b4a7f97810fbb0bde7630eb8878b53
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- 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)
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In unbundled apps_only build, in addition to the base apk, you can also
build the dpi-specific apk variants, with:
LOCAL_DPI_VARIANTS := <a list of dpi names>
Previously user needs to include $(BUILD_PACKAGE) repeatedly with the
same package definition except dpi flags.
With this change, all the dpi-specific apk variants share the base apk's
compiled Java code and only diverge at the point we add resources/assets
to the apk.
Also we set up variables/targets/rules in a way those dpi-specific apks
appear to be independent apks to the users, for example, you can pass
"AppName_<dpi_name>" to tapas, and AppName_<dpi_name>.apk lives in its
own intermediate directory.
Bug: 18388705
Change-Id: I2ba4972ea7d1f796352fab2407888f996781ae44
|
|
|
|
|
|
|
| |
aapt already does so.
Bug: 16947729
Change-Id: I813fb8cf41b3ec836e6e6d5f68af12dc385169f8
|
|
|
|
|
|
|
|
|
|
| |
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 bfcdf060bab129581acff32eb70896f719162bc9)
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
|
|
|
|
|
| |
Bug: 16319961
Change-Id: I8ea308c94ff58eaccd8854ab98e11238b993f867
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|\
| |
| |
| |
| |
| |
| | |
pointing to dir generated during the build"
* commit '01b179bf3b5c4c0307e0efb4004a1c44705fe780':
Allow LOCAL_RESOURCE_DIR pointing to dir generated during the build
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
generated during the build"
* commit 'bb964f00403a23d2f1ec3313f7b579a9e7f0f12a':
Allow LOCAL_RESOURCE_DIR pointing to dir generated during the build
|
| | |
| | |
| | |
| | |
| | | |
Bug: 15850610
Change-Id: I46b98adb556d8e6bf166761f8bb240006dbe5b14
|
|\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | | |
archs in multilib build."
* commit '904446ce0b3f430ac88ae0c08b9c613721474cd5':
Support to add JNI of both archs in multilib build.
|
| |\ \
| | |/
| | |
| | |
| | |
| | |
| | | |
multilib build."
* commit '1a3d260f68755b476aa867477fc75d47ef5317bf':
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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | | |
libdvm."
* commit 'dcf90646b0122b09755014832a67b7c44bc2e1ac':
Fix pattern rules for $(installed_odex) for libdvm.
|
| |\ \
| | |/
| | |
| | |
| | | |
* commit '8898f2e261d1bb2b389971803a1f4a23639ade9e':
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
|
|\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | | |
odex file"
* commit '913e031793928981640f51fa2e6480312f044c37':
Split the rules to build the odex file
|
| |\ \
| | |/
| | |
| | |
| | | |
* commit 'a72e6f80e447acf225822eebdf752c0d8aa2590c':
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
|
|\ \ \
| |/ /
| | |
| | |
| | | |
* commit '8074ff4d0f962a933586b9809d1f1bdffe1fe5ed':
Multilib support for odex
|
| |\ \
| | |/
| | |
| | |
| | | |
* commit 'a8355ecaadf9a0d052165d0cc14564927eb9a202':
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
|
| |\ \
| | |/
| | |
| | |
| | | |
* commit 'a59c2935bc63babded85aa1ce1a8b00e28dc6a11':
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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | | |
Change-Id: I56636a1d7dfdaa070706f1991f80e03fe2f71069
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The rules to build $(resource_export_package) need also the
framework-res's and potentially other shared libraries' package-export.apks.
Change-Id: I9ff10c621917ba7eed2da11a51cd2426845ad9be
|
|/ /
| |
| |
| | |
Change-Id: I5c5c90de3c8ce6c224b6e3fbf42d5e72cfd7a4d1
|
|\ \
| |/
| |
| |
| |
| |
| | |
c++_shared"
* commit 'd14f3cc7bc9983ea5ba1c2d952d2b5f51935f42c':
Add LOCAL_NDK_STL_VARIANT:=c++_static and c++_shared
|
| |
| |
| |
| |
| |
| | |
Add llvm libc++ static and shared libraries
Change-Id: I92af9b6ab21cbf8ea82e014a4c11aeb5455920f9
|
|/
|
|
| |
Change-Id: Ib4f062a59d442b29b9782fd8c0328fd551c3a32a
|
|
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
|