Building an app with Jack and with the environment variable
EMMA_INSTRUMENT_STATIC set to true will apply code coverage
onto the app targeting Jacoco.
Bug: 20115492
Change-Id: Ief3640fa3faa466f7f6aaa9739e06d3db24110a0
To build with AAPT2, set "USE_AAPT2=true".
TODO: Support split apks and generated resources from other than renderscript.
Bug: 25958912
Change-Id: I19b1a038824ce5b2a3d3ffadbce3173c845193fc
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
Only if an app has LOCAL_INSTRUMENTATION_FOR, it can get the emma
classes from the target app and we don't need to instrument the test app
itself.
Change-Id: If0fba50ddae757254fc58ca104d729d61603fd78
When an app has a resource directory, but the
directory contain no resources, R.stamp is not created.
This leads to that such apps are always rebuilt,
even when there are no changes.
This patch changes so that an empty R.stamp is
created even if there are no resources.
This leads to that affected apps are not rebuilt
unless changed.
Change-Id: Ia63e5b1913a4456402700b615ba7f9d56d2da852
- Deleted unused functions in definitions.mk.
- lint is never fully functional in the platform source tree.
- Retire LOCAL_DIST_BUNDLED_BINARIES: now the build system/framework
supports JNI embedded in apk.
Change-Id: I6314cb20d1544c704ccbc4c1f9cccb9c54fb5a51
A module can specify itself to be a Compatibility Suite module with:
LOCAL_COMPATIBILITY_SUITE := <cts-name>
<cts-name> can be "cts" or any other cts name supported by the
build system.
The cts name's config.mk must define global variable
COMPATIBILITY_TESTCASES_OUT_<cts-name> to point to the testcase
output directory.
This change copies the module's built file, as well as the module's
AndroidTest.xml, to the testcase output directory.
The build system collects all the testcase files in a global variable
COMPATIBILITY.<cts-name>.FILES, which you can reference in a build
task that builds the suite's zip package.
Also copy over the test case files if user runs mm/mmm/etc.
Change-Id: Ica0dbc4f193db7de7d395b9c686733bdac41f566
- We don't need LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES now, for we always
page-align jni shared libraries and store them umcompressed.
- For prebuilt apks, we don't extract jni any more; Instead we always run
uncompress-shared-libs on them.
- For apks built from source, we still install the jni separately, because
that way multiple apks can share the same jni and it saves space.
With this change, for most prebuilt apks, we don't need to specify
LOCAL_PREBUILT_JNI_LIBS ("@lib/<abi>/foo.so") any more, for the build
system automatically replaces the embedded jni with uncompressed files;
But if a prebuilt is a fat apk (i.e. containing jni not needed by the
current product architecture), you still need LOCAL_PREBUILT_JNI_LIBS to
specify what jni to keep. Otherwise all embedded jni will be replaced with
uncompressed files, that wastes space.
Bug: 8076853
Change-Id: Ic3666dc72bf17cd293787414dd185470b365f967
This allows to compile dex targeted java sources using Jack and Jill.
Default is still to compile with the legacy toolchain. Default can be
switched to the new toolchain by setting environement variable:
export ANDROID_COMPILE_WITH_JACK=true
Toolchain can also be forced for one module by defining
LOCAL_JACK_ENABLED:=full # disabled, full, incremental
in the mk portion defining the module.
Jack execution environement can be controlled with:
Global variable ANDROID_JACK_VM allow to change the jvm executing Jack.
Global variable ANDROID_JACK_VM_ARGS allows to change default args given
to the jvm.
Global variable ANDROID_JACK_EXTRA_ARGS allows to define some default args
to give to Jack
LOCAL_JACK_VM_ARGS allows to override default args given to the jvm for
the module.
LOCAL_JACK_EXTRA_ARGS allows to override default args passed to Jack.
This includes cherry-picks of the following changes:
b4c49cba5722c3fa6d73138768c1bb5dd3e1d31283d5d040478bc90fd2d6140274707e0fbc9ff2a2833b427d72f9a27f45b4280966694137822c443dc6b44d43c3d2a76c14bf06744f60fc95573d5036b8213916142794e7b582801f2c44d0c76d99dca1f528e132d676a5e0bd1ae25b3984ff Partially, only Jack related parts werekept
ec46a3b71fabee3a9f4177cbe10fd9daf07db4cdb6bfb5893a
Ie all Jack related changes untill
b6bfb5893a
except
a96cc59ab5 "Use Jack by default"
Change-Id: If9d47ef1c4fd1e6765ad2a47d816c1ad3cfab0e3
- We don't need LOCAL_PAGE_ALIGN_JNI_SHARED_LIBRARIES now, for we always
page-align jni shared libraries and store them umcompressed.
- For prebuilt apks, we don't extract jni any more; Instead we always run
uncompress-shared-libs on them.
- For apks built from source, we still install the jni separately, because
that way multiple apks can share the same jni and it saves space.
With this change, for most prebuilt apks, we don't need to specify
LOCAL_PREBUILT_JNI_LIBS ("@lib/<abi>/foo.so") any more, for the build
system automatically replaces the embedded jni with uncompressed files;
But if a prebuilt is a fat apk (i.e. containing jni not needed by the
current product architecture), you still need LOCAL_PREBUILT_JNI_LIBS to
specify what jni to keep. Otherwise all embedded jni will be replaced with
uncompressed files, that wastes space.
Bug: 8076853
Change-Id: Icf07e0998ac3602e6e05e80fed836fbafca33e01
- Set up LOCAL_JAVACFLAGS to run annotation processing.
- Set up a new intermediate directory $(data_binding_intermediates) to
contain data-binding intermediate files.
- The annotation generated code is generated to
$(data_binding_intermediates)/anno-src. The code will be automatically
included by javac, so no need to store it in
$(LOCAL_INTERMEDIATE_SOURCE_DIR).
- Set up rules to run DATA_BINDING_COMPILER. The generated code will be
put in $(LOCAL_INTERMEDIATE_SOURCE_DIR)/data-binding, so that it can
be automatically included by $(compile-java); Other generated files
are put in in subdirs of $(data_binding_intermediates). The generated
resource dir replaces the app's original LOCAL_RESOURCE_DIR.
Also fixed transform-jar-to-jack on prebuilt aar.
Bug: 19945740
Change-Id: I42d9b0e5cd48cf2dce4488298a960b3c95602beb
For dex preopt and JNI library extraction, we should remove the
classes.dex and .so files before we sign the APK so that there
isn't an entry in the manifest.
Prebuilt APKs which are pre-signed will simply not have the files
removed. This may cause some system.img bloat, but signature checks make
this necessary.
Bug: 20247329
Change-Id: I4742d1aa3aa64ab5aea2264304cb8c0bea24f784
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.
(cherry-picked from commit 8b27d1879c)
Bug: 19947218
Change-Id: I0e1a65a9cbe656974f8ef3923b2f15e9efa5feb9
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
- 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
Set LOCAL_BUILT_MODULE of static java libraries when Jack is enabled
to classes.jack instead of javalib.jar.
This allows that running mm in those libraries will build classes.jack
instead of the jar.
Change-Id: I96b4b227848e971df96331b3f0cc731e856be349
Each module may engage Jack incremental with
LOCAL_JACK_ENABLED := incremental
Include renaming of LOCAL_USE_JACK to LOCAL_JACK_ENABLED that is
now accepting 3 values "disabled", "full" and "incremental".
Change-Id: Icbff275b397bee36b29312e821f3e8d45f83fbcc
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
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 140274707e)
Bug: 18837479
Change-Id: I15ecf282bfb65fd53dd03fbd03dd4c71927c186a
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 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 e9dd9f2bfc)
