How to Inspect Smart Lock Agents and Device Trust States on Android Using ADB dumpsys trust

Modern Android smartphones balance user security with convenience by allowing devices to remain unlocked under verified environmental conditions—such as being connected to a trusted Bluetooth smartwatch, staying within a recognized home geofence (Trusted Places), or maintaining continuous on-body contact. In the Android Open Source Project (AOSP) security framework, these dynamic authentication privileges are governed by the TrustManagerService. The service manages registered Trust Agents, monitors active trust grants, handles biometric unlock integration, and enforces system lockdown policies. When diagnosing why an Android device fails to unlock automatically, investigating rogue trust agents, or auditing device lockdown states, Android Debug Bridge (ADB) provides direct access through dumpsys trust.

Architecture of the Android Trust Manager Framework

The Android Trust Manager operates as the central authority between hardware authentication sensors and the keyguard lock screen:

• Trust Agents: Background system services (implementing android.service.trust.TrustAgentService) that evaluate environmental telemetry and notify the system server when the device should enter or remain in a trusted state (such as Google Play Services Smart Lock).
• Trust Grants: Temporary cryptographic tokens granted by a Trust Agent. Grants specify an expiration duration and specific capability flags (such as whether the trust grant allows waking the display).
• Device Lock State: Tracks whether the primary credentials (PIN, pattern, or password) are required to decrypt user storage and grant access to application data.
• Lockdown Mode: A security fail-safe introduced in modern Android that immediately revokes all active trust grants and biometric authenticators, requiring the user to authenticate exclusively using their primary knowledge factor (PIN/password).

Dumping the Trust Manager Service State via ADB

To inspect real-time trust state, registered agents, and active grants on a connected Android device, execute the diagnostic command via ADB:

# Dump the full TrustManagerService diagnostic state
adb shell dumpsys trust

The output presents an immediate snapshot of device security across all user profiles:

Current Trust Manager state:
User "0" (active):
  deviceLocked=true
  currentUserIsManaged=false
  trustManagersCount=1
  Trust Agents:
    TrustAgent[ComponentInfo{com.google.android.gms/com.google.android.gms.auth.proximity.authorization.userpresence.TrustAgentService}]
      enabled=true
      bound=true
      managingTrust=false
      flags=0

Evaluating Key Metrics in dumpsys trust Output

Reviewing the dumped properties reveals how Android calculates device unlock permissions:

• deviceLocked: A boolean flag (true or false) indicating whether the device keyguard is currently locked.
• enabled: Confirms whether the target trust agent is enabled by the user in system settings.
• bound: Indicates whether the system server has successfully established an active IPC Binder connection to the trust agent process. If false, the trust agent crashed or was killed by memory management.
• managingTrust: Reports whether the agent is actively exercising authority over the lock state. When Smart Lock recognizes a trusted Bluetooth connection, this toggles to true.
• Active Grants: Lists any temporary trust overrides granted by the agent, along with remaining validity milliseconds before expiration.

Auditing and Simulating Device Lockdown Mode

When a user activates Android’s Lockdown feature from the power menu, Android immediately isolates the trust framework:

# Check whether device lockdown is currently engaged
adb shell dumpsys trust | grep -i "lockdown"

When lockdown is active, all biometric sensors (fingerprint and face unlock) and all Smart Lock agents are suspended. The dumpsys trust dump explicitly flags active trust grants as revoked, verifying that physical access requires direct PIN entry.

Auditing Active Trust Listeners

The TrustManagerService notifies registered system components (such as the KeyguardViewMediator and FingerprintManager) whenever trust status shifts:

# Inspect active trust listeners and registered client callbacks
adb shell dumpsys trust | grep -A 10 "Trust Listeners:"

If an application fails to recognize that the device has unlocked, check whether its listener callback is properly registered in this section.

Troubleshooting Smart Lock and Trust Failures

When Smart Lock fails to keep a device unlocked or exhibits erratic locking behavior:

• Trust Agent Unbound: If bound reports false for Google Play Services, clear the Google Play Services application cache or verify that background battery restrictions (dumpsys deviceidle) are not terminating the proximity agent.
• Expired Trust Grants: Trust agents often configure strict expiration windows (such as 4 hours of inactivity). Once expired, Android requires an explicit biometric or PIN entry to re-prime the trust grant.
• Device Administrator Revocation: Enterprise Mobile Device Management (MDM) profiles can force KEYGUARD_DISABLE_TRUST_AGENTS, globally disabling Smart Lock features regardless of user settings. Verify active administrative restrictions via dumpsys device_policy.