-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRDQNE1cO+UXoOBCWTorT+BmrEOeAUCZ8epjwAKCRDorT+BmrEO
eGPtAJ4xkVvM0OmK/dZBwdVVDMjKroC/zACaAsDXpFeOe6kT2WhEkvc6MqpfuNQ=
=5OoV
-----END PGP SIGNATURE-----
gpgsig -----BEGIN SSH SIGNATURE-----
U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgPpdpjxPACTIhnlvYz0GM4BR7FJ
+rYv3jMbfxNKD3JvcAAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5
AAAAQCn8sR4oKubEOLtjfwngAI9k+KVB6e2XzmS6vwsN1oRV3O7k4oSXLnNH+sHPQXQ6lX
4cqrmxPKTONclXrV4Ggw8=
-----END SSH SIGNATURE-----
Merge tag 'android-15.0.0_r20' into staging/lineage-22.2_merge-android-15.0.0_r20
Android 15.0.0 Release 20 (BP1A.250305.019)
# -----BEGIN PGP SIGNATURE-----
#
# iF0EABECAB0WIQRDQNE1cO+UXoOBCWTorT+BmrEOeAUCZ8epjwAKCRDorT+BmrEO
# eGPtAJ4xkVvM0OmK/dZBwdVVDMjKroC/zACaAsDXpFeOe6kT2WhEkvc6MqpfuNQ=
# =5OoV
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed Mar 5 03:31:59 2025 EET
# gpg: using DSA key 4340D13570EF945E83810964E8AD3F819AB10E78
# gpg: Good signature from "The Android Open Source Project <initial-contribution@android.com>" [ultimate]
* tag 'android-15.0.0_r20': (183 commits)
Revert "Define ueventd.rc.recovery"
Define ueventd.rc.recovery
Define init_second_stage.recovery
Define reboot.recovery and watchdogd.recovery
debuggerd: Use libprocessgroup to unfreeze
Define toolbox.recovery
Replace partition-specific toybox make module with soong modules
Start aconfigd socket defined in configinfra mainline module
Update trusty to use secretkeeper hal V1
ashmem: Ensure all memfds have non-executable permissions by default
libsnapshot: Cleanup temp metadata during rollback
libprocessgroup: Remove ramdisk_available from libcgrouprc
libprocessgroup: Remove vendor_ramdisk_available from libcgrouprc
libprocessgroup: Remove recovery_available from libcgrouprc
gatekeeperd_service_fuzzer: Add signal() to handle SIGPIPE
libutils OWNERS for shayba@
Deprecate cc_binary aconfigd and the controlling flag
libprefetch: rename property name
Update comments to point to the new location of event.logtags.
Fix the dm-verity Merkle tree caches to not expire so quickly
...
Conflicts:
init/devices.cpp
Change-Id: I16f4b8b40b74074b087b2fc719cf4a322ccd76cf
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRDQNE1cO+UXoOBCWTorT+BmrEOeAUCZ1IsswAKCRDorT+BmrEO
eHLxAJ9VFRJgjolHUwxeYIHRrAxp7WFw0wCeIiUvtF763IeQx6Ri6gz3/i1V9mY=
=uE+H
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEHrBYPudH862glXQBzJUERRm+ZmkFAmdYsU0XHG1rYmVzdGFz
QGxpbmVhZ2Vvcy5vcmcACgkQzJUERRm+ZmlzEhAAkyT+qSieZv1roFs6MW0sBnjP
60eSCsj/eVetsK91ExBdm+NPHmpFG1XUcwxxiWzlPweIYA+eaECdoP9qngwxH/fy
7m6lxzVx2C9JbSCRWuBmyFWfsm7l+cjDoO8a5QnummBNobhV6/z680+CPzhsXXp5
wQ8cRYLlZEwSMGlgW5KufhbEQISZK1rxWGcx7C0MwoAZybm0V7bcv9ot9XWVZdBI
0uvpZEAYuLqMTTOxd1HNZBKA+cMmWLE+0ALfydGqdHxTkpDXY17Ek4/R3H7KTcy0
mhp6rLQHMKn/atDUsYGvDp/wGs+PWHl9QPXprwj9g9XBNRaAcw/ANi+I/Gc17Qsc
X/5DeC0ycGBljhjnl7ZoXAPwLyN+tYZi+ekwBs0E4+uQCLG5AMSLGZHGHcZafXB1
s0pR1u85BxC/7CoVB22J5utjsLdJT0G8bIgfyrKVVIA9iIe9zO/rsMN+9kffrQ9W
xPohc1XyVrsQ2b6xk/PyqbAI5mk7+IKKhxhX+Vv2Fczp2OCPuefa1aS1lIv4bZBL
rRPlVyodLWsEqxGNhiCo5Hh24uufJGuBTL2w6Rn5/UkqUkvUQZbsRNTg7WQIfcWh
sNvuNNxpgsilXFJC0/aoLE557MjCWq4eolPLnyrz3yR3jPcAa269bMuiMXKsVeEd
PvjxgQawPY8QkE2woe0=
=R9aC
-----END PGP SIGNATURE-----
Merge tag 'android-15.0.0_r6' into staging/lineage-22.0_merge-android-15.0.0_r6
Android 15.0.0 Release 6 (AP4A.241205.013)
# -----BEGIN PGP SIGNATURE-----
#
# iF0EABECAB0WIQRDQNE1cO+UXoOBCWTorT+BmrEOeAUCZ1IsswAKCRDorT+BmrEO
# eHLxAJ9VFRJgjolHUwxeYIHRrAxp7WFw0wCeIiUvtF763IeQx6Ri6gz3/i1V9mY=
# =uE+H
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri Dec 6 00:44:03 2024 EET
# gpg: using DSA key 4340D13570EF945E83810964E8AD3F819AB10E78
# gpg: Good signature from "The Android Open Source Project <initial-contribution@android.com>" [marginal]
# gpg: initial-contribution@android.com: Verified 2481 signatures in the past
# 3 years. Encrypted 4 messages in the past 2 years.
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 4340 D135 70EF 945E 8381 0964 E8AD 3F81 9AB1 0E78
# By Akilesh Kailash (13) and others
# Via Automerger Merge Worker (317) and others
* tag 'android-15.0.0_r6': (158 commits)
trusty: storage: proxy: FS_READY property setting on vendor only
Fix the trigger name for loading bpf programs.
start netd earlier
Replace base::RandInt with std::uniform_int_distribution
trusty: keymint: rename trusty_ipc_dev property
Move the `dist` target of `mke2fs` to `build/core/tasks`
Remove define of SA_EXPOSE_TAGBITS.
Add input event profile to mitigate input latency of input threads
Remove usage of base/string/* in libfs_avb
Add getFdStateDebug to access Looper's callbacks
libsnapshot: CHECK -> CHECK_EQ
Mount /mnt/vm earlier
Define linker.config.json as a filegroup
Remove usage of base/logging.h in libfs_avb
debuggerd: recognize jumps to non-executable memory.
Support vendor partition in non-debuggable pVMs
Remind the reader that they'll need to modify CTS too.
Rename system/core/rootdir/Android.mk to create_root_structure.mk
trusty: keymint/gatekeeper: Pass device name from init scripts
Remove unused variable.
...
Conflicts:
fs_mgr/libsnapshot/include/libsnapshot/snapshot.h
fs_mgr/libsnapshot/snapshot.cpp
init/Android.bp
init/fuzzer/Android.bp
Change-Id: I29c07b3ac76940cb2b82726e98d2beb643b3e6e4
By removing `recovery_available` property from "init_second_stage"
and defining a dedicated recovery-specific module for
"init_second_stage". `recovery_available` property should be used
to allow the reverse dependencies recovery modules to depend on
the module, not to install the module to the recovery partition.
Test: m soong_generated_recovery_filesystem_test
Bug: 381888358
Change-Id: Ie9b93b8453bc1e40f7a28e57f498313d3bc4cedb
1: Check the presence of the file 'prefetch_ready'. If it doesn't
exist then the device is booting for the first time after wipe.
Thus, we would just create the file and exit as we do not want
to initiate the record after data wipe primiarly because boot
after data wipe is long and the I/O pattern during first boot may not actually match
with subsequent boot.
2: If the file 'prefetch_ready' is present:
a: Compare the build-finger-print of the device with the one record format
is associated with by reading the file 'build_finger_print'. If they match,
start the prefetch_replay.
b: If they don't match, then the device was updated through OTA. Hence, start
a fresh record and delete the build-finger-print file. This should also cover
the case of device rollback.
c: If the build-finger-print file doesn't exist, then just restart the record
from scratch.
Bug: 362507272
Test: Prefetch record/replay
Change-Id: I90b861ba9381ddba6ab7dedb9930a735e55b0e5d
Signed-off-by: Akilesh Kailash <akailash@google.com>
Summary: The nosymfollow mount option was added to Linux 5.10, and the bionic
headers support it. Allow mounting with the option set. Updated relevant
CTS test too.
Test: Successful build on master
Change-Id: I0b280287e07ef8c485762b820dbbb26300144982
Signed-off-by: Abdelrahman Daim <adaim@meta.com>
Instead of hard-coding the text path everywhere, this uses a library to
get the genfs labels version.
As genfs labels affect SELinux, this also adds logs to help debug
issues.
Bug: 378805380
Test: boot and check log
Change-Id: I843c97cbeb0c211c67e0172458a4f0d236cf1f06
1: This supports "mem" tracing only.
2: Replay option is modified to use "pread" instead
of readahead.
A simple utility binary "prefetch" is built which links to the library.
The binary allows record, replay and verifying the generated
metadata.
Bug: 362507272
Test: cargo test passes all unit tests.
Verify record, replay and dump options:
./prefetch record --duration 10 --path /data/test/trace-test
./prefetch replay --path /data/test/trace-test
./prefetch dump /data/test/trace-test --format csv
Change-Id: I1661e49183c6120d2878510e609571fe6d608bb5
Signed-off-by: Vikram Auradkar <auradkar@google.com>
Signed-off-by: Akilesh Kailash <akailash@google.com>
Allow ueventd configuration to specify what to do with
devices based on driver. This responds to bind events and
treats them similarly to add events.
The format of the driver stanza is exactly the same as
that of the subsystem stanza.
Bug: 376900376
Test: set up cbc_mbim driver stanza and ensure it properly
creates and destroys device nodes when a USB device with
that driver appears and disappears or is bound and unbound
Change-Id: I31f5c91bd074d14075b74fe7beefaa6ac07a7ac9
A new field 'partition' was added to `ApexInfo` recently which stores
pre-installed partition information as string (e.g. 'SYSTEM') in
aosp/3335753. Using 'partition' field for Subcontext vendor apex
initialization because the existing field `preinstalledModulePath` won't
be populated for brand-new apex (a new type we introduced recently).
Bug: 377111286
Test: atest CtsInitTestCases
Change-Id: I8970b3cb5884bdb949035f5bdc5b2e18618cc9cc
NVME devices have a subsystem of "class/nvme". Add that to the list of
subsystems we check so we can identify them properly.
Bug: 316324155
Test: Boot on a device with nvme
Change-Id: I2ab3f6890f62f525dba150a0368c666a1c4c875e
Now that FindPlatformDevice() isn't modifying the path argument, and
is just passing it on to FindSubsystemDevice(), take this argument by
const reference. That should avoid an unnecessary string copy.
Bug: 316324155
Test: Compile
Change-Id: I1d92a322d0c311ee46a117dd9d650896ec02520f
If it's 202504 or later, /sys/class/udc will be labeled as sysfs_udc. If
it's not set, /sys/class/udc will stay at the label sysfs. This is to
support GRF vendors older than 202504.
202404 or old vendors can choose either way. If they want to customize
permissions to /sys/class/udc, they can turn off
BOARD_GENFS_LABELS_VERSION and assign their own label to /sys/class/udc
/sys/class/udc with vendor sepolicy.
202504 or newer vendors must set BOARD_GENFS_LABELS_VERSION to a version
greater than or equal to 202504.
For now there's only one node /sys/class/udc, but more labels can be
added until 202504 freeze.
Bug: 361985697
Test: boot with and without BOARD_GENFS_LABELS_VERSION
Change-Id: I1a28109119368f1475628be85dd8d990c824922e
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRDQNE1cO+UXoOBCWTorT+BmrEOeAUCZyveowAKCRDorT+BmrEO
eEowAJ0Ut5Tkq4TVDFvrYySEynb9v8QVIQCfSPhFnaHGbSQiqBRHrEdNbZJQS3s=
=vYsf
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEHrBYPudH862glXQBzJUERRm+ZmkFAmcstXAXHG1rYmVzdGFz
QGxpbmVhZ2Vvcy5vcmcACgkQzJUERRm+ZmkWQQ//TxtLkYx/axq6FjdEX+/O98Ug
SKaMooXZZ+fukX3ZwDCeoqwzJyb/Yho+TdqIE6wtzJsdP79xgeeYofBV+fsTUyTG
tgjo/3fIbzpL8IjhxiJrJZdH4yVI7QxhK23Nfk91fvwwqm+XE9bPaiXPFkL1boSV
E25OGizCucqWXeY9zoHWTx3F1HeGx2uG/+2p7BZxwP/jbFsnHWrvnUlwTWi3NHz+
KnLCcgd6m1ZPuf141Od3rKPhkuPxEH3Ed3I1bWT+QebI+YvgIuVELdy2MNaDW+JH
iOwEqk9IHSDEQJ3jV1WO50dyRUsDej4ihCHe2bZgEe1Nhv8d5f1MhcnJs/S/I9tf
7A1zVcktKpSjrZjv7aFdlxr5oQvPT+OH9XgJqIfajadoaVGk+wnc0fPJwvH9/eUA
thmKvxToKJYJ+7DsODidOgJd6M0JsaHrFI37hW+PjiLyVmfyhNv0ihIZ7qyLgGSc
sZzbZTqXKav5cl94uSaFVieLN2mtcTTzd1oYmbzKxsCGUq5Cy+T7nualAyai5NpW
udKahmbiIxvihgNsvPPJtD8tewG8nqVIKan5h1nLoSq+iySnHS0b/6b1orTZ/nkg
9xZ6YrjeVBVO6oomesiIX5MMm3BmwRioK31mCA7MsY0/RhcyP5gBlsT/cfEEiWxQ
0dLyqPIPIi4Hw/LlbwA=
=dQ+a
-----END PGP SIGNATURE-----
Merge tag 'android-15.0.0_r5' into staging/lineage-22.0_merge-android-15.0.0_r5
Android 15.0.0 release 5
# -----BEGIN PGP SIGNATURE-----
#
# iF0EABECAB0WIQRDQNE1cO+UXoOBCWTorT+BmrEOeAUCZyveowAKCRDorT+BmrEO
# eEowAJ0Ut5Tkq4TVDFvrYySEynb9v8QVIQCfSPhFnaHGbSQiqBRHrEdNbZJQS3s=
# =vYsf
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed Nov 6 23:24:51 2024 EET
# gpg: using DSA key 4340D13570EF945E83810964E8AD3F819AB10E78
# gpg: Good signature from "The Android Open Source Project <initial-contribution@android.com>" [marginal]
# gpg: initial-contribution@android.com: Verified 2336 signatures in the past
# 3 years. Encrypted 4 messages in the past 2 years.
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 4340 D135 70EF 945E 8381 0964 E8AD 3F81 9AB1 0E78
# By Akilesh Kailash
# Via Android Build Coastguard Worker
* tag 'android-15.0.0_r5':
libsnapshot: Address GRF config when updating from Android S config
libsnapshot: Check if the vendor is updated from Android S for GRF
Change-Id: Ib7748aa00d12b2944e84516fec058b04bc18af89
The current code waits for boot partitions to show up by waiting to
see a uevent with the right partition name. However, nothing in the
waiting code validates that the partition that showed up is actually
on the boot device. That means that the current code can be confused
if there is another block device in the system (possibly connected via
USB) that has a partition name matching one of the system ones.
It can be noted that the problem is specifically just that the
"waiting" part returns too early. Later parts of the system,
specifically the parts of the system that create the
"/dev/block/by-name" symlinks, do properly look at the list of "boot
devices". This means that the problem we're fixing is that later code,
which assumes that the boot partitions have already initialized, can
fail to find an initialized partition.
To make it concrete, imagine that you have two block devices in your
system: the builtin emmc and an external USB disk. Let's say you're
booting over USB and "boot_devices" properly lists only USB. Both the
"emmc" and "USB" block devices are properly formatted Android disks
and have the full slew of partitions. At boot time, you can see:
1. We get to the point where we need to wait for the "boot" source
(USB) to show up.
2. We see the eMMC show up.
3. The eMMC has all the needed partitions, so we consider our wait
done. ...but eMMC isn't in the list of "boot devices" so we don't
create the "/dev/block/by-name" symlinks.
4. Later code assumes that the "/dev/block/by-name" symlinks are
already setup and fails.
5. The device fails to boot.
Fix it so that the wait makes sure that the partitions are on the boot
device.
Unfortunately, it appears that in some cases products (especially
emulators) aren't setting the "boot devices" and/or are not making
sure all boot partitions are on the same device. Limit the fix to only
devices using the new "boot_part_uuid" to make sure we don't break old
code.
NOTE: this is effectively the same change as a previous one ("init:
Look for super partition only on a boot device") but with the added
fix to only enable the check when using "boot_part_uuid".
Bug: 309244873
Bug: 349144493
Bug: 316324155
Test: Boot isn't confused when two boot devices are present
Change-Id: Iaae453ed661307f485cdf4dde86294105cae9b2d
The current mechanism for specifying boot devices on Android systems
involves passing a set of "boot_devices" though command line,
bootconfig, or device tree.
The bootdevices are specified as strings and, in general, need to
match a sysfs path but without the "/sys/devices" or
"/sys/devices/platform" prefix. The sysfs path is generally the path
to the closest parent of the block device that is a "platform" device.
As an example, if the sysfs path of the expected boot device is:
/sys/devices/platform/soc@0/7c4000.mmc/mmc_host/mmc1/mmc1:0001/block/mmcblk1
The bootloader would specify it as "soc@0/7c4000.mmc" since:
* We strip off "/sys/devices/platform/"
* As we move up directories, we don't find one whose subsystem is
"platform" until we get up to
"/sys/devices/platform/soc@0/7c4000.mmc".
The current mechanism is a bit brittle. Specifically:
* The sysfs path isn't _really_ stable and can change across kernel
upgrades. For instance, during one kernel upgrade the device tree
for a product changed so that the root node changed from "soc" to
"soc@0" and this changed all sysfs paths. In the past device tree
folks have asserted that we shouldn't rely on dts node names to stay
consistent, yet those node names are used to construct sysfs paths.
* For some devices, like USB, the path of the closest "platform"
device tends to be the path of the USB controller. This means that
if two USB disks are plugged in we can't guarantee which one will be
identified as the boot device.
Add a new method of finding the boot device by passing the partition
UUID that we loaded the kernel from. Using the partition UUID to
identify the boot device is standard on Linux. You can see this
because when you're not using an initramfs you can use the syntax
"root=PARTUUID=<valid-uuid-id>[/PARTNROFF=n]" to specify the root.
Using the same idea for Android's boot code makes sense.
With this new method for finding the boot device, we can make the code
much more specific about matching sysfs paths. Once we find the sysfs
path for the kernel we can make sure that all of the other boot
partition share the same "scsi" or "mmc" parent instead of going all
the way to the closest platform device. In the above example, this
means that we'd make sure that all boot devices are found under this
sysfs node:
/sys/devices/platform/soc@0/7c4000.mmc/mmc_host/mmc1/mmc1:0001/block/mmcblk1
...instead of just making sure they are under:
/sys/devices/platform/soc@0/7c4000.mmc
There is the question of what we should do if the bootloader passes
_both_ an old style "boot_devices" and also a partition UUID. In this
case, we'll issue a warning and then ignore the old "boot_devices".
Considering it a warning rather than an error could allow switching to
the "boot_part_uuid" method even if an old bootloader is still
hardcoding some old "boot_devices".
NOTE: Using partition UUID won't cause any security problems even
though someone _could_ plug in an external device crafted to have the
same UUID as the normal boot device's kernel partition. We already
have "verity" in the system making sure our filesystems are not
tampered with and this would also protect us from booting a tampered
disk. That means that the worst someone could do in this case would be
to confuse the system and make the device non-bootable. Chromebooks
have been using the partition UUID to find the root filesystems for
years and this has never been a problem.
NOTE: this new method relies on the commit ("init: Add partition_uuid
to Uevent") which in turn relies upstream kernel commit 74f4a8dc0dd8
("block: add partition uuid into uevent as "PARTUUID"").
Bug: 316324155
Test: Use partition UUID to boot
Change-Id: If824cb700ca3696a442a28e6ad02d7c522c3b495
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
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
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
As a preparation for upcoming commit, extract part which is responsible
for external program execution to libmodprobe so it can be later
re-used not only for firmware handler but also for dynamic module
options handler within libmodprobe.
RunExternalHandler is moved entirely to separate library with two
changes:
- Setting env needed previously by firmware handler was made generic and
now external handler can get envs_map containing pairs of env and its
value which needs to be set.
- "Firmware" was removed from one of the log since now it can be used in
different context (s/External Firmware Handler/External Handler/)
Bug: 335619610
Test: `atest CtsInitTestCases` passed, especially:
[105/129] ueventd_parser#ExternalFirmwareHandlers: PASSED (0ms)
[106/129] ueventd_parser#ExternalFirmwareHandlersDuplicate: PASSED (0ms)
Change-Id: Ie07cee763278f224bd3c0acfbe06c44eb36d0a81
This reverts commit 8d71220df2.
Reason for revert: Fix for gcar emulator (basically all QEMU-based emulators) landed at aosp/3315253 and aosp/3160116.
Change-Id: If4eddd3f7e224c31019ad3bd752e2375c7567780
When adding a dependencies, if the variants don't match, but the
dependency only has 1 variant anyways, soong will always use that
variant. This makes it hard to add new variants to soong, because the
1-variant fallback stops being used and you start getting missing
variant errors. Make changes to bp files such that all dependencies
correctly specify the variant to use.
Bug: 372091092
Flag: EXEMPT refactor
Test: m nothing
Change-Id: I35a5ac0e6b63080f692be6597edf5f213c4e7acb
On a preview device (where codename is not "REL"), filtering .##rc files
will choose the highest versions reglardless of ro.build.version.sdk.
Bug: n/a
Test: add .36rc to an apex and see if init reads it.
Change-Id: Icd63cf70e45cc14504f839ce9492e1766147a40e
Revert submission 3212512
Reason for revert: Droidmonitor created revert due to b/372273614. Will be verifying through ABTD before submission.
Reverted changes: /q/submissionid:3212512
Change-Id: I37568516e973cb940f1229d52f94b8dc801da2ab
