Differences between this implementation and the old one:
1. Resolves symbols/gdb based on device information (lunch
target is irrelevant)
2. Works with downloaded from build-server symbols
3. Does not require user to specify exe file - detects it automatically
Change-Id: I4e7ce0a51868634593a9f104fe3f2fa67b54ca9f
When WITH_DEXPREOPT=true is set, if we also set WITH_DEXPREOPT_PIC=true
then the build will generate position-independent OAT images.
This means that all the system applications no longer need to be
relocated into /data/dalvik-cache and this can achieve saving disk space
at the cost of slightly slower running code.
Bug: 18035729
Change-Id: Ifd517c842f48bf31568bf5ff56667298d422c2c0
The shell functions in this patch enable crashing processes with the core limit
set correctly to dump core in directory /cores. They do so by remounting the
root partition, which is RAM-backed, and by creating the 0777-chmodded /cores
under it. They also set the core file pattern in /proc/sys/kernel/core_pattern
to be /cores/core.%p, such that a core dump will have the crashing process' PID
appended to it. You enable core-dump generation once per boot, as follows:
coredump-setup
If a process does not have its core-size rlimit set (as most do not), you can
either set it manually by typing "adb shell prlimit <pid> 4 -1 -1", or by
typing coredump-enable <name>, e.g.
coredump-enable $(pid mediaserver)
Alternatively, you can cause a running process to dump core by sending it a
SIGSEGV via the shell function core <name>, e.g.:
core $(pid mediaserver)
Change-Id: Ib174e7ee95515fb9866fa6bf0d5b5bf23f3ec61b
Signed-off-by: Iliyan Malchev <malchev@google.com>
This assigns block device types as per device/generic/goldfish/fstab.goldfish.
Eliminates (permissive) avc: denied messages for fsck.
Change-Id: Ia72bdfb16975f051548b6b2c0636e4f907295789
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Allow apps running with any level to write to it.
Change-Id: I8fca1f377e14c624db5273bdacf8400addc6210d
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
- Added LOCAL_DEX_PREOPT_FLAGS to pass extra flags to dex2oat.
- Added macro add-product-dex-preopt-module-config to specify almost
arbitrary dex-preopt config/flags to modules in product
configuration:
$(call \
add-product-dex-preopt-module-config,<module_name_list>,<config_or_flags>)
How <config_or_flags> is interpreted is decided by
dex_preopt_odex_install.mk and dex2oat. For now if it's "disable" we
disable dexpreopt for the given modules; otherwise pass it to dex2oat as
command line flags.
- If there are multiple configs for the same module in the product
inheritance, the first takes precedence.
- Added PRODUCT_DEX_PREOPT_DEFAULT_FLAGS so you can specify default
dex2oat flags in product configuration.
- Added PRODUCT_DEX_PREOPT_BOOT_FLAGS to specify flags of building boot.oat.
Bug: 17791867
(cherry picked from commit 20ebd2ef08)
Change-Id: I2ee36892b40655c96837ee7a663dda1d25830878
- You can give a .aar as source file to a prebuilt static Java library
module. The build system will set up dependencies and rules to extract
classes.jar and other resource files.
- To build against a prebuilt AAR module, use:
LOCAL_STATIC_JAVA_AAR_LIBRARIES := <module names of aar prebuilt AARs>
The build system will set up rules to merge the library's
AndroidManifest.xml with the main AndroidManifest.xml, add the AAR's
resource dirs and link/merge the AAR's classes.jar.
Bug: 18168693
Change-Id: I478913d5d498f800b322529d7c2c2c0ea78425e5
Dmitriy Ivanov