Bug: 22796994
Bug: 22693954
This change fixes the RS_PREBUILT_LIBPATH when used with 64-bit target
devices. It also fixes an issue where the target RenderScript API is
below 21 for 64-bit compilation. In those cases, we should always
upconvert it to 21 (since that is the first available 64-bit release).
Change-Id: I27e9d0bd5c01bac0b3b28e9002333264a55d628f
- Don't overwrite [TARGET|HOST]_[CC|CXX] with the [CC|CXX]_WRAPPER prefix,
so that we can disable the wrapper per module.
- Disable ccache on a module when FDO is enabled.
Bug: 22612634
Change-Id: Ibc04a4742d589955066c7eceb43a0da9a2b893bc
Without this change, if an app with "LOCAL_SDK_VERSION := current" links
against a static library that uses removed APIs, the app will fail
ProGuard processing because the removed APIs can't be found in the
current SDK. This works around the issue.
Bug: 18510449
Bug: 20667396
Change-Id: Ia6e2a81cf5ecba972d155e56238ea946f8539411
- When raising the ProGuard sdk version for platform build, use
TARGET_DEFAULT_JAVA_LIBRARIES instead of just framework.
- Also added SUPPORT_LIBRARY_ROOT to reference support library resource
dir.
Bug: 20658265
Change-Id: Ib008d8e70508723db91431a062cac691367f2f6c
When an app's LOCAL_SDK_VERSION is lower than the support library's
LOCAL_SDK_VERSION, we artifically raises the "SDK version" "linked"
by ProGuard, to
- suppress ProGuard warnings of referencing symbols unknown to the
lower SDK version.
- prevent ProGuard stripping subclass in the support library that
extends class added in the higher SDK version.
This allows us to remove the dangerous ProGuard flag
"-dontwarn android.support.**".
Notes:
- We don't raise the app's LOCAL_SDK_VERSION, so that the app's own
code is still unable to use the higher SDK version.
- For platform build, we can't just raise to the "current" SDK,
because would break apps that use APIs removed from the current SDK.
We raise it to framework.jar instead, which contains the most complete
symbol set.
Bug: 20658265
Change-Id: I90099073457a65cb8031fbaec6b396d68ce614a7
(cherry picked from commit 8e8d1e7aba)
v8.renderscript is needed, even for bundled apps.
Bug: 19343399
Change-Id: I461e244be15e08d4525439bc042529314c84031e
(cherry picked from commit c919b0ba88)
- Removed unnecessary dependency of
"$(my_symlink) : $(LOCAL_INSTALLED_MODULE)"
We can generate symlink to nonexistent file.
Actually in multilib build $(LOCAL_INSTALLED_MODULE) points to file
that may not be the target file of the symlink and leads to always
obsolete $(my_symlink) in the above dependnecy.
- Touch by-product in the dummy rule, to make sure the by-product is
newer than the main-product.
Change-Id: I2f0e0cc197c49f920fa1f6794083b21cdc333c20
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
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 reverts commit 8bc90fd2d6.
This CL also impacts standard targets. With Jack enabled, a global
'make' without that CL produce ~287 dex files, with this CL, it
produces ~697 dex files.
Bug: 19069325
Change-Id: I39853da0cba8226f31037733edc420507d76c8c0
... from dexes to jars. This should allow to build less jars when
building dex files with Jack and Jill.
Change-Id: Ib3a717251e3bec3cc73564c205eb908ba1ef380f
Includes cherry-picks of:
2e78d2f4263bc7c0f90d58af7014017f16aa3ce6 Jack option --import-res was renamed --import-resource
fdc913ee86fe0c45581178b901a673fdd7937e03 Update references to Jack type collison policy
8d83d1b21ec678fb9fb1c6ee643ace46d5f700ce Rename jill tmp file
8a1c98ce4ba0b4db39f274d6258b6a08bbc3ec2c Ensure that jar-arg-list is never shared
8d83d1b21ec678fb9fb1c6ee643ace46d5f700ce Remove manipulations of jack libraries
Change-Id: I3ee159d408ba5281ac15c9836dc4fd2bdeb845d3
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
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
- 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
