What changed
FACT (source: Android Developers blog, 2026-06): starting in Android 17 the OS enforces per-app RAM limits by device tier and kills over-limit apps with NO stack trace. FACT (2026-05): the Android CLI hit stable 1.0 and lets any AI agent drive real builds/analysis; AI Studio can generate/modify native Android code from prompts. Together these make a hosted, agent-driven memory-pressure CI harness technically buildable by a solo dev.
Why now
The enforcement is imminent and the failure mode is uniquely invisible: no crash trace means the FIRST place a dev can observe the kill is a controlled emulator run they don't currently do. The window to sell 'pre-flight visibility' opens as field diagnostics close. HYPOTHESIS: urgency spikes as Android 17 rolls to devices and 1-star 'app keeps closing' reviews start landing.
Converging signals
Three signals meet at one point: (1) a new, traceless failure class Android 17 imposes on memory-heavy apps; (2) a stable first-party CLI that lets an agent drive emulator builds/profiling; (3) prompt-to-code that lets the same agent author remediation PRs. The convergence is real but it is a CAPABILITY convergence, not a forced-buyer mandate — the buyer is discretionary.
Customer pain
HYPOTHESIS (no demand_evidence provided): memory-heavy Android publishers (games, media, camera) will face silent kills → review-score damage → churn, with no trace to debug from. This is plausible and intense IF apps actually breach tier limits, but the input provides ZERO complaint threads, job posts, or forced-buyer evidence. The convergence's own KILL TEST ('run 20 apps; if fewer than a handful show real risk, it isn't biting') is unresolved.
Who pays
Publishers/studios of memory-heavy Android apps, as a per-repo CI subscription. Reachable buyer (dev/DevOps lead) who pays by card, no procurement — good. But willingness-to-pay is unproven and competes with 'just test on one low-RAM device.'
Solved today
Existing memory tooling: Android Studio Memory Profiler, LeakCanary (free, ubiquitous), Perfetto, Firebase Test Lab / Robo tests on real device matrices, macrobenchmark. Studios also just test on a cheap physical device. None yet packages 'boot at Android 17 tier RAM caps, drive to OOM-kill threshold, and auto-PR the fix' — but the primitives are free and familiar.
Why current solutions are bad
FACT: none of the free tools model Android 17's NEW per-tier hard caps or the traceless kill specifically. Profilers require manual driving and interpretation; LeakCanary catches leaks not tier-cap breaches; Test Lab isn't oriented to memory-cap thresholds. The wedge is 'answers the ONE new Android-17 question automatically in CI.' Weakness: Google itself is the most likely party to add tier-cap lint/test-lab checks, and it owns distribution.
Proposed product
A GitHub Action ('OOM Pre-Flight'): on each PR, boot emulators configured to low/mid RAM device tiers, drive the app through memory-pressure scenarios via the Android CLI, record the OOM-kill threshold per tier, fail the build if margin is thin, and post an agent-generated remediation PR (leak/allocation fixes) with the evidence. SaaS billing per repo.
MVP version
Narrow first cut: a CLI/Action that boots ONE low-RAM tier emulator, runs the app through a scripted memory-stress path, reports pass/fail + peak RSS vs the tier cap, and attaches a Perfetto/heap snapshot. Skip the auto-PR agent initially — sell the RISK REPORT first. Validate on real apps to resolve the KILL TEST before over-building.
30-day build
Run the convergence's own kill test: put 15-20 popular memory-heavy open-source/APK apps through a hand-built harness at Android 17 tier caps. Publish the findings ('X of 20 breach tier limits') as the marketing asset. If <~4 breach, pivot or kill. Meanwhile build the emulator-tier-boot + threshold-measure core.
60-day build
Package as a GitHub Action + hosted runner; add 3-4 device tiers; add the agent remediation-PR step using the Android CLI. Onboard 3-5 design-partner studios free in exchange for logos/feedback. Write the 'Android 17 will kill your app' launch content.
90-day revenue plan
Convert design partners to paid per-repo plans (~$99-$299/mo/repo tiered by app count) and self-serve via the GitHub Marketplace listing. HYPOTHESIS: first revenue 60-120 days given no forced buyer and a build-then-sell motion.
Distribution path
GitHub Marketplace (Action listing), a viral 'we ran the top N apps against Android 17 tier caps' report, r/androiddev + Android GDE channels, indie-game dev communities. Content-led, demonstrated-value fit for this founder.
Pricing hypothesis
Per-repo SaaS: Free tier (1 tier, manual trigger) → $99/mo (multi-tier, CI gate) → $299/mo (agent remediation PRs, priority runners). Card-paid, no procurement.
Technical difficulty
Medium-high. Reliable emulator memory-cap simulation, reproducible OOM-kill thresholds, and low-flake CI are genuinely hard; agent-authored fix PRs that actually compile and reduce memory are harder still and a credibility risk if wrong. Solo-buildable but not a weekend build.
Legal / regulatory risk
Low. No PII, no government portal, no licensure. Standard SaaS terms.
Platform dependency
HIGH and this is the core risk. Depends entirely on Google's Android CLI, emulator behavior, and AI Studio, and Android 17's kill mechanics. Google is the incumbent that can fold tier-cap checks into Studio lint or Firebase Test Lab and deplatform the wedge overnight. Not platform_policy_risk (no ban risk) but severe strategic dependency on the platform owner.
Founder fit
Moderate. Matches the founder's fast AI-assisted prototyping, agent-tool, and micro-SaaS/API preferences and dev-tool distribution style. But it is OUTSIDE his primary edge (government-portal/forced-filer/public-money) — no mandate, no forced buyer, and Android is a stated avoid-adjacent (he avoids consumer social/hardware, not dev tools, so it's allowed). No captive buyer means he sells on faith until the kill-test data lands.
Breakout potential
Real if the tier breaches are widespread: expands to a general 'Android 17 readiness' CI suite (ANRs, startup, baseline profiles), then per-tier performance budgets as a category. Capped by Google potentially owning the feature.
Final recommendation
CONDITIONAL / VALIDATE-BEFORE-BUILD. Timely, technically credible, and distribution-friendly, but it is a discretionary dev-tool with NO demand evidence and heavy dependence on the platform owner who can copy it — well outside the founder's forced-buyer edge. Do not commit the full build. Spend ~2 weeks running the convergence's own kill test on 15-20 real apps; only proceed if a meaningful fraction genuinely breach Android 17 tier caps. Treat as a fast, cheap experiment, not a flagship.
Next action
Build the minimal harness and run 15-20 popular memory-heavy Android apps at Android 17 low/mid tier RAM caps; measure how many breach and get killed. Publish the result — it is simultaneously the go/no-go signal and the launch content.