PO Pocket System Notes
ROM Decisions

Before Installing a Custom ROM: 12 Checks

Pocket System Notes · Updated 2026-07-19 · 4 min read
Before Installing a Custom ROM: 12 Checks
Fast takeBefore installing a custom ROM, verify the exact hardware model, carrier or region variant, codename, current firmware, bootloader-unlock support, and ROM support. Assume supported unlock and relock operations erase user data. Make and test multiple backups, inventory essential apps and eSIM recovery, read the complete device-specific guide, verify downloads, prepare reliable power and USB, and secure official factory images and recovery instructions. Check security-update cadence and hardware gaps. Never relock unless that ROM's current instructions explicitly support it, and stop when any model, backup, image, or recovery detail is unclear.
Contents

A custom ROM starts with a recovery plan

Before installing a custom ROM, confirm the exact device variant and project support, understand the bootloader wipe, verify independent backups, read the complete device-specific instructions, and secure a tested route back to official software. Then decide whether update cadence, app compatibility, hardware support, and security tradeoffs make sense for a phone you rely on.

This is a decision checklist, not a flashing tutorial. Commands, partitions, images, recovery methods, and relocking rules vary by device and build. A command correct for a similarly named phone can be impressively wrong for yours.

1. Identify the exact hardware

Record the manufacturer model number, product name, region, carrier variant, storage size, current Android build, bootloader version, and project codename from trustworthy device screens and official documentation. Do not infer compatibility from the retail family name.

Confirm that the ROM's current device page names that exact variant. Some phones with nearly identical branding use different radios, partition layouts, cameras, or chipsets. If the documentation is ambiguous, stop and ask the project's supported help channel before downloading anything.

2. Verify that bootloader unlocking is supported

The Android Open Source Project describes bootloader unlocking as the state that allows custom operating-system software to be installed. Actual availability, account requirements, waiting periods, carrier restrictions, codes, warranties, and tools come from the manufacturer and exact variant.

Read the official device-maker policy. Do not use a bypass, leaked utility, paid unlocker, or exploit merely because the normal option is absent. An unsupported route raises security, legality, fraud, and recoverability concerns.

3. Accept the data wipe before you proceed

Android's boot flow and compatibility requirements use secure deletion of user data during supported bootloader state changes. Plan for unlocking—and often relocking—to erase the phone completely. Never start with data that exists in only one place.

Record the screen lock and account credentials needed after reset. Confirm factory-reset protection and ownership implications.

4. Build more than one backup

Google's Android Help states that not every app backs up or restores all settings and data, and a backup from a newer Android version cannot be restored onto an older version. Review backup details rather than trusting one cheerful “complete” label.

Copy irreplaceable photos, downloads, documents, recordings, authenticator recovery codes, local contacts, calendars, message exports where supported, app-specific exports, and work files to another device or service. Verify by opening samples. Keep a second independent copy of critical data.

Do not copy secrets into an unencrypted public folder. Work profiles and managed devices may prohibit modification entirely.

5. Inventory accounts, SIMs, and essential apps

List banking, payment, identity, government, work, accessibility, health, media, camera, vehicle, smart-home, and authentication apps you need. Custom software, an unlocked bootloader, or changed device integrity can cause some apps, DRM features, contactless payments, enrollment systems, or protected content to stop working.

Document eSIM and carrier reprovisioning requirements without deleting the active profile prematurely. Make sure another device can receive account-recovery messages. If this is your only phone for work, travel, medical contact, or two-factor authentication, practice on nonessential hardware instead.

6. Check current ROM maintenance

Use the project's official device page and repository. Confirm that the exact device is currently supported, the release is intended for it, the security-patch status is stated, installation documents are current, and downloads use project-controlled infrastructure. Verify hashes or signatures when the project publishes them.

7. Audit hardware and feature gaps

Check calls, mobile data, emergency calling, Wi-Fi, Bluetooth, GPS, NFC, biometrics, camera modes, microphones, speakers, sensors, encryption, hotspot, USB, display refresh, stylus, foldable behavior, and accessibility features relevant to you. Community reports can reveal problems, but distinguish the exact build and hardware variant.

“Mostly works” is not a technical specification. Decide which missing feature is a nuisance and which one makes the phone unsafe or unusable.

8. Read the entire install guide in order

Use only the project page for your exact device and release. Read from preparation through first boot before taking action. Note required firmware versions, host operating systems, official platform tools, cable mode, battery level, partition instructions, warnings, and expected screens.

9. Prepare reliable tools and power

Use a computer you control, current official tools required by the guide, a known data-capable cable, a reliable USB port, and steady power. Verify downloads and unpack them as documented. Avoid hubs or virtual machines if the device guide warns against them.

10. Secure the official recovery route

Before modifying anything, obtain the exact official factory images, recovery utility, drivers, and return instructions for your variant if the manufacturer provides them. Store them offline with checksums and documentation. Confirm that the recovery path still works for the current bootloader version; anti-rollback and tool changes can matter.

A theoretical stock package behind a dead link is not a recovery plan.

11. Do not assume the bootloader can be relocked

Relocking typically wipes data and can make a device unbootable when the installed operating system is not signed or structured for that device's verified-boot policy. Relock only when the exact ROM's current device instructions explicitly support it and all prerequisites are satisfied.

Android Verified Boot exists to establish a chain of trust. Treat lock state as a security decision, not a cosmetic warning-removal trick.

12. Define a stop point

Write the condition that cancels the project: no current maintainer, missing factory image, unverified backup, unsupported model, essential app failure, unclear instruction, unreliable USB, or no spare communication device. Then obey it.

If your real goal is visual or workflow change, start with customizing Android without root. Browse ROM decisions only when the operating system itself is the justified target.

Sources

FAQ

Will installing a custom ROM erase my phone?

Plan for data loss. Supported bootloader unlocking securely erases user data, and relocking commonly erases it again; installation instructions may require additional formatting. Back up independently, inspect what each backup contains, and open sample files before proceeding. Some app data, authentication secrets, work profiles, and eSIM information may not restore. Never start when irreplaceable data exists only on the device.

How do I know a custom ROM supports my phone?

Match the manufacturer model number, region or carrier variant, project codename, required firmware, bootloader state, and current device page—not merely the retail family name. Use the ROM project's official download and documentation channels. Confirm that the maintainer and release are current and read known issues. If any identifier or instruction is ambiguous, ask the project's supported help channel and do not flash.

Can I relock the bootloader after installing a ROM?

Only when the exact ROM and device documentation explicitly supports relocking and every verified-boot prerequisite is satisfied. Relocking usually wipes data and can leave the phone unable to boot when installed images are not accepted by that device's trust policy. Do not use a generic relock command to remove a warning. Follow the current project procedure or leave the state unchanged while seeking qualified help.

Will banking apps work on a custom ROM?

They may not. Banking, payment, government identity, work enrollment, DRM, streaming, contactless payment, and other apps can depend on device integrity, certification, security hardware, or an expected operating-system state. Requirements can change without notice. Test on nonessential hardware or confirm with the service provider, but do not bypass security controls or rely on unofficial workarounds for important accounts.

What should a custom ROM recovery plan include?

Keep the official factory images or recovery package for the hardware variant, current manufacturer tools and drivers, checksums, written return instructions, account credentials, backup decryption information, reliable cable and power, and another working communication device. Verify that links and procedures still apply to the current bootloader. A recovery file for a similar model or an older anti-rollback state can make the situation worse.