core_current is a pseudo SDK version which is a core Java API subset of
the Android API. It is expected to be mainly used for external Java
projects which are agnostic to Android; such as junit, guava, etc.
A module built with this SDK version can only link to java modules of
the same kind. It can't depend on modules built with LOCAL_SDK_VERSION
:= current or without LOCAL_SDK_VERSION.
Bug: 72206056
Test: m -j
Change-Id: I34a9696393aa6704fd6684a40ea5b05d3fb46b23
The system_$(VER) can be set in LOCAL_SDK_VERSION, and the apk will use
android_system.jar at build time.
If LOCAL_SDK_VERSION is not defined and this module is installed in
vendor.img, LOCAL_SDK_VERSION is set to system_current.
Bug: 67724799
Test: 1. build && run on taimen
2. LOCAL_SDK_VERSION:=system_27 in ims.apk && build ims.apk && check
the vsdk_v27_intermediates.
Merged-In: I5b11c78b8fcd4a2f2a5e3b141527cd34dbe80018
Change-Id: I5b11c78b8fcd4a2f2a5e3b141527cd34dbe80018
(cherry picked from commit ef212cbe8d)
PRODUCT_AAPT2_CFLAGS and PRODUCT_AAPT_FLAGS are only used to pass
--pseudo-localize. The flag doesn't need to be conditional on the
product, because the pseudo locale will be stripped out later if it
is not wanted. Having it conditional on the product causes the
AAPT2-compiled resources to vary between products, which causes
unnecessary rebuilds when swithcing products.
Remove the variables, always add --pseudo-localize, and move
the AAPT2 compiled output to the common intermediates.
Test: m checkbuild
Change-Id: Iacc914114616b5bd19d9a1011802f4f9bca9bc19
If a resource was moved / removed without any other timestamp updates,
ninja would not re-run aapt. To fix this, add a list of resource files
into the same command as aapt (echo ... >/dev/null). That way if the
list changes, ninja will recognize the command line changing and rerun
aapt.
Bug: 67315436
Test: mmma cts/tests/autofillservice
Test: mv cts/tests/autofillservice/res/layout/welcome_activity.xml \
cts/tests/autofillservice/res/layout/welcome_activity_test.xml
Test: mmma cts/tests/autofillservice
Change-Id: Ia93ac4ff48910fed74a1f1539ce4e1f5a9db023f
Remove all support for running jack.
Bug: 65302138
Test: m -j checkbuild
Change-Id: I1ef87c88af3f2689f8b0dcf1a01c958b16159631
Merged-In: I1ef87c88af3f2689f8b0dcf1a01c958b16159631
(cherry picked from commit 5db5d31d73)
Downstream users of a library always link against javalib.jar, which
is either the dex jar for java libraries or a copy of
proguard.classes.jar for static java libraries. In preparation for
making java libraries a superset of static java libraries, make
classes.jar always be the final class-containing jar for use
downstream, and always create a classes-pre-proguard.jar for
users that need a jar without shrinking or obfuscation.
Also rename the intermediates to be consitent: classes-<tool>.jar
Test: m -j ANDROID_COMPILE_WITH_JACK=false java
Change-Id: I3df8b9a4edcd5db996f1fedc54c8a782d4f36a92
Merged-In: I3df8b9a4edcd5db996f1fedc54c8a782d4f36a92
(cherry picked from commit 6fabefa88e)
Downstream users of a library always link against javalib.jar, which
is either the dex jar for java libraries or a copy of
proguard.classes.jar for static java libraries. In preparation for
making java libraries a superset of static java libraries, make
classes.jar always be the final class-containing jar for use
downstream, and always create a classes-pre-proguard.jar for
users that need a jar without shrinking or obfuscation.
Also rename the intermediates to be consitent: classes-<tool>.jar
Test: m -j ANDROID_COMPILE_WITH_JACK=false java
Change-Id: I3df8b9a4edcd5db996f1fedc54c8a782d4f36a92
This is a partial revert of commits:
858657366f Remove support of disabling Jack.
3ae7861252 Remove javac support in host dex rules.
22313f2b2a Remove rules for building dex with dx
Test: builds
Change-Id: Ie12d743cbe978bdeb030910848b67f5945a4fec8
am: f562875d0c
* commit 'f562875d0c232b91be9a0931d30c31b1bbb98c45':
Make apks depend on their certificates
Change-Id: I28f5f91a6265201136cdf83c18c7ada359bb4d33
We removed code and variables related to running dx on classes.jar in
this change. Also removed target emma rules (but kept the emma rules for
host java libraries), for it's now done by Jack.
We still support to build classes.jar (and javalib.jar for static Java
libraries) using javac, because tools like javadoc need class files as
input.
Removed the obsolete install-dex-debug.
Bug: 27400061
Change-Id: If0bcdfe62cb181a98754fb0dbe1c12c92e38d3e8
This changes the build system to no longer run zipalign except for
those prebuilts which do not need to re-signed.
Running zipalign is no longer needed because signapk takes care of
alignment. For those prebuilts which do not need to be re-signed
signapk is not invoked and thus zipalign is still needed because the
prebuilts may not have been aligned properly. This exemption will go
away once prebuilts are properly aligned.
Bug: 25794543
Change-Id: I31f10af80b9baa3c9481cb36f41e5e5046e852f9
With commit 33360dd569 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
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
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
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
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
