Bootloop diagnosis: finding where the boot actually stops

People report bootloops as a single symptom, which is why the advice they get is usually useless. A device stuck on the manufacturer logo and a device cycling through a boot animation for twenty minutes have almost nothing in common except that neither reaches the home screen.

The useful question is not how to fix a bootloop. It is where does the boot stop — because each stopping point maps to a different layer, and each layer has a different fix.

Read the stopping point

Logo loop: verification and kernel

Stopping right after the logo means the bootloader handed over and something immediately refused to continue. The common causes:

• Boot image mismatch — a kernel that does not match the device or the installed system
• Verified boot rejection — the image is modified and the bootloader is locked, so the device stops rather than running it
• Missing vbmeta handling after flashing a custom image
• An incomplete flash where the boot partition was written partially

This is the layer fastboot is best at fixing, because you can replace the boot image alone and see whether the behaviour changes.

Animation loop: system and vendor

Reaching the animation is genuinely good news. The kernel loaded and Android is starting. Something is then failing during init and taking the system down with it.

The classic causes, in rough order of frequency:

1. A missing or mismatched vendor partition. A Treble ROM without a correct vendor image reaches exactly this point and stops — the situation described in the LineageOS install guide.
2. Unreadable data partition. Init cannot mount it, retries, fails. This looks identical to a ROM problem and is not — see TWRP mount failures.
3. GApps flashed after first boot, or a package mismatched to the Android version.
4. Permissions or SELinux context problems after files were copied in manually.

A working order

1. Wait long enough to be sure it is a loop and not a slow first boot.
2. Note the exact stopping point. This is the diagnosis, not a detail.
3. Try recovery. If you can reach it, wipe cache and dalvik — cheap and occasionally sufficient.
4. Check the partition that matches the layer from the table above.
5. Replace one partition at a time and retest. Reflashing everything at once tells you nothing about what was wrong.
6. Capture logs if the device gets far enough — adb logcat over USB often works during an animation loop even though nothing is on screen.

Frequently asked questions

How long is too long for a first boot?

Several minutes is normal after a fresh flash. Beyond roughly ten, treat it as a loop.

Will wiping cache fix a bootloop?

Sometimes, for app and dalvik-level problems. It will not help with a missing vendor partition or a verification failure.

Can I get logs from a device that never boots?

If it reaches the animation stage, adb logcat frequently works. Before that, no.

Bootloop right after a system update. Cause?

Often a partial or interrupted update, or a rollback protection conflict. Reflashing the matching full firmware is the usual route.

My device loops only when warm.

That pattern points at hardware — thermal or power delivery. Software fixes will not change it.