What changed
FACT (per the single source, Android Developers Blog, June 2026): Android 17 will enforce per-app memory limits keyed to device RAM and terminate apps that exceed them. HYPOTHESIS: that these kills leave 'no stack trace' and no diagnostic breadcrumb — the input asserts this, but Android already exposes ApplicationExitInfo (REASON_LOW_MEMORY) and Play Console Android Vitals surfaces OOM/kill data, so the 'no telemetry' premise is likely overstated.
Why now
Android 17 stable is expected fall 2026, with enforcement visible in developer previews/betas now. The window to build against preview builds and be 'first' is the only time-based hook — but it is a soft window, not a mandated deadline.
Converging signals
Thin. This is effectively ONE signal (a single Google blog post) spanning the android+platform bridge. There is no independent second source, no complaint corpus, no hiring/spend evidence, and no forced-filer mandate. Calling this a 'convergence' overstates a single OS release note.
Customer pain
HYPOTHESIS: publishers of memory-heavy apps (games, camera/ML, media) will see kill-rate spikes when caps turn on. This pain is REAL for a subset of apps but is NOT yet live (enforcement is fall 2026) and no evidence of it is provided — the demand_evidence array is empty.
Who pays
Android app publishers with memory-heavy apps. Reachable buyers, but they already run Sentry, Firebase Crashlytics, Embrace, Bugsnag, or Instabug and use free LeakCanary + Android Studio Memory Profiler.
Solved today
Android Studio Memory Profiler + Perfetto (free), LeakCanary (free, dominant OSS leak detector), ApplicationExitInfo API (free, gives kill reason), Play Console Android Vitals (free memory/kill metrics), and paid crash/perf platforms (Sentry, Embrace, Firebase, Bugsnag).
Why current solutions are bad
Existing tools are general crash/perf tools, not tuned to Android 17's specific RAM-tier caps or pre-kill state capture. That is the only genuine wedge — but it is a feature any incumbent adds in one release, and Google itself is the most likely party to surface exactly this in Android Vitals.
Proposed product
An Android SDK that samples live memory footprint against the projected RAM-tier limit for the device, snapshots heap/allocation state just before a projected OOM/kill, runs leak heuristics, and produces concrete remediation guidance, plus a web dashboard for trends across app versions.
MVP version
An instrumentation library wrapping ActivityManager memory APIs + ApplicationExitInfo, a per-device RAM-tier limit table derived from Android 17 preview behavior, a leak heuristic pass, and a minimal dashboard. Validated against current Android 17 preview builds.
30-day build
Reverse-engineer the actual enforced caps from Android 17 preview builds (are they documented, or must they be empirically measured?). Build the memory-sampling core and confirm ApplicationExitInfo does/does not already provide what the SDK would. Decide fast whether the 'no telemetry' premise survives contact with the real preview.
60-day build
Ship an alpha SDK + dashboard; recruit 3-5 design-partner app teams from Android dev communities to instrument real apps against previews.
90-day revenue plan
Convert design partners to paid; publish a data-backed 'which RAM tiers will kill your app' report as a content wedge. Realistically, meaningful revenue does not arrive until pain is live near the fall 2026 stable release.
Distribution path
Android developer communities (r/androiddev — note: Reddit ingestion is blocked from this server but the audience is real), Android Weekly, conference talks, and a viral 'test your app against Android 17 caps' free tool as top-of-funnel. Dev-tools distribution is slow and content-heavy.
Pricing hypothesis
Hypothesis: $49-$199/mo per app tier, or usage-based on captured events. No pricing evidence provided.
Technical difficulty
High for a solo founder: low-level Android memory instrumentation, chasing moving preview builds, empirically deriving undocumented caps, and ongoing maintenance across OS point releases. This is deep platform SDK work.
Legal / regulatory risk
Low.
Platform dependency
MAXIMAL and disqualifying-adjacent: the entire product exists at Google's pleasure. Google owns the OS, the enforcement, the kill telemetry (ApplicationExitInfo), and the free reporting surface (Play Console/Android Vitals). A single Play Console feature release subsumes the whole product.
Founder fit
LOW. This is a developer-tools/observability SaaS in deep platform territory — not the founder's edge. It is not a public-money flow, not a regulation-compelled filer class, not a claimable-money signal, and not a government-portal integration. It requires low-level Android engineering the founder would outsource, in a crowded space with strong free incumbents. It sells to developers who buy on benchmarks and community trust, a slow motion for a solo operator.
Breakout potential
Low-to-moderate. Even if the pain materializes, the defensible position accrues to incumbents (Sentry/Embrace) or to Google, not to a new single-signal entrant.
Final recommendation
PASS / DO NOT BUILD. This is a single-signal, evidence-free, deep-platform dev-tools play in a crowded market with strong free incumbents and maximal Google dependency — the exact profile the founder avoids, and none of the public-money/forced-filer/claimable-money shape he wants. The only sound action is a short, cheap validation spike to confirm the 'no telemetry' premise is false (which would kill it outright) before any build.
Next action
Spend one day loading an Android 17 preview build and empirically checking whether ApplicationExitInfo + Android Vitals already report the pre-kill memory reason. If they do (likely), archive this idea; if there is a genuine unfilled gap, reconsider only as a free lead-gen tool, not a product.