Currently, during a 'fastboot flashall/fastboot update', the 'getvar
max-download-size' command is issued once to the device when it is in
bootloader mode and the same value is used even after the device boots
into fastbootd. If the max-download-size returned by bootloader is
greater than the max-download-size in fastbootd, this could break flash
as large images are broken down into chunks before downloading by using
the max-download-size variable. This will cause fastbootd to return
an error since it checks whether the buffer being downloaded has a size
greater than the max-download-size limit.
Test: fastboot flashall
Bug: 536870912
Change-Id: Ife7c1ec0583d80d4a31ecf01f1fc14a8365afe0d
We can't create interface iterators for all devices (e.g. the keyboard,
touchbar, etc.), so we get multiple instances of this log spam on every
command.
Demote it to a warning that only shows up on debug builds.
Test: none
Change-Id: I20581b9134c05360d5723b09ffe8de8c4cfd6a3f
Switch FindEntry and the ZipString constructor to std::string_view. This
lets us accept an over-long name so that we can reject it as too long.
Also fastboot changes to track the API change.
Bug: http://b/129068177
Test: treehugger
Change-Id: I7df7acd1fe2c46380b789c25f8909e0553e2d55e
Currently if the device is unplugged from host,
there is a lot of log spamming since fastbootd
does not not recognize that the device has been
disconnected and keeps trying to read/write to the
device.
2856 printk messages dropped ** [ 169.941904] c7 579 fastbootd: aio: got error event on
read total bufs 1: No such devie
** 2960 printk messages dropped ** [ 169.953328] c7 579 fastbootd: Fastboot command:
** 2074 printk messages dropped ** [ 169.961355] c7 579 fastbootd: aio: got error event
on read total bufs 1: No such devie
Bug: 121333158
Test: unplug device and check for log spam multiple times
Change-Id: I1d4c6f48f34e313c5ebce23d62a4fe6a6373f94f
Vendor must be a logical partition and boot must not be a logical
partition.
Test: fuzzy_fastboot --gtest_filter=*Logical*
Bug: 117220134
Change-Id: Ifc6f2f715ca92cd1fe779e8fce2d6a10a1f140b9
This is required for read() to function correctly
in Windows since it behaves differently in text mode and
binary mode and may cause unpredictable behavior depending
on the contents of the image file.
Bug: 129281908
Test: fastboot.exe flashall
Change-Id: I64370af44a050bafea60ff1b0b2be18cc531480a
The function do_for_partitions() takes a const std::string
reference, so it's inefficient to pass a std::string::c_str().
Test: TreeHugger
Change-Id: Ia84ed9ec691ee2f524c61dd25a81b2995bb0bb33
As part of a refactor, commit db511207ed
added a timeout for receving responses for commands. Unfortunately,
the timeout is optimistic as to how quickly target devices can complete
such operations. Flash and erase commands can be quite slow on devices
with traditional flash chips. The fastboot protocol is already adept
at handling such cases because it allows for sending INFO packets during
these periods. We may receive one or more INFO packets during tehse long
operations. Every time we receive an INFO packet, it proves the remote
end is alive, but busy, which should reset our timeout timer.
Change-Id: Ia3bba21c497b22639b626d89711ecd4eb02504ed
Signed-off-by: Dima Zavin <dmitriyz@waymo.com>
Previously, system_clock was used for remote command timeouts
which can get disturbed by NTP adjustments (jumps).
Change-Id: I0ffc159bf34d12e8d3713044524114d60a6a45ca
Signed-off-by: Dima Zavin <dmitriyz@waymo.com>
This command erroneously reports that no GSI is installed, because
/metadata is not mounted in recovery. To address this, temporarily mount
/metadata when the gsi command is invoked.
Bug: 122556707
Test: fastboot gsi disable
fastboot gsi wipe
Change-Id: Ib21971b49b46fd580b902ff75f01cfb96192afc0
And deprecate one more old style function that is not used after this
change.
Test: boot, disable and enable verity
Change-Id: Id509f479850120352b4ea4dc3b6c40f6e8e2e53e
New arguments 'dtb' and 'dtb-offset' have been added to
support boot image header version 2 for the 'fastboot boot'
and 'fastboot flash:raw boot' commands.
Test: fastboot boot Image.lz4 --dtb <dtb_path> --header-version 2
Test: fastboot flash:raw boot Image.lz4 --dtb <dtb_path>
--header-version 2
Bug: 111136242
Change-Id: Idf5c2eb138609dc7e915e80c4db64677c89f24b6
Note: this only removes the bootable marker, since we're unable to
remove the userdata files within recovery.
Bug: 121210348
Test: fastboot gsi wipe
fastboot gsi disable
Change-Id: I64fe848c787d426ae9d18a1557a9d6b340bfc2cf
On non-DAP devices, fastboot flash <partition> will spam error messages
about not being able to read super_empty.img. We should check that
super_empty.img exists before trying to read it.
Bug: 120429424
Test: fastboot flash system on non-DAP device
Change-Id: I6c4eec19cb3ef8d24595a75e072e1d75baaa8cdd
When the update-super command is issued, we want overlayfs overrides
to disappear without a doubt, which includes non-A/B utilizing
/cache/overlay/ tree. Call fs_mgr_overlayfs_teardown() on successful
return.
Test: adb-remount-test.sh
Bug: 120034852
Change-Id: Ia5cdb797f7e8350b5591a51fc8ae5f323901aee4
On retrofit devices, if both slots contain dynamic partition builds,
then "flashall" will attempt to write secondary images to dynamic
partitions in the other slot. At worst, this can fail with an error. At
best, it will result in the "other" partition not being mounted on first
boot.
This patch therefore deletes logical partitions for secondary images, on
retrofit devices only. On a Pixel device on the "b" slot, this means
"system_a" and "vendor_a" will be deleted before flashing, and therefore
system_other and vendor_other will be flashed to physical partitions
instead.
Bug: 120034852
Test: fastboot set_active a
fastboot flashall
fastboot set_active b
fastboot flashall
Change-Id: I6affe9a6c639b0495bffc77fcf20f329b86ad159
When checking for existence of "super_empty.img" to determine if
flash image product set is meant for logical partitions, we die if
ANDROID_PRODUCT_OUT environment is unset or empty. This check
is done before we look at the flash image name to determine if it
is a candidate to look at the logical metadata.
Instead, allow this check to conservatively fail for now.
Test: export ANDROID_PRODUCT_OUT=
fastboot flash bootloader
Bug: 120041144
Change-Id: I43f124015f9d26c79a0feb9123522432fe937343
Merged-In: I43f124015f9d26c79a0feb9123522432fe937343
Retrofit devices will have two super partitions, spanning the A and B
slots separately. By design an OTA will never cause "A" or "B"
partitions to be assigned to the wrong super. However, the same is not
true of fastbootd, where it is possible to flash the inactive slot. We
do not want, for example, logical "system_a" flashing to super_b.
When interacting with partitions, fastbootd now extracts the slot suffix
from a GetSuperSlotSuffix() helper. On retrofit devices, if the partition
name has a slot, that slot will override FastbootDevice::GetCurrentSlot.
This forces partitions in the inactive slot to be assigned to the correct
super.
There are two consequences of this. First, partitions with no slot
suffix will default to the current slot. That means it is possible to
wind up with two "scratch" partitions, if "adb remount" is used on both
the "A" and "B" slots. However, only the active slot's "scratch" will be
visible to the user (either through adb or fastboot).
Second, if one slot does not have dynamic partitions, flashing will
default to fixed partitions. For example, if the A slot is logical and B
is not, flashing "system_a" will be logical and "system_b" will be
fixed. This works no matter which slot is active. We do not try to
upgrade the inactive slot to dynamic partitions.
Bug: 116802789
Test: fastboot set_active a
fastboot flashall # dynamic partitions
fastboot getvar is-logical:system_a # true
fastboot getvar is-logical:system_b # false
fastboot set_active b
fastboot flashall --skip-secondary
fastboot getvar is-logical:system_a # true
fastboot getvar is-logical:system_b # true
Booting both slots works.
Change-Id: Ib3c91944aaee1a96b2f5ad69c90e215bd6c5a2e8
On retrofit devices, it is easy to accidentally overwrite
system/vendor/product by flashing system in the bootloader. The reason
is that GPT system_a is really the super partition, and the bootloader
doesn't know it.
Addressing this in bootloaders would require two separate commands: one
that rejects flashing system/vendor/product, and another for
expert/factory use that would allow direct flashing.
This patch introduces protection into the host fastboot tool instead.
It's not mutually exclusive with bootloader changes; having protection
in the host tool affords us better and consistent UI. However it does
rely on users having newer builds.
With this change, the following will not work in the bootloader:
fastboot flash system # or vendor, product, etc
The message is the same whether or not the device is a retrofit. To
continue anyway, you can do:
fastboot flash --force system
If we decide on bootloader protection as well, the --force flag can be
re-used.
Bug: 119689480
Test: fastboot flash system # disallowed in bootloader, allowed in fastbootd
fastboot flash --force system # allowed in bootloader
Change-Id: I0861e3f28a15be925886d5c30c7ebd4b20c477cf
Removes a few more Android.mk files.
Test: check for adb, mkbootfs, and fastboot in the build artifacts
Change-Id: Ie4e50a363a734d0b9207f0d0098c54719f038e76
Similar to the change to adb in Id26760bc62c89a1f7ef67511b21f9d9252ab69f3,
pin the interface version to IOUSBFamily 5.0.0.
Bug: 119264733
Test: Manual
Change-Id: Ied9164532c0ba6f20415dafecb0c774578aa5c57
This patch adds a new variable, "super-partition-name", to query the
name of the super partition (with a slot suffix if it has one). The
fastboot flashing tool has been updated to query this variable.
Since the super partition name can no longer be determined without
fastbootd, the presence of super_empty.img is used to test for
dynamic partition support rather than the presence of a super partition.
Bug: 116802789
Test: fastboot flashall on retrofit device
Change-Id: If830768eba6de7f31ac3183c64167fae973c77a4
When updating the super partition, attempt to preserve partitions from
the other slot. If any partition can't be preserved, fail and require a
wipe (-w) to proceed. This allows two bootable builds to be flashed to
both slots.
The preserve operation can fail if the metadata is not compatible with
the old partition layout. For example, if the partition references a
group that no longer exists, or a group changed its capacity, or the
metadata's block device list or list contents changed.
Bug: N/A
Test: liblp_test gtest
fastboot flashall --skip-secondary
Change-Id: I53fdd29bc1f0ef132005a93d3cf1cdcd7f2fc05f
