SimpleUsbTerminal: a bare Android console for USB serial adapters

A phone becomes a serial console for a board

The project describes itself as an Android app that provides a line-oriented terminal or console for devices with a serial or UART interface connected through a USB-to-serial converter. That is the whole problem, and it is narrower than it sounds: no protocol awareness, no file transfer, no scripting, just a way to type characters at a device and see what comes back.

The interface is what the description calls line-oriented, which is the important word. This is not a full terminal emulator with cursor control, escape sequence handling and a shell. It is a console where a line you type is sent and a line that arrives is shown. For talking to a bootloader, a sensor board or a device that speaks a simple command set, that is exactly the right shape, and it is also why the application is small.

The platform constraint is Android, and the primary language is Java. The repository is a standard Android project layout: an app/ directory, build.gradle, gradle.properties, settings.gradle, a gradle/ directory and the gradlew and gradlew.bat wrapper scripts. There is no settings screen, no configuration file and no documentation directory, which is consistent with an application whose configuration is entirely in the connected device.

The audience is stated in the motivation section, and it is unusually specific. The author received various requests asking for help with Android development, or for the source code of the app. This repository is the answer to those requests, a simplified version of the full application, published so that people can read it and learn from it.

The supported hardware falls into two families

The device support is listed in two groups, and the grouping tells you how the app reaches each device.

The first group is USB to serial converters built on specific chips: FTDI FT232 and FT2232 among others, Prolific PL2303, Silabs CP2102 and CP2105 among others, and Qinheng CH340 and CH341. These are the classic bridge chips, and each family has its own USB vendor and product identifiers, which is why they are enumerated rather than described generically. A converter from a smaller vendor using one of these chips is in scope.

The second group is devices that speak the USB CDC protocol directly, with no bridge chip: an Arduino using an ATmega32U4, a Digispark using V-USB software USB, a BBC micro:bit running ARM mbed DAPLink firmware, and a Pi Pico. The word from the list is and more, so the list is representative rather than exhaustive, but it also means an unlisted board may or may not work.

The practical consequence is that the hardware question is answerable before you install anything. If your board is one of the four CDC examples, it is supported in principle. If your adapter uses one of the four chip families, likewise. If you have a device with a bare UART header and no USB interface at all, this app cannot help, because it is a USB-side tool.

Digispark deserves a note because of how it is listed. V-USB is a software USB implementation, meaning the microcontroller is running a USB stack in firmware rather than carrying a dedicated USB controller. The app lists it anyway, which says something about how flexible the underlying library is.

Five features, and the foreground service is the interesting one

The feature list has five entries, and one of them is the reason this application exists in its current form.

Permission handling on device connection is the first. On modern Android, opening a USB device requires the user to grant permission, and an application that does this properly has to deal with the permission dialog and with the permission being lost when the device is unplugged. Handling it is listed as a feature because it is work, not a given.

The foreground service is the second and, for this project, the most consequential. It buffers received data while the app is rotating, in the background, and in other situations where the activity is not in the foreground. Without it, a serial stream arriving while you turned the screen or switched apps would be lost, and losing bytes from a device that is streaming output is the kind of failure that produces a debugging session full of wrong conclusions. A foreground service keeps the process alive and lets the notification show that the app is still connected.

The remaining three are about the line itself. The app can send BREAK, which is the framing signal used to reset a serial device, and it can show the control lines, which are the modem signals on the connector. It supports RTS and CTS, DTR and DSR, and XON and XOFF flow control, which are the three common hardware and software handshake pairs, and which matter when the device on the other end cannot keep up with what you send.

That combination, a persistent reader plus proper flow control, is what separates this from a screen of typed characters.

The serial handling comes from usb-serial-for-android

The credits section is one line and it names the dependency: the app uses the usb-serial-for-android library, by mik3y. That single fact explains most of the hardware coverage described above, because that library is where the chip-specific drivers live, and it explains why the CDC devices work alongside the bridge chips rather than as a separate code path.

This is a project built on top of someone else's hard part, and it is worth being clear about which part is which. The vendor drivers, the USB enumeration, the device permissions and the CDC protocol handling come from the library. What this repository adds is the terminal application around it: the line-oriented interface, the foreground service that keeps the connection alive, the BREAK handling, the control line display and the flow control settings.

