There is a useful distinction here that older command snippets often blur: ADB can ask Android to turn on Bluetooth, but this intent-based path does not silently click through consent. It opens the same system-owned confirmation a well-behaved app would use. That makes it excellent for manual device-lab work and UI tests, but a poor fit for a truly unattended test rack.

Before you send the intent

  • Install a current Android SDK Platform-Tools release and make adb available in your terminal.

  • Enable Developer options and USB debugging on the Android device.

  • Unlock the device and accept its USB-debugging authorization prompt.

  • Keep the screen available: the Bluetooth request is a foreground system activity that needs a person’s response.

  • Remember that “discoverable” describes the local Android device being visible to remote Classic Bluetooth discovery. It is not the same operation as scanning for nearby devices.

Terminalbash
adb devices -l
List of devices attached
R58M123ABCD    device product:example model:Example_Device transport_id:1

Reading this check

  • adb devices -l asks the host ADB server for connected targets and includes useful product/model details.

  • The state must be device; unauthorized means the phone is waiting for USB-debugging approval, while offline indicates a broken transport.

  • The serial in the first column becomes the value for adb -s SERIAL when more than one device or emulator is attached. The sample serial and model above are illustrative, not values to copy.

Request Bluetooth from the ADB shell

Terminalbash
adb shell am start -W -a android.bluetooth.adapter.action.REQUEST_ENABLE
Starting: Intent { act=android.bluetooth.adapter.action.REQUEST_ENABLE }

Why the command stops at a prompt

  • adb shell runs the following command on the selected Android device; it does not execute it on your laptop.

  • am start asks Activity Manager to resolve and launch an activity, while -a supplies the intent action string defined by BluetoothAdapter.ACTION_REQUEST_ENABLE.

  • -W waits for the activity launch to settle. Its terminal result confirms that Android started the request UI—not that the user accepted it or that the radio reached STATE_ON.

  • Android returns from the system activity after Bluetooth turns on, fails, or the user declines. Watch the device and choose the appropriate response.

This is intentionally a request, not a privilege bypass. If Bluetooth is already on, behavior can vary by Android release and device implementation; verify state rather than treating a successful Activity Manager launch as proof.

Make the Android device discoverable

Terminalbash
adb shell am start -W -a android.bluetooth.adapter.action.REQUEST_DISCOVERABLE
Starting: Intent { act=android.bluetooth.adapter.action.REQUEST_DISCOVERABLE }

Risk level: caution. Review the command before running it.

What changes after approval

  • The action maps to BluetoothAdapter.ACTION_REQUEST_DISCOVERABLE and launches Android’s system consent UI.

  • Approval places the local adapter in SCAN_MODE_CONNECTABLE_DISCOVERABLE, allowing other devices doing Classic Bluetooth discovery to see it.

  • Android’s documented default request is 120 seconds and each request is capped at 300 seconds. The temporary window protects privacy and closes automatically.

  • This action also requests Bluetooth enablement when the radio is off, so a separate enable request is unnecessary when discoverability is the actual goal.

  • The command is marked caution because discoverability deliberately increases nearby visibility; use it only in a controlled test environment.

Ask for a specific discoverable duration

Terminalbash
adb shell am start -W \
+  -a android.bluetooth.adapter.action.REQUEST_DISCOVERABLE \
+  --ei android.bluetooth.adapter.extra.DISCOVERABLE_DURATION 180
Starting: Intent { act=android.bluetooth.adapter.action.REQUEST_DISCOVERABLE (has extras) }

Risk level: caution. Review the command before running it.

How the duration extra is encoded

  • --ei adds an integer intent extra; the following token is the official EXTRA_DISCOVERABLE_DURATION key and 180 is the requested number of seconds.

  • A request above 300 seconds is capped by Android, so do not build a test around indefinite visibility.

  • The user can reject the request. From an Android app, the activity result is the accepted duration or RESULT_CANCELED; a shell launch does not give your host script that app callback.

  • Line continuations make the example readable in Bash-compatible shells. Copy it as a complete command.

Target one phone when several are connected

Terminalbash
adb -s R58M123ABCD shell am start -W \
+  -a android.bluetooth.adapter.action.REQUEST_ENABLE

Why device selection matters

  • -s R58M123ABCD routes the request to exactly one transport; replace the sample with a serial reported by adb devices -l.

  • Without -s, ADB refuses an ambiguous request when multiple targets are available instead of guessing which phone you meant.

  • The remainder of the command runs unchanged on that selected target and still requires consent on its screen.

Verify the Bluetooth service, not merely the launch

Terminalbash
adb shell dumpsys bluetooth_manager

What this diagnostic tells you

  • dumpsys bluetooth_manager is the AOSP-recommended service dump for inspecting Bluetooth state and stack diagnostics.

  • Look for the adapter’s enabled/state and scan-mode information after responding to the dialog. Exact labels and the amount of output vary across Android and OEM builds.

  • The command reads service diagnostics; it does not enable Bluetooth or extend discoverability.

  • For repeatable app automation, observe BluetoothAdapter.ACTION_STATE_CHANGED and ACTION_SCAN_MODE_CHANGED, or query the relevant adapter APIs with the required runtime permissions.

A non-interactive toggle exists—but it is not the same contract

Terminalbash
adb shell cmd bluetooth_manager enable
adb shell cmd bluetooth_manager disable

Risk level: caution. Review the command before running it.

Treat this as a platform-test command

  • Current AOSP exposes cmd bluetooth_manager enable|disable, and the AOSP svc bluetooth wrapper delegates to it.

  • This route changes adapter state without the public user-consent activity, so it belongs in device-owner, platform, emulator, rooted, or otherwise controlled test environments.

  • Availability and authorization can differ on older Android releases and vendor builds. If the service rejects the shell caller or the command is absent, do not work around device policy; use the consent intent.

  • The command’s process exit is not enough for asynchronous radio startup. Follow it with the Bluetooth service dump and wait for the final state before the next test step.

Why a command may appear to do nothing

  • No dialog appears: unlock the screen, confirm the device is in device state, and look for Activity Manager errors in the terminal.

  • More than one device: add -s SERIAL; an emulator counts as another target.

  • Bluetooth remains off: the launch output only proves the request activity started. The user may have declined, the adapter may be transitioning, or a device policy may prohibit Bluetooth.

  • The phone is not visible: confirm the discoverability dialog was approved and the time window has not expired. Scan from another Classic Bluetooth device; BLE advertising is a different mechanism.

  • A duration above five minutes does not stick: Android caps each public discoverability request at 300 seconds.

  • A script hangs around the prompt: the workflow is interactive by design. Split host-side automation from the manual approval step or use an appropriately managed test image.

Android app permissions are a separate concern

These ADB examples launch system activities as the shell user; they are not a substitute for an app’s manifest and runtime permission design. Apps targeting Android 12 (API 31) or later use BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE, and BLUETOOTH_CONNECT according to the operation, and the Nearby devices permissions require runtime approval. In particular, making the local device discoverable is associated with BLUETOOTH_ADVERTISE.

If you are implementing the flow inside an app, use the Activity Result APIs around the documented Bluetooth intents, handle cancellation, and react to adapter state changes. Do not translate a successful shell experiment into calls to hidden framework services.

The mental model worth keeping

adb carries the request to the device. Activity Manager resolves the Bluetooth action. A system activity owns consent. Bluetooth Manager performs the asynchronous state change, and the remote scanner can see the phone only during the approved discoverable window. Each boundary explains a common testing mistake: transport success is not user approval, and approval is not yet final adapter state.

Primary technical references