OpenClaw Android: pair the official app with your Gateway
OpenClaw Android is the official companion app for an existing OpenClaw Gateway. It does not run the Gateway on the phone. First get the Gateway working on macOS, Linux, or Windows through WSL2; then pair Android as a node so you can use the same agent from a mobile device without moving its state or credentials onto the phone.
That distinction answers the two questions behind most “OpenClaw Android” searches: the app is available through Google Play or a signed release APK, and it needs a Gateway you already control. It is not a Termux-style way to turn every Android phone into a standalone server.
Contents
- What the OpenClaw Android app is for
- Pair OpenClaw Android with a working Gateway
- Use multiple Gateways without mixing up device control
- Separate mobile setup from agent configuration
- Troubleshooting OpenClaw Android pairing
- FAQ
What the OpenClaw Android app is for
The Android app gives a paired phone access to a self-hosted agent system. The Gateway remains the system of record for sessions, routing, tools, channels, and credentials. Android is a companion node that can connect to that system and expose selected device capabilities when you grant permission.
| Question | Practical answer |
|---|---|
| Does Android host the Gateway? | No. Run the Gateway on macOS, Linux, or Windows via WSL2. |
| Can the app connect to more than one Gateway? | Yes, but only the focused Gateway owns the Android node and its device capabilities. |
| Where should Gateway settings live? | On the Gateway host, not in the Android app. |
| Is sideloading supported? | Yes, when a release includes both the APK and its checksum file. Verify the exact release before installing. |
If you are still deciding where the Gateway should run, start with how OpenClaw works. The mobile app becomes useful once that host, model route, and access boundary are already clear.
Pair OpenClaw Android with a working Gateway
Treat pairing as an access decision, not as a login form. A paired phone can become an operator surface for the Gateway, so the sensible sequence is to prove the host first and expand access second.
1. Make the Gateway healthy before installing the app
Start with one working agent path on the host: a configured model route, a running Gateway, and a test conversation. The OpenClaw setup guide uses openclaw health as its basic sanity check after onboarding.
Do this before adding Android. If the first response fails, the problem is usually model access, Gateway reachability, or host configuration. Pairing a second client only adds another variable. The current OpenClaw onboarding guide explains why a real model completion is a better setup check than detecting an API key or installed CLI.
2. Install the official Android app from a source you can verify
The official Android documentation lists two distribution paths:
- Google Play for the standard install.
- A signed
OpenClaw-Android.apkfrom a supported GitHub Release for an outside-Play install.
For a sideloaded APK, download the checksum file from the same release tag and verify it before installing. The docs also describe GitHub provenance verification. Do not download an APK from a mirror simply because a search result says it runs a Gateway directly on Android; that is a different product and a different trust boundary.
3. Pair the phone through an authorized Gateway session
OpenClaw uses device pairing for the Android node connection. A paired administrator can create a short-lived mobile setup QR code or copyable pairing code from the Control UI. Pair the app with the Gateway you intend to use, then confirm that the app is connected to that Gateway rather than relying on an ambiguous local network discovery result.
The Control UI guide is useful here because it frames the browser UI as an operator surface. Pairing belongs beside the session, task, and approval controls that explain who is allowed to act.
For remote use, prefer a private, authenticated Gateway route such as Tailscale Serve or a real TLS-backed wss:// endpoint. Do not expose a raw Gateway port to the public internet just to make a phone connection easier.
4. Start with one ordinary chat, then grant only the capabilities you need
After pairing, send a normal message and confirm that it reaches the intended session. Only then consider features that use the phone itself, such as notifications, camera, microphone, location, or screen-related actions.
These capabilities are useful precisely because the agent is connected to a real device. They also deserve a narrower approval habit than ordinary chat. Grant a permission because a current workflow needs it, not because an app asks during setup. If you later switch Gateways, remember that the focused Gateway owns the Android node session and device capabilities.
Use multiple Gateways without mixing up device control
OpenClaw Android can keep more than one Gateway connection available while the app is in the foreground. The focused Gateway gets control of the Android node. Other enabled Gateways may remain connected for operator access, but they do not simultaneously own the phone’s device capabilities.
That design prevents a nasty ambiguity: two agent systems should not both think they can request camera, location, screen, or notification actions from the same phone. Choose the active Gateway deliberately before using a device-backed workflow.
A practical routine is simple:
- Keep one personal Gateway as the normal focused connection.
- Add a work or test Gateway only when there is a reason to switch.
- Check the active Gateway before approving a device permission or starting a task.
- Disconnect or disable stale test connections when the experiment ends.
This is the same operational discipline that matters for OpenClaw security: identify the system, user, and scope before granting authority.
Separate mobile setup from agent configuration
Android can open a dedicated Gateway settings assistant when the operator has the required admin permission and the Gateway supports it. That setup conversation stays separate from ordinary chat, and the Android app redacts secret replies locally before a user explicitly moves into regular Chat.
Keep the boundary intact. Use mobile setup to inspect or adjust the Gateway you have already paired. Keep long-lived configuration, workspace customization, and source-controlled changes on the Gateway host. OpenClaw’s setup documentation recommends keeping personal configuration and workspaces outside the source repository so ordinary updates do not overwrite them.
The phone is a useful control surface. It should not become the only place where the agent’s operating assumptions live.
Troubleshooting OpenClaw Android pairing
| Symptom | Check first |
|---|---|
| The app cannot find or connect to the Gateway | Confirm the Gateway is running, then verify the host’s private route or TLS-backed remote endpoint. |
| A task reaches the wrong agent or session | Verify which Gateway is focused and which session is selected before retrying. |
| A device feature does not work | Confirm that the focused Gateway owns the Android node and that the relevant Android permission was granted. |
| A sideloaded app will not install | Recheck that the APK and checksum came from the same supported release tag. |
| You need to change models or durable credentials | Return to the Gateway host and use the documented onboarding or configuration path. |
Avoid solving a pairing problem by exposing more network surface or copying credentials into a chat. A reachable Gateway is not necessarily a safely reachable Gateway.
FAQ
Can OpenClaw run entirely on Android?
The official Android app is a companion node and does not host the OpenClaw Gateway. Run the Gateway on macOS, Linux, or Windows through WSL2, then pair the phone with it.
Does OpenClaw Android need the internet?
The phone needs a reachable, secured path to its Gateway. On the same network that may be a local connection; for remote use, use a protected private route or a real TLS-backed Gateway endpoint rather than opening an unauthenticated public port.
Can I install OpenClaw Android without Google Play?
Yes. OpenClaw’s Android documentation describes signed release APKs and checksum files for supported GitHub Releases. Verify the APK against the checksum from that same release before sideloading.
Can multiple Gateways control one Android phone?
Android can retain more than one Gateway connection, but the focused Gateway owns the Android node session and device capabilities. That avoids simultaneous control of the same phone by multiple Gateways.