I don't think we can realistically turn this on for 32-bit builds any
time soon.
Also, fix the arm64 stack-protector hack.
Change-Id: Ie1e7c875bbc06fb21bb372b8ca99879a23ef53d4
Users of ARCH_ARM_* defines don't care about first vs. second arch,
set ARCH_ARM_* regardless of which arch is arm.
Change-Id: I2ae83ec5c3f839ff91a0e352c95d76ec2cbd5dc5
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
For whatever reason, two modules may have the same file as their
installed module. In that case circular dependency is created if the two
modules have requited-by relation.
Change-Id: I15ed271ca3f3c343e4662182ded5ccc63d6c42cc
Support the following new variables based on whether the current multilib
target is 32 bit or 64 bit:
LOCAL_CFLAGS_32
LOCAL_CFLAGS_64
LOCAL_LDFLAGS_32
LOCAL_LDFLAGS_64
LOCAL_ASFLAGS_32
LOCAL_ASFLAGS_64
LOCAL_C_INCLUDES_32
LOCAL_C_INCLUDES_64
Change-Id: Ia868d56dff114be301bf8297eec768675f186927
Host gtests that don't use pthreads themselves need to be linked
against libpthread because gtest itself uses pthreads to ensure
thread-safety. (It can't know in advance whether the code under
test is going to spin up threads, so it has to be pessimistic.)
Change-Id: I14fb1098c163d7fe6ae9a9a0314acead4ec9383d
arm and arm64 have distinct headers, but mips and mip64, and x86 and x86_64
use headers that work for both widths. So where arm/arm64 need to handle the
second architecture case specially, all we need to do for the others is
hard-code the name. (x86_64.mk already hard-codes x86; we need to change
x86.mk for the case where we're building the 32-bit binaries for a mixed
system. mips64.mk doesn't exist yet, but when it does, it'll hard-code
just plain "mips" too.)
Change-Id: Ia6b9f77b4eb2c78729b454045875c409e0ea8197
To ease the transition between toolchains, allow a target to specify
a list of cflags that the toolchain does not support. These will be
filtered out of the cflags provided by the module.
Add TARGET_GLOBAL_UNSUPPORTED_CFLAGS := -fstack-protector for the
aarch64 toolchain, it does not yet suport -fstack-protector.
Change-Id: I168d0c6f131326fad305ec86fad46e6a3e03295a
This should never have been on the default include path.
The NDK statically links its own libthread_db, so I'm removing
bionic's unused copy from devices.
Bug: 11882807
Change-Id: I49a67fe0902cc4bc178360f6c993959774d74e3a
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
Using LOCAL_MODULE_PATH in a shared library module while building a
multiarch target will cause build rules for both architectures to install
into the same path. Warn and suggest LOCAL_MODULE_RELATIVE_PATH.
Change-Id: I16208ccada6d43a26a342af35096f49d8df26e81
Most users of LOCAL_MODULE_PATH are setting a subdirectory of the
normal install path, for example to install HALs into system/lib/hw.
This is problematic for multiarch builds, where the install location
depends on the arch. Allow modules to specify LOCAL_MODULE_RELATIVE_PATH.
HALs will generally use:
LOCAL_MODULE_RELATIVE_PATH := hw
Change-Id: I4e4ceec61d026bbe74ba604554c06104bde42e5e
We have no rigorous way to detect whether the code referenced for this
mechanism changes in between builds. So declare this as a phony target
so that it is rebuilt every time.
Change-Id: Ie1670d96895719d406e7b0defd53ba3cd224dd83
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Print the name of the module that is providing an unhandled install
path.
Change-Id: I0e8b02f01de1dde715f0985034ad943f793218ba
Conflicts:
core/base_rules.mk
Set arm_objects_mode and normal_objects_mode when building a
module for arm when it is the 2nd arch.
Change-Id: I5f7df519b6e1dde6cbf92d106681f07a58e1f1f2
Compiling for arm requires using the arm kernel headers and not
the aarch64 kernel headers. Add $(combo_2nd_arch_prefix) to get
asm-$(TARGET_2ND_ARCH) when arm is the 2nd arch.
Change-Id: I15270d0ef35e48c034bf4d0d5e35b76f67b2a8e1
With those variables, you can set up different values for TARGET_ARCH
and TARGET_2ND_ARCH.
Also fixed a couple of variables.
Bug: 11654773
Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
Conflicts:
core/base_rules.mk
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
This is the first step to build 32-bit libraries in a 64-bit product.
It will work like this:
1) In the product's BoardConfig.mk, define:
TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT.
The build system uses those variables to set up an additional compiler
environment for the second arch.
2) When parsing Android.mks, the build system sets up rules to build a
module for both the 1st arch and the 2nd arch, unless it's explicitly
asked to skip so.
Android.mk will be adapted if there is additional rule of generating
source files.
The build system will accept arch-specific LOCAL_ variables, such as
LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15,
LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for
various archs at the same time.
3) Install binary of the 2nd arch by adding "<module_name>:32" to
PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32"
will be installed automatically.
Bug: 11654773
Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30
Conflicts:
core/combo/TARGET_linux-arm.mk
PRODUCT_COPY_FILES entries can include the src:dest:owner
syntax versus src:dest. This causes the filter to miss
certain cases. Instead use the word-colon function to
grab the dest regardless of syntax.
Change-Id: I1f4e57a236c1db148bada0cfe5bd1e87bb1194d6
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
/system/lib always contains 32-bit libraries, and /system/lib64 (if
present) always contains 64-bit libraries.
Move things around a little bit, so TARGET_ARCH can be used to define
the build paths.
Bug: 11654773
Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
This makes it easier for OEMs to extend the PRODUCT_BOOT_JARS in their
product configuration files.
Change-Id: I5feca2f808b1914c275f28c7a4c38cca2ba6851f
Because a library or app can be built from mere static libraries,
or generated java files. For example, framework is built from only
static library framework-base but without LOCAL_SRC_FILES.
Also added framework2 to PRODUCT_PACKAGES.
Previously framework2.jar was installed by dependency explicitly
established in frameworks/base/Android.mk. That's not enough for the
.odex file.
This fixed the boot failure reported in bug 12382916.
Bug: 12382916
Change-Id: If1a70261ab2bb7fef77cf7b7b995bdc029be0fc3
_LARGEFILE_SOURCE should never be defined with bionic.
_FILE_OFFSET_BITS should be 64 on 64-bit architectures.
Change-Id: I7acf6b39a3af7782d5d7ad00f709593d96fa8522
Also this fixes the LOCAL_UNSTRIPPED_PATH if the module is installed to
the vendor dir via LOCAL_PROPRIETARY_MODULE.
Bug: 11289169
Change-Id: Ib07e5761411210963076487fe0e148c259e1e082
All thumb code compiles with -fno-strict-aliasing. Let's not make aarch64
porting any more difficult than it needs to be.
Change-Id: I94874df1217b69532c328d7c86c9961631ebde8a
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
Once the aarch64 toolchain is refreshed this will be removed.
Also removed some CFLAG duplications.
Change-Id: I42fd86931263af82042ea696196fb25e948fe9cb
Add -Wa,--noexecstack and -Wl,-z,noexecstack as default
flags when compiling host-side applications. This enables
NX protections, which prevent code from executing on the
stack or heap. NX protections make exploiting memory
corruption issues more challenging and is an important
security feature.
Change-Id: Iae580abe887e01f9029ec2a4e0fc0aae496724a4
- Separate SDK checking from version checking and
make messages clearer.
- Add explicit source & target versions for javac to
make things clearer.
- Rename flag from EXPERIMENTAL_USE_JAVA7_OPENJDK to
EXPERIMENTAL_USE_JAVA7.
- Allow Oracle JDK 1.7 to be used on Mac OS, since there's
no official OpenJDK support for that platform.
Change-Id: I454d2c917ed78f03ec7559a99659fefe7e7d50f3
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
This enables the .so libraries to be built for apps using the
RenderScript support library. Traditionally, we trim these .so
files from full platform builds.
Change-Id: I6f8e9b8d2b671338d3d5a5ac0bfcc60fd448688b
This adds the --instruction-set-features= arguments to the dex2oat
commands for the system images. The feature set is determined at
build time
(cherry picked from commit 4145a2a20a0f275fe4c77e39d507cd5f8eb7a73b)
(cherry picked from commit 5174bb0529)
Change-Id: I45af3b59752a48897bff2dd468b74f3ea73000be
MIPS and x86 are almost completely switched over to uapi-only. ARM is still
currently old-only. A cleanup of the uapi headers over the weekend means
that the uapi-only <linux/kexec.h> is now in the right place, which will break
the ARM build unless the ARM build also looks in the uapi headers if it can't
find an old header.
Change-Id: Ie7a53ef2122b43cdef64b71d7b36a8381992a461
We currently have two types of host libraries, those
meant for the host VM (Sun, OpenJDK etc.) and those meant
for a host dalvik build. The former need to be compiled
against the host standard libraries and the latter need
to be compiled against libcore. This change introduces
two new build rules to complement the existing the existing
host rules.
BUILD_HOST_DALVIK_JAVA_LIBRARY : Build a java library for
a host build of dalvik. Bootclasspath will be set to a host
build of libcore.
BUILD_HOST_DALVIK_STATIC_JAVA_LIBRARY : Build a static java
library for a host build of dalvik. Bootclasspath will be set
to a host build of libcore.
This change also removes support for the LOCAL_BUILD_HOST_DEX
flag, which is now unnecessary.
bug: 8992787
(cherry picked from commit 0dd273a3f6)
Change-Id: I3569fff8eaa4d26d55fcc317bd98471f55d74c14
* commit '37335b42385970d957d48056145a3d4c4dbc6087':
Enable incremental builder to find files that moved, and try to process them via patch + rename, instead of delete + add.
This patch completes the support for AArch64. It adds the last few
tweaks that will enable a AArch64 build of bionic.
Please note that though AArch64 uses the new kernel infrastructure,
where the userspace exported headers live in uapi folders, we still
need to include "kernel/common" in the include search path
(take a look at external/kernel-headers/uapi/asm-generic/signal-defs.h).
Also remove the relro linker flags for now as they crash the foundation
model.
Change-Id: Ie2fa8c1056c84dc15fec4469f2d65b8d0c5e712b
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
In 4f2f16da14, we added
-Wl,--warn-shared-textrel to TARGET_GLOBAL_LDFLAGS. This generated
a warning whenever we created a shared library with a text
relocation. At the time, we wrote:
=====
Emit a warning when the static linker detects a shared library
has text relocations. Text relocations make it harder to
share pages across processes, and make it harder to use
certain memory protection features in, for example, SELinux.
This warning will turn into an error in a future change
(via --fatal-warnings)
=====
All code which uses text relocations has either been fixed, or
we've temporarily worked around the issue so the code can still
compile.
Enable --fatal-warnings.
Bug: 11353056
Change-Id: I2f2c65352166ef0a96f54858de1556f0290fe306
If LOCAL_COPY_HEADERS_TO is not set, then the copy headers rule
target is set to out/target/product/../obj/include//header.h.
If another rule depends on the header without the //, it will
fail. Don't insert LOCAL_COPY_HEADERS_TO if it is blank.
Change-Id: Ideac7f8e01288ab5cca98645b307945d6ae9e97c
-mandroid, -D__ANDROID__ is on by the toolchain;
-msse3 moved to llvm_config, it seems it's required only there;
__cxa_atexit is provided by libc now;
USE_SSE2 should not be used anywhere, it's always true;
remove -mstackreallign and -mfpmath=sse as useless for x86_64;
Change-Id: Ib7739f6522c375c09de10d22616c48a493841c4c
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
ARCH_X86_HAVE_MMX, ARCH_X86_HAVE_SSE, ARCH_X86_HAVE_SSE2,
and ARCH_X86_HAVE_SSE3 were all always on. There are no longer any makefiles
or code that are conditional on any of these, so let's just remove them
rather than encourage anyone to mess with knobs that don't work.
Change-Id: I5ee095e8041eecff4554ad4801894fbfca69093f
Static libraries and host modules are not installed under
TARGET_OUT_VENDOR and don't need to be, relax the checks.
Change-Id: Ia8b926d466420a8b6dd418d5e95fdf5ff919e078
Add x86_64 Android builds. Compiler is expected to be able to understand
-m64 code generation option.
Change-Id: I99e7337c5a5766afc5e528a481bd21631ff44dd5
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
only if the module is built against the platform, not the SDK.
Previously it added it if it's doing a platform build.
But we can do an apps_only build inside the platform source tree and
such a build may build modules against the platform.
This fixes the apps build in the platform source tree.
Change-Id: I73e32a8f0e505349790a102321f88e77fba472cd
With this change, you can install a shared library with module name foo
as bar.so to the system.img with:
LOCAL_INSTALLED_MODULE_STEM := bar.so
Note that we in general still disallow a static/shared library to
specify LOCAL_MODULE_STEM or LOCAL_BUILT_MODULE_STEM, because the build
system uses LOCAL_MODULE to compute build time dependencies, such as
export_includes, the -l linker flag etc.
Also, if you use LOCAL_INSTALLED_MODULE_STEM to change the installed
file name and if any other module links against this library, you may
run into runtime error: the library name baked in to the binary is not
the same as file name in the system image.
Change-Id: I55b571c8139c3bda07a4a0e50cea0f20d8d6c168
Library is located frameworks/ex/camera2/public.
This is required to allow pdk/apps/CameraITS to build in the PDK.
Bug: 10337323
Change-Id: I5b835134012f90462a70b9e38b69c3168df00cfd
Author: Negreanu Marius Adrian <adrian.m.negreanu@intel.com>
Author: Andrew Boie <andrew.p.boie@intel.com>
Author: Daniel Leung <daniel.leung@intel.com>
Currently, x86 target only has generic i686 and x86-atom
as arch variants. This patch adds the ability to have
more than two arch variants. Defining a new arch variant
is similiar to ARM targets, by adding a new file in
core/combo/arch/x86. These files also define what
capabilities the targeting CPU has (e.g. having SSE2,
SSE3, etc.).
We define arch variants for Sandy Bridge, Ivy Bridge,
Haswell; upcoming arches can be easily added to this
set with future patches.
Change-Id: Iafbce10d205e860738db4a216ff603f9a84d7311
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
With this change, modules introduced by LOCAL_REQUIRED_MODULES will be
split by host/target: target modules only depend on target modules and
host modules only depend on host modules.
Bug: 9303948
Change-Id: I4078a7983aa3c00e99534f3f170dfe4b66b12287
Since we have enabled Progaurd for all build variants, we don't need the
different naming scheme along the path to make incremental build work
properly when you switch build variant.
As a result, this fixes the nothing-to-do-do-build-gets-something-build bug
introduced by the multi-dex change.
Change-Id: I907ff13091013d28910b0aa190b9218144385132
* commit '3938f3e1af045e887735884b059224a86f46db74':
Revert "remove renderscript support lib from javadocs" ... put support lib javadocs for renderscript back in.
* commit '7cba6168c3cf7681e6200f78bfbf8deacc2f735c':
Revert "remove renderscript support lib from javadocs" ... put support lib javadocs for renderscript back in.
* commit '9a3fb8711f93751ba3e709f4e99691147e6c2c93':
Revert "remove renderscript support lib from javadocs" ... put support lib javadocs for renderscript back in.
A reorganization of the libcore test jar files caused the Conscrypt
tests to be accidentally dropped from CTS. Add them back in their own
package.
(cherry picked from commit 69c00c9ee8)
Bug: 10210673
Change-Id: I5ffc62736d3dab7e96e480c593e07d6c640b8950
Update the OTA generation script to understand SELinux file
labels and file capabilities.
Make fs_config aware of SELinux labels and file capabilities, and
optionally output those elements whenever we output the
UID / GID / file perms. The information is emitted as a key=value pair
to allow for future extensibility.
Pass the SELinux file label and capabilities to the newly created
set_metadata() and set_metadata_recursive() calls. When the OTA
script fixes up filesystem permissions, it will also fix up the SELinux
labels and file capabilities.
If no SELinux label and capabilities are available for the file, use
the old set_perm and set_perm_recursive calls.
Bug: 8985290
Bug: 10183961
Bug: 10186213
Change-Id: I4fcfb2c234dbfb965cee9e62f060092a4274d22d
The new option WITH_STATIC_ANALYZER=1 instructs build system to
run static analyzer via "clang --analyze" on a successful build.
If analyzer finds any issue, instruction to open report is displayed.
See http://clang-analyzer.llvm.org/scan-build.html for details.
WITH_STATIC_ANALYZER trumps WITH_SYNTAX_CHECK if both exist.
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_STATIC_ANALYZER:=true
Change-Id: I9970560560bd52ce5f0fd7129c3488629627c735
This makes "mmm <path> snod" work again.
Note that snod has dependency on the rest of the command line goals,
which is all_modules for ONE_SHOT_MAKEFILE,
so build race condition is avoided.
Change-Id: Ib0c0e622530cde773180a095e5ec4dde1149b8e5
A reorganization of the libcore test jar files caused the Conscrypt
tests to be accidentally dropped from CTS. Add them back in their own
package.
Bug: 10210673
Change-Id: Ia46a5de925c35115d25b7c0f974eba5b27bbfcd6
The new option WITH_SYNTAX_CHECK=1 instructs build system to invoke
"clang -fsyntax-only" to utilize clang's better diagnostics before calling
LOCAL_CC/LOCAL_CXX for code generation. The compilation time is slightly
longer, and the generated object file should be the same as w/o WITH_SYNTAX_CHECK
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_SYNTAX_CHECK:=true
Change-Id: I5689586788ef049bd967364f71f31f1e359bd121
The issues:
- The size increase from utilizing FDO is quite large while
utilizing runtime profiles in build.
- By default, FDO is utilized globally if the target arch variant
profiles exist.
- Not all modules can show statistical significance in
performance comparison, yet still suffer the size increase.
The solution:
- Only enable FDO locally with LOCAL_FDO_SUPPORT
for modules which may benefit enough to justify the size
tradeoff.
Solution notes:
- I've noted statistical significance in libwebcore and libskia
thus far from utilizing FDO.
- Analysis included sunspider, drawcanvas benchmarks, as
well as gooda analysis on both arm and x86
- To support runtime profile generation in modules which have
LOCAL_FDO_SUPPORT specified,
BUILD_FDO_INSTRUMENTATION is still used. Otherwise,
if the target arch variant profiles exist, FDO is utilized for
specified modules.
Change-Id: I7e95266943ff47c7d82b02e6200fd09911d0bb57
Rule-generated .o files (in gen_o_objects) were being given a dependency
on everything in LOCAL_GENERATED_SOURCES (except for other .o files);
unfortunately this can still create cycles in cases where there are
explicit dependencies between entries in LOCAL_GENERATED_SOURCES.
Instead, make handling of generated .o files consistent with other
generated files (which don't automatically get any dependencies on other
generated files) by excluding them from the target side of the rule.
Change-Id: I3fb5652dc3d85012c179a03b81887d16a85ab3bf
The existing logic in common.py breaks string arguments incorrectly:
e.g. --para1 val1 --para2 "val2 is a string" will be output as:
'--para', 'val1, '--para2', 'val2' 'is' 'a' 'string'
This will cause mkbootimg command fails due to the invalid arguments
generated from the wrong parsing.
The patch fixes this issue to get:
'--para', 'val1, '--para2', 'val2 is a string'
Change-Id: Ia34ec357550f11ae9d6adc719d86a0c6a9099fbc
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Switch from gcc-4.7 32-bit only to gcc-4.7 multilib (32/x32/64) compiler.
Tested x86 image build on Linux and Darwin.
This bionic patch is required:
https://android-review.googlesource.com/#/c/64183
Change-Id: Ifc2c6c5d6a4a1b71a00a87af072bb7f67b1c284d
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
In apps_only build (after running tapas or exporting TARGET_BUILD_APPS),
run "make notice_files" to collect and combine the NOTICE files of
modules that are needed by the apps.
Bug: 10445634
Change-Id: I6555bba1104e43b48c723c82143c46d444a75e80
Collect and store proguard obfuscation dictionary files.
Only do this for apps_only build for now.
Bug: 9407666
Change-Id: I51c78bf0f42f959dc920de230e60e0f71ed0d0ea
Collect and store proguard obfuscation dictionary files.
Only do this for apps_only build for now.
Bug: 9407666
Change-Id: I0324eed6bb236abb0d3725f8d2a0b6c5c31935fe
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
