IOIO: a USB and Bluetooth IO board driven from an Android app

A board that makes hardware look like part of the app

The IOIO is a board that provides a host machine with the capability of interfacing with external hardware over a variety of commonly used protocols. That is the whole idea in one sentence, and it is a good one: instead of an Android app talking to a USB serial device with vendor specific code, the app talks to a board that presents a set of familiar inputs and outputs.

The original IOIO board was designed specifically to work with Android devices. The newer IOIO-OTG boards, where OTG stands for on the go, work with both Android devices and PCs. That difference matters if your host is not a phone, because the older board's design assumed an Android host.

The connection to the host is over USB or Bluetooth, and the board provides a high-level Java API on the host side for using its I/O functions as if they were an integral part of the client. That last phrase is the design goal, and it is what makes the system pleasant to use: the pins, the digital outputs, the analogue inputs appear in the API alongside the rest of your application code.

The project is Apache-2.0 licensed, the primary language is C for the firmware, and the repository holds software, firmware and hardware in one place. It is the work of Ytai, the inventor of IOIO, whose blog is where new developments are normally announced, with an introductory post giving an overview of the technology.

The repository holds firmware, hardware and four host libraries

The top-level layout shows how much of the stack lives here, and the directory names are the clearest documentation of the architecture.

On the device side there is firmware, which is the code running on the IOIO board itself, and hardware, which is the board design files. The driver directory holds the pieces that talk to the peripherals, and release holds the release artefacts. The IOIOBridge directory is the component that bridges between the host and the board over the physical connection.

The host side is the set of libraries. IOIOLibCore is the shared core that the other libraries build on. IOIOLibAndroid is the Android flavour, and there are three specialised variants of it: IOIOLibAndroidBluetooth for a Bluetooth connection, IOIOLibAndroidAccessory for the USB accessory mode, and IOIOLibAndroidDevice for the device mode, which is the model the original board used. IOIOLibPC is the library for a PC host, which is what makes the IOIO-OTG boards usable from a desktop.

The split by transport is the detail that matters in practice. The same core API is reused whether the link is USB or Bluetooth, so an application that starts on a wired connection can move to a wireless one without a rewrite of its logic, and a PC host uses the same calling convention as an Android one.

There is also IOIODude, a desktop utility, plus applications, tools and a buildSrc directory, and the project is built with Gradle using a settings.gradle.kts and a gradlew wrapper, along with a jitpack.yml that describes how the artefacts are published.

Wiring the library into a Gradle build

The README documents the Gradle usage, and the shape of it reflects how the libraries are published. The artefacts come from JitPack rather than from a standard repository, so the top level build.gradle has to know about it. In the top level build.gradle:

maven { url 'https://jitpack.io' }

and in the module build.gradle the dependencies are declared like this:

implementation "com.github.ytai.ioio:IOIOLibAndroidBluetooth:$LATEST"
implementation "com.github.ytai.ioio:IOIOLibAndroidAccessory:$LATEST"
implementation "com.github.ytai.ioio:IOIOLibAndroidDevice:$LATEST"

Three things are worth noting. The group id is com.github.ytai.ioio, which is the JitPack convention of mirroring the GitHub coordinates. The three artefacts correspond to the three connection modes, so a project depends on the one it actually uses, or on all three if it supports several. And the version is written as $LATEST, which is a variable rather than a fixed number, and the README links to the JitPack page for details.

Using $LATEST in a production build is a decision with consequences. It pulls whatever the publisher has most recently built, which is convenient while you are developing and a bad idea in a shipped application, because a library change lands in your build without a commit of your own. Pin the version once the project stabilises, and treat the JitPack page as the place to check what a given release contains, since the repository publishes no conventional releases on GitHub.

Buying the hardware and finding the documentation

The software is only half of this project. The board has to come from somewhere, and the README lists the vendors.

SeeedStudio and SparkFun Electronics are both marked as primary manufacturers, with a note that manufacturing, testing and service standards have been inspected. After them come Jaycon Systems, LinkSprite, CuteDigi and AliExpress. The existence of multiple vendors is a good sign for availability, and the primary manufacturer labels matter because they imply a level of testing and service that a marketplace listing does not.

For documentation, the README is explicit that all user documentation is on the wiki. That is where the board specifics, the wiring, the supported peripherals and the API details will be, and it is the first place to look rather than the repository itself.

Two community resources are also named. The ioio-users group on Google Groups is where questions are answered and news appears, and the IOIO Gallery collects other people's projects, which the README suggests as a source of ideas for what to build.

The project is not a closed product with a single vendor behind it, and that is arguably its strength and its weakness at the same time. A hardware design published under an open licence lets anyone build the board, and the same openness means the quality of a board you receive depends on who made it.

The generations matter: original IOIO against IOIO-OTG

Before you write any code, the board generation determines which library you need and how the host connects, and the README is clear about the difference.

The original IOIO board was specifically designed to work with Android devices, which in practice means the device acts as the USB host and the board appears as an accessory. The IOIO-OTG boards work with both Android devices and PCs, using the on-the-go designation for the USB role swap that lets a PC drive the board as a USB device.

That maps onto the library names. IOIOLibAndroidAccessory is the accessory mode, the mode the original board relies on. IOIOLibAndroidDevice is the device mode, where the board presents itself as a USB device to a host that can act as a host. IOIOLibAndroidBluetooth covers the wireless link, which the OTG boards support. And IOIOLibPC gives a desktop host the same API surface.

The practical consequence for a project is that the transport decision is made in hardware, not in configuration. If you want a battery powered robot that connects over Bluetooth, you need an OTG board. If you want a board that plugs into a phone, either generation works, and the original one remains a reasonable choice for Android only projects.

The IOIODude utility in the repository is the desktop counterpart, and it exists because a PC host needs a way to talk to a board without an Android application in the picture.

Release rhythm and what a new major version implies

The release history shows a project that is still being worked on. Versions 6.3.2 on 2025-06-03, then 6.4 on 2026-10-17 and 6.5 on 2026-10-19, with the last push to the repository on 2026-10-20.

Two releases in consecutive days after a long gap looks less like a steady cadence and more like a burst of work landing in one go, and the numbering has moved to a new major version within days. If you are integrating this, that pattern is a reason to pin a version rather than track the tip, and to read the release notes for the version you pick, since a major bump in this project is likely to involve a breaking change in the API or in the firmware protocol.

The repository also carries a TODO file at the top level and a SECURITY.md alongside the Apache-2.0 LICENSE, so there is a place where known gaps and security policy live even when the wiki does not carry them.

The build is reproducible from the tree, with a Gradle wrapper committed, a buildSrc directory for convention plugins, and the jitpack.yml describing the publication. That means a fork can produce the same artefacts under a different group id, which is the escape hatch if the published versions stop working for your board.

Editorial conclusion

Use IOIO if you are writing an Android application that has to talk to sensors, motors or other peripherals and you would rather drive them through a Java API than write USB and Bluetooth stacks yourself. Do not pick it if you need a board you can buy off a shelf today with a support guarantee, since the hardware is manufactured by third parties such as SeeedStudio and SparkFun rather than by the project, and the boards themselves cost money and time. Before you commit, read the wiki for your board generation, note that the original IOIO targets Android while the IOIO-OTG boards work with PCs as well, and pin your library versions, since the latest release is 6.5 from 2026-10-19 and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. ytai/ioio on GitHub