Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.
Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
- Added GLOBAL_JAVAC_DEBUG_FLAGS and merge it to
PRIVATE_JAVACFLAGS/PRIVATE_JACK_FLAGS to get rid of
PRIVATE_JAVAC_DEBUG_FLAGS/PRIVATE_JACK_DEBUG_FLAGS.
- With Java rules out of base_rules.mk we can get rid
of java_alternative_checked_module now.
Change-Id: I1a14716c785e3d49330a75044107662ce96a9307
- Moved the target-only .aidl and .logtag rules to java.mk.
- Moved the .proto rules, Java library dependency calculation,
Java resource processing and Java-related
target-specific and global variables setup to a new java_common.java,
which is shared by both target and host Java modules.
- Minor cleanup for the moved code.
Bug: 23597357
Change-Id: Ic3eb72e26bb1a663e5739abe0a935f96b88bc352
So that we can support building both linux and windows binaries at the
same time on a linux host. This replaces the ifeq($(HOST_OS),...) checks
in Android.mk files.
Bug: 23566667
Change-Id: I693e11984e36d55bb6f09fa0d49bc485463e16fb
A module can install a companion init.rc file,
by specifying:
LOCAL_INIT_RC := <init.rc-file-path-replative-to-LOCAL_PATH>
You can also use the variant with _32 or _64 suffix.
Bug: 23186545
Change-Id: I00a96509f5707ae39361a0c5555fa59d46c90322
This is possible now that we have the new Jack server.
Also fix dependency from dex/jack target to jack script
instead of jack.jar.
(cherry picked from commit 5e50b34221)
Change-Id: I8e7aa5087ba8d73cc93140ddfca8f4ab2f505175
This is possible now that we have the new Jack server.
Also fix dependency from dex/jack target to jack script
instead of jack.jar.
(cherry picked from commit 5e50b34221)
Change-Id: I5dce864624e97c27441a5ee7f8c3cd582613390e
This is possible now that we have the new Jack server.
Also fix dependency from dex/jack target to jack script
instead of jack.jar.
Change-Id: I28b5f7176747853ef707b8d4055017bf60296641
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
Build additional images requested by the product makefile.
This script gives the ability to build multiple additional images and
you can configure what modules/files to include in each image.
1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile.
PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles.
Each makefile configures an image.
For image configuration makefile foo/bar/xyz.mk, the built image
file name
will be xyz.img. So make sure they won't conflict.
2. In each image's configuration makefile, you can define variables:
- CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm"
etc.
- CUSTOM_IMAGE_PARTITION_SIZE
- CUSTOM_IMAGE_FILE_SYSTEM_TYPE
- CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary
accepted by BuildImage() in tools/releasetools/build_image.py.
- CUSTOM_IMAGE_MODULES, a list of module names you want to include
in the image; Not only the module itself will be installed to proper
path in the image, you can also piggyback additional files/directories
with the module's LOCAL_PICKUP_FILES.
- CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to
the image. <dest> is relativ to the root of the image.
To build all those images, run "make custom_images".
Bug: 19609718
Change-Id: Ic73587e08503a251be27797c7b00329716051927
(cherry picked from commit 5fcf1094f9)
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
Print modules and their transitive dependencies with license files.
To invoke, run
"make deps-license PROJ_PATH=<proj-path-patterns> DEP_PATH=<dep-path-patterns>".
PROJ_PATH restricts the paths of the source modules;
DEP_PATH restricts the paths of the dependency modules.
Both can be makefile patterns supported by makefile function $(filter).
Example:
$ make deps-license packages/app/% external/%
prints all modules in packages/app/ with their dpendencies in external/.
The printout lines look like "<module_name> :: <module_paths> :: <license_files>".
Bug: 20823995
Change-Id: I06b66e85ff56c8628bffa3d948085ed45870100f
- 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
Build additional images requested by the product makefile.
This script gives the ability to build multiple additional images and
you can configure what modules/files to include in each image.
1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile.
PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles.
Each makefile configures an image.
For image configuration makefile foo/bar/xyz.mk, the built image
file name
will be xyz.img. So make sure they won't conflict.
2. In each image's configuration makefile, you can define variables:
- CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm"
etc.
- CUSTOM_IMAGE_PARTITION_SIZE
- CUSTOM_IMAGE_FILE_SYSTEM_TYPE
- CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary
accepted by BuildImage() in tools/releasetools/build_image.py.
- CUSTOM_IMAGE_MODULES, a list of module names you want to include
in the image; Not only the module itself will be installed to proper
path in the image, you can also piggyback additional files/directories
with the module's LOCAL_PICKUP_FILES.
- CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to
the image. <dest> is relativ to the root of the image.
To build all those images, run "make custom_images".
Bug: 19609718
Change-Id: Ic73587e08503a251be27797c7b00329716051927
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
Previously for hostdex Java libraries, we set up dependency on only
javalib.jar, which in turn is dependent on classes.jar.
But when jack is enabled there is no dependency of javalib.jar on
classes.jar. In commit b4c49cba57 classes.jar was universally added to
all host java library dependencies. That's unnecessary.
This change adds explicit dependency on classes.jar only for hostdex
modules.
On the other hand, if we switch checked module to $(full_classes_jack),
like what we did in commit 8bc90fd2d6, we won't need this to fix jack
build either, because classes.jar isn't needed when you run checkbuild.
Change-Id: I92c0e4d621d266f6e6914ab2b4f20e5531af070f
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
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
Previously we store tag's installed modules in a separate variable
ALL_MODULE_TAGS.$(tag). However we only record the main installed file
for a module, but omit affiliated files like .odex.
With this change, we handle the tagged module the same way as modules in
PRODUCT_PACKAGES.
Change-Id: I7972528a4df5a4ba8bc98930864da9672d32d7fe
This should obviate much of the need for cleanspecs, and also make it
unnecessary to continue adding LOCAL_ADDITIONAL_DEPENDENCIES for this
sort of thing all over the tree.
Change-Id: I97aa8fd280ae868a5f6364f8b7bf3c2fe235d6ce
Dan Willemsen