Before you flash a custom recovery, unlock a bootloader, or sideload a factory image, spending sixty seconds reading your device's fastboot variables can save hours of recovery work. The fastboot getvar all command dumps every piece of device-state information the bootloader is willing to share — lock status, anti-rollback counters, battery level, partition layout, and more — all without writing a single byte to the device.
Boot the device into fastboot mode by holding the appropriate button combination for your device (commonly Power + Volume Down, though this varies by manufacturer) or from within an existing ADB session:
adb reboot bootloaderOnce the fastboot screen appears and you have connected the USB cable, confirm the device is visible:
fastboot devicesIf the device appears, you are ready. Run the full variable dump:
fastboot getvar allThe output appears as a list of variable: value pairs. On most devices this completes in under two seconds. To save the output for later comparison — useful before and after an unlock or flash — redirect it to a file. Note that fastboot writes its output to stderr rather than stdout, so you must merge the streams first:
fastboot getvar all 2>&1 | tee device_info.txtOn Windows PowerShell the equivalent is fastboot getvar all 2>&1 | Tee-Object device_info.txt. The resulting text file becomes your reference baseline — keep a copy before any flashing operation.
| Variable | What It Tells You | Example Value |
|---|---|---|
unlocked |
Bootloader lock state: yes means unlocked | yes / no |
anti |
Anti-rollback protection counter (fused) | 5 |
product |
Device codename used to match factory images | cheetah |
variant |
Regional or carrier model identifier | G975FXXS9EUL1 |
current-slot |
Which A/B slot is currently booted | a / b |
slot-count |
Number of partition slots (1 = A-only, 2 = A/B) | 2 |
battery-voltage |
Current battery voltage in millivolts | 3850 |
partition-type:boot |
Filesystem type of the boot partition | raw |
max-download-size |
Largest image fastboot can receive at once | 0x20000000 |
is-userspace |
Whether fastbootd (userspace mode) is active | yes / no |
Anti-rollback, shown as anti or ANTI depending on the manufacturer, is an integer counter the bootloader uses to reject older firmware. Each time a manufacturer releases a security patch that raises the anti-rollback level, the bootloader writes the new counter value to a hardware fuse. Fuses are one-way: once written, they cannot be reversed by any software or firmware, including the manufacturer's own tools.
If you try to flash a factory image whose anti-rollback level is lower than the value already burned into the fuse, the bootloader will refuse to flash and may display an error like Anti rollback detected. Jumping to fastboot mode. On some Samsung devices the error is Failed to verify integrity of data block. Either way the flash is rejected before anything is written to flash memory, which means the device remains in its current state — a safe failure, but a frustrating one if you already wiped the userdata partition expecting to restore an older build.
Before downloading any factory image for a downgrade, check the anti level embedded in that image's bootloader binary. For popular devices this information is documented in the XDA thread for the specific model and build number. Compare it to the value from fastboot getvar anti. If the image's level is lower than your device's fuse value, that image is permanently unflashable on your unit. The only exception involves certain manufacturer-specific engineering modes that are not available to end users. The safe rule is: only flash images at or above your current anti level. When uncertain, go forward or stay on the same build.
Modern Android devices since roughly Android 8.0 use A/B (seamless) updates, maintaining two complete copies of all critical partitions. The variable current-slot reports which slot is currently booted. When you flash a new system image, fastboot typically writes to the inactive slot and schedules a slot switch on the next reboot. If the newly written slot fails to boot after a configurable number of attempts, the bootloader automatically falls back to the previous slot, which is why A/B devices are considered safer for OTA updates than older A-only designs.
Understanding the active slot matters when you are manually flashing individual partition images. If you flash boot.img to the wrong slot, the device will boot the unmodified slot and your change will appear to have no effect. Some fastboot commands accept a --slot flag to target a specific slot explicitly, and others default to the currently inactive one. Always check slot-count first: a value of 1 means you have an A-only device and slot-specific flags are irrelevant.
You do not always need the full dump. To check one variable without scrolling through dozens of lines, replace all with the exact variable name:
fastboot getvar unlocked
fastboot getvar current-slot
fastboot getvar antiThis is faster for a quick sanity check before a flash operation. Variable names are case-sensitive on many bootloaders. If a query returns FAILED (remote: unknown variable), try the uppercase variant or consult the full getvar all output to confirm the exact spelling your bootloader uses. The product variable is especially worth checking before flashing: it must match the codename in the factory image filename, otherwise the image was built for a different device.