summaryrefslogtreecommitdiffstats
path: root/core/package_internal.mk
Commit message (Collapse)AuthorAgeFilesLines
* Add back Java resources to apk without Java code.Ying Wang2015-03-271-1/+4
| | | | | | | | | | | | | | 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
* am 095c4515: Merge "Remove unused variables."Narayan Kamath2015-02-271-8/+0
|\ | | | | | | | | * commit '095c451541765c7efb9d5a8152f8ef15626ccedb': Remove unused variables.
| * Remove unused variables.Narayan Kamath2015-02-261-8/+0
| | | | | | | | | | | | Follow up from 13e5965306212a9051772ff1d5bc3a88e5fb5. Change-Id: I370e52acd998ce72b4d7dbf2aba604d4b08bb0cf
* | am 37a44faa: Merge "Store native libs aligned to PAGE_SIZE"Narayan Kamath2015-02-261-1/+11
|\ \ | |/ | | | | | | * commit '37a44faa7266c8a7e0cc5077a4c028d6f5bfa7f7': Store native libs aligned to PAGE_SIZE
| * Store native libs aligned to PAGE_SIZEDmitriy Ivanov2015-02-261-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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
* | am e937ac81: Merge "Add new build flag LOCAL_DONT_DELETE_JAR_DIRS."Ying Wang2015-01-291-0/+1
|\ \ | |/ | | | | | | * commit 'e937ac814c7f4e1989509f94f7ac8ae5b28a3526': Add new build flag LOCAL_DONT_DELETE_JAR_DIRS.
| * Add new build flag LOCAL_DONT_DELETE_JAR_DIRS.Fredrik Roubert2015-01-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | am 29a29875: Merge "Running jarjar on Java resources."Ying Wang2015-01-221-5/+8
|\ \ | |/ | | | | | | * commit '29a29875627758aa3c76aa5256641c1782c904bf': Running jarjar on Java resources.
| * Running jarjar on Java resources.Ying Wang2015-01-211-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Fix using variable intermediates.COMMON before defining.Ying Wang2014-12-181-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Add support for prebuilt AARs.Ying Wang2014-12-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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)
* | Support to build dpi-specific apk variants.Ying Wang2014-12-021-0/+10
|/ | | | | | | | | | | | | | | | | | 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
* Convert comma in split arguments to underscore.Ying Wang2014-10-011-3/+5
| | | | | | | aapt already does so. Bug: 16947729 Change-Id: I813fb8cf41b3ec836e6e6d5f68af12dc385169f8
* Allow LOCAL_ASSET_DIR point to nonexistent dirYing Wang2014-09-201-1/+8
| | | | | | | | | | 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
* Support to build apk odex for both arch.Ying Wang2014-09-131-1/+2
| | | | | | | | | | 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
* Don't apply PRODUCT_AAPT_PREF_CONFIG if LOCAL_PACKAGE_SPLITS is setYing Wang2014-07-301-0/+4
| | | | | Bug: 16319961 Change-Id: I8ea308c94ff58eaccd8854ab98e11238b993f867
* Improve rules of split apks.Ying Wang2014-07-231-6/+16
| | | | | | | | | | | - 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.Ying Wang2014-07-221-0/+30
| | | | | | | | | 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
* Support "LOCAL_SDK_VERSION := system_current"Ying Wang2014-07-191-2/+2
| | | | | | | | 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
* New installation path for apks and their JNIs.Ying Wang2014-07-181-0/+1
| | | | | | | | | 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
* am 01b179bf: am bb964f00: am 432cd6dd: Merge "Allow LOCAL_RESOURCE_DIR ↵Ying Wang2014-06-251-5/+13
|\ | | | | | | | | | | | | pointing to dir generated during the build" * commit '01b179bf3b5c4c0307e0efb4004a1c44705fe780': Allow LOCAL_RESOURCE_DIR pointing to dir generated during the build
| * am bb964f00: am 432cd6dd: Merge "Allow LOCAL_RESOURCE_DIR pointing to dir ↵Ying Wang2014-06-251-5/+13
| |\ | | | | | | | | | | | | | | | | | | generated during the build" * commit 'bb964f00403a23d2f1ec3313f7b579a9e7f0f12a': Allow LOCAL_RESOURCE_DIR pointing to dir generated during the build
| | * Allow LOCAL_RESOURCE_DIR pointing to dir generated during the buildYing Wang2014-06-251-5/+13
| | | | | | | | | | | | | | | Bug: 15850610 Change-Id: I46b98adb556d8e6bf166761f8bb240006dbe5b14
* | | am 904446ce: am 1a3d260f: am e69d4350: Merge "Support to add JNI of both ↵Ying Wang2014-06-251-2/+4
|\ \ \ | |/ / | | | | | | | | | | | | | | | archs in multilib build." * commit '904446ce0b3f430ac88ae0c08b9c613721474cd5': Support to add JNI of both archs in multilib build.
| * | am 1a3d260f: am e69d4350: Merge "Support to add JNI of both archs in ↵Ying Wang2014-06-251-2/+4
| |\ \ | | |/ | | | | | | | | | | | | | | | multilib build." * commit '1a3d260f68755b476aa867477fc75d47ef5317bf': Support to add JNI of both archs in multilib build.
| | * Support to add JNI of both archs in multilib build.Ying Wang2014-06-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Reinforce the dependency on package-export.apk.Ying Wang2014-06-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | | am dcf90646: am 8898f2e2: am f4999d3b: Merge "Fix pattern rules for for ↵Ying Wang2014-05-281-1/+1
|\ \ \ | |/ / | | | | | | | | | | | | | | | libdvm." * commit 'dcf90646b0122b09755014832a67b7c44bc2e1ac': Fix pattern rules for $(installed_odex) for libdvm.
| * | am 8898f2e2: am f4999d3b: Merge "Fix pattern rules for for libdvm."Ying Wang2014-05-281-1/+1
| |\ \ | | |/ | | | | | | | | | * commit '8898f2e261d1bb2b389971803a1f4a23639ade9e': Fix pattern rules for $(installed_odex) for libdvm.
| | * Fix pattern rules for $(installed_odex) for libdvm.Ying Wang2014-05-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | am 913e0317: am a72e6f80: am 8a3f514d: Merge "Split the rules to build the ↵Ying Wang2014-05-221-7/+12
|\ \ \ | |/ / | | | | | | | | | | | | | | | odex file" * commit '913e031793928981640f51fa2e6480312f044c37': Split the rules to build the odex file
| * | am a72e6f80: am 8a3f514d: Merge "Split the rules to build the odex file"Ying Wang2014-05-221-7/+12
| |\ \ | | |/ | | | | | | | | | * commit 'a72e6f80e447acf225822eebdf752c0d8aa2590c': Split the rules to build the odex file
| | * Split the rules to build the odex fileYing Wang2014-05-211-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | am 8074ff4d: am a8355eca: am 64f3a191: Merge "Multilib support for odex"Brian Carlstrom2014-05-191-7/+1
|\ \ \ | |/ / | | | | | | | | | * commit '8074ff4d0f962a933586b9809d1f1bdffe1fe5ed': Multilib support for odex
| * | am a8355eca: am 64f3a191: Merge "Multilib support for odex"Brian Carlstrom2014-05-191-7/+1
| |\ \ | | |/ | | | | | | | | | * commit 'a8355ecaadf9a0d052165d0cc14564927eb9a202': Multilib support for odex
| | * Multilib support for odexYing Wang2014-05-181-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | am a59c2935: am 488b23d9: Merge "Update rules to install JNI libraries."Ying Wang2014-04-191-44/+1
| |\ \ | | |/ | | | | | | | | | * commit 'a59c2935bc63babded85aa1ce1a8b00e28dc6a11': Update rules to install JNI libraries.
| | * Update rules to install JNI libraries.Ying Wang2014-04-181-44/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Update rules to install JNI libraries.Ying Wang2014-04-181-44/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Temporarily use a separate var for including shared resourcesAdam Lesinski2014-03-251-2/+2
| | | | | | | | | | | | Change-Id: I56636a1d7dfdaa070706f1991f80e03fe2f71069
* | | Set up dependency of resource_export_packageYing Wang2014-03-251-1/+2
| | | | | | | | | | | | | | | | | | | | | 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 LOCAL_APK_LIBRARIES to the AAPT -I flagAdam Lesinski2014-03-251-2/+12
|/ / | | | | | | Change-Id: I5c5c90de3c8ce6c224b6e3fbf42d5e72cfd7a4d1
* | am d14f3cc7: am 5384c187: Merge "Add LOCAL_NDK_STL_VARIANT:=c++_static and ↵Andrew Hsieh2014-03-181-1/+8
|\ \ | |/ | | | | | | | | | | c++_shared" * commit 'd14f3cc7bc9983ea5ba1c2d952d2b5f51935f42c': Add LOCAL_NDK_STL_VARIANT:=c++_static and c++_shared
| * Add LOCAL_NDK_STL_VARIANT:=c++_static and c++_sharedAndrew Hsieh2014-03-171-1/+8
| | | | | | | | | | | | Add llvm libc++ static and shared libraries Change-Id: I92af9b6ab21cbf8ea82e014a4c11aeb5455920f9
* | resolved conflicts for merge of 7cd7bd65 to klp-modular-dev-plus-aospColin Cross2014-02-121-13/+10
|/ | | | Change-Id: Ib4f062a59d442b29b9782fd8c0328fd551c3a32a
* add support for module supported or unsupported target architecturesColin Cross2014-02-121-0/+469
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