Secure ADB session expires or fails to connect when ADB duration is set to 1 hour on unattended devices

Android

If your Secure ADB sessions are expiring or failing to connect on unattended managed devices, the issue may be related to your ADB session duration settings. This article explains how to diagnose and resolve the problem.

Understand the issue

When ADB session duration is set to 1 Hour on unattended devices (such as store kiosks or headless deployments), your Secure ADB connection may fail or become inactive after the 1-hour window expires. This happens because the session is not automatically renewed on devices without user interaction.

The Esper Console may still show ADB as enabled because your Blueprint policy permits it, but the underlying session relay has expired, causing espercli secureadb connect -d <device-id> to fail or hang.

Before you begin

Confirm your device is online in the Esper Console
Verify that your assigned Blueprint has ADB permission set to Allowed
Note your device ID for use in commands

How to fix this

In the Esper Console, go to Devices & Groups → [Device Name] → Settings
Locate the ADB section and find the ADB Session Duration control
Change the ADB session duration from 1 Hour to Always On
Save and apply the setting. No Blueprint re-push is required

Attempt the Secure ADB connection again:

espercli secureadb connect -d <device-id>

Verify that the terminal returns a forwarded local port (for example: Forwarding local port XXXXX → device) and that you can run standard ADB commands like adb devices

Why this works

For unattended or always-on devices like store kiosks where you need persistent remote access, Always On is the recommended ADB session duration setting. This ensures your Secure ADB relay remains active and ready for connection attempts at any time.

The 1 Hour setting is intended for attended devices where ADB access should be time-limited as a security control. It is not suitable for headless or unattended deployments.

Best practices

Always disconnect an existing Secure ADB session before initiating a new one on a different device:
```
espercli secureadb disconnect -d <device-id>
```
Concurrent or stale sessions may interfere with relay allocation
Device-level ADB session duration settings override Blueprint-level permissions. If ADB is permitted via Blueprint but the device-level duration is set to a finite value, the device-level setting controls actual session behavior

If this doesn't work

If changing to Always On does not restore connectivity, gather the following information before contacting support:

Full terminal output from espercli secureadb connect -d <device-id> showing the exact error or hang behavior
Device logs pulled via ADB while the device is in the failed state:
```
adb shell logcat -d | grep -i "secureadb\|adb"
```
Confirmation that your Blueprint has ADB permission explicitly set to Allowed
Confirmation that your device is online and reachable in the Esper Console at the moment of the failed connection attempt
Your device UUID

Still need help?

If you've tried these steps and your Secure ADB sessions are still failing, contact Esper Support with the information gathered above. Include your device UUID and any Esper Agent logs so our team can investigate further.