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
Creates a build_system_stats.txt build artifact that contains statistics
on how many BUILD_* modules are defined in a build. Also writes out
information about the Soong module types sent from the Soong build.
Merged-In: Iaf0c7062f542dc6942b5349854f3d49267cac4a5
Change-Id: Iaf0c7062f542dc6942b5349854f3d49267cac4a5
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
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
Pass -X to zip so that Unix UID/GID and extra timestamps aren't
saved into the zip files.
Add a new tool, ziptime, that uses a very stripped down copy of
zipalign. It no longer depends on libandroidfw, and now rewrites the
timestamps in place instead of making a copy of the zipfile. This should
improve speed and reduce disk requirements, especially with the large
packaging zip files.
Bug: 24201956
Change-Id: I50f68669f659da1b4393e964ad40b6aafb00c1e7
This reverts commit 3c2c064c87.
zipalign depends on libandroidfw, and some setups don't include frameworks/base.
Bug: 24201956
Change-Id: I48ee95808924f6b2221f0a49ab205c2565096b1f
Pass -X to zip so that Unix UID/GID and extra timestamps aren't
saved into the zip files.
Add a new option to zipalign, -t, to replace all timestamps with static
timestamps (2008 Jan 1 00:00:00). Use this for all non-APK zip files.
APK zip timestamps are set based on the certificate date in SignApk.
Bug: 24201956
Change-Id: Ifb619fc499ba9d99fc624f2acd5f8de36d78ef8e
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
Now libart is the only supported runtime and
we don't need the build variables PRODUCT_RUNTIMES and
DALVIK_VM_LIB.
Bug: 18465297
Change-Id: Ibfda931cde0649163d79b584fb5ccad927a9bc2b
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_USE_JACK:=true # false
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.
Change-Id: Ib81a0fd5f86a51d1e0edbb81cc791d828a05dd29
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
1. Let aapt output the proguard_options file
2. If proguard is enabled, switch the dependency from
$(full_classes_jar) to $(full_classes_proguard_jar).
Change-Id: Idc641a1515b8899a4623a2aeec5cd494f6c1c1c5
This allows you to build apks that link against other
apks using the framework's new shared library apk feature.
Also if you are using LOCAL_APK_LIBRARIES, then LOCAL_DEX_PREOPT
will not be allowed. This is because using preopt means the
apk is stripped of its dex file, so the pre-installed apk can't
be redexed if its associated library changes. (Even if the build
system didn't strip the dex, Dalvik still has issues because it
assumes a pre-odex file is always valid.)
Change-Id: I952c0d24f8975f75aff67f78b5faeec91144c3e7
Currently building libcore (i.e. to get the core Java libraries) has a
dependency on AAPT. This is problematic for some users that don't want to pull
in the entirety of frameworks/base, e.g. for Dalvik development.
It turns out that all definitions.mk is using aapt for in this case is 'aapt
add -k <jar> <dex>', which adds a file to a JAR while stripping path info.
This is functionally equivalent to 'zip -j', and this CL just makes that
switch.
Change-Id: I292ecaf9d0321018bb7d2e68a49b2cc81de98a20
Bug: 6987838
- With this change, use "EMMA_INSTRUMENT=true" to enable emma in full or
unbundled build.
- You don't need to add "LOCAL_STATIC_JAVA_LIBRARIES += emma" any more for
unbundled apps.
- Now a single var LOCAL_EMMA_INSTRUMENT replaces the previous
LOCAL_NO_EMMA_INSTRUMENT and LOCAL_NO_EMMA_COMPILE.
- By default, if EMMA_INSTRUMENT is true, emma is enabled for only
non-test apps.
- A new global var EMMA_INSTRUMENT_STATIC. It enables EMMA_INSTRUMENT
and builds emma into apk/jar as static library, instead of using emma
as part of shared library core.jar.
Change-Id: I0aa219e83074879ececc159b5b07c39eb07ccc00
When common_javalib.jar is created, both LOCAL_BUILT_MODULE and
built_odex targets can be run.
If built_odex target runs before the directory is created by
LOCAL_BUILT_MODULE target, the error occurs.
Change-Id: I1ebcb27630f8373558da6acdfce95f5cdf714bbf
Bug: 5714516
The rationale behind this change:
- the library is compiled into a jar file, but its R class is generated
making the constant not constant (static, not final static) (aapt
option --non-constant-id). Also the jar file does not contain the R
class.
- this allows the integer value to not be inlined in the compiled
class files. Note that this prevents using switch statements.
- the main project use this jar file as a normal static library: it will
add all the class files except the R.class.
- the main project uses the library res folder as a resource
folder with lower priority than the main project (basically the
main project is an overlay. This is accomplished using aapt's
--auto-add-overlay to handle resources only in the main project
(which the normal overlay mechanism doesn't allow).
- the main project creates R classes in the main project's
package but also in the library's package. This is done with
aapt's --extra-packages which accept as many packages as
needed, separated by a :.
- manifest merging is not done yet, so
activities/services/permissions/etc... have to be manually declared in
the main app.
To use a static library with Android resource in your app,
1. Add the library's resource dir to your app as an overlay:
LOCAL_RESOURCE_DIR := <app_resource_dir> <static_library_resource_dirs>
2. Set the proper aapt flags:
LOCAL_AAPT_FLAGS := <apps_own_flags> --auto-add-overlay \
--extra-packages <lib1_package_name>:<lib2_package_name>:...
Change-Id: Ifb4d2300b952ea4aaee74da1bb0c6c72ea0698a3
Set "LOCAL_DEX_PREOPT := nostripping" to do dex-preopt while not strip
the classes.dex.
Bug: 5396625 5502338
Change-Id: Ie8dea4414ebeefeae89c6433b246faea27baa5e7
For target Java libraries, now the LOCAL_BUILT_MODULE includes both javalib.jar
and the .odex file, if dexpreopt is enabled.
These 2 files are moved to a product-specific dir in this change.
For target Java Libraries, $(intermediates) now points to the product-specific dir.
There is still a javalib.jar in the $(intermediates.COMMON) dir, which is used as dependency.
Nothing is changed for host Java libraries.
Change-Id: I2546dbb940c74537864ca002d1acb49bb731fbbc
