onebusaway-android: the official transit app you can run against your own city data

An app that is the client half of a server platform

The repository describes itself as the official Android app for OneBusAway, a project of the non-profit Open Transit Software Foundation. That framing matters, because the app is not a self-contained thing that talks to a public API. It is one component of a suite, and the README points to the application modules repository for the whole picture and to a mobile app design considerations page. The app's own feature list explains what a rider gets, and it is worth reading as a list of what the app asks the server for. Real-time arrival and departure information for public transit, a browseable map of nearby stops, a list of favourite bus stops, reminders to notify you when your bus is arriving or departing, the ability to search for nearby stops or routes, real-time multimodal trip planning using real-time transit and bike share information, a bike share map layer with real-time availability for floating bikes and bike rack capacity, and issue reporting to any Open311-compliant issue management system. The audience is a transit agency, or a regional transport authority, that has data and wants an app for it.

Two features depend on a regional OpenTripPlanner server

Two entries in the feature list carry an explicit dependency, and both name the same project. Real-time multimodal trip planning, using real-time transit and bike share information, requires a regional OpenTripPlanner server. So does the bike share map layer, which includes real-time availability information for floating bikes and bike rack capacity. That dependency is the single most important fact for anyone evaluating this app, because a rider with only a OneBusAway deployment and no OpenTripPlanner gets a good realtime arrival board and a map, and no journey planner. OpenTripPlanner is a separate routing service, and the requirement for a regional instance is stated twice in the same list, which suggests the authors are used to people missing it. The README also has a section on testing your own OneBusAway and OpenTripPlanner servers, and the point there is convenience: you can test both in the installed app without compiling any Android code, by downloading it from Google Play and following the custom server setup guide.

Two routes for a city: join the shared deployment, or rebrand

The deployment section is the part that makes this project unusual for a mobile app. There are two ways to deploy OneBusAway Android in your city. The first is to join the OneBusAway multi-region project, which the README calls the easiest way to get started: you set up your own OneBusAway server with your own transit data and get added to the OneBusAway apps. The second is to deploy a rebranded version of OneBusAway Android as your own app on Google Play, which the README says requires a bit more maintenance but lets you set up your own app based on the source code, with a rebranding page documenting the details. The distinction is about branding and distribution rather than functionality, since both routes point at your own server. That makes this repository a foundation for a city's own branded app rather than a single published app, and it also means the app is a thin piece of the overall system, with the server side living in a separate set of modules.

A codebase with documentation for servers, code and newcomers

The README organises the reading unusually well for a project of this kind, and it is worth knowing where to start. There is a System Architecture page for the question of which servers power which features, which is the one to read if you are evaluating the whole platform rather than the app. There is a Code Architecture page for newcomers to the codebase itself. There is build documentation for anyone who wants to build the project and test changes, a testing guide for alpha and beta testing that offers early access to new versions, a contributing guide that includes code style guidelines, a troubleshooting section for build problems, an FAQ for users of the app, a custom server setup guide, the rebranding page, and an issue reporting page for the Open311 integration. The top level of the repository matches that documentation plan, with a docs/ directory, a build.gradle.kts and settings.gradle.kts, gradlew and gradlew.bat wrappers, a gradle/ directory, a tools/ directory, a lint-rules/ directory of custom lint rules, an icons/ directory, and a CLAUDE.md alongside a .claude/ directory for assistant tooling. The primary language is Kotlin and the licence is a custom one that GitHub cannot classify, with the terms in the LICENSE file.

Small conveniences that indicate a long-lived consumer app

Two features in the README are unglamorous and worth noting because they are the kind of thing that only matters in an app that people keep installed for years. The first is that OneBusAway for Android automatically keeps track of your most used stops and routes, and allows you to put shortcuts on your phone's home screen for any stop or route you choose. The second is the permissions story. The README says that in order to support certain features, various permissions are needed to access information on your device, and points to a privacy explanation for why each permission is needed. For a transit app, location and notification access are the sensitive ones, and a per-permission justification document is the difference between a policy that reads as boilerplate and one a reviewer can actually check. The issue reporting feature, which posts to any Open311-compliant system, is a third: it means a rider can report a broken stop display or a wrong schedule and have it land in the city's own work queue rather than in a generic feedback inbox.

Where onebusaway-android is the wrong choice

There are two cases where this app will not serve you. The first is a city with no server of its own and no interest in running one, because the app is a client for data the agency publishes, and without a OneBusAway deployment pointing at your region there is nothing to show. Even the Google Play build, whose identifier is com.joulespersecond.seattlebusbot, is pointed at a specific region rather than being a universal national app. The second is a project that needs richer journey planning than OpenTripPlanner provides, since the app delegates that work entirely to the routing service rather than implementing its own. There is also the rebrand maintenance cost the README mentions but does not quantify: shipping your own Play Store listing means owning the release process, the review queue, the update cycle and the store policy compliance for as long as the app exists. The alternative worth naming is a commercial transit app or a custom build, which buys you a support contract and a feature roadmap in exchange for the source ownership and the ability to point at your own servers that this project gives you. For a public agency with a small IT team, that trade often favours the shared multi-region project over rebranding.

Maintenance, licensing and what the release history shows

The repository is not archived and the last push was on 2026-10-19, so the tree is being worked on. The release tags are more complicated than the numbers suggest: v2.4.19 from 2025-08-25 sits alongside v2.14.7 from 2025-04-29 and v2.14.6 from 2025-04-13, so the version numbering is not monotonic in date, which is a sign of parallel release lines rather than a single sequence. The licence is the item to read carefully, because it is marked as a custom licence that GitHub cannot classify and the terms live in the LICENSE file, and rebranding and shipping to Google Play is precisely the situation where the difference between a permissive licence and a copyleft one with a branding clause matters. The project is run under the Open Transit Software Foundation rather than a single company, which is the structural reason the rebrand path is documented at all: the foundation owns the code so that any city can take it. There is also a PRIVACY.md at the root, a CONTRIBUTORS.md, a CLAUDE.md, and a .git-blame-ignore-revs file, which tells you the history has been rewritten for formatting reasons at some point and that the project tracks that.

Editorial conclusion

Adopt onebusaway-android if you run a transit data service and want an Android client that your riders can install without you maintaining a native app from scratch. Do not adopt it if you need a consumer app for a single city with no server of your own, since the features that matter most depend on a regional backend. Verify first which OpenTripPlanner and OneBusAway deployments you can point the app at, because trip planning and the bike share layer are unavailable without a regional OpenTripPlanner server, and check the licensing terms in the LICENSE file before you rebrand and ship.

Frequently asked questions

Official sources

1. Issues
2. OneBusAway/onebusaway-android on GitHub
3. Project website
4. README
5. Releases