Run jack with no outputs as a quick check for compilation errors and use
a timestamp to store that check was made.
Bug: 19069325
(cherry picked from commit 43084d9f49)
Change-Id: I9b84b503b28cfdfa245f91da0061ee3a79386b28
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
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
- 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
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)
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
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
- 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
- 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: I478913d5d498f800b322529d7c2c2c0ea78425e5
LOCAL_ASSET_DIR may point to a dir generated during the build process.
We have done similiar things to LOCAL_RESOURCE_DIR.
(cherry picked from commit bfcdf060ba)
Bug: 16563899
Change-Id: Iaa72196e1e6350ae0720f8a4e0abc68d8d7ed642
Build odex for both arch in multilib build if an app has
LOCAL_MULTILIB := both.
Refactored the common setup code to a separate file setup_one_odex.mk.
Bug: 17409149
Bug: 14694978
Change-Id: I74c9426cd74fe0b0cb4811368f740a88ac2ae022
