All users have been moved to other, more suitable, interfaces.
Test: build
Merged-In: Ic4eb1f0ed6e35d8d6f7e63b80546f4e8bbe163e2
Change-Id: Ic4eb1f0ed6e35d8d6f7e63b80546f4e8bbe163e2
__android_logger_property_get_bool() has a clunky API and doesn't
belong in liblog, since a vast majority of liblog users will never
query this property.
Specifically
1) Replace with GetBoolProperty() when completely equivalent.
2) Remove checking if property values are 'eng' or 'svelte', since
there's no evidence that those values were ever used.
3) Remove checking 'persist.logd.statistics' and 'ro.logd.statistics',
since there's no evidence that those values were ever used.
4) Set ro.logd.kernel explicitly, so other processes don't need to
replicate the defaults that logd uses.
Test: build
Change-Id: I7c37af64ba7754e839185f46da66bf077f09d9c3
StagedInstallInternalTests contains test that verify staged installation
using adb commandline (e.g `adb install`) is working correctly.
Bug: 158314277
Test: atest --test-mapping system/core
Change-Id: Icc3bd464a91f31095316fbb85941e5e03089aaad
* changes:
init: Initiate other misc devices from BlockDevInitializer.
Allow snapuserd to be included in the initial ramdisk.
Add experimental daemon for handling dm-user requests.
An OEM asks for sub-second granularity, and that's most easily done if
we only have one timestamp generator. I'm not convinced sub-second
granularity is particularly useful myself, and I definitely don't think
that nanosecond resolution is meaningful but I do like this cleanup, and
if I'm going to use sub-second precision I may as well use the maximum
precision available to me.
Also reduce some duplication of code reading cmdline/comm.
Bug: https://issuetracker.google.com/161860597
Test: head /data/tombstones/*
Change-Id: I035ecfd4a3338ccd84dae0ef973a998a7c7c5056
If the system partition has been updated and _PATH_DEFPATH has a new
value, then we must set $PATH in second stage init to take on the new
value, as well as having set it in first stage init.
Bug: 160210288
Test: build
Change-Id: I18765709dc9bff9379b0ae39272199cf74a79d2f
The serialized log buffer along with compression results in:
* ~3.5x more logs than chatty
* Less CPU usage
* Less memory usage
* Equivalent log range
Also, delete tests that assume that the device logd implementation is
chatty. There are actual unit tests for this same behavior that don't
rely on the device logd.
Test: serialized log buffer is used
Change-Id: Ie12898617429a75b6caff92725aa7145650f8fc6
Updating language to comply with Android’s inclusive language guidance.
See https://source.android.com/setup/contribute/respectful-code for reference.
Bug: 161896447
Test: Trivial changes
Change-Id: Ia84d47930b5d9ca4a5f7c809777c886bece4f512
* changes:
Include memory tags in memory dump output.
Adjust conditions for dumping the memory around a register.
Statically link libminijail to debuggerd_test.
Tags appear in the addresses printed in the memory dump, which seems
like a reasonable place to put them because tagged addresses will
also appear in other places in the tombstone, such as registers and
the fault address.
Bug: 135772972
Change-Id: I52da338347ff6b7503cf5ac80763c540695dc061
Previously, we would do a simple bounds check before deciding
whether to dump the memory around a register. On 64-bit platforms,
the register's value was required to be less than (4 << 60). However,
after stripping tags on AArch64 as part of r.android.com/1365229, all
pointer values became less than (4 << 60), so the check became useless
for filtering out invalid pointers. As a result, we would attempt to
dump memory for all registers, which for a register not containing
a valid pointer would typically consist of 16 lines of dashes.
One possible fix may be to replace the constant (4 << 60) with the
process's actual address space limit (known as TASK_SIZE inside the
kernel; typically 39 bits on AArch64 and 48 bits on x86_64), but the
kernel provides no API for retrieving a process's TASK_SIZE value. We
could guess it by looking at for example the highest bit set in the
value of getauxval(AT_EXECFN), which points to an address on the stack
which typically is mapped at the end of the address space on program
startup, but at least on AArch64 it is possible to dynamically extend
TASK_SIZE at runtime by providing a hint to mmap(), so this is not
always sufficient.
Instead, it seems best to remove most of the early bounds check, and
simply issue ptrace() calls for each register value, bailing out of
the entire output if none of the calls ended up succeeding. This also
has the nice side effect of avoiding 16 lines of noise per register
whose value looks like a pointer but actually points to unmapped
memory. We still retain part of the bounds check in order to avoid
integer overflow during the dump (including overflows into the tag
part of the address on architectures that support tagging).
Bug: 154272452
Change-Id: I94e4b7124b7735b92fd83a49c80ebded3483cd4e
We do not install a 32-bit version of libminijail to 64/32 devices,
which means that "atest -a debuggerd_test" always fails on 32-bit.
Fix it by statically linking libminijail.
Change-Id: I1e5610d1353b4f5b718c1259825421c0c07d7c24
Presently, within ReadUevent(), true is returned for a successful case
as well as for the case where we read an invalid uevent (overflowed
buffer)where the Uevent object is not cleared, and the caller calls the
callback (with the earlier stored uevent object),leading to duplicate
firmware loading.
Uevent uevent;
while (ReadUevent(&uevent)) {
if (callback(uevent) == ListenerAction::kStop) return;
}
Scenario:
1. Proper Uevent received and callback is called (firmware loading
is triggered).
2. Overflowed uevent is received as part of the same ReadUevent session,
ReadUevent() returns true, but the uevent object is not cleared and
still has earlier event values.
3. Callback is called again, leading to duplicate firmware load.
Handle it by adding explicit return codes to let the caller know if the
uevent read is invalid, and the caller can ignore it and read
further pending uevents.
Bug: 161580785
Change-Id: I09e80052337fd1495b968dc02ecff5ceb683da18
The previous size, 2048, is only the size of the 'environment' for the
uevent message, but doesn't include the <action>@<dev path> portion.
The <action> portion has a max length < 10, but the <dev path> portion
is unbounded.
8192 should be plenty to capture all of these parameters.
Bug: 161580785
Test: ueventd still works
Change-Id: I6de6fd3a444ac91b3b4df154097abde3696e21b3
Tom Cherry