A future change will want the same stripping when looking for USB boot
devices. Move the stripping down to the helper.
This change is intended to be a no-op and just a reorganization.
Bug: 316324155
Test: See boot devices still found
Change-Id: I025d9d68fedf652055454cbd93e15f480b6056dd
We want to use the logic for FindPlatformDevice() in a future change
to look for devices that have USB parents. Break out a helper
function.
This change is intended to be a no-op and just a reorganization.
Bug: 316324155
Test: See boot devices still found
Change-Id: Ic5a57a89339c43dea1334644be9386637169c61c
Later code will want to use GetBlockDeviceInfo(), so factor it out to
a helper function. This change is intended to be a no-op.
Bug: 316324155
Test: Build & boot
Change-Id: If5d63f39efcd84a07eb8c6fa4f28bda45c4cbe5c
In GetBlockDeviceSymlinks() we may need to strip the
"/devices/platform/" or "/devices/" from a string. Use the helper
ConsumePrefix() to do this, which is more convenient and readable.
This change is intended to be a no-op and just a cleanup.
Bug: 316324155
Test: Build and boot
Change-Id: I1adb1906ec37ff8f6f505abc5f26e1e3b157e608
* changes:
init: Reorder GetBlockDeviceSymlinks() so FindDmDevice() is first
init: Add partition_uuid to Uevent
fs_mgr: Add getter for androidboot.boot_part_uuid
By moving FindDmDevice() it's easier to unify the code with the
IsBootDevice() function. In this case the order doesn't matter since
anything with the uevent path "/devices/virtual/block/dm-" (the only
devices FindDmDevice() looks at) won't match any of the other sections
of the if/then/else test.
Bug: 316324155
Test: Build & boot
Change-Id: I819eb60aa5077f0eb2c2f2783b152e43a52ba8b7
As of commit upstream Linux kernel commit 74f4a8dc0dd8 ("block: add
partition uuid into uevent as "PARTUUID""), it's easy to include the
partition UUID in the Uevent structure. Add it in so that other parts
of the init code can make decisions based on the partition UUID.
If this code is run on older kernels we'll never see the partition
UUID and it will be left blank.
Bug: 316324155
Test: Run w/ a newer kernel and see partition_uuid populated.
Change-Id: I48a52aa006c05023f7f1cc5cc0ab5c1f1ec37455
In order to make booting from some media types (like USB) more robust,
the bootloader will be extended to support passing the partition UUID
that it loaded the kernel from. It can pass this via kernel
commandline or via bootconfig. Add a way to get this.
Bug: 316324155
Test: Use the getter in a future change
Change-Id: Iab04742c0f2666db18dc48bcaaa2869eba405748
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
