What changed
FACT (per cited Android Developers Blog post): starting in Android 17 the system enforces per-app memory limits based on device RAM and kills apps that exceed them with no stack trace. FACT (per cited post): Android Studio features — profilers, Compose Previews, device streaming — are now drivable by coding agents via a stable first-party CLI. FACT (per cited Vercel post): Vercel ships an agent that autonomously investigates production incidents and proposes approval-gated remediation, proving the 'autonomous RCA agent' product pattern at the platform layer.
Why now
Enforcement just landed (June 2026 blog post), so memory-heavy publishers hit silent kills during their next release cycle — a compressed window where pain is new, unexplained, and evades their existing crash-reporting stack. The agent-drivable Android CLI reached stable only weeks earlier, so this automation was not buildable by a solo operator before now. HYPOTHESIS: incumbents (Crashlytics, Sentry, Embrace) will close the detection gap within 6-12 months, so the durable wedge is the *autopsy/repro* layer, not detection.
Converging signals
(1) OS-level silent kills with no crash artifact create a diagnosability void [Android 17 memory post]; (2) stable first-party CLI lets an agent run builds, profilers, and device sessions programmatically [Android productivity post]; (3) Vercel Agent validates that customers accept an autonomous agent investigating production failures and proposing remediation [Vercel blog]. Together: a one-person 'memory-kill autopsy' pipeline is newly feasible and newly needed.
Customer pain
FACT-ADJACENT (inferred from the OS behavior described in the source): a user's app just dies mid-session; the developer sees rating damage and vague reviews but no stack trace, no Crashlytics event, no repro. HYPOTHESIS: developers of games, media, and camera apps will burn engineer-days manually profiling to find which allocation path crosses the new limit — the exact expensive toil an agent can automate.
Who pays
Android publishers of memory-heavy apps (games, video/photo editors, camera apps, map-heavy apps) — teams that already pay for crash reporting and observability (Crashlytics/Sentry/Embrace-class budgets exist as a spending category; that this specific failure mode evades those tools is stated in the convergence input and is consistent with 'no stack trace'). HYPOTHESIS: mid-size studios (5-50 devs) are the sweet spot — big enough to feel rating damage, small enough to buy without procurement.
Solved today
Manually: an engineer tries to reproduce the kill locally, watches Android Studio Memory Profiler, hunts leaks with LeakCanary (free, leak-specific, not limit-enforcement-aware), and reads ApplicationExitInfo exit reasons if they know to look. Crash SaaS shows the exit happened at best, not why. HYPOTHESIS: most teams currently have no workflow at all for limit-enforcement kills because the enforcement is weeks old.
Why current solutions are bad
No artifact to start from: the kill produces no stack trace, so the entire existing crash-triage pipeline (symbolication, grouping, blame) has nothing to ingest. Manual profiler sessions are slow, non-deterministic, and require the failing device/RAM class. LeakCanary finds leaks, not legitimate-but-over-limit allocation patterns (large bitmaps, caches sized for old headroom assumptions).
Proposed product
A CI-attachable autopsy agent: customer provides an APK/AAB plus a scenario script (or lets the agent record one); the service runs instrumented sessions across RAM-class-representative emulator/device profiles via the stable CLI, captures heap dumps and allocation tracking over time, bisects growth to the responsible allocation sites (and, with repo access, to the commit), and delivers a plain-English root-cause report with a proposed remediation diff — Vercel Agent's pattern ported to Android memory kills. Priced per autopsy, no SDK required for the core product.
MVP version
2-3 weeks: (a) a free open-source 'kill detector' — a tiny library/CLI that reads ApplicationExitInfo and tells a dev 'you were memory-killed N times, here are the sessions' (lead magnet + proof the pain exists); (b) a manual-behind-the-curtain autopsy service: Charles runs the agent pipeline (Claude-driven CLI + profilers) on the customer's APK and hand-delivers the first reports for a fixed fee (~$500-1500 per autopsy). No dashboard, no self-serve, no SDK integration required.
30-day build
Week 1: complaint-mine r/androiddev, StackOverflow, Google IssueTracker, and gamedev Discords for developers reporting unexplained kills post-Android-17; build a list of 50 named apps/devs showing the pain. Week 2: ship the free ApplicationExitInfo kill-detector + a write-up ('Android 17 is killing your app silently — here's how to see it') to r/androiddev and Android newsletters. Weeks 3-4: offer 3 free autopsies to devs from the complaint list in exchange for testimonials; validate the agent pipeline end-to-end on real apps.
60-day build
Convert the free-autopsy pipeline into a paid productized service ($750-1500/autopsy or $299/mo monitoring + 1 autopsy). Automate the repro/bisect loop enough that an autopsy costs <2 hours of oversight. Publish 2-3 public teardowns of (permissioned or open-source) apps as demand-gen. Target: 5-10 paying autopsies.
90-day revenue plan
HYPOTHESIS: $2-6k/month by day 90 via 3-6 autopsies/month plus early monitoring subscriptions — contingent on the complaint-mining in week 1 actually surfacing acute pain. If week-1 mining finds fewer than ~20 credible complaints, kill or shelve; the market is not feeling it yet.
Distribution path
Demonstrated-value channel, matching founder profile: the free kill-detector and public teardown posts do the selling; r/androiddev, Hacker News, Android Weekly, gamedev Discords. No enterprise sales — buyers are individual Android leads who can expense a sub-$1500 report. The free tool doubles as an intent-qualified lead list.
Pricing hypothesis
Per-autopsy fee ($750-1500) mirroring his proven per-transaction ELDT model; $299-499/mo monitoring tier (detector + monthly autopsy credit) for recurring revenue. Anchor against the cost of 2-3 senior-engineer days per manual investigation.
Technical difficulty
HIGH — this is the biggest honest risk. Deterministically reproducing a memory kill requires realistic scenario driving, RAM-class-matched environments, and apps whose builds the agent can instrument; obfuscated release builds without customer cooperation are much harder. The CLI makes orchestration feasible, but repro flakiness could make each autopsy artisanal rather than automated. Solo-buildable MVP: yes. Solo-buildable *reliable product*: unproven hypothesis.
Legal / regulatory risk
LOW. Analyzing a customer's own app with their consent involves no regulated data by default; needs standard NDA/DPA hygiene if repo access is granted. No government filings, no PII-heavy surface.
Platform dependency
HIGH and double-sided: the product depends on Google's CLI/profiler stability (new, could churn), and Google is the most likely party to ship native tooling — Play Vitals or Android Studio adding 'memory limit kill' diagnostics would gut the standalone detection layer overnight. The autopsy/remediation layer is more defensible than detection but still lives in Google's shadow.
Founder fit
MODERATE, not the VERY-HIGH pattern. This is NOT his proven gov-portal shape (no regulation compelling a filing, no per-filing capture point). It does match: complaint-mining, AI-agent workflows, per-transaction pricing, demonstrated-value distribution, fast prototyping, no enterprise sales. It does not match: he has no established Android-internals credibility, and dev-tool buyers weigh technical credibility heavily — the free tool and public teardowns must manufacture that credibility from zero.
Breakout potential
If the autopsy loop generalizes, it extends to ANR autopsies, battery/thermal kills, and startup-time regressions — a 'production incident agent for mobile' (the mobile Vercel Agent). That is a venture-scale story, but the founder profile says no VC, so breakout means an acquisition target for Embrace/Sentry-class incumbents or a durable $10-30k/mo service.
Final recommendation
CONDITIONAL PURSUE as a cheap two-week probe, not a build commitment. Grade: B-. The convergence is real and the timing window is genuine, but demand is unproven, technical repro risk is high, and this sits outside his highest-conviction gov-portal pattern. The probe costs almost nothing and fits his complaint-mining strength: mine for post-Android-17 silent-kill complaints and ship the free detector. Proceed to paid autopsies ONLY if the mining surfaces 20+ credible complaints and 3+ devs accept a free autopsy. Otherwise tag 'revisit later' and re-check when Android 17 device penetration forces the pain (likely 2-4 months post-rollout).
Next action
Spend 2 days complaint-mining r/androiddev, StackOverflow, Google IssueTracker, and gamedev Discords for unexplained-app-death reports since the Android 17 rollout; log every named app and author as a prospect. Decision gate: 20+ credible complaints → build the free ApplicationExitInfo kill-detector that same week; fewer → shelve with a 60-day re-check.