specdeviceinfo
中文
2026-06-05 · Technical explainer

Reading Build.FINGERPRINT: what each field actually means

The Android Build.FINGERPRINT string looks like noise. It isn't — every character is doing something. Here's a field-by-field tour, and what each segment tells you about the device.

Run adb shell getprop ro.build.fingerprint on any modern Android and you get back something like this:

samsung/dm3qxxx/dm3q:14/UP1A.231005.007/S911BXXS5BXG2:user/release-keys

Set at the factory, baked into the system partition, read by everything from your bank app to the Play Store to whichever ad network is bidding on the current impression. Nearly every "is this phone real?" check starts by parsing this string.

The 6-field structure

Per AOSP, it's always:

$<brand>/<product>/<device>:<release>/<id>/<incremental>:<type>/<tags>

Six fields separated by /, with a stray : stuffed into fields 3 and 5. Each is set independently and encodes a different thing.

Field 1: brand

Resolves from ro.product.brand. For a real Samsung Galaxy, it's always lowercase samsung. Capitalization mismatches — Samsung, SAMSUNG, or the classic SAMUNG — are the single most reliable counterfeit tell. Look up the expected brand string for any verified device in our brand database.

Field 2: product

Internal product codename. In the example, dm3qxxx is Samsung's codename for the Galaxy S23 Ultra international variant. Each SKU gets its own: dm1qxxx for S23, dm2qxxx for S23+, dm3qxxx for S23 Ultra. Region matters too — dm3qins is the India build.

Hard to fake, because the codename has to line up with the kernel's device-tree binding. Flash an S23 ROM onto an S22 board and this field will fight the actual hardware during early boot until something crashes.

Field 3: device:release

Two fields joined by a colon. dm3q:14 means device codename dm3q on Android 14. The device codename is usually a shortened form of the product code — it identifies the hardware platform the kernel was built for. The release is the user-facing version number.

Mismatches here are diagnostic. Device codename generic = emulator. Release version that never shipped officially on this hardware = custom ROM.

Field 4: id

The internal build ID from the OEM's build system. Samsung uses UP1A.231005.007 — UP is Android 14's platform codename ("Upside-down cake"), 1A is the platform release, 231005 is the build date (2023-10-05), 007 is the incremental. Pixel does the same shape with different letters: AP2A.240605.005 for Android 14 on Pixel.

This is the single best field for "is this firmware current?" — diff it against the latest official release for the model.

Field 5: incremental:type

Two fields joined by a colon. S911BXXS5BXG2:user unpacks as:

  • S911BXXS5BXG2 — Samsung's incremental. S911B is the model prefix, XX is region, S5 is firmware revision, BXG2 encodes the build date.
  • user — build type. On any production phone this is user. See userdebug or eng and you're looking at a dev device or a custom ROM.

Field 6: tags

Almost always release-keys on a production device. The other value you'll see is test-keys, meaning the build was signed with AOSP test keys instead of the OEM's release keys.

This is the most useful single field for spotting custom ROMs. Ends in test-keys → the phone is rooted, on a custom ROM, or both. A lot of banking apps flat-out refuse to launch against it.

What's safe to parse, what isn't

Build.FINGERPRINT lives in the system partition, read by the framework, exposed read-only to apps. Mostly. Magisk's DenyList hooks the property read and can serve one fingerprint to Settings and a different one to your bank app. That's exactly why banks stopped trusting the string on its own and started stacking Play Integrity, StrongBox attestation, and hardware-backed key attestation on top.

For your own purposes — checking a second-hand phone before paying — Build.FINGERPRINT is still one of the highest-signal fields you have. A seller can't pre-hook it, and structural anomalies stand out once you know the shape.

The 30-second sanity check

Pull the string and walk through:

  1. Brand lowercase? ✓
  2. Product codename matches the claimed model — check the device database.
  3. Device codename plausible for the hardware. ✓
  4. Release version actually shipped on this model. ✓
  5. Build ID matches the OEM's known format. ✓
  6. Build type is user, not userdebug. ✓
  7. Tags is release-keys, not test-keys. ✓

Seven boxes. Anything fails and the phone's been modified — you want to know how before you hand over the money.

← Back to all posts