OCTO Android: the native client you can install tonight or fork and sign
OCTO Android Client — Open-source enterprise IM
At a glance
- What is it?
- octo-android is the official native Android client for OCTO, the self-hosted workplace for humans and Lobster AI agents: Kotlin and Java over REST and WebSocket, with a downloadable APK for operators who just want to connect, and a secrets-stripped source tree for teams who want their own build. Apache-2.0, released monthly.
- Who is it for?
- octo-android fits organizations self-hosting OCTO whose users carry Android devices, with a downloadable APK for fast evaluation and a cleanly secrets-stripped source tree for branded forks, both talking the same protocol as the web client. It does not fit standalone use, since it needs your octo-server address at login, or teams wanting a general-purpose messenger, which the Matrix ecosystem serves better.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Native Android for an agent-native workplace
OCTO describes itself as the open workplace built for humans and AI agents, with Lobsters, its OpenClaw-powered digital doubles, doing the thinking and doing while the human keeps the taste. The Android client is one of three fronts on that platform: native Kotlin and Java, not a webview, talking to the octo-server backend over REST and WebSocket, driving the same Lobster-agent conversation surface as the web client.
The native claim is cashed out in platform integration rather than slogan: an AndroidX base with Material theming, a foreground service for message push, scoped storage for attachments, and Jetpack Compose alongside XML views where each pays off. For an agent-centric messenger, that integration is what makes streaming responses, typing indicators and tool-call previews feel at home on a phone.
The audience is whoever operates an OCTO deployment and carries Android devices: the client points itself at your server address on the login screen and nothing else.
Two adoption paths: APK tonight, fork when needed
The distribution is dual-track, and the README is explicit about the easy one: download the latest APK from the releases page, install it, and enter your own octo-server address at login. No build required, which is a genuine courtesy for operators who want to evaluate the platform with a device in hand rather than a toolchain on a laptop.
The second track is forking, and it begins with a mandatory pre-flight the repository refuses to soften: the fork will not build a distributable APK until three placeholder artefacts are swapped. The bundle identifier must be renamed away from the documented placeholder, following a dedicated checklist document. Firebase configuration must be supplied as your own services file, from a template guide. And a release keystore must be generated and wired into the build, per its own template.
Once past pre-flight, the build is standard:
git clone https://github.com/Mininglamp-OSS/octo-android.git
cd octo-android
./gradlew :app:assembleDebug
./gradlew :app:installDebugThe client defaults to a local server on port 8080, with the configuration file in the resources tree as the documented place to aim it at your deployment. The secrets discipline mirrors the iOS sibling: nothing identifying the upstream team survives the release pipeline, and everything identifying yours is yours to provide.
The module map
The architecture table reads like the Android version of a pattern: a main application module with activities, fragments and a navigation graph; a UI layer for the screen surfaces, chat, channels, organization, settings; a data layer holding the REST and WebSocket client, local cache and Room database objects; an agent layer for the Lobster-aware components, streaming, tool-call previews, agent identity; and a push layer with the Firebase messaging receiver and notification routing.
The persistence and messaging choices are conventional in the good sense: Room for the local database, a foreground service for push so message delivery survives, scoped storage for attachments. None of the interesting risk is in the plumbing, which is exactly where you want the plumbing.
Localisation ships in English and Simplified Chinese, matching the server's internationalization keys, so the client tracks the platform's bilingual surface rather than maintaining a translation fork.
The nine-repo ecosystem, kept in sync
The ecosystem diagram is a shared snippet marked to stay identical across all nine OCTO repositories, a small governance touch that keeps every client documenting the same architecture. The matrix: a Go backend handling the API, business orchestration and Lobster agent scheduling; a Go task micro-service; a Go LLM summarisation service; a TypeScript and React web client that also ships as a desktop build; the native Android and iOS clients; a TypeScript and React admin console for tenant, organization, user and channel management; a shared Go library covering protocol, crypto, storage and HTTP; and an adapters repository of third-party integrations, message-bridge and AI-flavoured, in TypeScript and Python.
For this client specifically, the load-bearing property is protocol parity with the web surface: the same REST and WebSocket protocol, the same resource keys, the same Lobster identity, streaming and typing semantics, so feature work lands on both clients without a protocol fork.
The admin console's presence in the matrix is worth noticing: this is a platform aimed at organizations, with tenancy and channel management as first-class concerns, not a chat app with server bits attached.
Cadence, licence, and the neighbours
The release cadence is steady: v1.3.7 on 2026-08-17, v1.3.5 in July, v1.3.4 in June, and the last push on 2026-09-17. The licence is Apache-2.0 with a notice file, and the community scaffolding is bilingual throughout, conduct and contribution documents in English and Chinese, plus a security policy in both.
The neighbours are the same comparison the platform always invites. Matrix-based Android clients offer a decade-hardened federated protocol with mature clients and no agent assumptions, the conservative choice for messaging alone. OCTO's bet is that the agent is the reason for the workplace, with Lobster scheduling in the server and agent-aware UI in every client, and this repository is the Android entry point to that bet. Teams choosing between them are choosing what their messaging is for.
Editorial conclusion
octo-android fits organizations self-hosting OCTO whose users carry Android devices, with a downloadable APK for fast evaluation and a cleanly secrets-stripped source tree for branded forks, both talking the same protocol as the web client. It does not fit standalone use, since it needs your octo-server address at login, or teams wanting a general-purpose messenger, which the Matrix ecosystem serves better. Verify first: that your server version matches the client release notes, which Firebase and signing choices apply if you fork, and whether the foreground-service push model meets your users' battery expectations. The licence is Apache-2.0, and the last push was on 2026-09-17.
Frequently asked questions
Can I install OCTO on Android without building it?
Yes. The releases page publishes an APK that installs directly, and the login screen asks for your own octo-server address. Building from source is only needed for a customized, self-signed fork.
What do I need to change before forking octo-android?
Three placeholder artefacts, per the mandatory pre-flight: rename the bundle identifier away from the documented placeholder using its checklist, supply your own Firebase services configuration from the template guide, and generate a release keystore wired into the Gradle build.
Does the Android client keep pace with the web client?
By design it mirrors the web surface: the same REST and WebSocket protocol, the same internationalization keys and the same Lobster identity, streaming and typing semantics, so feature work lands on both clients without a protocol fork.
Community notes