1. delete-logical-partition was deleted
- After merge "Don't require bootloader fastboot for VTS compliance." commit, delete-logical-partition sequence was deleted in LogicalPartitionCompliance test. "create-logical-partition failed" is occurred when run vts fastbootverification module. So restore this sequence.
Test: run vts -m VtsFastbootVerification
Bug: 153913610
Signed-off-by: Yongcheol LEE <yongcheol09.lee@lge.com>
Change-Id: I00366b281eafa5677b0941419a86f2702fb3484b
Merged-In: I00366b281eafa5677b0941419a86f2702fb3484b
This test is repeatedly seen to be flaky. Disable it until we can run
tests against a dedicated logd instance.
Bug: 155146087
Test: logd-unit-tests
Merged-In: I0cd953955f613e40d17df73f70543d7d2f0925b6
Change-Id: I0cd953955f613e40d17df73f70543d7d2f0925b6
(cherry picked from commit 25a4d708e2)
The StringPrintf one is heavily used and brings the overhead versus
fmtlib down to 1.5x rather than 2x. I don't have a convenient benchmark
for the other two.
Test: libbase tests & benchmarks
Bug: http://b/155324241
Change-Id: I9e704a360846d5520c53f668e7c315b0c0ea55f8
(cherry picked from commit 8c253d4d42)
When the subcontext code was redone to allow only one subcontext
(vendor_init), the code for restarting it and for terminating it
during shutdown was not updated, resulting in it not working.
Bug: 155203339
Test: kill subcontext init and notice it restart
Test: subcontext init stops during shutdown
Merged-In: Ib77f59d1e7be0ffcfd3f31c8450dc022c20bb322
Change-Id: Ib77f59d1e7be0ffcfd3f31c8450dc022c20bb322
(cherry picked from commit e3e77d382f)
These historically used atomics to manage their lifetime. They were
unfortunately unsafe and later replace with a RwLock. A lock is
also problematic as it is too heavy weight for the typical use case
and implies that logging is neither async nor fork safe.
This change returns us to using atomics with two key changes:
1) compare_exchange_strong() is used instead of atomic_exchange().
The latter has a race condition where a separate thread could have
read the atomic value into a register, while the thread performing
the atomic_exchange closes that FD. The new code only changes the
FD in the atomic if it is uninitialized.
2) Using the fact that DGRAM sockets can have connect() called on them
multiple times, it uses a single logd_socket for the duration of
the program.
These sockets are thread/async/fork safely created and accessed.
The one caveat is __android_log_close(), which is intended only to be
used by zygote when it is single threaded and is therefore not thread
safe. It will close this socket and reset the underlying variable,
such that the next log message will go through the above
initialization.
Bug: 65062446
Test: logging works, logging unit tests
Test: new unit test
Merged-In: Ia4dbf7479dbe50683d124558ab2f83bff53b8f5f
Change-Id: Ia4dbf7479dbe50683d124558ab2f83bff53b8f5f
(cherry picked from commit 7acfba274c)
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
For now setting min_sdk_version doesn't change build outputs.
But build-time checks will be added soon.
Bug: 152655956
Test: m
Merged-In: If4ff1fbc31e5be3f5611a4713ae4032aba4ee5f2
Change-Id: If4ff1fbc31e5be3f5611a4713ae4032aba4ee5f2
(cherry picked from commit 3851f7e836)
Previously, we would split messages by line and call the logger
function for each line. We would hold a lock during this, to ensure
that multiple threads would not interleave their messages.
There are a few problems with this approach:
1) Using a lock is not efficient and is not fork safe
2) With APEX, there is one lock per instance of libbase, so we must
move the lock to a location where all instances can access it, or
perform the line splitting in a way that does not require the lock.
To solve these issues, we reimagine line splitting.
1) We move the lock out of the LogMessage::~LogMessage() and make it
the logger's responsibility to split lines, giving the logger the
option to lock or not.
2) We do not need any locks at all for StderrLogger.
Instead, we generate a single string that contains all of the lines
with their appropriate log header. A single write() call is used
to output this at once.
3) Logd handles log messages with newlines correctly, however it only
accepts up to a maximum size of log message. Therefore we
separate the incoming log message into chunks, delimited by new
lines, up to that maximum size, and send each of those to logd.
Note that this is the strategy used in
android.util.Log.printlns().
This should solve a majority of use cases, since the maximum size
that logd accepts is nearly 4K, while remaining lock free.
If interleaving messages absolutely must be avoided, a lock can
still be used given 1) above.
Bug: 65062446
Bug: 153824050
Test: logging, particularly multi-line stack traces, show correctly
Test: existing and new unit tests
Change-Id: Id0cb5669bee7f912da1e17f7010f0ee4c93be1e3
(cherry picked from commit 36d31c530d)
These shared_libs are missing from /system/lib/ on 64-bit devices.
Test: Build, install, and run 32bit vts_libsnapshot_test.
Bug: 154115505
Change-Id: Iaf2014748546a055d35e4fe0e24969eef13db7fa
Debugging information for addressing the reason why the process stops as
a zombie, can be found by observing the call trace and running status of
threads in thread group of the zombie process.
Bug: 154667692
Change-Id: Icd7fa2161e88b08fd5ce0d5dc3a3790ed4ac02d1
(cherry picked from commit e5a09d8da5)
Fixes:
system/core/base/include/android-base/result.h:
133:94: warning: potentially unintended semicolon [bugprone-suspicious-semicolon]
Bernie says:
it probably means that there's a parser bug with "if constexpr"
maybe, at static analysis pass, the "if constexpr" was evaluated to false,
and the compiler removed the "then" block from the AST...
... and then it thought you had written it that way :-)
https://reviews.llvm.org/D46027
Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I25df8eeca4ec06b3180c1cd21b554fc583c5581a
Merged-In: I25df8eeca4ec06b3180c1cd21b554fc583c5581a
Fixes:
system/core/base/include/android-base/expected.h:
186:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
195:22: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
611:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
To quote Tom Cherry:
I'm a bit confused at what's happening there.
I think it's a bug in the linter itself.
The general solution to that problem is a heavy dose of std::enable_if<>
to hide that constructor when the 'U' parameter is the same class,
but those constructors do have the necessarily std::enable_if<> lines.
I think the problem is that the linter doesn't check that the macro
_ENABLE_IF() expands into std::enable_if<>. Let me try explicitly
putting the std::enable_if<> instead of the macro and check if it
goes away.
I expanded the macro but the linter doesn't still doesn't accept
the format of `std::enable_if_t<(condition_here)>* = nullptr`.
It does accept `typename Enable = std::enable_if_t<(condition_here), void>`,
which is the syntax used on their example here:
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-forwarding-reference-overload.html.
That latter syntax doesn't work for us.
See the Notes section on
https://en.cppreference.com/w/cpp/types/enable_if
as a reference for why what we're doing is correct.
Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I493ff19208cc104f5f176a36ec23fbcb914388f7
Merged-In: I493ff19208cc104f5f176a36ec23fbcb914388f7
commit 5327d931ac ("logcatd: fallocate and fadvise to logcat files")
introduced pinning log files in order to avoid f2fs fragmentation.
But, logcatd does not guarantee to write data within fallocated 2MB space.
So, we can see some bytes written beyond 2MB boundary which results in
pinning small chunks across the filesystem. This makes F2FS GC have to unset
the pinning blocks via GC loop. If this happens during checkpoint=disable
at booting time, we can see long delay to mount /data accordingly.
Bug: 136483670
Bug: 137180754
Bug: 149418646
Fixes: 5327d931ac ("logcatd: fallocate and fadvise to logcat files")
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I986221d6d1da9b8e46e63d1be98ddf0ce4cb099f
Some system services (e.g. SoundTriggerMiddleware) assume that
whenever they start, the audio HAL is in its default (reset) state.
init.rc scripts tie the lifetimes of the audio HAL and system
processes, but when using stop/start this is not the case, and this
may cause spurious crashes in this case.
stop/start is apparently being relied on in some test infrastructure,
so this change is needed to avoid causing problems for those systems
or false detection of problems, which are not actually present in
production.
Bug: 154029444
Test: Manually verify that the audio HAL is stopped on
'adb shell stop', restarted on 'adb shell start' and that the
system boots correctly after.
Change-Id: I39878b978b47a169c4fe446c43d7347809d15e06
There are no libbase users that require thread safety for SetLogger,
SetAborter, or SetDefaultTag and the equivalent liblog symbols are
unreleased, thus have effectively no users.
It is hard to imagine a scenario where a user would need to use these
functions in a multi-threaded program, and it is unreasonable for all
users to pay for thread safety for a vast minority of potential
scenarios. Thread safety implies less efficiency and necessarily means
that these functions are neither fork safe nor async-signal safe, and
we do have users who depend on those characteristics.
It is always possible for users of the non-thread safe versions of
these functions to build thread safe versions on top of them. For
example, if a user needs a thread safe SetLogger(), they can use the
non-thread safe SetLogger at the start of their program to register a
logger that has its own lock and pointer to a logger function.
Bug: 119867234
Test: logging unit tests
Change-Id: I8afffec1a6957d3bda95502a4c59493e0c5049ce
(cherry picked from commit 53d301c29b)
create both 32 and 64 bit variants
fixes libstatssocket_test for 32 bit devices
Bug: 154652564
Test: make mts, adb push, adb shell all 4 tests
Change-Id: Ia6b51686c06e786b38cb3713315977533f1bb819
The "OwnsSector" tests did not work if one range fit completely inside
another range. The new OverlapsWith() methods address this case.
Bug: 154277287
Bug: 154646936
Test: liblp_test gtests
Change-Id: I1a59069db4ffe4f13c45963c4847cff7b3dd3dfc
- Cherry pick of aosp/1228482
As of aosp/1224611, there is a new step in the preparation of APEXes
where init calls back into apexd after DE user data is unencrypted to
allow DE apex data to be snapshotted or restored.
aosp/1228581 introduces a new apexd.status value of "activated" that
is set once APEXes are activated but before this snapshot has occurred.
init may execute "perform_apex_config" once this has occurred, so this
CL changes init to wait for "activated" rather than "ready" before
doing this.
Bug: 148672144
Test: build & flash, check boot completes and check in logs that init
waits on the correct status value.
Merged-In: I339580bf593d3b09a5dff749ac2a5d1952bcb210
Change-Id: I71b62c9dd2f7951811606002f38612784d3d9086
This will allow Phonesky to read APEXes under /data/apex/active.
Test: adb shell su 10114 dd if=/data/apex/active/com.android.tzdata@300000000.apex of=/dev/null
Bug: 154635217
Change-Id: I5278897413ca0e32aed9d1c7f82e48138bc51404
* changes:
adbd: add apex_available and visibility for internal libs.
Set apex_available property
Set apex_available property
Set apex_available property
Set apex_available property
