TL;DR: To recover Android bootloop after kernel flash on an A/B device, back up anything still accessible, inspect the active slot, try the known-good slot, then restore only the modified partition from the exact installed firmware. If that fails, sideload a full signed OTA; use a complete, usually data-wiping factory flash last.
By the PrivacyPortal team
Last updated July 2026.
A failed over-the-air update or incompatible kernel does not automatically mean an A/B Android device is permanently bricked. Recovery normally follows a controlled ladder: preserve data, identify the current slot and build, switch slots only when safe, restore the partition actually modified, install a matching full OTA, and finally reflash complete factory firmware. Stop guessing if the firmware version is unknown: mixing boot images from different builds can turn a recoverable bootloop into a harder failure.
How to recover Android bootloop after kernel flash safely
Before running any command, assume that recovery may erase the phone. Back up files, authenticator recovery codes, messaging databases and app-specific exports whenever recovery or Android still provides access. Bootloader unlocking wipes user data by design, so do not unlock an already locked bootloader merely to attempt these fastboot steps.
An unlocked bootloader changes the device’s security state and may affect warranty support, over-the-air updates, banking apps and Play Integrity checks. Relocking with modified or mismatched partitions can prevent booting. No rooting, kernel or concealment method can be promised to pass a particular bank’s checks.
The recovery order matters. A/B devices keep two sets of selected boot-critical partitions, called slots A and B. An update normally installs to the inactive slot before the bootloader tries it. A failed kernel flash, however, may modify the currently active slot directly.
Image caption: Fastboot mode showing the product name, bootloader status and current active slot before any recovery command is issued.
Android’s A/B boot-control design tracks three distinct slot properties: active, bootable and successful.
Diagnose the failure before flashing anything
First establish which states remain accessible. A phone that reaches fastboot or bootloader mode is usually recoverable with the correct firmware. A phone that reaches stock recovery may accept a signed full OTA through ADB sideload. If neither fastboot nor recovery appears, the device may require a manufacturer-specific emergency mode or professional repair.
- Bootloop after a kernel app reports success: suspect an incompatible boot, init_boot, vendor_boot or device-tree image.
- Bootloop immediately after an OTA: suspect an unsuccessful new slot, interrupted update or incompatible rooted boot image.
- Fastboot works but recovery does not: boot-critical partitions may be inconsistent even though the bootloader remains intact.
- “No valid slot to boot”: neither slot is currently marked bootable; switching slots repeatedly will not repair their contents.
- Boot starts but data cannot be decrypted: stop before formatting. Firmware, recovery and encryption metadata may not match.
Record the device’s exact model, regional variant, Android build number and previous active slot. If Android is unavailable, the bootloader screen or fastboot getvar all may expose useful version fields. Do not post the complete output publicly because it can include serial numbers.
Choose the least destructive recovery method
| Method | Use it when | Data risk | Main limitation |
|---|---|---|---|
| Switch A/B slot | The other slot contains a known-good installation | Low, but not zero | Rollback rules or an incomplete snapshot merge may prevent booting |
| Restore one stock partition | You know exactly what the kernel installer changed | Usually low | The image must match the installed build and slot |
| Sideload a full signed OTA | Stock recovery works and matching firmware is available | Normally preserves data | Downgrades and unsigned packages are rejected |
| Flash complete factory firmware | Individual repairs and OTA sideload fail | High; plan for a wipe | Wrong model, region or options can worsen the failure |
| Format data | Firmware is correct but encryption or user data prevents booting | Complete data loss | Does not repair an incompatible kernel by itself |
Prerequisites and files you need
Use a reliable USB data cable, a charged phone and a computer with the current official Android SDK Platform-Tools. Run fastboot --version and save the displayed version with your recovery notes. Avoid old “minimal ADB” bundles because outdated fastboot builds can mishandle modern dynamic partitions.
Obtain factory images or a full signed OTA only from the device manufacturer. The required images must match the exact device, region and installed build. On an A/B device, boot, init_boot, vendor_boot, dtbo, vbmeta, vbmeta_vendor and vbmeta_system files from different OTA versions are not interchangeable merely because they belong to the same model.
Kernel packages and flashing apps such as Horizon Flasher and Kernel Flasher may keep a backup of the original image. Treat that backup as valid only if it came from the same phone, slot and installed build. The automatically appended “Modules, apps & files to try” section identifies these apps; they are useful while Android still boots, but they cannot rescue a phone that only reaches fastboot.
Step-by-step A/B Android recovery procedure
- Protect anything still reachable. If Android or recovery exposes user files, copy them before changing slots or partitions. Do not unlock the bootloader as a recovery experiment: unlocking wipes data. Keep the phone above 50% charge and prevent the computer from sleeping during a flash.
- Confirm fastboot communication. Enter the manufacturer’s bootloader or fastboot mode, connect USB and run fastboot devices. Continue only when the expected device appears consistently. A blank result usually means a cable, port, driver or mode problem rather than damaged firmware.
- Inspect the active slot. Run fastboot getvar current-slot. Record whether the result is a or b. Also record build and bootloader information visible on screen. Do not use commands copied from another model without checking the manufacturer’s partition layout.
- Try the known-good slot only when appropriate. If the failure followed an OTA and the old slot is known to contain the previous working system, use fastboot set_active a or fastboot set_active b, choosing the other slot, then run fastboot reboot. Do not switch during an active virtual A/B snapshot merge, and do not expect a slot containing older firmware to bypass anti-rollback protection.
- Return to fastboot if the other slot fails. Set the original slot active again before partition-level repair. Repeatedly alternating slots does not fix corrupted contents and makes the recovery history harder to follow.
- Identify what the kernel installer modified. Consult the kernel’s installation log or documentation. Traditional custom kernels commonly alter boot; newer devices may also involve init_boot, vendor_boot or dtbo. A Magisk-patched boot image is not a valid KernelSU kernel, and KernelSU or APatch packages must match their documented architecture.
- Restore only the confirmed partition. For a kernel stored in boot, place the exact matching stock image in the Platform-Tools directory and run fastboot flash boot boot.img. If the installer changed init_boot, use fastboot flash init_boot init_boot.img. Flash additional partitions only when the installation record proves they changed. Do not casually flash vbmeta or disable verification; verified-boot metadata must remain consistent with the firmware.
- Reboot and verify. Run fastboot reboot. Allow several minutes for the first boot, but stop if the phone repeatedly resets or becomes unusually hot. Once Android starts, verify the build number, active slot, Wi-Fi, mobile service, camera and encryption. Remove or update the incompatible kernel-flashing configuration before the next OTA.
- Sideload a complete signed OTA if individual restoration fails. Enter stock recovery, select the option to apply an update from ADB, then run adb sideload exact-full-ota-file.zip. Follow the manufacturer’s instructions and use a full OTA compatible with the installed build and rollback rules. A percentage mismatch between the computer and recovery can be normal; trust recovery’s final success or error message.
- Use complete factory firmware as the final software recovery. Follow the manufacturer’s official flashing procedure, such as the Android Flash Tool for supported devices. Assume this step will erase user data even if a tool offers a no-wipe option. Verify the device, region and build before starting, and do not disconnect it until the tool reports completion.
Image caption: A recovery workstation containing the exact full OTA, matching factory images and an up-to-date Platform-Tools installation.
When restoring boot, init_boot and dtbo is not enough
A modern kernel installation can depend on firmware interfaces outside the obvious kernel image. Restoring boot, init_boot and dtbo may therefore leave recovery inaccessible if vendor_boot, verified-boot metadata, slot state or another component remains inconsistent.
In one community case, a SUSFS-enabled Wild Sultan kernel intended for different firmware failed before the Google logo on Android 17 QPR1 beta 7. Restoring init_boot, boot and dtbo did not restore boot or recovery. Flashing the corresponding complete ROM through Android Flash Tool recovered the device without a wipe. That outcome is useful evidence, not a guarantee: no-wipe factory recovery varies by device and build.
A reported failure on build CP31.260623.005 required the complete matching ROM after restoring boot, init_boot and dtbo proved insufficient.
If several matching stock partitions fail, stop adding unrelated images. A complete signed firmware package is safer than constructing a hybrid installation from multiple releases.
Common recovery mistakes that cause harder bricks
- Using a boot image from a similar build: even a small monthly update can change the kernel, ramdisk and verified-boot chain.
- Flashing both slots immediately: this can overwrite the only working fallback.
- Formatting data first: a format removes personal data but does not replace an incompatible kernel.
- Relocking too early: relock only after completely stock, correctly signed firmware boots and the manufacturer’s procedure explicitly supports it.
- Flashing vbmeta as a universal fix: mismatched verified-boot metadata can block boot or weaken security without addressing the actual kernel failure.
- Ignoring regional variants: modem, vendor and bootloader differences can matter even when product names look similar.
- Interrupting a virtual A/B merge: snapshot state can make slot switching and partial flashing unsafe.
- Assuming root concealment equals compatibility: Magisk, APatch, KernelSU and SUSFS use different mechanisms. App detection, Play Integrity and banking behaviour vary by device and update.
How to prevent the next failed kernel flash
Before installing a custom kernel, save the exact factory package and note the current build, slot and kernel version. Read the kernel’s supported-device and supported-firmware list literally. “Same Android version” is not sufficient evidence of compatibility.
Horizon Flasher and Kernel Flasher can make routine kernel installation more convenient, but convenience does not remove partition risk. Keep any original-image backup outside the phone, because internal storage may become inaccessible during a bootloop.
Disable automatic installation until you understand how the custom kernel interacts with OTAs. Rooted A/B updates often require restoring stock images before updating and reapplying modifications only after the new slot boots successfully. The official Android A/B update documentation explains the slot model and boot-success process.
Readers planning a fresh privacy-focused setup may also find our guide to installing GrapheneOS and practical Android rooting guide useful. Treat installation and rooting as separate decisions: a privacy-respecting operating system does not inherently require root.
On 12 July 2026, community guide author Yuri described returning to Magisk as a personal preference while still rating KernelSU and its forks strongest for root hiding.
Image caption: A pre-flash checklist recording the device model, firmware build, active slot, stock-image checksum and kernel compatibility statement.
Frequently asked questions
Can switching slots recover an Android bootloop after a kernel flash?
Sometimes. It works when the other slot remains bootable and contains firmware allowed by the bootloader’s rollback rules. It is most useful after a failed A/B OTA. A flashing app may have modified only the active slot, but some installers touch shared or additional partitions, so slot switching is not guaranteed.
Does flashing stock boot.img erase user data?
Flashing the correct boot image normally does not erase the data partition. The risk remains significant: an image from the wrong model or build can prevent booting, and later recovery steps may require a factory reset. Back up before kernel modification, not after a failure.
Should I flash vbmeta with boot.img?
Not by default. Flash vbmeta only when the device-specific official procedure or a verified installation record requires it, using the exact matching firmware. Disabling Android Verified Boot is not a general recovery method and can reduce security.
Can a full OTA sideload preserve my files?
A signed full OTA installed through stock recovery normally preserves user data, provided the package is compatible and the device accepts it. Corruption, encryption problems or manufacturer-specific behaviour can still force a reset, so preservation must never be assumed.
Will factory firmware always fix a failed kernel flash?
Complete matching factory firmware resolves most software-only failures when the bootloader or supported flashing mode remains accessible. It cannot repair hardware damage, and flashing the wrong package can worsen the problem. Treat factory flashing as data-wiping unless the manufacturer explicitly documents otherwise.
Can I recover without unlocking the bootloader?
A locked device may accept a manufacturer-signed full OTA through stock recovery or an official rescue tool. It generally will not allow arbitrary partition flashing. Unlocking the bootloader erases user data and may be unavailable after the phone stops booting, so it is not a harmless recovery shortcut.
