Every Android device carries a large set of system properties describing its build, hardware, and current configuration, and getprop is the command-line window into all of it. It's the fastest way to confirm exactly what firmware, chipset, and security patch level a device is running without digging through several different Settings screens, and it's frequently the first command worth running before diagnosing anything else about a phone connected over ADB.
Running adb shell getprop with no arguments dumps every readable property on the device, often several hundred lines, formatted as [property.name]: [value]. That's useful for a full audit but overwhelming for finding one specific value, so most practical use narrows it down immediately.
adb shell getprop ro.build.version.release
adb shell getprop ro.product.model
adb shell getprop ro.build.fingerprint
adb shell getprop ro.hardwarero.build.version.release and ro.build.version.sdk — the Android version and its corresponding API level, useful when a version shown in Settings doesn't match what an app or tool actually detects.ro.build.fingerprint — a single string uniquely identifying the exact build, useful for confirming two devices are running byte-identical firmware, or for reporting a bug against a specific build.ro.build.version.security_patch — the security patch level, independent of the Android version number, which matters for confirming whether a known vulnerability has actually been patched.ro.product.cpu.abi and ro.hardware — the CPU architecture and underlying hardware/chipset codename, useful for confirming which chipset-specific driver or flashing tool actually applies to a device whose spec sheet is vague or inaccurate.ro.boot.verifiedbootstate — reflects whether verified boot is currently green, orange (unlocked), or a failure state, a quick way to confirm bootloader unlock status without navigating Settings.ro.serialno — the device's serial number as Android reports it, occasionally different from the one printed on the box or SIM tray.For properties whose exact name isn't known in advance, piping the full dump through a text filter on the host machine finds it faster than guessing:
adb shell getprop | grep -i battery
adb shell getprop | findstr /i security_patchThe first form works on macOS, Linux, and inside WSL; the second is the Windows Command Prompt equivalent using findstr when grep isn't available on the PATH.
A companion command, setprop, exists to change some properties at runtime, but most of the properties worth reading with getprop are read-only (indicated by the ro. prefix) and can't be changed this way even with root access — they're baked into the build itself. Attempting to set a ro. property simply fails silently or is ignored, which is expected behavior, not a bug in the command.
Scripting a check against ro.build.version.sdk before pushing an APK that requires a minimum API level, confirming ro.product.cpu.abi before choosing which architecture variant of a native binary to push, or comparing ro.build.fingerprint across two supposedly identical devices to catch a firmware mismatch are all faster and more precise through getprop than tapping through several Settings menus by hand. Combined with dumpsys for runtime state rather than build-time properties, the two commands cover most of what's needed to characterize a device fully from the command line. Google's system properties documentation covers how these values are defined at the platform level for anyone building against them.
Because getprop writes a single clean value to stdout when called with a specific property name, it's convenient to capture directly into a shell variable for use in a larger script, rather than parsing it out of the full dump:
SDK=$(adb shell getprop ro.build.version.sdk)
if [ "$SDK" -lt 26 ]; then
echo "Device API level too old for this APK"
fiThis pattern is common in build and deployment scripts that need to branch based on a connected device's capabilities before pushing an app or running a test suite, avoiding the need to hardcode assumptions about which devices a script will run against.
Every example here works over a standard, non-rooted ADB connection with USB debugging enabled — getprop itself needs no elevated privileges to read the values covered above, since they're intentionally exposed as public, readable system state. Root access only becomes relevant for a small number of more sensitive properties that some manufacturers restrict further, which is a minority case rather than the default for most of what's useful in day-to-day diagnostics.