Voice-controlled phone actions layer for Android (calls, apps, settings) via accessibility API
A voice assistant that actually executes phone tasks—launching apps, sending messages, toggling settings—for Android users frustrated that ChatGPT Voice only talks.
The broad concept is not supported by the evidence. A narrower direction is on file: Work/personal context separation for AI assistantsEvaluated Aug 14, 2026 · thresholds published at /methodology
Supporting evidence2
Direct, explicit demand: users say they'd grant full device access to an assistant that could control their phone, and ChatGPT Voice does not do this today.
Related frustration with ChatGPT's mobile voice experience (unreliable dictation on Android) shows existing dissatisfaction with the incumbent's voice UX, a possible wedge.
Falsifying evidence4
OpenAI is the obvious incumbent to ship phone-control voice actions directly into ChatGPT Voice; if user demand is real and visible on HN, this is a roadmap item for them, not a defensible moat for a startup.
The evidence base is five signals, only one of which (S-223) actually describes this product; the rest are about account separation, connector limits, dictation bugs, and API parity — different problems bundled into one cluster.
Deep phone control on Android requires broad accessibility/automation permissions; Google's platform policies and user trust barriers around granting an app 'the keys to my phone' are a real adoption tax not addressed by any signal here.
No revenue or pricing signal exists anywhere in this cluster; willingness to grant access is not the same as willingness to pay, and no product in the space (P-1697) shows monetization for this feature.
Most likely cause of death
Most likely failure: a solo builder ships an Android accessibility-based voice-control layer, but Google/Samsung/OpenAI ship a native, permission-trusted version faster (Gemini/Assistant already has device-level integration), and the startup is left fighting a permissions-trust problem it cannot win as an unknown third-party app. Defensibility would need to come from a specific integration depth (e.g., power-user automation recipes, cross-app chaining) that the platform owners are structurally slow to build, but nothing in the evidence demonstrates that gap exists today.
Demand ladder
A complaint is not a customer. Weighted ×1 / ×3 / ×8 / ×15.
Verified revenue: none on file for this problem yet. That is an absence of records, not proof nobody is earning here.
Momentum
Is this problem getting louder or quieter?
Saturation
How many people are already on it. Most sites hide this.
Problem evidence
Who feels this, how often, and why what they use today does not fix it.
- Who feels it
- Android users who already use ChatGPT Voice daily as an assistant and expect it to do things on the device — launch an app, send a message, toggle wifi/DND — and instead get a conversation partner. Within that, the sharpest complaints come from heavy daily users (2+ years) who treat the phone assistant as a workflow tool, not a novelty.
- How often
- Every time the user tries to hand the phone a task by voice — plausibly several times a day for a heavy user, but the evidence block contains no frequency data, only one-off statements of the wish (S-223) and one report of recurring dictation failure (S-2142).
- Why current fixes fail
- ChatGPT Voice terminates at text: it answers, it cannot act, so the user still has to unlock, find the app and tap — the exact motion they invoked voice to avoid (S-223). The one path that does act on Android is the built-in assistant, which sits behind the OS trust boundary; a third-party app has to ask for accessibility/automation permissions that read and drive the whole screen, which is where non-technical users stop (X-205). And the secondary failure mode is even more basic: voice input itself is unreliable enough on the Android ChatGPT app that a two-year daily user was shopping for alternatives (S-2142) — meaning the layer above the input is not the only broken part.
At least one user explicitly wants a voice assistant to control phone functions and apps, and says ChatGPT Voice is conversation-only.
Trust is not the stated blocker for at least some power users — the quoted user volunteers to 'give OpenAI the keys to my phone' — but that willingness is expressed toward OpenAI, a brand they already use, not toward an unknown third-party app.
Voice input on ChatGPT's Android app is unreliable enough that a two-year daily user was actively looking to switch products, which suggests the adjacent, smaller problem (dictation that works) has churn-level pain behind it.
The demand evidence for this specific product is one signal. The other four records in the cluster concern work/personal chat separation, multi-account connectors, dictation bugs and API/product parity — different problems that were bundled together.
No signal in this block shows anyone paying, or offering to pay, for phone-action voice control; willingness to grant permissions is the only expressed commitment.
The party best placed to close this gap is the incumbent the users are already inside: OpenAI shipping actions into ChatGPT Voice, or Google/Samsung deepening the native assistant. Nothing in the block identifies a capability those parties are structurally unable to ship.
Deep device control requires broad accessibility/automation permissions governed by Google's platform policies, an adoption and distribution tax that none of the signals acknowledges.
Two of the five signals are about keeping work and personal AI contexts separate and about connecting multiple accounts of the same provider — an unrelated but more concretely described pain than the phone-control wish.
Who buys it
The person who feels the pain and the person who signs are rarely the same.
- User
- Android power user who already pays for an AI assistant subscription and customises their phone (the profile implied by S-223's framing and by the tool list: ChatGPT, ChatGPT Voice, Gmail, Slack, Google Drive, Google Calendar).
- Buyer
- Same person. This is B2C; there is no separate payer in the evidence.
- Pain owner
- The end user. Nobody else is inconvenienced when their phone won't obey a voice command, which means there is no third party who will fund the fix.
- Budget source
- Personal discretionary spend, competing directly against the AI subscription they already hold. Assumption: a consumer already paying one assistant subscription treats a second one as a substitute, not an addition.
- Urgency
- Low. No deadline, no cost of inaction, no compliance driver. The closest thing to urgency in the block is churn intent driven by dictation failure (S-2142), which is about the input layer, not phone actions.
- Already spending on
- ChatGPT (paid tier implied by daily-user behaviour; no price recorded in this block)ChatGPT VoiceCodexOpenAI APIGmail / Google Drive / Google Calendar (Google account, likely free tier)Slack (likely paid by an employer, not this user)
Product concept and MVP
Two versions: the one you deliver by hand first, and the one you build.
An Android app that turns spoken requests into executed device actions — open app, send message, toggle setting, chain two steps — using the accessibility API plus an LLM to map utterance to a whitelisted action. Positioned as the 'it actually does it' layer that ChatGPT Voice refuses to be.
Concierge version
No software. Ten users, done by hand. This is how you find out you are wrong for the price of a weekend.
Real-time hand execution is not possible: nobody can tap a stranger's phone for them without remote-control permissions that are as invasive as the product itself. That is a finding, not a gap. The workable manual version: recruit 10 Android users from the threads below, get on a 30-minute screen share each, and hand-build their top three voice-triggered automations using existing free tools (MacroDroid/Tasker-style recipes plus Google Assistant routines) — no code of your own. Deliver a one-page 'say this, get that' card. Then measure: do they still use the recipes on day 14, and will they pay $5 for you to build three more? Cost: your time only.
Vibe-coded version
What a build platform can scaffold, and what you write yourself.
Kotlin Android app, single accessibility service, hard whitelist of ~15 actions (launch app by name, send SMS/WhatsApp message to a named contact, set alarm/timer, toggle wifi/bluetooth/DND/torch/rotation, play music, start navigation to a saved place, read last notification). Speech to text via Android's on-device recogniser; one LLM call to map transcript to a structured action JSON; confirmation toast with a 2-second undo. No cloud account, no chat UI, no history.
Must have
- Wake-free activation that beats tapping: assistant-button/gesture takeover or a lock-screen-usable trigger
- Deterministic action execution with visible confirmation and undo — a voice layer that silently does the wrong thing is worse than none
- Reliable transcription on cheap Android hardware and accented English (S-2142 shows this is where competitors already fail)
- Honest, single-screen permission explainer, because accessibility permission is the funnel's cliff edge
- Latency under ~2s from end of speech to action
Nice to have
- Two-step chaining ('open Slack and post I'm running late')
- User-defined phrase aliases
- Offline fallback for the top 5 device toggles
- Widget/shortcut so power users can test without granting full accessibility on day one
Not yet
- Any chat/conversation feature — that is the incumbent's ground and it invites direct comparison you lose
- Cross-app scraping or reading screen content for context
- iOS anything
- Accounts, cloud sync, teams, sharing recipes
- Gmail/Calendar/Drive/Slack API integrations (they look adjacent because they appear in the tool list, but they are OAuth work that has nothing to do with device control)
- Custom wake word
- Integrations
- Android AccessibilityService · Android Intents / ContentResolver for app launch, SMS, alarms · Android SpeechRecognizer (on-device) · One LLM provider for utterance→action parsing (OpenAI or equivalent) · Google Assistant / assistant-app slot for trigger takeover
- Build difficulty
- 4/5 — The action whitelist is a weekend each; the hard 80% is permission onboarding, wake-path reliability across OEM skins (Samsung/Xiaomi battery and background-service killing), and Play Store review of a broad accessibility-permission app — a policy risk flagged directly in X-205.
Competitors and alternatives
Including the free workaround people use today, which is usually the real competitor.
Direct
- No direct competitor is recorded in this block — the products list is empty. That is missing data, not an empty market: Google Assistant/Gemini and Samsung…
Indirect
- ChatGPT Voice (talks, does not act — the stated trigger for the idea, S-223)
- OpenAI more broadly, as the party most likely to ship actions into the app users already have (X-204)
Workarounds
- Just unlocking the phone and tapping — the free, zero-trust-cost baseline every user has today
- The built-in OEM assistant for the handful of commands it already handles (implied by S-223's framing that the *ChatGPT* assistant is the one that can't act)
- Existing Android automation apps and OS routines configured once by hand (the concierge MVP leans on these; no signal names one, so treat as inference)
- Living with unreliable dictation and re-typing, or switching AI product entirely (S-2142)
- For the work/personal problem in the same cluster: manually disconnecting and reconnecting accounts, or keeping separate browser profiles (S-567, S-317)
| Product | Customer | Pricing | Strengths | Weaknesses | Gap |
|---|---|---|---|---|---|
| ChatGPT Voice | Consumers using an AI assistant conversationally on mobile | Not recorded in this block | Already installed and trusted by the exact complaining user; strong conversational quality; brand permission to ask for deep device access (S-223) | Conversation only — no device actions; Android dictation reliability problems severe enough to drive churn intent (S-2142) | Execution of device actions. Narrow, and explicitly on the incumbent's likely roadmap (X-204). |
| OpenAI (platform) | Same users, across ChatGPT / Codex / API | Not recorded in this block | Owns the surface, the account, the voice pipeline and the users' trust; can ship actions as a feature flag (X-204) | Slow on adjacent user-visible gaps: work/personal separation (S-317), multi-account connectors (S-567), API-vs-product parity (S-2163) all remain open | The unmet needs OpenAI actually leaves open are context/account separation, not device control. |
| Codex (app/CLI) | Developers using OpenAI tooling for work | Not recorded in this block | Dedicated work-mode surface that users valued | Folded into ChatGPT, leaving users unable to keep work and personal contexts apart with no standalone replacement (S-317) | A context-separation layer — the strongest complaint in this cluster by severity (75) and the one with no incumbent fix on file. |
On the evidence here the competitive position is the weakest part of the idea. The single demand signal describes a feature gap inside an incumbent product, the incumbent has both the trust and the surface to close it (X-204), and the OS vendors already ship a permission-trusted version of the same capability. No record in this block shows a durable capability gap. Meanwhile the highest-severity complaint in the cluster (S-317, work/personal separation) has no owner. If you proceed, proceed as a validation exercise with a hard kill date, not as a build.
Pricing model
modelledA proposal, not an observation. Benchmarks come from the data; the ladder is ours.
Consumer subscription with a free action-limited tier. Chosen over one-time purchase because LLM parsing is a per-use cost; chosen over ads because the product is a system-level utility and ads would poison the permission ask. All numbers below are assumptions — the block contains zero pricing or willingness-to-pay evidence (X-207).
Free
$0 — 20 voice actions/month, 6 device…
Everyone; exists purely to get past the accessibility-permission cliff and measure retention
Pro
$3.99/mo or $29/yr (assumption)
Daily users; unlimited actions, chaining, custom phrase aliases
Lifetime
$49 one-time (assumption)
Android power users who reflexively distrust subscriptions; also a cheap willingness-to-pay probe
What the space charges
| ChatGPT subscription | Not recorded in this block | The comparison every prospect makes. Pricing above it is not viable; the product must read as a small add-on, not a second assistant. |
Confidence in this pricing: none
Revenue scenarios
modelledArithmetic on the assumptions listed underneath. Change an assumption and the number changes.
| Case | Customers | ARPA / mo | MRR | ARR |
|---|---|---|---|---|
| base | 300 | $4 | $1,200 | $14,400 |
| upside | 2,500 | $4 | $10,000 | $120,000 |
| aggressive | 15,000 | $5 | $75,000 | $900,000 |
Assumptions behind these numbers
Disagree with one of these and the table above is wrong. That is the point of listing them.
- No revenue or pricing signal exists in this block (X-207); every figure below is an assumption chain, not a projection from data.
- ARPA of $4/mo assumes the Pro tier at $3.99 with a small mix of $49 lifetime purchases amortised over ~12 months.
- Base case: 20,000 installs over 12 months from organic HN/forum/Play Store discovery with no paid spend; 60% complete the accessibility permission grant (assumption — this is the number most likely to be worse); 2.5% of granted installs convert to paid = 300.
- Upside: 100,000 installs (one strong HN front page plus a mid-size Android YouTube review), same 60% grant rate, 4% conversion = 2,400, rounded to 2,500.
- Aggressive: 500,000 installs, 60% grant, 5% conversion, ARPA $5. This requires Play Store category placement or a viral demo, and assumes neither OpenAI nor Google ships the equivalent inside 24 months — which X-204 says is unlikely.
- Variable cost per paid user assumed at $0.30-0.60/mo of LLM parsing at ~150 actions/month with a small model; gross margin ~85% at Pro price. Not evidenced.
- Play Store takes 15-30%; base ARR net of store fees is roughly $11-12k.
Market size
modelledReachable customers, not a top-down industry figure.
- Target customers
- Cannot be sized from this block. What is here: one HN commenter (S-223) and one Android ChatGPT daily user with input problems (S-2142). No install-base numbers, no survey, no analogue product with users. Any TAM figure would be invented.
- Spend per year
- Assumption only: $36-48/yr per converting user at the Pro price. The block records no consumer spend on this category at all (X-207).
- Reachability
- Mixed. The niche is reachable cheaply — the people who want this congregate on Hacker News, the OpenAI community forum, and Android customisation communities, all zero-cost to post in. Distribution beyond that niche is gated by the Play Store and by the accessibility-permission dialogue, both of which the founder does not control (X-205).
- Obtainable in 3 years
- Modelled, not evidenced: the base case above, ~$14k ARR, is the honest three-year expectation for a solo builder in a consumer utility category with one demand signal and an incumbent on the same roadmap. Treat $120k ARR (upside) as the outcome that justifies the three months, and assign it well under even odds.
- Comparable
- None available. The products list for this space is empty (0 records), so there is no verified revenue anywhere in this block to anchor against — an absence worth taking seriously before building.
Go to market
Named places, not channel categories. These signals came from somewhere.
First 10 customers
- Reply in the Hacker News thread that S-223 came from (2026-08-02, ChatGPT Voice phone-control discussion) offering to hand-build the automations for anyone who comments — this is the single highest-intent person on file.
- community.openai.com (Discourse) — the threads behind S-2142 (Android voice dictation alternatives) and S-2163; post asking Android users what they last tried to make their phone do by voice and failed.
- Hacker News 'Ask HN' post: 'What do you say to your phone that it refuses to do?' — collect verbatims, not signups.
- Android customisation communities (r/tasker, r/AndroidQuestions, r/Automate, XDA forums). Flagged: none of these appear in the evidence block; treat as untested channels.
- Search terms to seed and monitor: 'ChatGPT voice control my phone Android', 'ChatGPT Voice open app', 'Android voice launch app accessibility', 'ChatGPT dictation not working Android'.
- Direct outreach to the GitHub issue participants behind S-567 — they are technical, self-select for automation frustration, and will tell you fast if the concept is trivial.
First 100
- A single 90-second screen-recorded demo, no narration, posted to HN and one Android subreddit — the product is only convincing as video.
- Play Store listing tuned to the search terms above; measure install→permission-grant→first-action funnel from day one.
- Ask each of the first ten users for the exact phrase they'd use to recommend it, then use their phrasing in the listing.
- One Android-focused YouTube reviewer with under 100k subscribers; free lifetime keys, no payment.
Scalable channels
- Play Store organic search on device-action intents (only channel here with real headroom; entirely dependent on the permission funnel not collapsing)
- Android customisation communities and creators
- Nothing else. Paid acquisition on a $4/mo consumer subscription with unproven conversion is not a channel, it is a way to lose money faster.
What will not work
- Founder has no stated audience; every channel above requires earning attention post by post, and HN goodwill is single-use.
- The demo that gets attention on HN (deep, chained control) is exactly the demo that triggers Play Store accessibility-policy scrutiny (X-205).
- Any traction visible on HN is also visible to OpenAI and Google (X-204); success in the channel accelerates the copy.
Roadmap
Each version ships something a user can use. No infrastructure-only phases.
- Ten hand-built automation setups via screen share (concierge MVP)
- Day-14 usage check-in with each of the ten
- $5 paid-recipe offer as a willingness-to-pay probe
- Written go/no-go against the kill criteria
- Accessibility service plus 6 device toggles and app-launch-by-name
- Permission explainer screen with drop-off instrumentation
- Latency measurement on two cheap Samsung/Xiaomi devices
- Ship to the ten concierge users only
- LLM utterance→action parsing with confirmation and undo
- Messaging actions (SMS, WhatsApp) to named contacts
- Alarms, timers, navigation, media control
- OEM background-kill survival work
- Play Store submission (allow 2+ weeks for accessibility policy review)
- Free tier with 20-action cap; Pro and Lifetime purchase
- Funnel dashboard: install → grant → first action → day-7 retention → paid
- Demo video, HN post, one creator outreach
Pivot paths
Where this goes if the first version does not land — and the number that says it did not.
Work/personal context separation for AI assistants
S-317 is the highest-severity signal in the cluster (75) and S-567 corroborates it from a different source: users cannot keep work and personal AI contexts apart, cannot connect two accounts of the same provider, and have no standalone replacement since Codex was folded in. No incumbent fix is on file, and the sufferers are developers — a segment with budget and a habit of paying for tools.
Reliable Android dictation/voice-input layer
S-2142 shows a two-year daily paying user shopping for alternatives because voice input fails. Narrower, less glamorous, no accessibility-permission cliff, and the pain is already churn-grade. It is also the layer this idea depends on, so building it first de-risks the bigger version.
Automation recipe packs for existing Android automation tools
If the concierge phase shows people use hand-built recipes but won't grant accessibility to a new app, the value was the recipes, not the runtime. Sell curated packs and setup service — no platform risk, no permission cliff, far smaller ceiling.
Pivot trigger
Pivot if, by end of week 5, either (a) fewer than 6 of 10 concierge users are still using their hand-built automations at day 14, or (b) permission-grant rate on v0.1 is under 40% across the first 50 installs. Either result means the pivot to S-317 (context separation) starts week 6.
Risks and kill criteria
The thresholds at which the honest move is to stop. Written before you are attached to it.
Kill criteria
If one of these is true, stop. The value of writing them now is that you will not want to later.
- By day 14: if fewer than 6 of 10 concierge users are still using their hand-built voice automations, stop.
- By day 14: if fewer than 3 of 20 interviewees say they have tried to make their phone do something by voice and failed in the last month, stop — the pain is not recurring.
- By day 21: if fewer than 3 of the 20 interviewees accept the $5 paid-recipe offer, treat willingness to pay as unproven and stop (directly tests X-207).
- By week 8: if accessibility-permission grant rate is under 40% of installs across at least 50 installs, stop — the funnel cannot be fixed downstream.
- By week 12: if OpenAI or Google has announced or shipped device-action execution in ChatGPT Voice or Gemini on Android, stop immediately regardless of your own metrics (X-204).
- By week 14 (2 weeks post-listing): if day-7 retention among permission-granted installs is under 20%, stop.
Validation plan
Seven days that cost nothing but time and can kill the idea before you build.
The next 7 days
- Day 1Re-read the source records. Write down, in one sentence, exactly what S-223 asks for. Then list the four other signals and mark which are the same problem — you should conclude none are (X-206). Post a comment in the original HN thread offering free hands-on help building the automations.
- Day 2Post to community.openai.com and one Android automation forum: 'What did you last try to make your Android phone do by voice, and what happened?' No product mention, no link. Target 20 responses.
- Day 3Book 8 screen-share calls from the responses. Install free automation tooling on your own phone and build the five commands you'd most want, timing how long each takes — this is your cost per concierge customer.
- Day 4Run 4 concierge sessions: build each user's top three voice automations by hand, live. Record where they hesitate on the permission prompts and the exact words they use for each command.
- Day 5Run 4 more sessions. In each, make the $5 offer for three more recipes next week. Log yes/no verbatim. Also ask each user what they currently pay for ChatGPT and whether they'd pay anything on top.
- Day 6Check the Play Store: search your target terms, list every app already doing voice-driven Android actions, note their install counts, ratings and whether they charge. This fills the empty products list in the evidence block — do it before writing a line of code.
- Day 7Score against the kill criteria. Write the go/no-go in one page. If the $5 offer got fewer than 3 yeses or the Play Store search shows several established free apps with the same whitelist, switch to the S-317 context-separation pivot and repeat this week for that problem.
Ask them this
Questions about what they did, not what they would do.
- Walk me through the last time you spoke to your phone and it didn't do what you asked. What did you do next?
- How many times last week did you pick up your phone to do something you'd rather have said out loud?
- Which assistant is already on your home button, and what have you actually got it to do successfully?
- When an app asks for permission to see and control your screen, what do you do? Has that ever stopped you installing something?
- What do you pay for ChatGPT today, and would you pay anything for a separate app that only executed phone actions? How much, before you'd rather just tap?
- Have you ever set up a phone automation yourself — Tasker, a Google routine, a shortcut? What happened to it?
- If OpenAI added this to the ChatGPT app next month, would you still want a separate app? Why?
- (For the pivot) How do you keep work and personal AI chats apart today, and what does that cost you when it breaks?
Sources and freshness
Every reference opens the original post. This is the part you should check first.
How sure are we, per claim
Where the data is thin, we say so instead of rounding up.
- demand
- Low
- payment
- No data
- market size
- Low
- competitor gap
- Low
10 references from 5 signals · evaluation written Aug 14, 2026.
Related opportunities
Nearest by what the problem actually is, not by category label.
AI voice receptionist for Spanish dental clinics with emergency triage
A 24/7 AI phone agent for Spanish dental practices that books appointments, captures insurance details, and flags urgent dental emergencies for callback.
Third-party calibration app to suppress false theft-lock triggers during running (Android)
A companion app for Android runners that detects a 'run session' (via connected earbuds/watch or manual toggle) and temporarily suppresses Google's theft-detection lock so it stops mistaking running for a phone snatch.
Escalation-to-human triage add-on for SMB SaaS AI support widgets
A drop-in escalation layer that SMB software vendors plug into their AI chatbot so frustrated users can reach a real human, sold to the vendor not the end user.
Turn this into a spec
One Universal Core, then the exact file layout your platform expects — CLAUDE.md, .cursor/rules, a Lovable knowledge base, a Bolt prompt under its 400-word ceiling. Evidence travels with it.
Reading an open idea needs nothing. Generating a spec from it calls a model and costs real money, so it needs an account and credits — the cost is shown before you spend anything.