Direct Install reports success when boot partition write fails

Start by reading app/src/main/assets/util_functions.sh and app/src/main/assets/boot_patch.sh, focusing on flash_image(), dd, sync, and the saved command status. Preserve write errors, propagate failures through the flash path, and ensure failed writes do not produce a success message or reboot request. Verify the behavior on a device or with a controlled failing write.

Please check before submitting

• I searched existing issues and did not find a relevant report.
• This is an APatch Manager flash error-handling issue, not a KernelPatch image patching or boot failure.
• The problem is reproducible on the affected device.

Bug description

Direct Install can report Successfully Flashed and request a reboot even when writing the patched image to the boot partition failed.

In this case, KernelPatch generated a valid patched image, but Android runtime writes to boot_a were rejected by the storage device. APatch hid the dd error and returned success, so after reboot the old KernelPatch version was still active and Manager continued to request an upgrade.

The same patched image was later flashed successfully through fastboot and booted normally.

Reproduce method

1. Use a device on which the active boot partition rejects writes while Android is running.
2. Open APatch Manager and perform Direct Install to upgrade KernelPatch.
3. APatch displays a successful flash result and asks for a reboot.
4. Reboot the device.
5. The previous KernelPatch version is still active and APatch asks for the upgrade again.

A direct write test reproduces the underlying failure consistently:

- Flash source: new-boot.img (134217728 bytes)
- Flash target: /dev/block/by-name/boot_a (134217728 bytes, block size 4096)
dd: /dev/block/by-name/boot_a: I/O error

Kernel log at the same time:

Sense Key : 0x7 [current]
ASC=0x27 ASCQ=0x1
blk_update_request: critical target error, dev sdc, sector 1452032, op WRITE

The SHA-256 of boot_a remained unchanged after the failed Direct Install. Fastboot successfully flashed the exact same patched image, and the device booted with KernelPatch 0.13.3.

Expected behavior

• Preserve or display the write error from dd.
• Return a non-zero result when writing or syncing fails.
• Do not display Successfully Flashed or request a reboot after a failed write.
• Preferably verify that the written image matches the target before reporting success.

Actual behavior

APatch reports a successful flash even though boot_a was not modified. After reboot, the old KernelPatch version remains active.

Relevant code

Current main (6ec140efc693025e1cd74b0571269d9be21b3ca9) still contains both error-handling problems.

In app/src/main/assets/util_functions.sh, dd stderr is discarded and flash_image() returns success after sync regardless of the write result:

eval "$CMD1" | dd of="$2" bs="$blk_bs" iflag=fullblock conv=notrunc,fsync 2>/dev/null
sync
...
return 0

In app/src/main/assets/boot_patch.sh, $? is checked and then read again inside the if body. At that point it is the status of [ ... ], not the original flash_image status:

flash_image new-boot.img "$BOOTIMAGE"
if [ $? -ne 0 ]; then
  >&2 echo "- Flash error: $?"
  exit $?
fi

Saving the result immediately, propagating write/sync failures, and optionally comparing the written prefix against the source image prevents the false-success result.

Screenshots

The UI showed a successful Direct Install/reboot flow, but after reboot the old KernelPatch version was still displayed. After flashing the same image through fastboot, APatch correctly displayed KernelPatch 0.13.3 as working.

Device name

Redmi 24094RAD4C (beryl)

OS version

HyperOS OS2.0.210.0.VOQCNXM

APatch version

11224 / 9a63e0f (the affected official build). The relevant code path is also present on current main at 6ec140e.

Kernel version

5.10.236-android12-9-00020-gf997514b333d-ab13743839

KernelPatch version

Upgrade from 0.12.2 to 0.13.3

Other information

This report is about false success reporting in APatch Manager. The device-specific write protection itself does not need to be bypassed by APatch. Correctly reporting the failed write would let users choose an appropriate external flashing method instead of repeatedly rebooting with an unchanged boot partition.