1. A CTS package can specify the test runner used to launch
its tests from the device. This is useful for preparing
and cleaning the device through some shell commands if
necessary.
bug:5946699
Change-Id: Ib1d6454c4274b1c37323235c9b3a195f3b9d8131
This allows us to have per-host OS (or OS + arch) atree files in case we
need to get tools which source varies per host OS, example:
- sdk/build/tools.linux.atree
- sdk/build/tools.linux-x86_64.atree
- sdk/build/tools.windows.atree
etc.
Change-Id: I9a1256548345fb866b0750fce6810913413dd946
By default we build tool in 32-bit. This flag allow individual tool and its
dependencies to be built in 64-bit (eg. Emulator). Fixes to resolve 64-bit
porting issues (in other git) will be submitted seperately.
Change-Id: I486cf7ddac727d3c374ed890857d497c3a69e598
Everything that is based on ARMv7a should have a cp15 TLS register.
Enable it by default so it's not accidentally missed in newer board
configurations. In fact, this could be enabled for ARMv6 as well, but we
currently don't distinguish between ARMv5 and ARMv6 in the build system.
This can still be disabled by setting it to "false" in the board
configuration, but this shouldn't ever be needed.
Change-Id: Ic2918f32899c8bcfa482f92c98f5a192fa318470
This replaces the list maintained in build/core/main.mk
by 2 makefiles in sdk.git and development.git.
Pre-requisite CLs: Change Ifa8111dbae for sdk.git
and Change Ie6f728bee for development.git
(cherry-pick of 347f305181)
Change-Id: I6d1f4c974a6425e50e3e287c66a4e8090cf814cb
1. This change adds the shell command to the bin folder on the device.
This will enable using shell commands (assuming right permissions
are held) on a user build to manipulate state of content providers.
For example, this will be used for running CTS tests that rely on
secure settings without adding intermediary APKs and/or manual setup.
Main change:https://android-git.corp.google.com/g/162774
Change-Id: I562eb86a4bb971dbaa42848e95e7650bf2cbb0c9
This should help us support users with build issues.
Given that they inculde the dumpvars in their error report,
we will be able to avoid asking standard questions like
"what version of Ubuntu are you using?"
Change-Id: Ib7c452d805d5e64075a44dc40e41d4605cc1ef4a
libgccdemangle.so is required to build libcorkscrew, which is in
system/core and built when BUILD_TINY_ANDROID is set.
Change-Id: Ide9af58cfc075e27a7368993b29be2c0e53275a8
With "-Wl,-rpath,@loader_path/../lib" the linker embeds
@loader_path/../lib as the target binary's rpath.
Here @loader_path means the path of the binary that initiates the
loading.
With "-install_name @rpath/libfoo.dylib " the linker runtime searches
libfoo.dylib in the binary's embeded rpath.
With this change you can call dlopen() without specifying the full path
of the shared library.
Change-Id: If9beb3f6f4642a377bff603bab5ba3fdb96211bf
Before this change, path of the install name is relative to the top dir.
That means you can execute dynamically-linked binaries only in the top dir.
With this change, you can execute dynamically-linked binaries anywhere.
Change-Id: I1c6441579ffb68505ea678296aceb2e66a6df1be
We'll need a special case to set device properties on the factory ramdisk
Change-Id: I146d5c503e8c97005caa1ab1dbaca7ee9ab30faf
Signed-off-by: Nick Sanders <nsanders@google.com>
I got an Out of memory while compiling, Andreas Huber suggested that
increasing the heap size, which worked.
Change-Id: Id8293ef100ef814b0fe13aa6e1b891a36a2ee853
When common_javalib.jar is created, both LOCAL_BUILT_MODULE and
built_odex targets can be run.
If built_odex target runs before the directory is created by
LOCAL_BUILT_MODULE target, the error occurs.
Change-Id: I1ebcb27630f8373558da6acdfce95f5cdf714bbf
This replaces the list maintained in build/core/main.mk
by 2 makefiles in sdk.git and development.git.
Pre-requisite CLs: Change Ifa8111dbae for sdk.git
and Change Ie6f728bee for development.git
Change-Id: Id6178b000c464c989da2c7f22977986a60de1f44
What was I thinking?
That would be *ridiculous*.
What sane person would come up with a release like that?!?
I mean... four words! Six if you try to say it! Insane!!
Instead, we shall call you:
Jelly Bean.
Yum.
Change-Id: Ice28fc17b7eb77cf6b708958161339890234d1d8
Sometimes TARGET_TOOLS_PREFIX is passed in as command line makefile
variable or environmental variable without TARGET_TOOLCHAIN_ROOT.
This change computes TARGET_TOOLCHAIN_ROOT from TARGET_TOOLS_PREFIX in
that case.
Change-Id: I0a37dc1f4d1e3e1951faeffd5e9f926f0a6614dd
When this is enabled we ensure that files from the vendor directory
get installed to /system/vendor/* instead of elsewhere in /system/*.
This changes the PRODUCT_RESTRICT_VENDOR_FILES variable
to accept "owner", "path", "owner path", or "all".
"true" will still only enforce vendor file owner restrictions.
Change-Id: I4598130a590ad56976e011f4cb2a9f5f227d5732
So we can have the same set of module names in different host arch
/ toolchain version combinations.
Change-Id: Iec66584bf3de92aedd71a59f9dbe74b6ed025b2e
Only generate the core test and vmtest descriptions when something has
actually changed rather than everytime CTS is built. This should make
iterative test development in CTS more pleasant.
The rule targets are changed to be the paths of the test description
XML files in a separate directory outside of the CTS distribution.
The buildCts.py rule copies these XMLs when they change to the
final CTS distribution location and creates the final plan file.
The dependencies have also been changed to reply upon the full
package paths rather than their phony targets to avoid rebuilding
everything all the time.
Finally, the AppSecurity rule was removed, because I have taken
care of that in my prior change to the Makefiles in the CTS
project.
Change-Id: I88b92c7a4cb4c2c2e20f06641e7ba0604d37f805
With this change, if a module name is associated with multiple modules,
you can specify multiple install paths in
PRODUCT_FACTORY_RAMDISK_MODULES.
For example, if we have 2 modules named "foo", one is Java library and
the other is executable, then you can write:
PRODUCT_FACTORY_RAMDISK_MODULES += \
foo:system/bin/foo:system/framework/foo.jar
Or:
PRODUCT_FACTORY_RAMDISK_MODULES += \
foo:system/bin/foo \
foo:system/framework/foo.jar
The build system will choose the correct built files based on the
install paths.
Change-Id: I6efc72e8abd1e81710ada16731b6792989aefd85
With this change, if a module name is associated with multiple modules,
you can specify multiple install paths in
PRODUCT_FACTORY_RAMDISK_MODULES.
For example, if we have 2 modules named "foo", one is Java library and
the other is executable, then you can write:
PRODUCT_FACTORY_RAMDISK_MODULES += \
foo:system/bin/foo:system/framework/foo.jar
Or:
PRODUCT_FACTORY_RAMDISK_MODULES += \
foo:system/bin/foo \
foo:system/framework/foo.jar
The build system will choose the correct built files based on the
install paths.
Change-Id: I6efc72e8abd1e81710ada16731b6792989aefd85
OTOH, should we just allow the expression to be >= 3.81
for all platforms? For cygwin it's a specific case since
we don't build the platform, only a handful set of tools
and it works just fine with a newer make 3.82.
Change-Id: Icff0d0e13bce79f7164007985f14db56e9049552
Bug: 5769921
With this change, to build factory_ramdisk.img, set
PRODUCT_FACTORY_RAMDISK_MODULES in your product config.
PRODUCT_FACTORY_RAMDISK_MODULES consists of
"<module_name>:<install_path>" pairs.
<install_path> is relative to the root of the factory ramdisk output.
For example:
PRODUCT_FACTORY_RAMDISK_MODULES := \
toolbox:bin/toolbox adbd:sbin/adbd adb:bin/adb
On the other hand you can use PRODUCT_COPY_FILES to copy prebuilt files
to the factory ramdisk.
Or you can define modules that are specific for the factory ramdisk
(with LOCAL_MODULE_PATH pointing to TARGET_FACTORY_RAMDISK_OUT) and add
the module names to PRODUCT_PACKAGES.
Change-Id: I80ff72606415cd74fe6f3bc93020a05d84e45b70
Bug: 5769921
With this change, to build factory_ramdisk.img, set
PRODUCT_FACTORY_RAMDISK_MODULES in your product config.
PRODUCT_FACTORY_RAMDISK_MODULES consists of
"<module_name>:<install_path>" pairs.
<install_path> is relative to the root of the factory ramdisk output.
For example:
PRODUCT_FACTORY_RAMDISK_MODULES := \
toolbox:bin/toolbox adbd:sbin/adbd adb:bin/adb
On the other hand you can use PRODUCT_COPY_FILES to copy prebuilt files
to the factory ramdisk.
Or you can define modules that are specific for the factory ramdisk
(with LOCAL_MODULE_PATH pointing to TARGET_FACTORY_RAMDISK_OUT) and add
the module names to PRODUCT_PACKAGES.
Change-Id: I3778e3d091979261cb476628da1365f931e11f49
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
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
Bug: 5620615
Before this change it only reports the limit if the real size exceeeds
or approaches the limit.
Change-Id: Ie1737d6ba2dc2d57ad82c487990e109882526d6e
Bug: 5573756
With this change, we can set LOCAL_EXPORT_C_INCLUDE_DIRS in the module
definition to export include dir paths.
Paths in LOCAL_EXPORT_C_INCLUDE_DIRS should be relative to the top dir
of the source tree.
If a library (shared or static) exports some include paths, any module
using it will import the include paths and add them to the compiler
command line.
Change-Id: I49aabc589d2cf214044d13ccd5532ef68209adf0
Bug: 5153694
To build cache.img, set BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE (required,
ext4 only for now), BOARD_CACHEIMAGE_PARTITION_SIZE (optional) in
BoardConfig.mk.
Change-Id: I1d8b91646aa1dba88285e008ad3335768bcbddd2
While building Android with latest host gcc, it causes the following
build error:
Install: out/host/linux-x86/bin/mkbootimg
host C++: obbtool <= frameworks/base/tools/obbtool/Main.cpp
<command-line>:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
<built-in>:0:0: note: this is the location of the previous definition
cc1plus: all warnings being treated as errors
In order to make build system happy, this patch does unset macro
_FORTIFY_SOURCE and then define it in host cflags.
Change-Id: Ic37a90f05081a2c3650b3335bc87e9e895900fb2
Compile all x86 programs on Android with -fPIE and -pie. This enables
PIE (Position Independent Executables), which helps protect Android
applications from exploitation due to memory management bugs.
Note 1: PIE *static* executables are not supported at this time and
require additional linker changes.
Note 2: This change compliments 026a85b129,
which was the exact same change, except for ARM.
Testing: Rebuilt the tree completely from scratch, and verified
that the system boots and basic functionality works in the emulator.
Change-Id: I990064c37da3d857e663b27f31fee05f689a2824
Bug 5563917
This stops packaging the startcts script and the cts.jar into
the android-cts.zip. Since we are only testing using Tradefed,
we should prevent confusion by removing the old test runner.
Change-Id: I79f991617dd9e6a51a314207b4727cce3136d60f
Bug: 5398808
Before this change we have duplicate code in the Makefile and the
python-based releasetool. That's a real headache to maintain.
Change-Id: I8ddf04a79c6886540e89d990f723d8f77c9dd883
