When mounting fstab entries it is practical to be able to specify
for example LABEL=data instead of a specific block device.
This is particularly important for the new Android Emulator code base,
which uses virtio block devices for the various partitions
(system,data,cache), because there is no defined ordering between the
way the filesystems are specified to the emulator and how they are
enumerated by the android kernel as /dev/vdX.
Change-Id: I7aef95f12e8f7b02ac2e33804ba7897fdcb9ad7f
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Due to a typo, the --no-rebind option never worked (it always failed).
The root of the problem was that the client was sending on the wire
a command like:
host:forward:norebind::tcp:<port>;tcp:<port>
^^
Instead of:
host:forward:norebind:tcp:<port>;tcp:<port>
^
Note the erroneous double-column.
The fix is local to the adb client and thus doesn't require a new
version of the server or guest adbd on the device-side.
This also fixes 'adb reverse --no-rebind'.
See https://code.google.com/p/chromium/issues/detail?id=451109
Change-Id: I680fd432b5470072f6a9968ca32a7f90c600ac68
LOCAL_FORCE_STATIC_EXECUTABLE was not working properly for clang
because -Bstatic was ignored by clang. We can now enable clang
for init after the -static flag is added to link static executable
files in build/core/definitions.mk.
BUG: 18008984
Change-Id: I3f361b83c1e0b313914603dff33fd090cd3b116a
Delay mounting encryptable but unencrypted volumes until we can
check the ro.vold.forceencrypt flag, then optionally encrypt.
Requires matching vold change from
https://googleplex-android-review.git.corp.google.com/#/c/615309/
Bug: 18764230
Change-Id: If22008be8de6a4f3216b349f81ace49be1730314
On 64 bit systems, calls to dump_backtrace_to_file or dump_tombstone
try and directly contact the correct debuggerd (32 bit vs 64 bit)
by reading the elf information for the executable.
Unfortunately, system_server makes a call to dump_backtrace_to_file
and it doesn't have permissions to read the executable data, so it
defaults to always contacting the 64 bit debuggerd.
This CL changes the code so that all dump requests go to the 64 bit
debuggerd, which reads the elf information and redirects requests for
32 bit processes to the 32 bit debuggerd.
Testing:
- Forced the watchdog code in system_server to dump stacks and
verified that all native stacks are dumped correctly.
- Verified that dumpstate and bugreport still properly dump the native
processes on a 64 bit and 32 bit system.
- Intentionally forced the 64 bit to 32 bit redirect to write only a
byte at a time and verified there are no errors, and no dropped data.
- Used debuggerd and debuggerd64 to dump 32 bit and 64 bit processes
seemlessly.
- Used debuggerd on a 32 bit system to dump native stacks.
Bug: https://code.google.com/p/android/issues/detail?id=97024
Change-Id: Ie01945153bdc1c4ded696c7334b61d58575314d1
When mounting fstab entries it is practical to be able to specify
for example LABEL=data instead of a specific block device.
This is particularly important for the new Android Emulator code base,
which uses virtio block devices for the various partitions
(system,data,cache), because there is no defined ordering between the
way the filesystems are specified to the emulator and how they are
enumerated by the android kernel as /dev/vdX.
Change-Id: I12c3db0ba6a515dc8e917e0349afd257888d3aef
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Under some unknown circumstances, debuggerd could become unresponsive.
If you try and take a bugreport during this time, it will hang forever.
Adding functions that have a timeout will allow dumpstate to stop if
dumping is taking too long.
Bug: 18766581
(cherry picked from commit 5f2ff6a910)
Change-Id: I39e8e9c60209e3ef9efac795fedb8e1edce2bd3e
