summaryrefslogtreecommitdiffstats
path: root/core/dpi_specific_apk.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. Bug: 19947218 Change-Id: I0e1a65a9cbe656974f8ef3923b2f15e9efa5feb9
* Package dpi specific resources when Jack is enabledYohann Roussel2015-02-191-1/+8
| | | | Change-Id: I75995305359fe3870df61e67ba22c8d259342bf9
* am 385f5e7d: am 7ecc76a0: Support dpi specific aapt flags.Ying Wang2015-01-301-1/+1
|\ | | | | | | | | * commit '385f5e7d090d4721e61d0db60e7287dae8117b77': Support dpi specific aapt flags.
| * Support dpi specific aapt flags.Ying Wang2015-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | With this support, you can set dpi-specific aapt flags like: $(LOCAL_PACKAGE_NAME)_aapt_flags_hdpi := --version-code 100 \ --version-name "100 which will override the --version-code and --version-name set in the base apk's LOCAL_AAPT_FLAGS. Bug := 18388705 Change-Id: Ie79d7b1b6bbf7463bce51ddae04ba81384ec58dc
* | Running jarjar on Java resources.Ying Wang2015-01-211-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. When jack is enabled, in jack-java-to-dex we add the Java resources to a temp jar using the PRIVATE_EXTRA_JAR_ARGS, and extrac the files in a temp dir. Jack will process the resource files and output the result to PRIVATE_JACK_INTERMEDIATES_DIR. When we package the final apk/jar, we need to call add-carried-jack-resources to readd the resources. (TODO: if jack can output all resources to a jar/zip file, we can use that file as the initial package file as well.) Bug: 18837479 Change-Id: I8d7296e30ec8d005054cf04c4f2aed6d7a0d823b
* | Revert "Running jarjar on Java resources."Narayan Kamath2015-01-211-13/+10
| | | | | | | | | | | | | | | | This reverts commit 140274707e31c9585aa28b0de2f1418c64ecd272. Breaks the build on uiautomator_compat. Change-Id: I6d14f39e3432bf5e691027bbb8e7260e4bec8e8d
* | Running jarjar on Java resources.Ying Wang2015-01-201-10/+13
|/ | | | | | | | | | | | | | | | | | | | | | 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. When jack is enabled, in jack-java-to-dex we add the Java resources to a temp jar using the PRIVATE_EXTRA_JAR_ARGS, and extrac the files in a temp dir. Jack will process the resource files and output the result to PRIVATE_JACK_INTERMEDIATES_DIR. When we package the final apk/jar, we need to call add-carried-jack-resources to readd the resources. (TODO: if jack can output all resources to a jar/zip file, we can use that file as the initial package file as well.) Bug: 18837479 Change-Id: I15ecf282bfb65fd53dd03fbd03dd4c71927c186a
* Support to build dpi-specific apk variants.Ying Wang2014-12-021-0/+70
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