Bug: 5448433
Instead of deferring the removal to building the app.
In that case any R/Manifest classes in any static Java libraries will be
deleted, no matter if they are generated from Android resource, or just
source R.java/Manifest.java in the source tree by accident.
Change-Id: I656f45e3cbc3796c5d4832363231480b3f1dc5b8
Unfortunately there is R.java checked in the source tree that gets built
into static library.
So we have to find a way to delete classes from R.java generated by the
build system on the fly.
Change-Id: I2d82d28234cecbf6dd5b02b2dd4f7dbd47e3b626
Bug: 5714516
The rationale behind this change:
- the library is compiled into a jar file, but its R class is generated
making the constant not constant (static, not final static) (aapt
option --non-constant-id). Also the jar file does not contain the R
class.
- this allows the integer value to not be inlined in the compiled
class files. Note that this prevents using switch statements.
- the main project use this jar file as a normal static library: it will
add all the class files except the R.class.
- the main project uses the library res folder as a resource
folder with lower priority than the main project (basically the
main project is an overlay. This is accomplished using aapt's
--auto-add-overlay to handle resources only in the main project
(which the normal overlay mechanism doesn't allow).
- the main project creates R classes in the main project's
package but also in the library's package. This is done with
aapt's --extra-packages which accept as many packages as
needed, separated by a :.
- manifest merging is not done yet, so
activities/services/permissions/etc... have to be manually declared in
the main app.
To use a static library with Android resource in your app,
1. Add the library's resource dir to your app as an overlay:
LOCAL_RESOURCE_DIR := <app_resource_dir> <static_library_resource_dirs>
2. Set the proper aapt flags:
LOCAL_AAPT_FLAGS := <apps_own_flags> --auto-add-overlay \
--extra-packages <lib1_package_name>:<lib2_package_name>:...
Change-Id: Ifb4d2300b952ea4aaee74da1bb0c6c72ea0698a3
This is the result of a recent conversation around the x86 ABI
and its relationship with how we build platform images. Briefly:
- We want to use feature-based macros like ARCH_X86_HAVE_$FEATURE
instead of relying on explicit compiler macros like -DUSE_$FEATURE
- We want to allow for other x86-based arch variants, e.g. if
someone wants to build Android for a CPU that doesn't support
the NDK x86 ABI. However, we need to ensure these are not
tagged compatible by mistake (see check at the end of TARGET_linux-x86.mk)
- There are several flags which use is dubious now that we have
a dedicated toolchain to build all the x86 stuff. Comment them
as 'to be considered for removal'. We'll do the proper checks
later.
Change-Id: I7768d7c34d73e274cbf4c09ae831b55280d6bb58
Bug 4970300
Adds two new variables, CTS_TEST_CASES and CTS_TEST_XMLS, to be read
from CtsTestCaseList.mk. The CTS_TEST_CASES variable can be used to
copy any sort of file to the repository/testcases CTS directory.
The CTS_TEST_XMLS variable can be used to inject test package xmls
from any source rather than relying upon the monolithic and
mostly serial buildCts.py script.
The existing CTS_CORE_CASE_LIST is coded to only support APKs, so
it could not be retrofitted to support native tests. However, the
two new variables can do even more than CTS_CORE_CASE_LIST due to
their generality. In the future, the idea is move away from
CTS_CORE_CASE_LIST and also generate XMLs using separate tools
rather than just buildCts.py.
Change-Id: Ib52722861c37e0f4d511f9041928395bcaba5dea
Emulator and system image now support ADBD communication over QEMUD pipe rather
than over a TCP port forwarding. However, emulator has to know ahead of time
(before system starts booting) whether or not the system image supports ADBD
over pipe to properly setup the communication. For that, we introduce a boot
property "ro.adb.qemu" that is readable by the emulator early enough for the
proper ADB communication setup.
Change-Id: I978489c5acf46177b520e775d745bcc78f469837
Bug: 5692177
If you set "PRODUCT_RESTRICT_VENDOR_FILES := true" in a product
configuration, this changes restricts that:
- No overlays in the vendor tree.
- No PRODUCT_COPY_FILES coming from the vendor tree.
- Any referenced package with Android.mk in the vendor tree must have
LOCAL_MODULE_OWNER set to a value that's compared against a whitelist
stored in the core build system.
Change-Id: I172b84c7c853e9a04bf9879ea8dec90bd5054230
If the emulator is run without GL acceleration enabled, the OpenGL
renderer will disable itself at runtime.
Change-Id: Ie40c7895120f51bb6a817c2f3cf7fab0a3dda292
Ying Wang