Bootloop After an OTA Update: The Only Copy of the Family Photos
A customer brings in a three-year-old Android handset that rebooted during a system update and now loops: the brand logo appears for 6–9 seconds, the screen goes black, and it restarts. It never reaches the lock screen. The phone belonged to her late husband and holds the only copy of family photographs; she knows the 4-digit PIN. In recovery mode the options Wipe data/factory reset, Apply update from ADB and Reboot to bootloader are available; the bootloader is locked and the device is signed into a Google account. With the back cover off, the battery reads 3.42 V at rest and sags to 3.1 V under a 1 A load. Your bench has a current-limited DC power supply, a USB cable, a Windows PC with the manufacturer's official firmware tool, the full OTA package of the version already installed, and the newer version that triggered the update. The customer will pay for a data-recovery attempt but not for a board replacement.
1. What do you check before treating this as a software fault, and why does it matter here?
Read the worked answer
The battery, before anything is flashed. An open-circuit reading of 3.42 V means a low state of charge, and a sag to 3.1 V at only 1 A means high internal resistance - that is a battery that cannot hold the rail during boot. A failing cell produces exactly this symptom: logo, brown-out, restart, repeat. Flashing on a marginal battery is also the classic way to permanently brick a phone, because a power dip in the middle of writing the bootloader or system partition leaves a half-written image.
So: substitute a known-good battery, or power the phone from the current-limited supply at 3.9–4.1 V with the correct capacity limit, and retest before touching software. If the phone then boots to the lock screen with the customer's PIN, the whole problem was the battery and the photos are safe. Only if the loop persists on a stable supply do you move to firmware work - and you have then eliminated the most common hardware red herring at zero cost.
2. If the loop persists, which flashing option do you choose and why is it the least destructive?
Read the worked answer
Rank the options by how much they touch the user data partition:
- Sideload the full OTA of the same build from recovery is the first choice. A signed full OTA rewrites system, boot and vendor images and can repair a corrupted boot chain, but it does not erase /data and does not touch the user's encryption keys, so the photos remain readable.
- Download-mode flashing with the vendor's 'keep data' package (the home/no-wipe variant rather than the full-erase variant) is the second choice, again same version only.
- Wipe data/factory reset is the last resort and destroys the very thing the customer is paying to recover - never press it first.
- Downgrading or flashing a different build risks anti-rollback protection and can leave the encryption keys incompatible with the new keystore, making the data permanently unreadable even if the phone boots.
- Unlocking the bootloader triggers a mandatory data wipe, so it defeats the purpose.
Rule: same version, signed package, no-wipe option, and stop the moment an option requires erasing userdata.
3. The attempt fails and the phone still loops. What do you do now, and what should have been agreed in writing first?
Read the worked answer
Stop experimenting. The phone is the only copy, and further flashing reduces the odds of a professional recovery.
Options to present:
- Specialist data recovery, such as reading the eMMC/UFS directly by ISP or chip-off, which can bypass the boot chain entirely. Explain the cost (often far more than the handset is worth), the real chance of failure, and the risk that the memory is encrypted and useless without the working board.
- Return the phone in exactly the condition it arrived in, with a written note of what was attempted.
- Charge only what was agreed - often a reduced fee or nothing if the recovery failed.
What should have been signed before starting: a data-recovery consent form stating that the fault may be hardware, that recovery is not guaranteed, that some procedures can cause total data loss, and that the customer accepts this and has been advised to stop using the device. Also record the IMEI, the condition on arrival and photographs of the handset. Afterwards, advise cloud backup and a memory card - and never promise a recovery you cannot guarantee.