A service report for an older phone contained these fields:
Model name: Redmi Pro
Manufacturer: Xiaomi
Device code: omega
Product name: omega
ABI: arm64-v8a
Android version: 6.0
Build fingerprint: Xiaomi/omega/omega:6.0/MRA58K/8.0.7.0:user/release-keys
SoC: mt6797
Boot verified boot state: green
The commercial model is Xiaomi Redmi Pro and its Android device codename is omega. That conclusion comes from several matching identifiers, not from a single filename or a reseller description.
The same report also included a serial number and service job identifier. Those values are not needed for public troubleshooting and should be removed before sharing logs.
Model name, model number and codename are different things
Android service tools often expose several identities at once:
- Commercial name: the name printed on packaging and used in shops, such as Redmi Pro.
- Regulatory or hardware model number: a manufacturer-specific identifier that may distinguish markets or radio variants.
- Device codename: an internal Android product identifier used in builds, recovery packages and source trees.
- Product name: a build target that is often, but not always, the same as the device codename.
- SoC platform: the chipset family used by the board.
Huawei-style identifiers such as ANE-LX1 combine a product family with a regional or hardware suffix. Xiaomi frequently uses memorable codenames such as omega, but that codename should not be treated as a complete regulatory model number.
For firmware work, the codename is useful. For ordering parts, confirming LTE bands or proving regulatory identity, read the label, packaging and the model field in Settings as well.
Decode the build fingerprint
Android build fingerprints follow a structured pattern. In this example:
Xiaomi/omega/omega:6.0/MRA58K/8.0.7.0:user/release-keys
The components identify the brand, product, device, Android release, build ID, incremental build, build type and signing tags. Android’s compatibility definition documents this general fingerprint structure.
Here, both the product and device components are omega, the Android release is 6.0, and the system build is a production-style user/release-keys build. This is stronger evidence than an app reporting only a friendly model string, because apps can display incomplete or overridden labels.
Use at least three matching fields before selecting a ROM or recovery package:
- commercial model or label;
- device/product codename in the fingerprint;
- chipset or board platform.
If any one conflicts, stop and investigate the exact variant. Flashing a package because its filename contains the commercial name can brick a device when that name covers multiple boards.
Do not overinterpret individual properties
Some report fields look more definitive than they are.
nosdcard does not prove the phone lacks a microSD slot
Build characteristics: nosdcard is an Android storage/build characteristic. It is not a reliable physical inventory of card slots. Verify expandable-storage support from the exact hardware documentation or by inspecting the SIM/card tray.
green is a boot-verification state, not a complete forensic verdict
Android defines the green verified-boot state as a verified chain of trust. The current Android attestation documentation explains the verified, self-signed, unverified and failed states.
An old service report can combine properties collected from different layers or moments. If a system fingerprint says release-keys while a boot-related field contains userdebug/test-keys, preserve the mismatch as evidence. Do not declare the phone stock, rooted or compromised from that contrast alone.
A service tool may display stale or synthesized values
Cross-check the label, fastboot/recovery output and Settings screen when possible. Record the collection method and timestamp. A pasted report without provenance is useful for identification, but not sufficient for high-risk flashing.
A safe identification checklist
Before downloading anything, record:
- exact commercial name and regulatory model from the label;
- device and product codenames;
- Android version and full build fingerprint;
- chipset/board platform;
- bootloader and recovery state;
- region or installed ROM branch;
- whether the owner can access the linked Xiaomi and Google accounts.
Do not publish the serial, IMEI, account address, unlock token or private keys. Redact them in screenshots and terminal output.
Factory reset from the running system
If the phone is accessible, use the reset function in Settings. Menu wording varies across old MIUI versions, so follow the phone’s own Settings search or the backup/reset section rather than a path copied from a new model.
Before confirming:
- back up photos, authenticator exports, documents and app data;
- verify the Xiaomi and Google account credentials;
- charge the battery;
- remove or securely erase removable storage separately if required;
- understand that the installed Android/MIUI version will not be upgraded by a reset.
Xiaomi’s current factory-reset guidance confirms that a reset erases applications, settings and personal information while leaving the operating-system version in place.
Factory reset from recovery
On many Xiaomi phones, the supported recovery entry sequence is:
- power the phone off;
- hold Volume Up and Power until the recovery screen appears;
- select Wipe Data;
- select Wipe All Data and confirm;
- reboot when the wipe completes.
Xiaomi documents this sequence in its current recovery-mode instructions and notes that all local data is erased. An older Redmi Pro recovery may look different, but the destructive consequence is the same.
If recovery does not appear, buttons are damaged or the device cycles at the logo, stop repeating wipes and move to model-specific service diagnostics. Do not select a nearby Xiaomi model in a flashing tool.
A reset does not remove ownership controls
A factory reset is not an account bypass. After erasure, the phone may require credentials for the previously linked Xiaomi or Google account. Recover access through official account channels before wiping a device you intend to reuse.
Xiaomi provides an official Mi Account password recovery process using the bound phone, email or account appeal. If ownership cannot be established, use an authorized service route. Instructions for bypassing activation or account locks should not be part of ordinary repair guidance.
The useful hierarchy is simple: use the label for hardware identity, the fingerprint and codename for software identity, and the SoC as a cross-check. Once all three agree, a factory reset can be planned safely—but it remains a destructive data operation, not a method for changing firmware or ownership.
