There was an email thread about this recently, and I've been asked many
times.
For instance, if this error wasn't attributed, denials a service is
hitting would be attributed to init, and that's a recipe for disaster.
Secondarily, thinking about SELinux whenever you write a new service is
good.
Bug: N/A
Test: N/A
Change-Id: Ib9d2c5d8947375a0d4c33ecf3d075caef6b41f70
* changes:
logd: don't send logs before the start time on the first flushTo()
Revert "logd: drop mSequence from LogBufferElement"
Revert "logd: regression in handling watermark boundary."
Revert "logd: logcat --clear respect pruneMargin"
logd: wait for timeout via CLOCK_MONOTONIC
Revert "logd: wakeup wrap timeout if realtime changes drastically"
logd: do not attempt to sort log messages by time
Logs in logd's buffer are not in time order.
If a client connects and requests logs from a given timestamp, we
start at the beginning of the buffer and find the first entry that has
happened since that timestamp and use its sequence number to flush
logs from. This ensures that we get all logs accumulated in the
buffer since that time stamp and not just the most recent.
However there may be other logs in the buffer that happened before the
timestamp and have likely been already served to the client, therefore
we do not flush those.
We only do this for the first flush, since once we have flushed all of
the logs in the buffer, if another log comes in with a timestamp
earlier than the requested timestamp, it must be out of order and not
seen yet, since it is new even to logd.
Note! This is still broken. There is a race that logs before the
timestamp may come in out of order since the last time the client
disconnected and before it reconnects. The *only* solution to this
problem is that clients need to request logs after a given sequence
number. That will be done as a separate liblog API change, while
these changes put in the ground work to make that possible.
Note 2: the security log implementation, which is one of the most
important users of this, already captures logs from seconds before the
last previous log to work around issues with timestamps. That
workaround mitigates the above issue.
Test: logs work with logcat -t
Change-Id: If1a62a90c082d98c4cf2eb5c92ae3b7e89850cf2
This reverts commit 5a34d6ea43.
There is a long standing bug that logd will leak memory during its
prune process if the time on the device changes significantly forwards
then backwards. This is due to using the timestamp of each log
message to determine what log messages are yet to be processed by a
reader thread.
Various attempts have been made to rectify this, but the only solution
that safely fixes this issue is to go back to using sequence numbers
on the log messages.
Bug: 64675203
Bug: 77971811
Bug: 149340579
Bug: 150923384
Test: logcat output looks sane
Change-Id: Ibce79cf184eb29a4914f3e42a8cb2868d04dc165
This reverts commit 0878a7c167.
This is a partial revert of the above commit. It simply removes
pruneMargin from these calculations since it is going away.
Bug: 149340579
Test: --clear works well
Change-Id: I1763be56fae7052058a800fad3b295c73cdcadf6
/sys/class/power_supply/*/current_now should return uA and the HAL
expects uA too.
Test: VtsHalHealthV2_0TargetTest
Bug: 136717180
Change-Id: I675be1ae645413b9494af4a5d49955aad5bd4f2e
Crc calculation shows up in the profiler in 2-5% range, and is
never currently validated. Let's disable it for good.
For a well-compressible test data the difference is even nicer:
Benchmark Time CPU Iteration
------------------------------------------------------------------
ziparchive-benchmarks:
before:
#ExtractEntry/2 1943244 ns 1926758 ns 375
#ExtractEntry/16 1877295 ns 1867049 ns 375
#ExtractEntry/1024 1888772 ns 1879976 ns 373
after:
#ExtractEntry/2 817003 ns 812870 ns 874
#ExtractEntry/16 814029 ns 809813 ns 875
#ExtractEntry/1024 804904 ns 800972 ns 879
Bug: 153392568
Test: atest, manual
Change-Id: I917abecab01301f1d09a5bf3b542d24b3875e359
This test is killing critical device services, and if it runs
repeatedly or some of the critical services have already died, it'll
force the device to reboot again and potentially consider the test a
failure.
This forces the test to reboot first, so that it is in a fresh state and
we can avoid this type of flake on the device.
Bug: 153444614
Test: atest init_kill_services_test
Change-Id: Ia81a319af1d209f58e70f824bb8eb7f11973637c
There are well known issues with CLOCK_REALTIME jumping drastically.
Test: --wrap works successfully
Change-Id: I5676274783ac9aa9374d2b9254e0109d883cc5a8
This reverts commit 5e001776f4.
The next commit will use CLOCK_MONOTONIC for the timeout, so changes
to CLOCK_REALTIME will no longer be an issue.
Test: logcat output looks sane
Change-Id: I84e5b2db3c25ea6a7024557dba7fa6cc8c9237e5
Sorting does not work in all cases:
* It only sorts messages up to 5 seconds backwards in time
* CLOCK_REALTIME, which is used as the time that is sorted, can jump
drastically
* Buffers are not sorted if there is a reader holding a region lock
Removing sorting entirely will give more consistent behavior from
logd.
Test: logcat still seems sane
Change-Id: I0923ab2fb377cda941c1e4972689df46f395ac99
The marked library(ies) were available to the APEXes via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Bug: 150999716
Test: m
Change-Id: I8fd2a3c9b69454c6018c72f5198898bc90dc4d0d
The marked library(ies) were available to the APEXes via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Bug: 150999716
Test: m
Change-Id: Id08058f3105463558c6c82298344a33af0efb2d3
If the Dex file we're trying to examine is already within the unwinder's
address space, we don't need to load it from disk or copy it across
processes.
This avoids using up virtual address space to map in dex files, and
also should be a bit faster to read since it won't go out to the file.
Patch by Chris Sarbora
Test: Ran new unit tests.
Test: Ran 137-cfi art test.
Change-Id: I949457856f051cca11b9020e9da3a41bbf6e5c8e
We don't actually need to extract the empty entries. Since the old
code support extracting the empty entry to a empty buffer, add the
support back in ExtractToMemory.
Bug: 153393683
Test: unittests pass
Change-Id: Idb9f0f4e6e4ffd4b44b80ddd3f54069bb7cedd7b
Bug: 151896491
Test: local build
Exempt-From-Owner-Approval: This CL moves all tests in vts-core to vts.
It won't change test logic or behavior.
Change-Id: I24779951257ce37fc18929f214d3cf5f76c23a19
Merged-In: I24779951257ce37fc18929f214d3cf5f76c23a19
This reverts commit bfe3dac36d.
This seems to be correlated with an increase in the rate of devices
going offline. Revert it to see if failure rates improve.
Bug: http://b/150863651
Test: treehugger
Change-Id: Ia6163fd9e31d2bf812628e028249662594ac2024
Use realpath as a canonical representation of block devices. This makes
it easier to reason about block devices. This also fixes a bug, in which
fs_mgr_get_mounted_entry_for_userdata didn't properly work on devices
that don't support metadata encryption.
Test: atest CtsFsMgrTestCases
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 153363818
Change-Id: I139c2be46336a632bbaee86667019c075d7de814
In the post-apocalypse, it's increasingly common for people to use ssh
port forwarding to use an adb client with a remote adb server. This
results in `adb kill-server` being catastrophic, because the client has
no way of restarting the server on the other end. Android Studio in
particular has an unforunate habit of trying to manage adb's life cycle
such that starting or exiting Studio will result in a kill-server.
Add the ADB_REJECT_KILL_SERVER environment variable which ignores
kill-server, to make this scenario a bit better.
Bug: http://b/152251952
Test: ADB_REJECT_KILL_SERVER=1 adb start-server; adb kill-server
Change-Id: I5533a6dcbdb9220526a6fcf9ca31d9fcef1cec17
In recovery mode, load modules from modules.load.recovery if it
exists. Otherwise load from modules.load as usual.
Change-Id: I7636bb5958ed10ae9a66015f04f168129618272f
Also switch to #pragma once and s/__inline__/inline/g for consistency.
There are a handful of inlines that are missing static, which seems like
a bug, but I've left those for now.
Bug: http://b/153328340
Test: treehugger
Change-Id: I2353215c0a8a6154ce8b39ecde022b282f5c0cb9
To make it easier to support disk formats created using old versions
of dm-default-key with new kernels, stop checking the kernel module
version; instead, the caller decides whether to use the old or new
options format.
Bug: 150761030
Test: crosshatch and cuttlefish boot normally; cuttlefish
fails with "default-key: Not enough arguments" as expected when
option is set to 1
Change-Id: I810bb7e085b9b8648858de1a02165162d1fd163e
We are stating that these structures will be stable, so include them
in the documentation directly.
Bug: 152466437
Test: n/a
Change-Id: I52a05f61163aa35b99869d722284ff3f98d7f010
This cl supports the parsing and extraction of the zip entry who
has a large size than UINT32_MAX. Also add a few checks in the
entry writers to make sure callers have enough space for extraction.
As many users of the library assume the entry size to be 32 bits long,
we keep the 32 bit ZipEntry. We also keep the functions that expect
the 32 bit ZipEntry in the public header file. These 32 bit wrappers
could be removed later once all users recognize the 64 bit ZipEntry.
Bug: 150900468
Test: unit tests pass
Change-Id: Ia6760638ccf51e97dbef6bd55dff352f1e7ce816
Add VTS10 variant of vts_libsnapshot_test so that
it can be added to vts-kernel test.
Bug: 142513589
Test: vts10-tradefed run vts-kernel -m VtsLibnsapshotTest
Change-Id: I4e2516b94d84acb16f595aab87dd3c0cadad6166