That division also shapes what a reader can learn from the source. If you want to know how to talk to an FTDI or a CH340 from Android, the answer is in usb-serial-for-android. If you want to know how to keep a serial connection alive in the background on Android, or how to present a serial console, the answer is here.

The licensing point follows the same shape. The repository itself is MIT, per the LICENSE.txt file at the root, which is the permissive end and carries no obligation beyond keeping the notice. The library it builds on carries its own licence, which applies to you as its user rather than to this project as a distributor, and it is worth reading before you ship anything built on top.

No releases, so this is source you build rather than an app you install

The repository has no GitHub releases, and the release list is empty. There is no download link, no signed APK and no version history beyond what the commit log holds.

That is the central practical difference between this and the full application it comes from. The author's Serial USB Terminal is on the Google Play Store, and the motivation section refers to it as the app people were asking about. This repository is the simplified version of that app, with the source released in response to requests for help and for code. If what you want is a terminal on your phone right now, the Play Store app is the artifact to get. If what you want is to understand how the app is put together or to change it, this is the artifact.

The build is a Gradle project with the wrapper committed, so gradlew and gradlew.bat are present and a standard Android build works from a checkout with an Android SDK and a compatible JDK in place. The build.gradle file at the root and the settings.gradle file are the places to look for the module structure and dependency versions, and the gradle.properties file for the build configuration.

There is also a Codacy badge in the readme, pointing at a code quality and analysis service configured for the project, which tells you static analysis is part of how the code is kept in shape rather than an afterthought.

Where SimpleUsbTerminal is the wrong tool

The first limit is that it is USB only. There is no Bluetooth serial profile support, no network serial, no OTG over a headset jack, and no TCP bridging. If the device you need to reach is a Bluetooth module, an ESP WiFi board configured for AT commands over the network, or a machine on the other side of a serial-to-Ethernet adapter, this is the wrong application and no setting will change that.

The second limit is that it is deliberately simplified. The author says so, and the feature list reflects it: five features, no configuration screens, no logging to file, no scripting, no macro support, no session profiles for different devices. The full application presumably has more, since the requests for source were about that one, and choosing this version means accepting the smaller feature set in exchange for a codebase you can read.

The third limit is the line-oriented interface. A device that draws a progress bar, uses cursor positioning, or speaks a binary protocol will not look right in this console. Tools like PuTTY, minicom or picocom on a desktop are built for the full terminal behaviour, and for a device that expects a real terminal, one of those on a laptop connected to the same adapter remains the more reliable choice.

The fourth is the hardware list, which is a floor as much as a ceiling. The four bridge chip families and the four CDC examples are what is documented as supported, and the underlying library is where the rest of the coverage lives. A converter with an unusual chip, or a board with a vendor-specific USB stack, is a research project rather than an install.

The fifth is maintenance, and it is the one to weigh before depending on it. The last push to the repository was on 2026-07-18, and there are no tagged releases, so the code you read today is the code as it stands on the default branch with no version markers to pin against.

Editorial conclusion

SimpleUsbTerminal is worth looking at for an Android developer who needs a serial console for a board and wants to read the source rather than install an app, because the whole project is small enough to understand in one sitting and it covers the hardware families most USB serial adapters fall into, from FTDI and Prolific chips to boards speaking USB CDC. It is the wrong choice if you want a ready-to-install terminal, because there are no GitHub releases and the repository is a source drop, and it is the wrong choice for anything that needs Bluetooth rather than USB. Before you build it, check the three things that decide the outcome: that the adapter or board you have is on the supported list, since the chip families and the CDC devices are enumerated rather than universal; that you can supply a development environment, because the project ships a Gradle wrapper and no prebuilt artifact; and that the features you need are the ones this version has, because the project is explicitly a simplified version of the author's full serial terminal app, with permission handling, a foreground receive buffer, BREAK, control line display and the three flow control modes as the documented feature set.

Frequently asked questions

Official sources

1. Issues
2. kai-morich/SimpleUsbTerminal on GitHub
3. License: MIT
4. README