Revert submission 3334193-no-llndk-versioning
Reason for revert: Droidmonitor created revert due to b/378038995. Will be verifying through ABTD before submission.
Reverted changes: /q/submissionid:3334193-no-llndk-versioning
Change-Id: Id8d85be1930bef68f94cee66a0fe29278de48d64
Versioned LLNDK symbols are guarded with __builtin_available.
Bug: 362658565
Test: m --no-skip-soong-tests
Change-Id: I0fb3bc87b74da62b8a8fba0c5bb6a3373e6a55dc
If server disconnects, then handle the empty response.
Bug: 377068272
Test: Full OTA
Change-Id: Ic48204c457ef924ba9a3c1ae84a3317fb1ccda04
Signed-off-by: Akilesh Kailash <akailash@google.com>
This reverts commit de6707df0c.
Reason for revert: changing code without modifying JSON file now
Original description:
To improve input latency, set the critical input threads to RT priority.
This will use RT priority on AOSP devices by default. OEMs can still
choose to customize what "input policy" means for their device, which
may not necessarily mean RT.
For example, on device with multiple small / big cores, input task
affinity could be changed to prioritize big cores + higher CPU frequency
/ voltage, but still keep the standard / default input thread priority.
With this patch, I'm finding that sometimes, one of the critical input
threads has priority 100 instead of the expected 98. Still looking into
that specific issue, but the issue is already present with the existing
"input policy" code.
Bug: 330719044
Flag: com.android.input.flags.enable_input_policy_profile
Test: took perfetto trace and checked the priority on InputDispatcher
and InputReader threads.
Change-Id: I3dabf4da0398324cf542e701c103551343b883cf
This reverts commit 930f77b02c.
Reason for revert: DroidMonitor: Potential culprit for http://b/376665573 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I9b9914703946f1eb4e40e779aa9cb5154ea108d3
This reverts commit 5bfb93678f.
Reason for revert: b/376468452 and trusty boot up on arm64. This CL is causing a lot of troubles (now only on emulator, but may affect more devices in field) and shall be reverted. Desktop team will handle support for selecting single boot source (while having more than one) as part of boot_part_uuid support (at aosp/3318438).
Change-Id: I2804c119631f592d0862f3472ffe18dbb23b17e5
This patch teaches pbtombstone to use llvm-symbolizer to symbolize
stack traces and augment the protobuf tombstones with the symbol
information, before printing tombstones with the symbolized stack
traces included.
The main advantage of adding this information to the tombstone
as opposed to having developers use the stack tool is that stack
does not print all of the information in the original tombstone,
which means that both reports may be required to understand a crash.
Furthermore, stack traces printed by stack are not correlated with
the stack traces in the tombstone, making the report harder to read,
especially with GWP-ASan and MTE which may produce multiple stack
traces for the crashing thread.
Although we could teach stack to print more information, this would
continue to be fragile because stack relies on parsing textual
tombstones. Switching stack to read proto tombstones would be
tantamount to a full rewrite and would require duplicating the C++
proto-to-text logic that we already have in Python. It seems better
to reuse the C++ code for the proto-based symbolization tool.
llvm-symbolizer will look up the symbol files by build ID using a
.build-id directory following the standard here:
https://fedoraproject.org/wiki/RolandMcGrath/BuildID
It will look for .build-id directories under paths specified with
--debug-file-directory, which pbtombstone will pass through to
llvm-symbolizer using its own --debug-file-directory flag. The
intent is that tools for platform developers will pass the flag
--debug-file-directory $ANDROID_PRODUCT_OUT/symbols to pbtombstone.
Soong will start creating .build-id under symbols after a corresponding
Soong CL lands.
Bug: 328531087
Change-Id: Ia4676821cf980c69487cf11aefa2a02dc0c1626f
This is preparation for the next patch, which adds host-side
symbolization capabilities to pbtombstone.
Bug: 328531087
Change-Id: Id5813ae6b121af784643b1ed76084e49fdca118b
Sometimes read returns fewer bytes than requested. read() only read at
most 0x7ffff000 bytes.
Bug: 376247649
Test: manual, make mkbootfs, mkbootfs out/target/product../VENDOR_BOOT
Change-Id: I8cbbae40c5f5c6c54d19bf77e9a801ed3390ed48
This reverts commit 1df3536b95.
Previous land got reverted because of selinux denial, which is
already taken care of in aosp/3314877
Reason for revert: b/349507086
Change-Id: Id642b4d8726c72f324e369d8506c78eacea331e3
To organize it under trusty and distinguish it from
Widevine VM.
Bug: 368502791
Test: launch_cvd --secure_hals=guest_keymint_trusty_insecure
Test: atest VtsAidlSharedSecretTargetTest
Change-Id: I48e43b9709e59b1cb9e1ba9113d5ef894469f485
To improve input latency, set the critical input threads to RT priority.
This will use RT priority on AOSP devices by default. OEMs can still
choose to customize what "input policy" means for their device, which
may not necessarily mean RT.
For example, on device with multiple small / big cores, input task
affinity could be changed to prioritize big cores + higher CPU frequency
/ voltage, but still keep the standard / default input thread priority.
With this patch, I'm finding that sometimes, one of the critical input
threads has priority 100 instead of the expected 98. Still looking into
that specific issue, but the issue is already present with the existing
"input policy" code.
Bug: 330719044
Flag: com.android.input.flags.enable_input_policy_profile
Test: took perfetto trace and checked the priority on InputDispatcher
and InputReader threads.
Change-Id: I75b6a726f0d066f16bdec26f6cf90721479d17ff
This removes the error log when apexd-bootstrap starts:
cutils-trace: Error opening trace file: No such file or directory (2)
Bug: 376150518
Test: boot-time trace shows apexd-bootstrap
see https://source.android.com/docs/core/perf/boot-times#systrace
Change-Id: I5feaece50663a602b61377cee034060fd30217f9
This appears to have been due to the use of prctl, which apparently
caused issues for mac builds. Now that use of prctl has been removed, it
doesn't look like we need this anymore.
Fixes: 075008174 ("libprocessgroup: Remove prctl interface for setting timer slack")
Test: m
Bug: 372498744
Change-Id: I8a43951f30d7dd838591a8ba225d712742d7cd4a
