BUILD_PDK and some of the other infrastructure will go away once
we're done with the new new PDK work, but for now don't disturb
that stuff.
Change-Id: Ia39bf759ec03f203858ddcc4880af72bd132cb5a
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>
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>
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
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
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 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
Original description:
CTS vm-tests now depend on hosttestlib.
Bug 3125713
Conflicts:
core/tasks/cts.mk
Change-Id: I9e364a9d9d2cae396691921424ca591beca05468
Include another optional Makefile from the CTS project that
specifies additional JARs that the CTS host may need. This
will make it easier to create modules in the CTS project
that can be built for the host and device and shared between
the host and test cases.
The first such library will include annotations like
"RequiresFeature" and "SupportsProfile" that will be needed
to support multiple device profiles in CTS.
Another planned libraries could include defining the CTS
version number in a central spot and sharing code used to
probe for certain properties like the OpenGL version and
other system properties.
Can be checked in after this other change without causing
breakage: https://review.source.android.com/#change,16740
Change-Id: I3c488247b66522dc86277ab43198c34f790e0618
Merge commit 'af44485fe83bb36a9d55fb54a8f5362854dd7b10' into gingerbread
* commit 'af44485fe83bb36a9d55fb54a8f5362854dd7b10':
Include Test Case List from CTS Project
Bug 2732160
Have the cts.mk include the test case list from CTS rather
than defining it in cts.mk. This permits CTS developers to
add new packages and applications without having to submit
multiple project changes to both the CTS and build projects
everytime.
Change-Id: I63d90ac4f5d9fc9a9aa0ff79a8bf9dfb1a79c822
Bug 2814482
Froyo's cts.mk was missing two lines added to Eclair's cts.mk that
are needed to build the accessibility tests and apk.
Change-Id: I05f93bc0a56b2ec1e07eab8c7a15ef7d4bb90d18
