- 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
This is needed for projects that have known ubsan issues that we can't
fix right away (perhaps because it's an upstream project that we're
diligent about keeping in sync with upsteam).
Also make the normal ubsan use -fno-sanitize-recover=all by default.
Change-Id: I1b0f3309792f32dbd08c18816d7306e76c8d7c30
Add replocation-packer step for dynmic executables.
Enable it by default for arm and arm64 platforms.
Bug: http://b/18051137
Change-Id: I0c88fd31595bcea62a087f219acb9ecf9c80f2e5
Rather than adding LOCAL_UB_SANITIZER, LOCAL_THREAD_SANITIZER, etc for
each new sanitizer, deprecate LOCAL_ADDRESS_SANITIZER in favor of
LOCAL_SANITZE that mirrors the behavior of -fsanitize=<sanitizers>.
For example, the following will use both asan and ubsan:
LOCAL_SANITIZE := address undefined
We'll leave LOCAL_ADDRESS_SANITIZER around for compatibility until we
can clean up the tree.
Change-Id: I8a62315129d4753f8e992584ca6db1e5dfdd4d2a
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)
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
There will be two version of the the nanopb-c library,
libnanopb-c-2.8.0 which doesn't support automatic malloc
and libnanopb-c-2.8.0-enable_malloc which does.
There will be two version of the the nanopb-c library,
libnanopb-c-2.8.0 which doesn't support automatic malloc
and libnanopb-c-2.8.0-enable_malloc which does.
Set LOCAL_PROTO_OPTIMIZE_TYPE=nanopb-c which doesn't support
malloc and set it to nanopb-c-enable_malloc which does.
For client code details see nanopb-api:
http://koti.kapsi.fi/jpa/nanopb/docs/reference.html
Change-Id: If238412463aabb5e1d556dfc9c464bcaf9e3333a
- 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
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
- 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)
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 will be necessary to support -std=gnu99 mode for clang 3.6, which
defaults to C11 mode (unlike prior releases that use C99).
Change-Id: Iea84582f9f12ba76b988463cbc0a20bd61042538
Two new LOCAL variables are added to support dpi-specific prebuilt apk
selection:
- LOCAL_DPI_VARIANTS: specify a list of dpis the module provides with
specific prebuilt.
Example: LOCAL_DPI_VARIANTS := xxhdpi xhdpi hdpi mdpi
- LOCAL_DPI_FILE_STEM: specify the dpi-specific source file name
pattern.
Example: LOCAL_DPI_FILE_STEM := MyApp-%.apk
"%" will be substitued by $(PRODUCT_AAPT_PREF_CONFIG) in the core
build system.
If you don't set up LOCAL_DPI_FILE_STEM, the default is
$(LOCAL_MODULE)_%.apk.
The build system searches $(PRODUCT_AAPT_PREF_CONFIG) in a prebuilt apk
module's $(LOCAL_DPI_VARIANTS). If not found, use whatever
$(LOCAL_SRC_FILES) as the source file; Otherwise use $(LOCAL_DPI_FILE_STEM)
to construct the dpi-specific apk's source file name, and use whatever
directory name of $(LOCAL_SRC_FILES).
Bug: 18388705
Change-Id: I63cae73f1b6f880302142abc476b3ce1fb5500b5
- 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
Ying Wang
Dan Albert
Dmitriy Ivanov
Etan Cohen
Wink Saville
Yohann Roussel
Narayan Kamath
Ying Wang
Fredrik Roubert
Stephen Hines
Nick Kralevich