Previously when a file in LOCAL_SRC_FILES starts with "../", the object
file may escape out of the module's intermediate directory, because we
insert the source file's path (but not with LOCAL_PATH) to the object
file's path. Even worse when two object files escape to the same destination
and cause conflict.
This change fixes the issue by removing the "../" inside the object
files' paths. To do that, we have to set up the compilation rules for
those files one by one, instead of using the one-for-all static
pattern rules.
Bug: 19641115
Change-Id: I19f3c48ece3244fa14acb2caa609deea710840d3
We should put the NDK library path before
$(TARGET_OUT_INTERMEDIATE_LIBRARIES), so that we link against the NDK
libc/libm, instead of the platform libc/libm in
$(TARGET_OUT_INTERMEDIATE_LIBRARIES), which may still being written out,
because we don't have dependency on them.
Bug: 19613709
Change-Id: I26a8b272e38b7436bca3324246b21cd71349662b
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
Previously if user has a directory with name dummy in the root of the
source tree, "zip -qd package.apk dummy" fails with:
"zip error: Nothing to do!".
This change mitigates the error.
Change-Id: I642e3bf0378e5b9911a068ecb72f795b3e92f1fe
- 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
These CFLAGS and CPPFLAGS will always be added last, and are
controlled by the build system. This way we can add warnings that
users are not allowed to disable.
Change-Id: Id71f69249078f62ca2687ecbf764aff0fd3a1c1b
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
Don't remember why I didn't enable this for the host when I made the
first pass, but it works just fine.
Change-Id: I0892c0bc353bf8b60b432ba9f69f97281177d41d
Clang driver needs -static flag, not -Bstatic,
to produce statically linked modules.
However, -static is not added if LDFLAGS contains -shared,
which is used in bionic/linker to create a shared object with static libraries.
BUG: 18008984
Change-Id: I75c3e24973ee77170285ec4c8e7aacc345722685
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.
(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
java-to-jack is not manipulating jar files, just zip files so there
are no META-INF files generated by jar in them and no reason to filter
them out. And mainly, there are valid META-INF resources in the tree
we must keep.
Bug: 8287658
Bug: 18901198
Change-Id: Ice0fafca686b8fa3bafd886076946fbb1f952fb6
If LOCAL_WHOLE_STATIC_LIBRARIES contains a library that has
two files that have the same name but are in different
directories, only the first gets included.
This fix detects this case, and uses the m option to ar to force the
duplicate object to the end of the archive. After this, using the p
option gets the correct object file.
Change-Id: I2e183f48cef3c79499d4ab8ff147444611ff938b
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 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
This caused a lot of failures in the libc++ tests, since linking
libgcc.a before libc++.so means that the wrong unwinder will be used.
This patch is still correct, but I will revert for now while I find a
good way to apply it without breaking unwinding.
This reverts commit 741b36e922.
Change-Id: I57e0b89534adf5c1677dbf2f64ac750e74bd5fbf
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
The previous position of libgcc.a/libatomic.a on the link line causes
the linker to prefer satisfying dependencies from these libraries from
other libraries that might include them, rather than from libgcc.a (or
libatomic.a) itself. This imposes an ABI requirement that those
intermediate shared libraries _always_ export those symbols, which is
undesirable.
Change-Id: Ib593236b475d3e98356b2b1be6f96cee2b67378f
Previously, there was one generic definition for each of the
transform-o-to-* functions in definitions.mk, and one target specific
one in each combo/TARGET_*.mk. The generic one was entirely unused,
and the target specific ones were all nearly identical.
Changing anything in these functions was tedious at best, and often
error prone. The differences between any 32-bit arch and its 64-bit
equivalent were restricted to the name of the linker, and the ARM and
MIPS definitions were identical. The few differences between ARM and
x86 looked to be compatibility for an old (ca. 2008) toolchain issue
with --gc-sections, and a bug (LDFLAGS coming first rather than
later).
To simplify things, I've moved the definitions for these out of
combo/TARGET_*.mk and back into definitions.mk. The differences
between ARM and x86 have been scrapped. Anything that really does
still need to be target specific can be handled as I have the linker:
add a TARGET_FOO variable to the given target and then add it to the
generic definition.
Change-Id: I54dc1bffc32ac39f27f0b87247dd6a6dbaf0b162
build/core/Makefile looks for build tasks in either device/*/build/tasks
or vendor/*/build/tasks. Do the same with vendor-specific definitions.mk.
Change-Id: Ib4fd00a1d0effe8e347382a922da101ce26bf696
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Bug: 14416410
Our linker uses "start" as the primary entry point, so we need to adjust this
for mingw-based Windows compiles, or nothing will execute correctly.
Change-Id: I6e99f43e075ef9f00500099ce34ec4425c996454
So result of get-prebuilt-src-arch can be passed to
LOCAL_MODULE_TARGET_ARCH, which takes empty string as "any" actually.
Change-Id: I916c9738ccce4a94ac084fb4141d54659e896a1f
Strip prebuilt shared library but not try adding gnu debuglink.
It would fail if you try run the adding gnu debuglink command if a
prebuilt is already stripped.
Bug: 17177288
Change-Id: If5811865715c2437e45fbd329983ef1212ef0109
Improves performance for LOCAL_WHOLE_STATIC_LIBS by copying the first .a
to the new .a rather than extracting and recreating
Change-Id: Iecdb5e4bb2ce987bb41a70c3393d18a6d72ae689
This fixes mips unbundled build since we switched to mips64el toolchain
for both mips and mips64.
TODO: multilib build support.
Change-Id: I7add92d2cecfc3ab739785ceef6700240a25093a
This fixes mips unbundled build since we switched to mips64el toolchain
for both mips and mips64.
TODO: multilib build support.
Change-Id: I7add92d2cecfc3ab739785ceef6700240a25093a
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
(cherry picked from commit 4803ce2696)
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
- Better messaging if the expected split apk isn't generated by the aapt
command in the base apk rule; Remove the built base apk, so make will
rerun aapt after the user changes the splitting parameters.
- Use cleaner static pattern rules instead of running $(foreach) with
$(eval).
Bug: 16319961
Change-Id: If6ae302e1a39d2e0db8f784d4e1cf292ec855281
Support LOCAL_PACKAGE_SPLITS, which accepts a list of resource lables
and generates multiple apks. The build system sets up rules to sign and
zipalign the split apks.
Bug: 16319961
Change-Id: I344b3d1c7eb158c6d0df879093d666a89870aadd
Apk's path is changed to <parent_dir>/MyApp/MyApp.apk;
JNI path is changed to <parent_dir>/MyApp/lib/<arch_name>/libfoo.so.
Symlinks of JNIs are changed accordingly.
Bug: 16319961
Change-Id: Ib3b2309c95fa9aea27837fcc29e28d990b04747b
Dx is now capable of generating multiple dex file in one run.
This capability is not compatible with --output=*.dex so this CL
changes the --output argument to be a directory. This CL also
includes the packaging of the multiple dex files when dx generates
more than one dex file.
(cherry picked from commit 8ffe9c3e79)
Conflicts:
core/java.mk
Change-Id: I1ddc91b416de5929d4d4b41824c6012b32f94deb
Use "LOCAL_MULTILIB := both" to install jni libraries of both archs in
multilib build.
The build system will package jni of both archs to the apk, or install
them to the right location on the system image and create symlinks,
extract .so files from prebuilt apk, etc if appropriate.
Bug: 15849902
Change-Id: I7e147b5a47db476584c38250de7b36c75ea40d81
- Remove the incorrectly used (and unused) 3rd arg to assert-max-image-size
- Remove test for fstype in assert-max-file-size() as it was always
set to a value leading to 0.
Change-Id: I0a1182fcc85c6c3801d45731e691b9bb38657606
Signed-off-by: JP Abgrall <jpa@google.com>
Previously we only expanded product_MODULES with LOCAL_REQUIRED_MODULES,
but not modules introduced by LOCAL_SHARED_LIBRARIES; Later we did a further
shared libary expansion in vendor_module_check.mk.
It couldn't track C in the following case:
A : B, by LOCAL_SHARED_LIBRARIES; B : C, by LOCAL_REQUIRED_MODULES.
With this change, we transformed the LOCAL_SHARED_LIBRARIES dependencies
into LOCAL_REQUIRED_MODULES dependencies before doing the required
module expansion and the loophole is closed.
All module names are now expanded to product_MODULES now and it makes
vendor_module_check.mk simpler.
Change-Id: I8835a478d2ce0ce10601a8449f446f07b01c2b7f
Previously the RS cpp files are generated by the timestamp rule. Though
we have the generated RS cpp files depend on the timestamp file, we
don't have a build recipe. In such case gmake does some "optimization"
that it skip recompiling the generated cpp files, because it assumes the
generated cpp files are already up to date even if the rs files have
been updated.
Bug: 15313144
Change-Id: Ie69ecd2c788057d3619f9c7d2a125d44c4a534a1
Allow LOCAL_JAR_PACKAGES to work on subpackages. Previously it
only worked on top-level packages due to a bug in how the directories
were recursively deleted.
Add LOCAL_JAR_EXCLUDE_PACKAGES to allow specific subpackages to
be excluded. This rule applies after LOCAL_JAR_PACKAGES has
selected which packages to include. It may also be used independently.
Change-Id: Ibd0e495be1a20c84b59c9da132e92100ef3f8705
_extract-and-include-single-(host|target)-whole-static-lib was written such that
only the first file of a given name would be extracted and included into the new
library. This patch iterates over each identically named archive member,
extracts them individually, and adds them to the new archive.
Bug: 15110069
Change-Id: Ia08c7be6f40bfc8403908a8808898ada479099b1
Previously the odex file is byproduct generated by the package.apk rule.
Though we have the odex file depend on the package.apk it doesn't have
its own build recipe. In case package.apk isn't updated but we still
need to update the odex file (such as changed LOCAL_MULTILIB), the odex
file will never be rebuilt.
This change split out the rules to build the odex file and make sure the
build recipe get executed if the odex file needs rebuild.
Change-Id: I60c2f32b536b3d59045301ee863aae1451734aad
We already support pure 32-bit and 64-bit-by-default multilib build.
With HOST_PREFER_32_BIT we can build 32-bit-by-default multilib build.
This will be lest disruptive during the period we transition to
64-bit-by-default.
Bug: 13751317
Change-Id: I0d56ce4abbe4afeaacfd70d709f6a349791c0722
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
"GYP" class targets are used by external/chromium_org for gyp's "none"
type. The processing in these targets needs a separate intermediate
directory for the primary/secondary architecture, so add it to the list
in intermediates-dir-for along with libraries/executables.
Change-Id: Id05899c83b45ed0647dfbfa6b0b2e7f61b04348b
When LOCAL_STRIP_MODULE := keep_symbols is set, then the normal strip rules
will be modified so that only the .debug_* sections are removed. The original
symbol table is left alone.
This allows the compilation of certain libraries so that libbacktrace library
can provide meaningful names to functions.
Bug: 12958251
Change-Id: I82bdc304a463012e29086325ccb51163464cb4a9
The doclava build does not need to depend on the intermedidate
removed.txt. It depends on public_api.txt. Removed.txt is generated
along with public_api.txt by doclava.
BUG: b/11293324
Change-Id: Ia5ea675bbfb15b81ce6ae81cf34c608e83676ca1
Depending on the file extension of the generated C++ file,
bison will generate a #include of a .h or .hpp. So both files
must be kept in the generated directory.
Change-Id: Id0aac7f407bdc69c7f5012c0d021761b0fceb427
For host executables and shared libraries, the global LDFLAGS were being
inserted into the linker command line after the module-specific ones,
making it impossible to override the default settings. Change the order
to match target linker invocations.
Change-Id: Icd5f6f83df9f27a5be97ddb197ee245c1ab8c2be
For host executables and shared libraries, the global LDFLAGS were being
inserted into the linker command line after the module-specific ones,
making it impossible to override the default settings. Change the order
to match target linker invocations.
Change-Id: Icd5f6f83df9f27a5be97ddb197ee245c1ab8c2be
2ND_TARGET_DEPENDENCIES_ON_SHARED_LIBRARIES was not set,
which was causing the later += to act like = instead of
:=, and the dependencies would disappear as soon as
LOCAL_MODULE was cleared.
Change-Id: Idea291524fc06377deafec62f37d20eaa7f93bca
* commit '8c89a9ff9cd461e4bc077a91a0c7c32b17a92ebd':
add new gen/ directory for generated sources
warn on LOCAL_MODULE_PATH in multiarch shared libraries
Support LOCAL_MODULE_RELATIVE_PATH
Allow modules to generate source into $OUT/gen, which will then
be copied into $OUT/obj and $OUT/obj_$(TARGET_2ND_ARCH) as
necessary. This allows a single build rule invocation that includes
generated source to build for the first and second architectures.
Modules will need to change calls to local-intermediates-dir into
local-generated-sources-dir.
Change-Id: I62504bad9454b3d9fde7b84ab9f0a487a2ecf0bf
By default, an executable is built for TARGET_ARCH.
To build it for TARGET_2ND_ARCH in a 64bit product, use:
LOCAL_32BIT_ONLY := true
To skip a module for TARGET_2ND_ARCH, use:
LOCAL_NO_2ND_ARCH := true
Bug: 11654773
Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
The rules for the 2nd arch are set up in the second inclusion
of shared_library_internal.mk.
Intermediate fils of libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/SHARED_LIBRARIES/libfoo_intermediates/
and the built libfoo.so will be in
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/lib.
Bug: 11654773
Change-Id: I58bbe5a05a65f63bce6279131552f3792000716e
The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.
Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
By default, an executable is built for TARGET_ARCH.
To build it for TARGET_2ND_ARCH in a 64bit product, use:
LOCAL_32BIT_ONLY := true
To skip a module for TARGET_2ND_ARCH, use:
LOCAL_NO_2ND_ARCH := true
Bug: 11654773
Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
The rules for the 2nd arch are set up in the second inclusion
of shared_library_internal.mk.
Intermediate fils of libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/SHARED_LIBRARIES/libfoo_intermediates/
and the built libfoo.so will be in
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/lib.
Bug: 11654773
Change-Id: I58bbe5a05a65f63bce6279131552f3792000716e
The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.
Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
Compile all host programs for Android with -fPIE and -pie. This
enables PIE (Position Independent Executables), which helps
protect these applications from exploitation due to memory
management bugs.
Note: PIE *static* executables are not supported at this time. darwin
and windows are also not supported.
Change-Id: I67c1be297711ea23064c349f97ebd02eef3eff09
find-files-in-subdirs uses utility find to find given files in the given
subdirs. This function uses $(1), instead of LOCAL_PATH as the base.
Change-Id: Ib76631c97acd257d651a580cbad767606874f5d0
(cherry picked from commit 85898bca99)
find-files-in-subdirs uses utility find to find given files in the given
subdirs. This function uses $(1), instead of LOCAL_PATH as the base.
Change-Id: Ib76631c97acd257d651a580cbad767606874f5d0
find-files-in-subdirs uses utility find to find given files in the given
subdirs. This function uses $(1), instead of LOCAL_PATH as the base.
Change-Id: Ib76631c97acd257d651a580cbad767606874f5d0
* if a module uses LOCAL_JAR_MANIFEST
* if the manifest file has the string '%BUILD_NUMBER%' in it
Bug: 10793010
Change-Id: I1ed3dae0706e6ad26c2bce68269c1abb7b4a7325
With this change, use:
* LOCAL_PROGUARD_ENABLED := obfuscation # to enable obfuscation
* LOCAL_PROGUARD_ENABLED := optimization # to enable optimization
* LOCAL_PROGUARD_ENABLED := obfuscation optimization # to enable both
Now the meaning of the LOCAL_PROGUARD_ENABLED options:
* full:
Use the build system's default configurations:
with shrink but no obfuscation or optimization,
global proguard flags in build/core/proguard.flags
are applied.
* custom:
The same as "full" except no aapt-generated resource-related
proguard flags.
* nosystem:
Don't use any build system's default configurations; but
aapt-generated proguard flags are still applied. You are
responsible for any other flags.
* disabled:
Disable proguard.
* obfuscation:
The same as "full" but with obfuscation enabled.
* optimization:
The same as "full" but with optimization enabled.
* no value (the default):
The build system chooses the proper value: "full" if it's an
app; "disabled" if it's a library.
You can use more than 1 of them in a meaningful combination,
for example:
LOCAL_PROGUARD_ENABLED := obfuscation optimization
Bug: 10307372
Change-Id: Id248caca3048e99547f16559fae74f4afe85c354
Dx is now capable of generating multiple dex file in one run.
This capability is not compatible with --output=*.dex so this CL
changes the --output argument to be a directory. This CL also
includes the packaging of the multiple dex files when dx generates
more than one dex file.
Change-Id: I1ddc91b416de5929d4d4b41824c6012b32f94deb
This reverts commit 28b46fc16c.
Speculative fix for master builds. I cannot repro the break the bots
are seeing locally, but it seems related to building protobufs and this
CL was in the first broken build.
Also source files which have dependencies need to be bundled together
(at least the way the build system is set up now). Move
--proto_path=$(TOP) to the end so that it does not take precedence
over user-supplied --proto_path flags.
Change-Id: Ia532647fe8811d39230a23ba3671685b0388cbe0
Since commit 6c86a1 we have split LOCAL_SHARED_LIBRARIES out of
LOCAL_REQUIRED_MODULES and the vendor check does no longer cover the
installed modules introduced by LOCAL_SHARED_LIBRARIES.
This change brings back the coverage.
Change-Id: Ie78692e48f173a3350792eb2fee8127ff9433caa
If we don't do "-lc", we end up missing symbols like "memset" on our non-NEON
builds. It also makes more sense to have bcc_compat as a standard dependency
for now, since it occasionally changes the way we compile/link our source
files.
Change-Id: I4b0ead66caa7c72fb7733db8804a33faa5350930
Previously, any target Java code that depends on framework.jar has to
wait for the library's javalib.jar.
To build javalib.jar we have to run dx, which is quite slow.
Actually when code links against framework.jar, only classes.jar is
needed.
This improves the potential parallelism of the build system.
Change-Id: I82c5926ef282a3a6096bbf49b54ef4f2a0c2c0e7
Before this, if there are duplicate module names in both the host and
target spaces, LOCAL_SHARED_LIBRARIES results in mixed dependencies.
Bug: 7026946
Change-Id: I5407e3d078a8903c94978cc6d3e256851c52340f
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
With this change, you can easily switch between building from source
code and prebuilt.
Set LOCAL_PREBUILT_MODULE_FILE to the path of the prebuilt file,
relative to the top of the source tree, in the usual module definition.
The prebuilt will be used unless any of the followings satisfied:
1) ANDROID_BUILD_FROM_SOURCE is "true", which disable prebuilt globally;
2) The module name is in ANDROID_NO_PREBUILT_MODULES;
3) The LOCAL_PATH is prefixed by any of ANDROID_NO_PREBUILT_PATHS.
A developer can set ANDROID_NO_PREBUILT_MODULES or
ANDROID_NO_PREBUILT_PATHS to build only his own module(s) from source,
while build other modules from prebuilts.
You can set ANDROID_BUILD_FROM_SOURCE to true to build everything from
source.
Those variables can be set with shell environmental variable or in your
buildspec.mk.
Sometimes module B is able to be built from source only if module A is
also
built from source, for example, if B is the test apk of A.
In that case, you can use the macro include-if-build-from-source to
include B's Android.mk only if A is built from source too, or
if-build-from-source to conditionally include the definition of module
B,
if their module definitions are in the same Android.mk.
Support host-executable-hook and host-shared-library-hook.
Change-Id: Icab7cf028c87eaba0dd7efc2a7749fd6f32b44e4
1) Move check-api to definition.mk, so it can be used in other places.
2) Add additional dependency to the api-stub module to consolidate the
apicheck dependency. Previously you have to run 2 "make"s in a row and
only in the 2nd run apicheck is run, due to a gnu-make optimization.
Bug: 7540265
Change-Id: Ib24ed87d9330027a9f95ed7b16dd4002cc0e3198
