Bootloop After OTA With Data at Stake
A 4G handset with a MediaTek MT6765-class chipset, 3 GB RAM and 32 GB storage comes in stuck on the brand logo. The owner accepted an over-the-air update two days ago; since then the phone restarts every 25-30 seconds, sometimes reaching the recovery menu. The bootloader is locked, USB debugging was never enabled, and the phone holds about 2,800 photos and a business WhatsApp account. The shop has a licensed flashing box, a Windows laptop, the exact-model firmware package (same build number), a firmware package for the 4 GB/64 GB variant, and a universal ADB driver. The battery shows 45%, the USB-C port is loose and disconnects if the cable is moved, and the customer's train leaves in three hours. The shop's standard flashing charge is ₹600, with a written 'data loss is customer's risk' clause.
1. Order your attempts to recover the phone while preserving data; justify why each step comes before the next.
Read the worked answer
Make the connection and power stable. Clean the USB-C port, use a known-good cable, support the plug, and charge the battery to at least 50–60%. A flash or update that loses power or USB connection mid-write can hard-brick the phone. This must come first because every later step depends on a reliable link.
Use recovery mode with the least destructive option. Try 'wipe cache partition' only, then reboot. Cache wipe does not touch user data and can clear a bad OTA cache. Do not choose 'wipe data/factory reset'.
Try a signed same-build OTA by sideload. If recovery is reachable, use 'apply update from ADB' with the exact same-build full OTA package. A signed OTA can repair the system without wiping user data.
Only then consider flashing exact-model firmware with a 'download only' or keep-userdata option, never 'format all'. Do not unlock the bootloader, because unlocking normally wipes data. Do not downgrade, because anti-rollback can permanently brick the phone.
The order is least destructive first: each step carries more risk of data loss than the one before. With three hours left, I would not skip the charging and port-stability step to save time.
2. Assess the risks of using the 4 GB/64 GB firmware and of flashing with the current battery and port. What conditions must be met before any flash?
Read the worked answer
The 4 GB/64 GB firmware is not a safe substitute. Even with the same chipset family, the partition layout, preloader and memory configuration can differ. Using it can fail at the preloader stage, trip anti-rollback, corrupt the baseband or IMEI area, or leave a phone that no ordinary tool can recover. The exact-model, same-build package is the only acceptable base for a flash attempt.
The 45% battery is marginal. A short flash may complete, but a voltage sag during a critical write can brick the phone. The loose port is worse: a disconnect during flashing is a known cause of dead boards. Before flashing, I would charge to at least 50–60%, clean and stabilise the port, use a short known-good cable, and avoid moving the phone. I would also verify the firmware checksum and model, confirm the customer understands the data-loss risk in writing, and check whether a less destructive OTA sideload is still possible. If the port cannot be made reliable, I would not start a flash just because the customer is in a hurry.
3. The phone dies during flashing and no longer responds. What are your obligations and how do you handle the customer?
Read the worked answer
I would stop, unplug, and not retry blindly with another package. I would record exactly what happened: the tool used, firmware name and checksum, battery level, port condition, time, and the point at which it failed. The phone was already bootlooping, and the risk was disclosed, but that does not remove my duty to be honest and to try a reasonable recovery.
I would tell the customer before the train leaves: the flash did not complete and the phone is now unresponsive. I would offer a no-extra-charge attempt to reach download mode with the correct tool and exact firmware, within a fixed time limit. If that fails, I would refund the ₹600 flashing fee and give a written report with options: authorised service centre, board replacement, or data-recovery specialist. If the failure was caused by my own error, such as using the wrong variant or flashing with an unstable port, I would accept responsibility for the loss rather than blame the phone. I would not keep the phone indefinitely without the customer's written consent.