Status 7 is a recovery error that stops a ZIP install. It usually means an assert check failed inside the package. The package checks your device and your current system before it writes anything. When a check fails, recovery aborts to protect the phone. That abort is frustrating but it prevents a worse outcome.
Common causes include a wrong device build and a corrupt download. Other causes include an outdated recovery and a mismatched firmware version. Signature checks can also fail when a package is modified. Each cause has a different fix. Guessing the fix wastes time and can damage data.
Read the full error text before you act. Recovery shows lines above the Status 7 line. Those lines name the failed check. Copy the text exactly into your notes. The exact wording points to the cause faster than any generic search. Do not wipe data before you understand the error.
This article walks through diagnosis in order. Start with the cheapest checks and move to deeper fixes only if needed. Keep your backup ready throughout. Most Status 7 cases resolve without data loss when you follow the order.
When you are ready to go further, read about how custom ROMs handle VoLTE and fingerprint hardware and compare it with the plan you made for your own phone.
Read The Error Message Carefully
Boot to recovery and repeat the install to capture the message. Look for lines that mention device codename or build version. Look for lines that mention signature or file verification. Look for lines that mention a missing partition. Each line is a clue and not noise.
Write down the codename the package expects and the codename your phone reports. A mismatch here is the most common cause. Also note the recovery version you use. An old recovery may fail a check that a new recovery passes. Exact notes make forum help much faster.
- Read the full error lines above Status 7
- Confirm codename and version match the package
- Verify checksum before every flash attempt
- Use the recovery version the guide recommends
- Never edit a signed ZIP before flashing
Confirm The Package Matches Your Phone
Download the ZIP again for your exact codename. Check the file name for the codename string. Check the file size against the download page. If the size differs, the download is incomplete. Delete it and download again on stable Wi-Fi or a wired connection.
Compare the Android version target of the package with your current system. Some packages require a minimum stock version. Update stock firmware first if the package demands it. A version gap can trigger an assert even when the device matches. The package notes state any such requirement.
Verify File Integrity Before Flashing
A corrupt ZIP fails verification even when the name looks right. Use the checksum from the download page when one is provided. Compute the checksum on your computer and compare it character by character. A single differing character means a bad file. Do not flash a file with a bad checksum.
Also check the storage where the ZIP sits. A failing SD card can corrupt a file after a good download. Copy the ZIP to internal storage and try again. If internal storage also fails, test a different cable and a different USB port. Hardware faults hide behind software errors more often than people expect.
When you are ready to go further, read about tuning battery life on a custom ROM and compare it with the plan you made for your own phone.
Update Recovery To A Matching Version
Recovery and ROM builds evolve together. An old recovery may lack a check the new package needs. A new recovery may enforce a check the old package lacks. Use the recovery version your ROM guide recommends. Flash that recovery and retry the install.
Some devices need recovery flashed to a specific slot. Follow the slot note for your model. Flashing recovery to the wrong slot leaves the old recovery in place. The error then persists even though you think you updated recovery. Verify the recovery version on screen after flashing.
Handle Signature And Verification Fails
Signed packages fail verification when any byte changes after signing. Do not unzip and rezip a signed package. Do not edit files inside it. Download a fresh copy instead. If you built the package yourself, sign it correctly before flashing. An unsigned test package needs a recovery setting that allows it.
Some recoveries offer a signature verification toggle. Toggling it off can install an unsigned package. Use that toggle only for packages you trust and built yourself. Never toggle it off for a random download. A signature check is a safety net and not an obstacle to bypass casually.
Fix Assert Lines For Your Device
Assert lines compare your device properties with expected values. A renamed device or a changed build property can break the check. Restoring stock firmware often restores the expected properties. If you changed build properties by hand, revert those changes first. Then retry the install.
Dual SIM and regional variants can also trigger asserts. The package may expect one variant while your phone reports another. Check the variant list on the download page. If your variant is absent, do not force the install. Wait for a build that lists your variant or seek a build for your region.
When you are ready to go further, read about keeping OTA updates working on official builds and compare it with the plan you made for your own phone.
Recover Cleanly After Repeated Fails
If several fixes fail, stop and protect your data. Boot to recovery and confirm your backup is intact. Reflash recovery and try a known good ZIP from an earlier version. A success with an older ZIP proves the phone and recovery work. The problem then lies with the newer package.
Seek help with your full error text and your device details. Include codename and recovery version and package version. Include the steps you already tried. Clear reports get useful answers. Vague reports get guesses that waste your time.
Why Recovery Aborts Instead Of Forcing The Install
Recovery aborts a failing install to protect partitions. A forced install could write a system for the wrong device. That write could break the modem or the bootloader. An abort leaves the old system intact. That intact system lets you try again. The abort feels annoying. It is actually a safety feature working as designed. Respect the abort and read its message.
Assert checks compare device properties before writing. They check codename and version and partition layout. They check signatures on signed packages. Each check guards a different failure. A codename check guards wrong device flashes. A version check guards firmware gaps. A signature check guards tampered files. Together they form a safety net. Bypassing the net removes protection you may need.
Some users edit packages to remove assert checks. That edit can allow a wrong install to proceed. The phone may then bootloop or lose radio function. Editing asserts should stay a last resort for developers. Regular users should fix the underlying mismatch instead. A correct package needs no assert edit. Seek the correct package first.
Build A Status 7 Diagnostic Routine
Start every Status 7 case with the same routine. Capture the full error text first. Check codename match second. Check file checksum third. Check recovery version fourth. That fixed order prevents random guessing. Random guessing wastes time and risks data. A routine turns a scary error into a checklist. Checklists work under stress.
Keep a log of each attempt and its result. Note the package version and recovery version for each try. Note the error text for each try. A log reveals patterns across attempts. It shows whether a change helped or hurt. It also helps forum helpers. Helpers trust logs more than summaries. A good log often leads to a fast answer.
If the routine fails three times, pause and seek help. Post the log with device details. Include codename and recovery version and package version. Include steps already tried. A complete post respects helper time. It also protects your phone from further random attempts. Pausing is a skill in troubleshooting.
Status 7 On A And B Slot Devices
A and B devices add slot complexity to Status 7 diagnosis. The package may target the active slot. Recovery may report the inactive slot. A slot mismatch can trigger an assert failure. Check the active slot before flashing. Switch slots deliberately when the guide requires it. Random slot switching confuses diagnosis. Know your current slot at every step. Slot awareness prevents a whole class of errors.
Updates on A and B devices install to the inactive slot. A failed update leaves the active slot intact. That design protects the working system. Recovery can boot the old slot after a failure. Use that fallback instead of wiping data. Wiping data cannot fix a slot targeting error. Slot fallback is the intended recovery path. Learn it before you need it under stress.
Some Status 7 errors on A and B devices mention slot specific partitions. Read those partition names carefully. A system partition name may include a slot suffix. A missing suffix in a command targets the wrong slot. Copy commands exactly from the guide for your layout. Do not adapt commands from A only guides. Layout specific commands exist for a reason.
When Status 7 Indicates A Truly Incompatible Package
Some Status 7 errors mean the package simply does not fit your phone. The codename may match but the variant may differ. A dual SIM variant may need a different package than a single SIM variant. A carrier variant may need its own package. The download page variant list is the authority. If your variant is absent, the package is incompatible. Accept that verdict instead of forcing the install. Forcing risks radio and sensor damage.
Incompatible packages sometimes come from outdated mirrors. A mirror may host an old package under a new name. Check the package date and version against the official page. A mismatch signals a stale mirror. Download from the source your guide names. Fresh sources reduce incompatibility surprises. Mirror hygiene matters as much as file hygiene. Trust sources with current listings.
If no compatible package exists, wait or choose another project. A patient wait often brings a compatible build. Another project may already support your variant. Forcing an incompatible package helps nobody. It risks a phone that needs stock recovery. Stock recovery costs time and data. Waiting costs only time. Choose waiting over risking hardware function.
adb reboot recovery
adb sideload rom.zip
sha256sum rom.zip
fastboot flash recovery recovery.imgThe steps above follow the approach described in the official developer documentation for this platform and in the recovery guides that explain install checks.
