How to Inspect Connected USB and Bluetooth MIDI Devices on Android Using ADB dumpsys midi

Modern Android smartphones, tablets, and automotive systems increasingly serve as audio workstations, synthesizer hosts, and musical controllers. Through the Android MIDI API (introduced in Android 6.0 and enhanced in Android 13+ with USB MIDI 2.0 support), the platform supports external hardware MIDI controllers connected via USB-C, Bluetooth Low Energy (BLE) wireless MIDI peripherals, and virtual software synthesizer apps exchanging real-time MIDI messages between processes. When an audio application experiences dropped note events, stuck channels, or pairing failures, isolating whether the bottleneck lies in hardware device descriptors or application port bindings is challenging.

The Android Debug Bridge (ADB) provides direct, low-level insight into the audio subsystem via dumpsys midi. Querying the MidiService diagnostic dump reveals all active hardware and virtual MIDI devices, input/output port counts, connected client UIDs, and real-time message routing statistics directly from the terminal.

Understanding Android MIDI Architecture and Device Classes

The Android MidiService acts as the central router for musical data across the operating system:

• Hardware USB MIDI Devices: Class-compliant USB audio and MIDI hardware plugged into the device’s USB-C port. The Linux kernel’s ALSA driver detects these endpoints and surfaces them to Android’s native audio daemon.
• Bluetooth Low Energy (BLE) MIDI: Wireless MIDI controllers operating over Bluetooth GATT profiles using the standard MIDI over Bluetooth specification.
• Virtual Software MIDI Devices: Android applications that expose MIDI input and output ports to receive notes from virtual keyboards or send sequencer patterns to external hardware.
• Port Hierarchy: Each MIDI device exposes zero or more Input Ports (receives MIDI data) and Output Ports (transmits MIDI data). Android manages bidirectional thread-safe queues between these ports.

Connecting via ADB and Verifying Audio Subsystem Support

Establish a debugging connection between your development workstation and the Android device via USB or Wireless debugging:

# Verify connected device status
adb devices -l

# Ensure device shell access is operational
adb get-state

Confirm that the device’s feature flags include hardware MIDI and Bluetooth Low Energy support:

# Check for platform MIDI feature support
adb shell pm list features | grep -i "android.software.midi"

# Check for Bluetooth Low Energy feature support
adb shell pm list features | grep -i "android.hardware.bluetooth_le"

Both features must be present for full hardware and wireless MIDI connectivity.

Executing dumpsys midi

To inspect active MIDI hardware and virtual device registrations, execute the command via the ADB shell:

# Query the MidiService diagnostic dump
adb shell dumpsys midi

The output presents a comprehensive breakdown of the active MIDI ecosystem:

• Device Count: Total number of registered MIDI devices currently recognized by the operating system.
• Device Descriptors: Detailed hardware identifiers, including manufacturer, product name, serial number, and ALSA card/device index.
• Input and Output Port Maps: An inventory of every open MIDI port alongside the process ID (PID) and package UID of the application holding the connection.

Analysing Hardware and Virtual MIDI Device Telemetry

Examine a typical device record from the dumpsys midi output:

Devices:
  Device 0:
    Name: USB MIDI Keyboard
    Type: TYPE_USB
    UID: 1000
    Package: android
    Properties:
      manufacturer: Arturia
      product: KeyStep 37
      serial_number: 501234
      alsa_card: 1
      alsa_device: 0
    Input Ports: 1
      Port 0: Input (opened by PID 14210: com.example.synthesizer)
    Output Ports: 1
      Port 0: Output (opened by PID 14210: com.example.synthesizer)

Key properties to examine during troubleshooting:

• Type: Distinguishes between TYPE_USB (wired physical controller), TYPE_BLUETOOTH (wireless BLE controller), and TYPE_VIRTUAL (on-device software app).
• alsa_card & alsa_device: Indicates the raw Linux ALSA soundcard node handling the stream (e.g. /dev/snd/midiC1D0).
• opened by PID: Identifies which foreground or background application currently holds an exclusive or shared lock on the MIDI port. If an app fails to receive incoming notes, this field reveals if another background process has hijacked the port.

Correlating MIDI Ports with Raw ALSA Endpoints

To cross-reference dumpsys midi output against raw Linux kernel audio hardware detected on the device:

# Query Linux kernel soundcards
adb shell cat /proc/asound/cards

# Inspect raw ALSA sequencer and MIDI clients
adb shell cat /proc/asound/seq/clients

This confirms whether hardware disconnects originate from physical USB-C cable faults (causing the ALSA card to disappear entirely) or software-level service registration hangs.

Testing MIDI Device Disconnect and Cleanup Cycles

When developing digital audio workstation (DAW) apps, verifying that applications cleanly release ports when controllers are unplugged is critical to prevent memory leaks:

# Filter logcat to monitor MidiService connection events in real time
adb shell logcat -s MidiService

When an external MIDI device is connected or disconnected, MidiService outputs immediate registration logs, allowing engineers to verify lifecycle callbacks (onDeviceAdded, onDeviceRemoved, and onDeviceStatusChanged) without attaching heavyweight code debuggers.

Using dumpsys midi provides Android developers and audio engineers with essential, low-latency diagnostic visibility to ensure robust musical hardware performance across all Android devices.