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.
Regulatory barrier — Android's security model increasingly restricts background access to motion sensors and lockscreen control, making a third-party app unable to reliably detect 'run mode' or suppress theft alerts without requiring intrusive permissions that would block Play Store distribution.Evaluated Aug 14, 2026 · thresholds published at /methodology
Turn this into a build 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.
32 credits · every platform format after it is 5
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.
Building this?
Tell everyone else. It shows on this page and on the idea cards, and it collects in your dashboard. Ship it and add the link — we fetch it and re-check it weekly.
Sign in to tell others you're building this.
Supporting evidence2
Multiple complaint signals describe the exact same failure mode — phone motion during running being classified as a theft/snatch event — suggesting the bug is reproducible and annoying enough to write about.
One signal frames this as a safety-relevant failure (unreliable during actual emergency situations), which is a stronger hook than mere annoyance.
Falsifying evidence3
All seven signals are from a single 48-hour window (Aug 6-8, 2026) on one platform (HackerNews), likely representing one viral thread being quoted rather than independent demand. No follow-up complaints exist in the data to suggest this persists beyond the initial discussion.
Android's security model increasingly restricts background access to motion sensors and lockscreen control, making a third-party app unable to reliably detect 'run mode' or suppress theft alerts without requiring intrusive permissions that would block Play Store distribution.
Google already owns the theft-detection feature being complained about and can ship a native workout exception or sensitivity toggle in a single OS update, eliminating the problem before a third-party solution gains distribution. The stated cause of death explicitly predicts this.
Most likely cause of death
Google ships a native fix (a run/workout exception or sensitivity setting) within a release cycle or two, since the bug report explicitly names their theft-detection feature as the culprit; a third-party app would need OS-level motion/permission access that Android increasingly restricts, making the workaround fragile and hard to distribute, while the underlying demand turns out to be one viral HN thread rather than a sustained, monetizable pain point. Defensibility would require either an exclusive integration with wearable OEMs (to get reliable 'run mode' signals) or becoming the de facto fitness-safety layer before Google patches it — neither of which the current evidence supports.
Demand ladder
A complaint is not a customer. Weighted ×1 / ×3 / ×8 / ×15.
Counted from clustered complaint signals. No candidate-relative commercial check was applied, so no revenue is attributed to this idea.
Verified revenue: not established for this idea. No record ties a revenue figure to a product selling what this would sell.
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 (and per one signal, iPhone) owners who run with the phone on their body and have the OS theft-detection lock enabled. Within that, the acute sub-group is runners who rely on the phone mid-run for maps, music or emergency calls and find it locked.
- How often
- Per the signals, on every run for the affected user — but the entire evidence base is one quote from one Hacker News thread over 6-8 Aug 2026, so real-world frequency across a population is unmeasured.
- Why current fixes fail
- The failing component is a system security feature owned by the OS vendor, not an app. The runner's only real options mid-week are: (a) turn theft detection off entirely in Settings before every run and remember to turn it back on afterwards — two deliberate navigations per run, which is exactly the behaviour people forget; (b) leave it off permanently and lose the protection they enabled it for; (c) carry the phone in a way that produces less snatch-like acceleration (armband vs. hand), which does not reliably stop the trigger. There is no run-aware exception exposed to third parties: an app cannot legally or technically veto the lock, so any third-party 'fix' is a reminder or a deep link to the same Settings toggle, not a suppression. That is the gap and it is also why the gap may not be fillable.
Running motion is misclassified by phone theft-detection as a snatch event, locking the device mid-activity.
The named culprit is Google's built-in theft-detection lock on Android, i.e. an OS feature rather than a third-party app.
At least one report attributes the same false positive to iPhone's anti-theft detection, so this is not Android-exclusive.
The stated consequence is safety-relevant: the phone becomes unreliable for emergency use during exercise.
All seven signals are the same verbatim sentence from one Hacker News thread inside a three-day window, so this is one amplified incident, not seven independent demand events.
No signal in this block shows anyone paying, offering to pay, or having bought anything to fix this; the demand tier labels list spend and revenue counts but no spend or revenue signal record exists.
The vendor can obsolete a third-party workaround with a single OS update adding a workout exception or sensitivity setting.
Android does not give third-party apps the permissions needed to intercept or suppress a system-level security lock, so the core mechanism of the proposed product may not be buildable at all.
Who buys it
The person who feels the pain and the person who signs are rarely the same.
Who buys it is part of membershipThe buyer, the budget it comes out of, and what these people already pay for.Product concept and MVP
Two versions: the one you deliver by hand first, and the one you build.
Product concept and MVP is part of membershipThe concierge version, the buildable version, and the features deliberately left out.Competitors and alternatives
Including the free workaround people use today, which is usually the real competitor.
Competitors and alternatives is part of membershipDirect products, indirect ones, the workarounds, and where the gap actually is.Pricing model
modelledA proposal, not an observation. Benchmarks come from the data; the ladder is ours.
Pricing model is part of membershipA tier ladder with the reasoning behind each price point.Revenue scenarios
modelledArithmetic on the assumptions listed underneath. Change an assumption and the number changes.
Revenue scenarios is part of membershipBase, upside and aggressive cases with every input written out.Market size
modelledReachable customers, not a top-down industry figure.
Market size is part of membershipHow many buyers exist, what they spend, and how many you could realistically reach.Go to market
Named places, not channel categories. These signals came from somewhere.
Go to market is part of membershipWhere the first ten customers come from, then the first hundred.Roadmap
Each version ships something a user can use. No infrastructure-only phases.
Roadmap is part of membershipVersion by version, with what belongs in each.Pivot paths
Where this goes if the first version does not land — and the number that says it did not.
Pivot paths is part of membershipAdjacent directions, and the measurable trigger for taking one.Risks and kill criteria
The thresholds at which the honest move is to stop. Written before you are attached to it.
Risks and kill criteria is part of membershipRanked risks, and the numeric conditions under which to walk away.Validation plan
Seven days that cost nothing but time and can kill the idea before you build.
Validation plan is part of membershipA day-by-day plan and the interview questions that do not lead the witness.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 6 signals · evaluation written Aug 11, 2026.
Related opportunities
Nearest by what the problem actually is, not by category label.
Security scanner for Lovable/Bolt/Supabase-built apps
A pre-deployment scanner that finds exposed databases, leaked keys, and missing RLS in apps built with AI code generators, targeted at vibe-coders shipping on Lovable, Bolt, and v0.
Budget repairable GPS sports watch (sub-$300, no-frills screen-optional)
A cheap, repairable GPS sports watch for athletes who want accurate health metrics but refuse to pay Garmin's premium prices or deal with bloated smartwatch features.
OCR/SMS-based expense tracker for Indian UPI users
An expense tracker that auto-logs spending by reading bank SMS/UPI notifications and receipt screenshots, for people who abandon manual-entry apps.
Eleven more sections behind this one
Who signs the cheque, what the space already charges, the seven-day validation plan, and the thresholds at which you should stop. Three ideas are open in full so you can judge the depth before paying.
29 people have looked at this · 0 turned it into a spec · 0 say they're building it