The Xiaomi build string that lied to me

I was setting up a Xiaomi Redmi as a portable pentest device and needed the exact stock fastboot ROM to extract boot.img for Magisk patching. Wrong build → bootloop, so the identifier has to be exact.

I asked the device:

adb shell getprop ro.build.version.incremental
V12.5.7.0.RCZMIXN

Off to the mirrors. Searched xmfirmwareupdater, mi-globe, xiaomirom, even Google with the string in quotes. Zero hits for RCZMIXN anywhere. The site listed dozens of dandelion builds — RCZEUXM, RCZRUXM, RCZIDXM, RCZMIXM — but every single one ended in XM, not XN.

My first theory: the site only archives Android 10 builds for this device, and the N suffix means Android 11. Plausible. The phone is on Android 11.

Wrong theory. I ran one more prop:

adb shell getprop ro.build.fingerprint
Redmi/dandelion_global2/dandelion:11/RP1A.200720.011/V12.5.7.0.RCZMIXM:user/release-keys

The fingerprint says RCZMIXM. Same Android 11. Same device. Different last letter from what incremental reported.

The fingerprint was right. RCZMIXM had a matching ROM on the official Xiaomi CDN, MD5-verified, exact device codename match (dandelion_c3l2_global). The XN in incremental is either an OTA patch artifact or a bookkeeping value that diverged from the canonical build name at some point — but for the purposes of finding firmware, it’s a dead end.

The lesson is small but it cost me twenty minutes and an incorrect mental model:

• ro.build.version.incremental is the version label the OS reports for itself.
• ro.build.fingerprint contains the build identifier as it appears in the actual firmware archive.

When they disagree, the fingerprint wins. Anywhere you’re looking up firmware — vendor mirrors, leaked archives, linageOS device pages — search the fingerprint string. I’d been treating incremental as the authoritative ID for years and never noticed because they usually match. On Xiaomi/MIUI, evidently, they don’t always.

Filed under “props you trust without checking, until you can’t.”