-----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
use health HAL v4 for fastbootd, healthd, and storaged
Ignore-AOSP-First: deprecated_ota_test compilation
Bug: 371322457
Test: th
Change-Id: Ia941d67a5248641246a7298487c6a13fe92d8d66
When updating the vendor_boot ramdisk, there may be device tree
dependencies that require updating the device tree with the new ramdisk
which contains the first stage init kernel modules. This patch adds the
support to use the `--dtb /path/to/dtb` option to update the DTB when
updating the vendor_boot ramdisk. To do so, run the command:
fastboot flash --dtb /path/to/dtb.img \
vendor_boot:<RAMDISK_NAME> /path/to/ramdisk
Test: fastboot_vendor_boot_img_utils_test
Test: Verifed updating the dtb with the above command on r4
Bug: 368308832
Change-Id: Iaa1867fe64054971a698497a2e3486424fed19fe
Because `mke2fs`, `make_f2fs`, and `make_f2fs_casefold` have
`recovery_available` set to true, Soong forcibly adds a new variation
with a `_recovery` suffix to the existing variations. If this is
directly added to the `dist` of the corresponding module, it will cause
duplication of the `android_recovery_<arch>/meta_lic` and
`android_<arch>/meta_lic` files.
Therefore, it is temporarily moved to `build/core/tasks`. Once the
issues are resolved, they will be moved to the corresponding modules.
Bug: 349741178
Test: m sdk dist
Change-Id: Id003f6aed85c909aeb36606691cc4daf10c9c1d4
* Use different endpoint addresses for sinks and sources
* Consider locked only explicitely `green` devices
* [npjohnson] Updated for 12's logic
Change-Id: If093556e8e839cadf29f9e8f995f09ed3f188ed1
ro.revision defaults to 0 if it's not set in cmdline.
Some devices might want to set it in their device specific init files,
however it's not possible to override ro properties.
Test: Set ro.boot.hardware.revision in device specific init.rc and
observe fastboot getvar hw-revision in fastbootd
Change-Id: I6e785c3fe3a49409e815af269a9a8db732b80ada
std::vector<const T> uses std::allocator<const T>, which is an
undocumented libc++ extension to the C++ standard library. The extension
was removed in llvm.org/PR96319. Use an ordinary non-const T instead.
Bug: http://b/349681543
Test: m fuzzy_fastboot CtsInitTestCases
Test: m MODULES-IN-system-core
Flag: EXEMPT, refactor to fix build failure
Change-Id: Ia98a2f090e87541fd35a89bd75bf9638bc7dc711
snapshot metadata files are stored in /metadata. This means, we cannot
wipe after installing any update.
This patch does the following:
1: Create a scratch space in super partition. The scratch space for ota
metadata is just about 1MB.
2: Create ext4 filesystem on top of scratch block device.
3: Mount the scratch on /mnt/scratch_super
4: When snapshot-manager instance is created, point the /mnt/scratch/ota
to metadata_dir_ so that all the snapshot files are stored in the new
path.
All the logic of OTA remains the same. This flow is enabled only on userdebug builds for now and the only consumer would be snapshotctl
$snapshotctl apply-update /data/nbd/ -w
During init, we would have to mount the scratch partition to detect
if there is any pending updates.
With this, we would now be able to wipe the device along with the update flow. This will help incremental flashing wherein we would end up saving ~35-40 seconds on Pixel devices.
With this flow, the end-to-end update for incremental builds takes
~20-30 seconds.
Bug: 330744468
Test: Pixel 6 incremental flashing with wipe, Full OTA, vts_libsnapshot
Change-Id: Iac6ce2cf37b70ea221cd18175c8962988d03d95b
Signed-off-by: Akilesh Kailash <akailash@google.com>
Wait for the device to disconnect when rebooting to userspace fastboot.
This is a particular problem for USB-over-IP devices, which must tunnel
the USB commands over a relatively-slow network and thus will not
disconnect as quickly as local ones.
Only currently effective for Linux hosts, since LinuxUsbTransport is the
only transport that implements WaitForDisconnect().
Test Plan:
provision with a usbip-attached device, see flash succeed
Change-Id: Ia8903dfa6e40755377870fbeaef9162934f992a0
With a device capable of saturating the bus at SuperSpeed+,
the next bottleneck is the fixed (size-independent) overhead of
the usbfs ioctl() system calls, which includes entering/exiting
the kernel, allocating/deallocating a contiguous buffer for DMA,
configuring/deconfiguring the IOMMU and issuing the DMA to the HC. In
order to saturate the bus from the host software perspective, we must
reach the schedule() call in reap_as() before the next interrupt from
the HC indicating the completion of the URB.
In my experimental setup, with an SS+ capable host and device
and 16 KiB URBs, we reach the schedule() call in 25us, but the
URB is serviced in an estimated 16us, so we lose roughly a third
of the bandwidth. Increasing the URB size to 64KiB there are
65us between interrupts and 55us until schedule(). This means
we usually reach schedule() in time but not always, so we lose a
bit of bandwidth. Increasing it again to 128KiB and we have 128us
between interrupts and 65us until schedule(), so we're now comfortably
saturating the bus. In order to account for differences between hosts,
this CL uses a doubled maximum of 256KiB.
With larger allocation sizes we now risk contiguous allocation
failures, so I implemented a fallback where we try smaller sizes if
a larger one fails.
With this CL download speeds on my hosts are now around 980 MB/s over
SS+ and 440 MB/s over SS.
Bug: 325128548
Change-Id: Ie5ad480c73f2f71a50ce7f75ffb4aaa93ded2f0b
If the system time changes during the execution of fastboot we might
see some strange output such as:
Sending sparse 'super' 4/20 (254972 KB) OKAY [-516.263s]
Fix it by changing now() to use clock_gettime(CLOCK_MONOTONIC).
I confirmed that all callers of now() are using it for relative time
and not time since the epoch.
Change-Id: Ic3e9442c2ab21dfb076bfed88915085a183754b0
If the device provides an interface string, we should remove the newline
from the read file that is added from by the linux kernel.
Bug: 324320178
Test: Ran the same command with my local changes vs not
```
bash$ ./fastboot devices -l
5f42ad5ad259c90cf14ea222791b6aaa fastboot usb:7-3
bash$ fastboot devices -l
5f42ad5ad259c90cf14ea222791b6aaa fastboot
usb:7-3
```
Change-Id: Ida3316fdba8e35f0c66784f83455a4d82e90ba1c
The fastboot command currently uses USBDEVFS_BULK to transfer data
(including image data) to the target. On the kernel side it looks
like this:
1. Allocate a contiguous memory region and copy the user data into
the memory region (which may involve accessing storage).
2. Instruct the driver to start a DMA operation.
3. Wait for the DMA to finish.
This is suboptimal because it misses out on a pipelining
opportunity. We could be doing 3 for the current operation in parallel
with 1 for the next operation, so that the next DMA is ready to go
as soon as the current DMA finishes.
The kernel supports asynchronous operations on usbdevfs file
descriptors (USBDEVFS_SUBMITURB and USBDEVFS_REAPURB), so we can
implement this like so:
1. Submit URB 0
2. Submit URB 1
3. Wait for URB 0
4. Submit URB 2
5. Wait for URB 1
and so on.
That is what this CL implements. On my machine it increases transfer
speed from 125 MB/s to 160 MB/s using a USB 3.0 connection to the
target (Pixel 8).
Bug: 324107907
Change-Id: I20db7ea14af85db48f6494091c8279ef7a21033d
This adds a new metadata header flag to the super partition. This flag
is set when "adb remount" is used, and is implicitly cleared when
flashing.
If there is a scratch partition present on /data, we require that the
flag be set in order to proceed using overlays. If not set, scratch is
not mapped in first-stage init, and scratch images are removed later
during startup.
Bug: 297923468
Test: adb remount -R, touch file in out/, sync, flashall
Change-Id: I9cc411a1632101b5fc043193b38db8ffb9c20e7f
* changes:
fastboot: Add getvar commands to query battery part info.
Update fastbootd to use Health AIDL HAL V3.
Update healthd to use Health AIDL HAL V3.
Update storaged to use Health AIDL HAL V3.
This adds two commands to test the new v3 Health HAL, to query the
battery serial number (unlocked devices only) and part status.
Bug: 309792384
Test: adb reboot fastboot
fastboot getvar battery-part-status
fastboot getvar battery-serial-number
Change-Id: Ie0a14eda06483d047544833124c327fb88ba43a2
We rely on parsing the `fastboot devices` output in device labs, and a
format change previously broke us. This test will ensure that the output
is exactly what we expect.
Test: atest --host fastboot_integration_test
Change-Id: I7606e7b3e4a1edfe487ff14bb06cbd3c0a3aa777
Trying to move the AVB footer on a sparse file will corrupt the sparse
format. Rather than implement this properly, for now, have the
copy_avb_footer() function gracefully fail by skipping the operation.
Bug: 304574023
Test: fastboot flash sparse image with avb footer
Change-Id: Ia6f0711789a04897ec266ad604a3d243c7184082
This code path was never invoked. is_logical will return false on
secondary partitions in retrofit devices, so nothing actually is ever
deleted. If we manage to call the delete, the device side code will
fail with "cannot open the super partition"
Test: fastboot flashall on sargo device
Change-Id: I20b430c5c30bf992506190ea4e00b0b69c7b1005
FastbootDevice::boot1_1 attempts to dereference a null pointer when the
boot_control_hal_ is not set. It needs a guard statement to prevent
that.
Test: Manually tested on device without BootControl.
Bug: 301682120
Change-Id: Id86bcb915c8e2857bda26f64738dd5b643048e98
Introduce new battery-soc variable to read battery
SSOC, this benefits manufacturing to better track
the SSOC after FSI image flashing in the userspace
fastbootd using the same approach as Android space,
otherwise it is difficult to implement the entire
battery SW stack from Android to fastboot bootloader
and generate the same test experience monotonically.
Bug: 303561559
Test: fastboot getvar battery-soc # in fastbootd
Change-Id: Ia3f68e314263d7dd4d4c45a908a0a49db6e761f9
Signed-off-by: Harry Pan <gspj@google.com>
The current code keeps a pointer to a local variable which doesn't
work too well. Change this to a unique_ptr and allocate the source
object that will be used instead.
Test: All unit tests pass.
Test: fastboot -w flashall on a mokey which crashed without this change.
Change-Id: Ief5437374181e514928c45dd540b42898901a137
We should change should_flash_in_userspace to work without
$ANDROID_PRODUCT_OUT being set and fall back on $OUT directory when
source isn't specified
This also fixes the flashing issue of flashing retrofit devices without
$ANDROID_PRODUCT_OUT set. If we
call fastboot update on a retrofit device, copy_avb_footer will resize
buf->sz of secondary partitions to the partition size, causing us to
send the unsparsed payload to the device -> "Invalid Size" issue.
This is because secondary partitions are considered physical partitions
on retrofit devices && should_flash_in_userspace wouldn't work if
$ANDROID_PRODUCT_OUT is set, so our first return clause in
copy_avb_footer doesn't catch this edge case causing us to resize the
buf-> sz incorrectly.
Did some testing, and also observed a case where flashing is able to
succeed despite $ANDROID_PRODUCT_OUT not being set before, so there
might still be some other edge case that we are still missing.
Test: fastboot update on sargo without $ANDROID_PRODUCT_OUT
Change-Id: I0e4781d96709b712f7d71657ec0d16d99b90214d
Changing is_retrofit_device() to work in bootloader. Previously flashall
flow was to boot into fastbootd and then make a call to get
"super-image-name", however this does not work in bootloader. Since all
tasks are generated ahead of time, this old check will now fail and we
will fail to add the correct delete tasks in collectTasks(). This change
does make it so that is_retrofit check only works during fastboot
flashall + fastboot update (since this function is only used here,
nothing is currently affected).
To determine if a device is retrofit, it must satisfy two conditions -> Has
dynamic partitions && does not contain a super partition. The check for
if source has super_empty.img is sufficient for determining if a device
has dynamic partitions and if any single partition has
LP_PARTITION_ATTR_SLOT_SUFFIXED it is determined to be retrofit
Test: logs from fastboot update on sargo device confirms this check
returns true. Fastboot update on sargo
Bug: 300287332
Change-Id: Iadf5c56de51993a79307c60e45d6cc4988436f23
Removing some unused headers and swapping out std::string_literal to
strings
Test: fastboot flashall
Change-Id: I343272f4a678398a0446660a639c525e42e25891
From aosp/2475604 the functionality of deleting retrofit partitions
wasn't added back correctly. aosp/837186 adds this logic in. We should
only have one delete that exists if the image is secondary and is
dynamic.
Unfortunately don't have a retrofit device to test on, but from an eye
test this logic seems to match the old functionality and should be
working
Test: m fastboot
Change-Id: I5481893ab1638541d21813efe1c4aab5219e1dcd
This enhances the security requirement by only allowing
the owner app to change a locked DSU.
Bug: 277691885
Bug: 296985785
Test: 1. ensure device is OEM locked
2. adb shell am start-activity \
-n com.android.dynsystem/com.android.dynsystem.VerificationActivity \
-a android.os.image.action.START_INSTALL \
--el KEY_USERDATA_SIZE 2147483648 \
--es KEY_DSU_SLOT foo.lock
3. adb reboot fastboot
4. `fastboot gsi disable|wipe` should be blocked
Change-Id: I1a0cb8a074412468d16043ddf4101fbb76490115
