via a new definition LOCAL_ABS_MANIFEST_FILE. The existing
LOCAL_MANIFEST_FILE variable will also be supported.
(Necessary if manifests are being programmatically generated in the
intermediates directory)
Change-Id: I77a8eb1b8040b966b944464281d00c161ff34d3c
* BOARD_KERNEL_CMDLINE_FACTORY_BOOT can be set to
add kernel commandline items to the factory ramdisk,
such as fiq_debugger.console_enable=Y
Change-Id: Iee4060b96eaeecc517975c56342fd5445b1feabf
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>
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: 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 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
Set "LOCAL_DEX_PREOPT := nostripping" to do dex-preopt while not strip
the classes.dex.
Bug: 5396625 5502338
Change-Id: Ie8dea4414ebeefeae89c6433b246faea27baa5e7
Before, if a module had several proto source files,
they would all be compiled in a single invocation
of aprotoc. If any of the files imported one of the
other files, you got an aprotoc error about duplicates.
And if you removed the files that were imported
from the list of source files, no Java code
would be generated for the imported files,
causing a Java compile time error.
This changes compiles each proto file separately, which
avoids both of the problems above. It's slightly more
inefficient, but aprotoc is really fast.
Change-Id: I7bd8092ec2953c20269367a1c68ff84acceea3be
To use the new aapt --preferred-configurations option. For use with Prime
to be able to strip everything but xhdpi density bitmaps selectively,
not stripping when this would result in no data for the resource.
Change-Id: I4e1012929b8f9b0b1e79c06496647f69661ba1f2
To package libstlport_shared.so, use the following syntax in the app
module definition:
LOCAL_NDK_STL_VARIANT := stlport_shared
LOCAL_NDK_VERSION := <num>
The rationale behind is:
The NDK prebiult libstlport_shared.so is intentionally different from
the system libstlport.so.
Essentially they are slightly different versions of the library so
shouldn't be mixed up.
libstlport.so is used by the system, but not exposed by the NDK, it is
routinely tweaked in various ways between platform releases, and there
is no guarantee that its ABI is stable, or that it will not be replaced
by something else in the future.
libstlport_shared.so is typically distributed with application packages,
and should not be part of the system.
Change-Id: I72c9911781f7d8402687e9891f3f605f3a60be22
Joe Onorato