GPT Assistant for Android: volume-key voice access, agent mode, and a GPL-3.0 build you compile yourself

The problem is not chat, it is the three taps before chat

Android already has a dozen ways to talk to a language model. The friction is upstream of the model. Unlocking the phone, finding the app, waiting for a cold start, tapping the input field, typing or holding a microphone button: that sequence is long enough that people stop doing it for short questions. GPT Assistant attacks the entry point instead of the model. The README describes long-pressing the volume-down key to bring up the interface, holding the volume key to start voice input, releasing and short-pressing again to send, with the reply optionally spoken back through system TTS. There is also a quick-settings tile labelled GPT, and a text-selection handler so that selected text in another app can be routed into the assistant. The target user is someone who wants a general-purpose assistant reachable from wherever they already are, not a chat app they deliberately open. The secondary audience is people who want a document or photo interpreted in place: the app accepts images, TXT, PDF, DOCX, PPTX and XLSX, and the README lists five ingestion paths (in-app attachment button, share sheet, open-with, drag and drop from another app, and text selection).

Two accessibility services, two different jobs

The volume-key trigger is not a media-session hack. The README states plainly that you must enable the app's accessibility service for volume-key wake, and that after a phone restart the service may need re-enabling (the Q&A repeats this for the case where long-pressing volume-down only changes the volume). A second, separate accessibility service is required for agent mode. That distinction matters when you evaluate the app's permission surface: the first service exists to observe a hardware key, the second exists to read the current screen's control tree and to perform clicks, scrolls and text entry. The README is explicit that agent mode does not use image recognition and instead reads control information exposed by the accessibility framework, which is why it can work with any model that supports Function or tool calling rather than only vision models. It is also why it fails on apps that do not expose complete control information, a limitation the README states directly. The background-popup permission is a third, separate gate: the README says that if long-pressing volume-down produces a vibration but no window, the missing permission is the likely cause.

Web access is a Function call, and it is billed like one

Networking is not a search API integration. According to the README, the app exposes a Function interface through which the model can request a fetch; the app loads the page in an Android WebView and returns the content to the model. That design has consequences the README spells out. Pages are loaded with a 15-second timeout, so a slow site fails. Login walls and verification pages fail. Only plain text is returned for ordinary sites, while a named list of sites (Baidu, Bing, Google, Google Scholar, Zhihu, Weibo, JD, GitHub, Bilibili, CNKI) has been adapted so the model can also receive result links. The README recommends priming the model with phrases like a search-engine name before the question, and notes that model randomness can send the fetch to the wrong URL. The cost note is the one to read twice: sending page content to the model consumes a large number of tokens, and the README advises caution with gpt-4 for that reason. Models without Function support, gpt-4-vision-preview among them, cannot use networking at all.

Getting it running: an APK, an API key, and two permission grants

Installation is the released APK from the latest release, which at the time of writing is v3.0.0. There is no build step for ordinary users and no package manager entry. Configuration is manual. In settings you enter an API base URL and key: the README gives https://api.openai.com/ as the official endpoint, and notes that the official service is not directly reachable from mainland China, pointing at the third-party GPT_API_free project as one relay option with a stated limit of 200 requests per day per IP and key. Speech recognition defaults to Huawei HMS, and the README says no configuration is normally needed because the author's key is bundled. If you switch to Baidu you must create a cloud application, set its speech package name to Android, and enter the app package name com.skythinker.gptassistant along with AppID, API Key and Secret Key; the long-speech toggle decides whether the short-form or real-time recognition endpoint is used. Google recognition requires the Google app installed and set as the system speech engine. Whisper requires only that your OpenAI-compatible endpoint serves the Whisper model. For agent mode the README lists three conditions: enable the agent accessibility service, choose a model that supports Function or tool calling, and avoid sensitive pages.

The Huawei key is not in the source you compile

