| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| | |
factory_ramdisk.img now is a real u-boot img containing
a kernel and memory offset metadata.
Change-Id: I9b4624eab8a6f769bb8bf0568484ee1865267c08
|
| |
| |
| |
| | |
Change-Id: I92c7f26d13a05c4306c22b2e9e513cdd22e839ce
|
| |
| |
| |
| |
| |
| | |
Because factory ramdisk build depends on the global view of all modules.
Change-Id: I51de434e7800ac6e55b0eeca9394361e5e14cd55
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| | |
If there is shared library with the same name.
Change-Id: I6c18ffc2a6c1f6d5b6468677cc420be817ea950d
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| | |
- additional files will be added to pdk/build
Bug: 6079146
Change-Id: Ieb5fcab8002193250d770b923f60ec7333ce84e5
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Change-Id: I978569e1be4c9d1d52d2b7fb7de2da4d4f616f39
|
| |
| |
| |
| | |
Change-Id: I711dbfb0d98a5e8a4d784d3ee6f3f9cfdc926209
|
| |
| |
| |
| |
| |
| | |
Because factory ramdisk build depends on the global view of all modules.
Change-Id: I5b35821cd287b70702191f3c30be6735d3339544
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| | |
If there is shared library with the same name.
Change-Id: Iaa43219cab7737c02a79d168f13ad4c473421f24
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Bug: 5693205
Change-Id: I045b83949f8b29d7c5cf5c0ab32c5b83cf398e71
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 5728172
The VM tests were used with the old test runner.
Change-Id: I7ba819a394bb9643f937240ebd315d7d7820a8bf
|
| | |
| | |
| | |
| | | |
Change-Id: I9a215b74167efc2a6b3070dc8b616a289669d10f
|
|\ \ \
| | |/
| |/|
| | | |
Change-Id: I0febb15b690932ad342da4b10eb9c0f13d1d1517
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|
|
|
|
|
|
| |
We no longer want a reference directory, but rather
maps_api and effects_api directories.
Change-Id: I72b3a342d0871ec4cf7010be0d2b6486ca83571b
|
|
|
|
|
| |
Bug: 5429077
Change-Id: I8d962c803496479ba5b5e7316538aced65ee4df1
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| |
| | |
Change-Id: Ia07eb9d022a8036c2b1674c591514740aa0d4596
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
google_sdk_x86 add-on build." into gingerbread
* commit 'fdb13fccfecdf526549ad453a20e8136253edb51':
sdk: Fix broken google_sdk and google_sdk_x86 add-on build.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch fixes the broken builds for PRODUCT-google_sdk-sdk_addon
and PRODUCT-google_sdk_x86-sdk_addon.
Change-Id: Iba0f23a03c143cd38aaba98b0bd0d52686330ed6
|
|\ \ \
| |/ /
| | |
| | |
| | | |
* commit '8658fa51d15290cf43178d0633b53f11ff08a4aa':
Disable Dexpreopt for generic_arm5
|
| |\ \
| | | |
| | | |
| | | |
| | | | |
* commit '9d014e6570deb3861b503833823e56e1c589626c':
Disable Dexpreopt for generic_arm5
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|\ \ \ \
| |/ / /
| | | |
| | | |
| | | | |
* commit '3eae5b7c1b3197bed4c883a671cfea9d5d9570bf':
Use package.apk.unaligned in CTS Build
|
| |\ \ \
| | |/ /
| | | |
| | | |
| | | | |
* commit '08b8e0024812ea907cf3938bcd07b8dca6188eaf':
Use package.apk.unaligned in CTS Build
|
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug 5252989
This prevents dexopt installation failures when trying to
install CTS apks on production devices.
Change-Id: I1eeb0ac567c3be3b831c8c27dee4005ec00fd7cd
|
| |\ \
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 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
...
|
| | |
| | |
| | |
| | | |
Change-Id: I39ad022a5bb03ea39fc41c134d1d4855dc491deb
|
| | |
| | |
| | |
| | | |
Change-Id: I659d996dda0a2047ebb3240607e66411fc60fda6
|
| | |
| | |
| | |
| | |
| | |
| | | |
git cherry-pick --no-commit ec122eb2c11dfb8553d3707208a1ecbe7366f61b
Change-Id: I685ece362674f83f179ace34367fce88a7f541fb
|
| | |
| | |
| | |
| | | |
Change-Id: Ia7538dc204faa93f47cd3fd104ed05c9da3e8741
|
| | |
| | |
| | |
| | | |
Change-Id: I523860b4e73b11cc158706a30e6694d9188a6697
|
| | |
| | |
| | |
| | | |
Change-Id: I47dfe29957a9a65dddae973640ff9029418ffdc5
|
| | |
| | |
| | |
| | |
| | |
| | | |
(and much much easier to read)
Change-Id: I31832069d4fd78a937802aa20d0b0861bf99768c
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git cherry-pick --no-commit 5fac8d8f7096d8a950acad1ad0a8b963cef72e03
git cherry-pick --no-commit 1a8210710b46a0796ff2f8e76b6beb3a54f89019
git cherry-pick --no-commit 4fe2ac9f7284b838393aec8f0f48caef2510fd46
git cherry-pick --no-commit 7beb710a8f976fc4cb1e8be780644386870c4975
Change-Id: Ib10348e5509c906c6b95fa4accd6a18900bfe748
|
|\ \
| | |
| | |
| | | |
Change-Id: Idddf7afb063109654664ecac252cf6be73125c20
|
| |\ \
| | |/
| | |
| | | |
Change-Id: Ia4d8719337f84927f96a162b97df8a8bc62630e1
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
not merge.
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
|