How to Inspect Hardware UART and USB Serial Ports on Android Using ADB dumpsys serial

Modern Android operating systems extend far beyond consumer smartphones and tablets into embedded Internet-of-Things (IoT) appliances, point-of-sale (POS) terminals, industrial kiosks, robotics platforms, and Android Automotive head units. In these specialized hardware environments, communication with external peripherals—such as barcode scanners, receipt printers, vehicle CAN-bus transceivers, microcontrollers (Arduino/STM32), and diagnostic sensors—relies heavily on serial communication. Android handles low-level serial communication through dedicated hardware Universal Asynchronous Receiver-Transmitter (UART) ports and class-compliant USB-to-serial bridges (such as FTDI, Prolific PL2303, Silicon Labs CP210x, and CH340 chips).

When an embedded application experiences dropped data packets, framing errors, or fails to open a serial communication port, diagnosing whether the failure originates from hardware device enumeration, kernel driver bindings, or Android SELinux security permissions is critical. The Android Debug Bridge (ADB) provides direct, low-level insight into the serial subsystem via dumpsys serial.

Understanding Android Serial Subsystem Architecture

The Android SerialService bridges low-level Linux character devices with the higher-level Android framework:

• Kernel TTY Abstraction: The underlying Linux kernel exposes physical UART controllers as /dev/ttyHS* or /dev/ttyS* and USB serial bridges as /dev/ttyUSB* or /dev/ttyACM*.
• Hardware Access Permissions: Access to serial device nodes is governed by Linux group permissions (typically group dialout or system) and strict SELinux type enforcement rules (e.g. serial_device context).
• Android SerialManager API: The platform exposes the android.hardware.SerialManager system service, allowing authorized system applications to enumerate available port names, open native file descriptors, and configure baud rates, data bits, stop bits, and parity modes.

Connecting via ADB and Verifying Serial Subsystem Support

Establish a debugging connection between your terminal 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

Verify whether the OEM Android build includes the serial port hardware feature flag:

# Query platform feature list for serial support
adb shell pm list features | grep -i "android.hardware.serial"

While standard consumer smartphones often omit the user-facing feature flag, industrial, development board, and automotive Android builds include this feature by default.

Executing dumpsys serial

To inspect the active serial port infrastructure, query the SerialService diagnostic dump via the ADB shell:

# Query the SerialService diagnostic dump
adb shell dumpsys serial

The output provides an inventory of available serial ports recognized by the Android framework:

-------------------------------------------------------------------------------
SERIAL SERVICE (dumpsys serial)
  Serial ports:
    /dev/ttyHS0
    /dev/ttyUSB0
-------------------------------------------------------------------------------

If an external USB-to-serial adapter has been plugged into the device’s USB-C OTG port, it appears as an active node (e.g. /dev/ttyUSB0), confirming that the kernel driver loaded successfully.

Auditing Linux Kernel TTY Devices and USB Enumeration

To cross-reference the output of dumpsys serial against the raw Linux kernel hardware table:

# List all active TTY character devices
adb shell ls -l /dev/tty*

# Inspect connected USB device descriptors
adb shell lsusb

Inspect the kernel ring buffer (dmesg) immediately after plugging in a USB-to-serial adapter to verify driver attachment:

# Inspect recent kernel messages for serial driver initialization
adb shell dmesg | grep -iE "tty|ftdi|cp210|ch341|pl2303"

A healthy connection will output lines confirming the chip manufacturer and assignment: “ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected, ttyUSB0: FTDI USB Serial Device converter now attached to ttyUSB0”.

Diagnosing SELinux and Permission Denials

In modern Android versions, even if a serial port exists in /dev/, third-party and unprivileged applications will encounter EACCES (Permission denied) when calling open() if SELinux policies block access.

Inspect the security context of the target serial node:

# Inspect SELinux security context on the serial node
adb shell ls -lZ /dev/ttyUSB0

Audit system logcat for SELinux audit denials targeting serial ports:

# Filter logcat for SELinux avc denials involving serial devices
adb shell logcat -d | grep -i "avc: denied.*serial"

On production builds, third-party apps must leverage the Android USB Host API (via android.hardware.usb.UsbManager) with user-granted USB permission prompts to communicate with USB-serial chips via user-space drivers (such as usb-serial-for-android), avoiding root and SELinux restrictions completely.

Testing Serial Data Streams via ADB Shell

On engineering or rooted development boards, test raw serial transmission directly from the ADB terminal:

# Configure baud rate to 115200 on target serial port
adb shell stty -F /dev/ttyUSB0 115200 raw -echo

# Send a test payload string
adb shell 'echo "AT" > /dev/ttyUSB0'

# Read incoming response stream in background
adb shell cat /dev/ttyUSB0

Leveraging dumpsys serial and ADB kernel auditing gives embedded systems engineers transparent diagnostic insight to build robust, industrial-grade serial communication pipelines on Android.