This is the sharpest practical trap in the repository, and the README documents it under development questions. The bundled Huawei HMS speech key has package-name and signature verification enabled to prevent abuse, so a self-compiled build cannot use it. To build from source with working Huawei recognition you must create your own AppGallery application and replace the authentication material: the app/agconnect-services.json file and the hms_api_key entry in app/src/main/res/values/strings.xml. That means a fork is not a drop-in replacement for the released APK unless you either supply your own Huawei credentials or switch the recognition backend to Baidu, Google or Whisper. The same asymmetry applies to the model list: only a few models ship built in, and the README tells you to add custom models in settings, which is also how you reach anything not on the default list. For non-OpenAI-shaped APIs (Claude, Gemini, Ollama are named), the project states it has no plan to adapt them individually and suggests running OneAPI or NewAPI as a translation layer.

Agent mode is experimental, and the README says so twice

The feature that will draw most attention is also the one with the weakest guarantees. The README labels agent mode experimental in the feature list and again in its own section, and warns that it cannot be relied on to recognise and operate every app or control. Two failure classes are named: applications that do not expose complete control information to accessibility services, and models that do not support Function or tool calling. There is also an explicit safety instruction to avoid payment, verification-code and password screens. The README states the software does not retain your information, but that statement is about retention, not about what a mis-aimed tap can do on a payment page. Treat agent mode as a demonstration of accessibility-tree automation rather than a dependable automation layer, and treat the sensitive-page warning as a constraint on where you enable it, not as a disclaimer to skim past.

Where it fits against Tasker plus an API call, or a hosted assistant

The closest comparison is not another chat app. It is Tasker (or Macrodroid) wired to an HTTP request action: those tools own the trigger layer, can bind to volume keys and quick-settings tiles, and can post a notification with the reply. The difference in approach is where the assistant lives. Tasker gives you a general automation engine and leaves you to build the prompt, the speech loop and the document handling yourself; GPT Assistant ships that loop as a single opinionated app with a fixed UI, a template system, and the accessibility services already written. The trade is configurability for a working default. The other comparison is a hosted assistant such as Google's or a vendor assistant: those are supported, updated on someone else's schedule, and cannot read arbitrary control trees, but they also do not ask you to paste an API key into a settings screen or keep two accessibility services enabled. If your requirement is a supported product with a service-level expectation, this project is the wrong shape. If your requirement is a hackable Java codebase that already solves volume-key wake and WebView fetching, it is a reasonable starting point.

Licence, upgrade cost, and what a fork inherits

The project is GPL-3.0, stated in the README badge and the repository metadata. That is a copyleft licence, so a distributed derivative must be released under the same terms with source available; if you intend to ship a closed-source product, this licence is a blocker and you should get your own legal advice rather than treat this paragraph as one. Upgrades are APK installs from the releases page, and the release history shows a wide gap between v2.0.1 in May 2025 and v3.0.0 in April 2026, with no patch releases in between. That cadence matters if you depend on it: there is no channel for a quick fix, and the README's own Q&A entries (re-enabling accessibility after a restart, re-granting background-popup, retrying on 502/503 from the upstream API) describe conditions you resolve on the device, not conditions the maintainer resolves for you. The maintenance cost you take on is therefore mostly operational: keeping two accessibility services alive across OS updates, holding an API key with its own rate limits, and re-verifying agent mode against each app you care about after that app updates its UI.

Editorial conclusion

Adopt it if you want a system-wide voice entry point on Android and you already hold an OpenAI-compatible API key, or if you intend to fork a Java codebase under GPL-3.0. Do not adopt it if you need a supported product with a service-level expectation, if your users cannot grant accessibility and background-popup permissions, or if you plan to ship a closed-source derivative. Before installing, verify three things on your own device: that the volume-down long-press produces a vibration but no window (which the README attributes to the missing background-popup permission), that your chosen model supports Function or tool calling, and that your WebView can reach the sites you intend to fetch.

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Skythinker616/gpt-assistant-android on GitHub