What changed
FACT (per cited sources): Android 17 now enforces per-app memory limits scaled to device RAM and kills offending apps with no stack trace; Google's Android CLI hit stable 1.0, letting coding agents programmatically drive Android Studio profilers, builds, and device streaming; Gemini 3.5 Flash brought computer-use to a cheap model tier; Vercel Agent proved the 'autonomous production-incident RCA' product shape on web deploys.
Why now
The three enabling pieces (enforced silent kills, agent-drivable first-party profiler CLI, cheap agentic compute) did not coexist three months ago. Pain will ramp exactly with Android 17 adoption over the next 6-12 months. HYPOTHESIS: the current moment is slightly EARLY — most fleets are not yet on Android 17, so acute buyer pain is predicted, not yet demonstrated.
Converging signals
Android 17 memory enforcement (Android Developers Blog, Jun 2026) + Android CLI stable 1.0 agent tooling (May 2026) + agent-drivable profilers/device streaming (Jun 2026) + Flash-tier computer use (DeepMind) + Vercel Agent validating autonomous incident RCA as a paid platform feature.
Customer pain
App teams see retention/session-length drops and 'app just closed' 1-star reviews with no crash log to debug, because the OS kill leaves no stack trace (FACT per source 841). Reproducing requires low-RAM device matrices most teams don't maintain. HYPOTHESIS: games, camera, and media apps feel this first and hardest.
Who pays
Small-to-mid Android studios (games, media, camera, AR) with revenue tied to session length; secondarily agencies maintaining client apps. Priced per-incident report or small monthly CI check. NOT enterprise: buyer is the lead Android dev with a company card.
Solved today
Manual profiling in Android Studio, Perfetto traces, Firebase/Android Vitals aggregate metrics, or paid mobile-observability SDKs (Embrace, Instabug, Sentry). All require the developer to instrument, reproduce, and interpret themselves; none autonomously reproduce OS-initiated kills per RAM class and return a remediation diff.
Why current solutions are bad
Vitals tells you kills happened, not why; profilers require the dev's time and a repro they can't get; observability SDKs need pre-crash instrumentation shipped in advance and still don't produce fixes. The missing stack trace breaks every log-driven workflow — the gap is real (FACT for the mechanism, HYPOTHESIS for how badly teams feel it today).
Proposed product
'Kill Autopsy' — customer submits APK or repo + a description of the kill pattern; an agent pipeline (Android CLI + emulators pinned to 2/3/4/6GB RAM profiles + heap profiler runs + cheap computer-use model to drive UI flows) reproduces the memory climb, bisects the allocation source, and returns a ranked report with heap snapshots and concrete code-level remediation suggestions (a diff when repo access is given).
MVP version
No SaaS. A semi-manual concierge pipeline on the existing server/local rig: scripted Android CLI + emulator matrix + Claude-driven analysis, hand-assembled PDF/Markdown report. Sell 3-5 autopsies at $300-750 each to validate before automating. Buildable solo in 2-3 weeks since the profiler driving is the exact agent-CLI workflow Google now documents.
30-day build
Week 1-2: build the repro rig against 2-3 open-source memory-heavy apps; publish one spectacular free public autopsy of a popular OSS app as the demo asset. Week 3-4: mine r/androiddev, Google IssueTracker, and Play reviews for teams already complaining about Android 17 kills; direct-offer 10 paid autopsies. Kill criterion: fewer than 2 paid bookings from 30+ direct offers = shelve and revisit at higher Android 17 adoption.
60-day build
If validated: automate intake→emulator matrix→report to cut delivery to <1 day; add repo-access tier that returns an actual patch PR; publish 2-3 more public autopsies as SEO/content distribution; introduce a $99-199/mo 'pre-release memory gate' CI check for prior customers.
90-day revenue plan
Target: $2-5k from 8-15 paid autopsies plus 3-5 CI subscriptions. HYPOTHESIS — depends entirely on Android 17 adoption pace and whether pain shows up in month 1-2 validation.
Distribution path
Demonstrated-value distribution (matches founder): public teardown reports of known apps, posted to r/androiddev, Hacker News, X Android-dev circles; answering Stack Overflow/IssueTracker threads about Android 17 kills with genuinely useful snippets linking the service. No ads, no enterprise sales.
Pricing hypothesis
$300-750 per incident autopsy (concierge phase); $1,000-1,500 with remediation PR; $99-199/mo per app for pre-release CI memory-regression gate.
Technical difficulty
Moderate. Emulator RAM classes, Android CLI profiler orchestration, and agent loops are well-documented first-party surfaces; hard parts are flaky repro of nondeterministic memory pressure and apps whose kill only manifests on real devices/OEM skins (emulators may not reproduce OEM-specific limits — HYPOTHESIS, must test).
Legal / regulatory risk
Low. Analyzing a customer's own APK/repo with their authorization is clean. Public autopsies of third-party OSS apps are fine; avoid publicly shaming closed-source apps without permission.
Platform dependency
High and double-edged: the whole rig sits on Google's Android CLI, and Google is the single most likely party to absorb this feature into Android Studio/Gemini in a release or two — the same way Vercel absorbed AIOps into the platform. This caps the window at roughly 12-24 months (HYPOTHESIS).
Founder fit
MODERATE, not his best shape. It fits his automation/AI-workflow strengths, low-budget concierge-first execution, and demonstrated-value selling. But it is NOT the proven government-portal pattern: no regulation compels anyone to buy, he has no existing Android-dev audience or credibility, and the buyer is a developer peer rather than a compliance-obligated business. His FMCSA edge doesn't transfer here.
Breakout potential
If validated, expands into a general 'mobile incident RCA agent' (ANRs, battery, startup regressions) — the Vercel Agent shape for mobile. But that bigger version is exactly what Google or Embrace would ship, so the realistic play is a 12-18 month cash-flow service, not a durable company.
Final recommendation
CONDITIONAL GO as a 30-day, low-cost validation sprint only. The technical convergence is real and the mechanism (no stack trace) genuinely breaks existing workflows, but demand is predicted rather than observed, the platform-absorption risk is severe, and it sits outside the founder's proven regulatory-filing edge. Cap investment at ~2-3 weeks; treat as a cash-flow service with a 12-24 month window, not a company. If <2 paid bookings after 30 offers, shelve and revisit at Android 17 majority adoption.
Next action
Spend one day mining r/androiddev, Google IssueTracker, and Play Store reviews for concrete Android 17 silent-kill complaints; if fewer than ~10 distinct sufferers are findable, stop before building anything.