How to Inspect Carrier Bootloader Restrictions and OEM Lock States on Android Using ADB dumpsys oemlock

In mobile security audits, custom ROM development, and enterprise device lifecycle management on Android, verifying the physical hardware state of the bootloader is paramount. Before an Android device can boot custom recovery partitions, flash third-party kernels, or install custom firmware images via fastboot, the device bootloader must be unlocked. However, on carrier-subsidized smartphones or devices deployed under enterprise Device Owner policies, unlocking the bootloader is governed by a strict two-tier authorization system enforced by hardware fuses and cryptographic certificates. To audit carrier lock restrictions, query user unlock authorization flags, and verify tamper-resistant bootloader security states, Android exposes the dumpsys oemlock diagnostic service via ADB.

Understanding Android OEM Lock and Bootloader Security Architecture

The Android bootloader security model separates bootloader unlocking into two distinct cryptographic checkpoints managed by the OemLock Hardware Abstraction Layer (android.hardware.oemlock):

• Carrier Lock State (isOemUnlockAllowedByCarrier): Controlled directly by telecommunications carriers or OEM device provisioning servers. If a carrier locks a device under an installment plan or corporate contract, the carrier flag remains false. Under this state, the user-facing “OEM unlocking” developer option is greyed out and cannot be enabled.
• User Lock State (isOemUnlockAllowedByUser): The manual toggle configured by the device owner under Developer options > OEM unlocking. Even if the carrier permits unlocking, the bootloader remains cryptographically locked until the user explicitly toggles this flag and confirms their device PIN/pattern.
• Hardware Tamper Flags (Device Lock State): The physical state of the device bootloader (locked or unlocked). Flashing custom images via fastboot flashing unlock or fastboot oem unlock only succeeds when both carrier and user authorization flags evaluate to true.
• Factory Reset Protection (FRP) Integration: The oemlock service coordinates directly with persistent_data_block. If an OEM unlock is initiated, the device triggers a mandatory, cryptographic wipe of the user data partition to prevent data extraction.

Querying OEM Lock Diagnostics via ADB

To inspect the bootloader authorization hierarchy, connect your Android device with USB debugging enabled and execute:

adb shell dumpsys oemlock

The command queries the active OemLock HAL implementation and dumps the active state flags. A representative output appears as follows:

OemLockService Diagnostics:
  Active HAL Provider: android.hardware.oemlock-service.default (AIDL)
  Hardware Backend: RPMB / Secure Hardware Storage

  Carrier Authorization State:
    isOemUnlockAllowedByCarrier: true
  User Authorization State:
    isOemUnlockAllowedByUser: false
  Device Hardware Lock State:
    isDeviceOemUnlocked: false

Analyzing these fields reveals:

• isOemUnlockAllowedByCarrier: If true, the cellular network carrier has unlocked the device’s bootloader policy (e.g., the device was purchased unlocked directly from the manufacturer or paid off in full). If false, the carrier restricts firmware modifications at the hardware level.
• isOemUnlockAllowedByUser: Indicates whether the toggle in Developer Options is currently switched on. In the example above, false indicates that the user has not authorized bootloader unlocking.
• isDeviceOemUnlocked: Indicates the actual operational state of the bootloader. A value of false confirms that Android Verified Boot (AVB) is enforcing strict signature verification on the boot, init_boot, vendor_boot, and system partitions.

Auditing Enterprise Restrictions on OEM Unlocking

Enterprise Mobility Management (EMM) agents and Mobile Device Management (MDM) platforms routinely restrict bootloader unlocking on corporate-owned devices to prevent employees from tampering with corporate security baselines.

To audit whether an active Device Policy Manager has blocked OEM unlocking:

# Query active device owner user restrictions
adb shell dumpsys device_policy | grep "DISALLOW_OEM_UNLOCK"

If DISALLOW_OEM_UNLOCK is active, the Android framework prevents the user from toggling OEM unlocking regardless of carrier state.

Verifying Settings Provider Flags via ADB

In addition to dumpsys oemlock, administrators can query the internal settings provider key tracking user toggle state:

# Check OEM unlock toggle key
adb shell settings get global oem_unlock_allowed

A return value of 1 indicates the user has enabled unlocking; 0 indicates it is disabled.

Correlating OemLock with Fastboot Hardware Querying

To verify that the flags reported by dumpsys oemlock match the bare-metal bootloader state, reboot the device into bootloader mode:

adb reboot bootloader

From the host computer, query the bootloader directly using fastboot:

fastboot getvar unlocked
fastboot getvar secure

If isDeviceOemUnlocked was reported as false, fastboot getvar unlocked returns no, confirming that unauthorized flashing attempts will be rejected by the hardware processor.

Tracing Carrier Unlock Provisioning in Logcat

When a carrier sends an over-the-air unlock token to update carrier lock state, or when the user toggles OEM unlocking, filter logcat for OemLock tags to monitor the cryptographic handshake with secure hardware:

adb logcat -s OemLock:V OemLockService:V

The logcat stream outputs the status of the secure storage write:

OemLockService: setOemUnlockAllowedByUser: true
OemLockService: Writing updated unlock state to secure RPMB partition
OemLockService: Hardware storage acknowledged write successful

By leveraging dumpsys oemlock alongside fastboot commands and device policy audits, security engineers, firmware developers, and enterprise administrators can definitively verify carrier bootloader restrictions and guarantee compliance with hardware-rooted chain of trust standards.