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
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
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 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 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 5267392
After coming across another place where I would have to use
package.apk.unaligned, I decided maybe it is best to just
disable dexpreopt as was previously suggested.
Use package.apks in the CTS Makefile task.
Change-Id: Iec839a72f4b53441337523b8a9cccda657eec8e8
Bug 5252989
This prevents dexopt installation failures when trying to
install CTS apks on production devices.
Change-Id: I1eeb0ac567c3be3b831c8c27dee4005ec00fd7cd
This patch fixes the broken builds for PRODUCT-google_sdk-sdk_addon
and PRODUCT-google_sdk_x86-sdk_addon.
Change-Id: Iba0f23a03c143cd38aaba98b0bd0d52686330ed6
* commit '36331f8455822539fe4fbb0a25fbc377bbc80a89': (23 commits)
sdk-addon.mk: Copy image files to ABI-specific dir
emulator: Enable dex-preoptimization
sdk: provide ABI-dependent atree files
emulator: Build emulator platform images as ARMv7-A
x86: Add proper gcc-4.4.3 x86 toolchain support.
sdk: Add pc-bios files for IA qemu emulator
x86: qemu emulator is the default build target
Add full_x86 product.
x86: sdk_x86 build target
Minor cleanup - DO NOT MERGE
Clean up full config - DO NOT MERGE
Make a full list of locales available
Truly default to the full config.
generic_x86 builds don't need/use the sparse ext4 format.
Use ext4 file system for generic_x86 userdata partition
GB Updates for init.rc and boot command line
Fix TARGET_PREBUILT_TAG so that get_build_var can retrieve the correct value across architectures
Display the TARGET_ARCH_VARIANT
Add generic_x86-eng to the lunch menu
Move buildspec vars to BoardConfig.mk
...
When the build is invoked with the fake target "sdk_repo" and
a main target of sdk, win_sdk or sdk_addon, we now create
packages in DIST_DIR that can directly be used to populate the
SDK Repository.
This is quite close to how we actually distribute the SDK.
Change-Id: I863ac8baf159432d7c95df46cba6e4f3b9122629
Change-Id: I1fc3cb491d593d3e28f90278cfc8de5d77852932
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
When the build is invoked with the fake target "sdk_repo" and
a main target of sdk, win_sdk or sdk_addon, we now create
packages in DIST_DIR that can directly be used to populate the
SDK Repository.
This is quite close to how we actually distribute the SDK.
Change-Id: Ie7e0f789bafd73d5ee2461349155a6e562e2edd9
