What changed
FACT (source: Android Developers Blog, 2026-06): starting in Android 17 the OS enforces per-app memory limits keyed to device RAM and terminates over-limit apps with no stack trace (signal id 841). This is a hard, OS-version-gated behavior change.
Why now
HYPOTHESIS on timing: the launch window is the Android 17 Beta / Platform Stability milestone, before stable rollout. The pre-build thesis is to ship a limit-simulation tool during the documented-but-not-yet-enforced beta window so developers can certify apps ahead of the silent-kill enforcement.
Converging signals
Only ONE signal underpins this: the single Android blog post announcing the enforcement. The 'convergence' is really one capability change plus an inferred developer-pain reaction — there is no independent demand signal in the input.
Customer pain
HYPOTHESIS (not evidenced in input): memory-heavy apps (games, media, camera/ML) getting silently killed on lower-RAM devices with no crash report, producing undiagnosable failures and 1-star reviews. Plausible and technically grounded, but the input carries ZERO demand_evidence — no complaints, no job posts, no forced-filer mandate.
Who pays
Android app publishers with memory-heavy apps who must certify against the new per-app RAM ceilings. This is a discretionary developer-tools buyer, NOT a forced filer with a statutory deadline. The 'deadline' is a soft ship-quality pressure, not a compelled submission.
Solved today
Android Studio Memory Profiler, Perfetto/heapprofd, LeakCanary (free, ubiquitous), Android Macrobenchmark, Firebase Crashlytics, and ANR/OOM analytics. Peak-memory and leak detection are already mature, mostly free, first-party tooling.
Why current solutions are bad
FACT-adjacent gap: today's crash reporting relies on stack traces; the new kill produces none, so post-hoc diagnosis breaks. The genuine wedge is PRE-release simulation of the exact device-RAM-scaled ceiling and a per-tier pass/fail gate — something current free tools do not package as a CI certification report.
Proposed product
A CI/CD-integrated 'memory pre-flight' that (1) reads Android 17's documented device-RAM→limit formula, (2) drives the app under instrumented tests, (3) captures peak RSS/PSS per device-RAM tier, (4) surfaces leak/hotspot attribution, and (5) emits a pass/fail certification report per tier that blocks the build if any tier would be killed.
MVP version
A Gradle plugin + GitHub Action wrapping Perfetto/heapprofd + Macrobenchmark that runs the app on emulator profiles at several RAM tiers, applies the documented limit formula, and outputs a red/green per-tier report. Solo-buildable in 6-10 weeks IF the founder has Android/native-memory depth — which is outside his stated strengths.
30-day build
Validate the enforcement formula from Google's docs; confirm whether Android Studio/Macrobenchmark already exposes the limit at build time (this could kill the wedge). Interview 15-20 Android leads at memory-heavy studios to test whether they'd pay for a gate they don't already get free.
60-day build
If demand survives, build the Gradle plugin + emulator-tier harness and the pass/fail report. Get 3-5 design partners running it in CI.
90-day revenue plan
Convert design partners to paid CI seats; publish a free 'will Android 17 kill your app?' scanner as a lead magnet. Realistically first revenue is 90-150+ days given the build depth and a skeptical, free-tooling-saturated buyer.
Distribution path
Android dev communities (r/androiddev, Android Weekly, KotlinConf/droidcon talks), a free single-run scanner as top of funnel, GitHub Marketplace Action listing. Content/demonstrated-value fit, but this is a noisy, hard-to-monetize audience.
Pricing hypothesis
Per-repo/per-seat CI SaaS, ~$49-199/mo per team; or usage-based per CI run. Developers are notoriously price-sensitive and default to free/OSS.
Technical difficulty
HIGH. Accurate native+managed peak-memory measurement, matching Google's exact scaled-limit formula, and cross-device-tier emulation is deep platform work — and the formula may change between beta and stable, invalidating the simulation.
Legal / regulatory risk
Low. No government portal, no PII of consumers.
Platform dependency
HIGH and structural: the entire product exists inside Google's toolchain. Google can (and historically does) ship first-party support — expose the limit in Android Studio, Macrobenchmark, or Play Console pre-launch reports — and vaporize the wedge at zero cost to developers. This is the core kill.
Founder fit
WEAK. This is not the founder's primary thesis (no public money, no regulation compelling a filer class, no government portal, no per-filing monetization). It requires deep Android/native-memory internals he does not list as a strength, and sells into the ad-averse, free-tooling developer market he prefers to avoid.
Breakout potential
Modest. Even if it works, it's a point tool with a shelf life tied to how long Google takes to build it in-house; limited expansion beyond adjacent Android performance gates.
Final recommendation
PASS / KILL. The behavior change is real and the technical gap (no stack trace, no pre-flight gate) is genuine, but this fails for the right reasons: platform-owner will almost certainly ship it free, there is zero demand evidence, the buyer is a price-averse developer audience, and it is squarely off the founder's public-money/forced-filer thesis and outside his skill set. Do not build. If anything, keep a cheap free 'Android 17 memory scanner' lead-magnet idea on a revisit-later shelf, but it is not a business.
Next action
Spend 2 hours reading Google's Android 17 memory docs and Play Console pre-launch report roadmap to confirm Google is already building the pre-flight gate in-house; if so (likely), close this permanently and redirect reasoning budget to public-money/forced-filer signals.