If you rely on __builtin_trap, it's likely to use an illegal instruction,
which is a misleading way to abort. If we just call abort, it's more
immediately obvious that we've aborted.
Bug: 19644330
Change-Id: I63a962e4748aec7b019ea94b007593e478a3b61a
It hasn't worked in some time (it removes /data/dalvik-cache, which is
required by art), and if you're prepared to reboot (to let init put back
all the directories a working system needs) there are other ways to wipe
data (such as "fastboot format userdata reboot").
Bug: 19644330
Change-Id: Ib074ea21cc28409a506d66d75060bb4ad85539e2
I've been deliberately vague about the name of the readme because I want to
come back and switch to markdown, but that probably won't happen today.
Change-Id: I60651703709bbfd499227f882eb949396e8f4f6c
Fix host/sdk builds:
- Drop logprint from list of host products
- Drop <endian.h> for FAKE_LOG_DEVICE
Change-Id: I8aa854413ff6d809f0b04987cf913eb228e4213c
* changes:
logcat: remove dead label code
logcat: do not stop on unexpected log ID
Revert "logd: Add minimum time bucket statistics"
liblog: Instrument logging of logd write drops
We are changing the log read API to allow event notification
regarding logging system data loss. We would like these out
of band events to be reported.
Change-Id: I9e802113604d8cc0fc9adff0d1e014bbc40914fe
This forward port reverts
commit e457b74ce6
No longer as necessary once we add
liblog: Instrument logging of logd write drops
Although this provided an indication of how close statistically we
were to overloading logd it is simpler to understand fails thus to
hunt and peck a corrected value for /proc/sys/net/unix/max_dgram_qlen
Change-Id: I2b30e0fc30625a48fd11a12c2d2cc6a41f26226f
- If logger system is prostrated, send an event message with the
liblog tag from the associated UID and PID with a count of
dropped messages once logging is resumed.
- Added to the README a description of the error return values.
- Describe in the README the appropriate mitigations for dropped
messages.
- If the caller sees this message, then
/proc/sys/net/unix/max_dgram_qlen is likely too small
Change-Id: Iaf387b9e5e1b6aa93bebc7481f9e8353732e3229
Add a built-in command for loading verity state. If dm-verity
will be started in logging mode, trigger verity-logging.
Needs changes from
Ibb82953594d234f81ad21c40f524190b88e4ac8f
Change-Id: I5af4918f2f14fdd4d07f51c55837e08111fd3748
Add support for dm-verity modes and storing persistent state in
a location specified by the following properties:
ro.verity.state.location
ro.verity.state.offset
If these properties do not exist, dm-verity is always loaded in
EIO mode. If the properties do exist, but the location does not
have valid state data, dm-verity is loaded in RESTART mode. The
mode is updated to LOGGING if a dm-verity triggered restart has
occurred.
Change-Id: Ibb82953594d234f81ad21c40f524190b88e4ac8f
Currently, when verity is set up on a block device, the underlying
device is still accessible directly. Change the existing function
fs_set_blk_ro visible to other fs_mgr modules, change the behavior
to match the comment above the function definition, and call it to
disable write access to the block device when setting up verity.
Bug: 18609347
Change-Id: I7884175df15f9161174788d74d20a08e4cd472ca
