What changed
Two shifts landed within weeks of each other: (FACT, source 2) Android 17 enforces per-app memory limits scaled to device RAM and kills violating apps with no stack trace; (FACT, sources 1 and 3) the Android CLI hit stable 1.0 in May 2026 and lets coding agents programmatically drive Android Studio profilers, builds, and device streaming. Together they make fleet-scale automated memory audits technically feasible for one person at the exact moment a new invisible failure mode hits every memory-heavy legacy app.
Why now
Android 17 shipped June 2026 (FACT per source publication dates). Silent kills will surface over the next 3-6 months as unexplained churn and 'app keeps closing' reviews, mostly on lower-RAM devices first (HYPOTHESIS about rollout timing — depends on OEM update cadence, which is historically slow; this both delays and extends the window). The CLI that makes the audit automatable reached stable 1.0 only in May 2026, so no incumbent has had time to productize this.
Converging signals
Signal 841/source 2: per-app memory enforcement with trace-less kills creates compliance-style pressure on all apps. Signals 843/835, sources 1 and 3: stable first-party CLI lets agents drive profilers and builds without brittle scripting. Bridge: the enforcement creates the demand; the CLI collapses the cost of supply from consulting-hours to near-zero marginal cost per audit.
Customer pain
An SMB's or agency's legacy app starts 'closing itself' on users' phones. There is no crash report to read (FACT that no stack trace is produced, source 2). The original contractor is gone, there is no in-house Android team, and standard crash tooling shows nothing actionable. Pain is real but currently LATENT — the buyer experiences symptoms without knowing the cause, which cuts both ways: they need a diagnostician, but they also won't search for 'Android 17 memory compliance' (HYPOTHESIS: they will search 'why does my app keep closing' or do nothing until churn hurts).
Who pays
Primary: agencies maintaining portfolios of old client apps (one audit pipeline, many billable apps — best unit economics). Secondary: SMBs with a single revenue-relevant app in maintenance mode. Tertiary: freelance Android devs who white-label the audit. All stated buyer categories are HYPOTHESES from the convergence description; no purchase behavior is yet observable.
Solved today
(a) Ignore it and lose users; (b) hire an Android consultant at $100-200/hr to manually profile — requires finding one and a multi-day engagement; (c) integrate an observability SDK (Sentry, Embrace, Instabug) — requires a developer to modify and reship the app, which is exactly what these owners lack; (d) a developer manually reads ApplicationExitInfo/exit-reason APIs (HYPOTHESIS that these partially capture OOM kills on Android 17 — must be verified in week 1, because if Play Console vitals surface these kills clearly, the diagnostic gap shrinks).
Why current solutions are bad
Every current path requires either an Android developer the buyer doesn't have, or an SDK integration into an app nobody maintains. None offers a no-touch 'send us your APK/repo, get a verdict' product. The silent-kill mechanism specifically defeats the crash-reporting tools owners might already have (FACT that no trace is emitted, source 2; HYPOTHESIS that existing SDKs therefore miss or under-attribute these kills).
Proposed product
A productized audit: customer submits APK + repo (or just APK for a reduced 'triage' tier). An agent pipeline drives the Android CLI to build, run memory profilers against Android 17 limits across simulated device RAM classes, identify leak sites and peak-usage violations, and emit a plain-English report: 'your app will be killed on devices with ≤X GB RAM; here are the 3 causes; here is the fix estimate.' Upsell: patched build delivered as a fixed-price remediation. Flat pricing, no subscription required to start.
MVP version
Weeks 1-2: harness that takes a repo, runs agent-driven profiling via the stable CLI against 2-3 emulated RAM profiles, and outputs a scored report. Validate on 5 open-source legacy apps and publish the results as marketing evidence ('we audited 5 popular open-source apps; 3 get killed on 4GB devices'). No dashboard, no SaaS — a form, a pipeline, a PDF. Solo-buildable with AI assistance; the CLI doing profiler orchestration is the load-bearing capability (FACT it exists, sources 1/3; HYPOTHESIS that it exposes enough profiler depth headlessly for leak attribution — verify day 1, this is the kill-or-proceed technical test).
30-day build
Verify the two load-bearing hypotheses: (1) CLI can drive memory profiling headlessly to actionable depth; (2) ApplicationExitInfo/Play vitals do NOT already give owners a clear answer. Build the pipeline. Mine Play Store reviews for post-June-2026 spikes in 'closes by itself'/'keeps crashing with no error' complaints to build a target list of specific apps in pain — this complaint-mining is directly in the founder's proven wheelhouse. Send 30 evidence-led outreach emails: 'your app X is being killed by Android 17 on these devices; here's a free 1-page triage.'
60-day build
Convert free triages to paid full audits ($750-1,500). Land 1-2 agencies with app portfolios and offer batch pricing (10 apps for $5k). Publish 2-3 public teardown posts of well-known apps failing Android 17 limits for inbound SEO on the symptom phrases owners actually search. Add the 'patched build' remediation tier ($2-5k fixed) for audits that find fixable leaks.
90-day revenue plan
Realistic: 5-10 paid audits + 1-2 remediations = $8-20k cumulative (HYPOTHESIS — depends entirely on outbound conversion, the weakest link). The agency-batch channel is the plausible path to repeatable revenue; single-SMB sales are one-offs. If OEM Android 17 rollout is slow, revenue slips a quarter — mitigate by selling 'pre-flight' audits to devs preparing for Android 17 as a second segment.
Distribution path
Evidence-led outbound to specific apps identified via Play-review complaint mining (founder's demonstrated skill), plus SEO on symptom phrases ('app closes by itself android'), plus agency batch deals. NOT enterprise sales, but IS cold outreach to buyers who don't know the cause of their problem — the single hardest part of this business. The FMCSA-style pull (a mandate forcing buyers to come to you) is absent: Google punishes apps but doesn't compel anyone to file anything, so demand must be manufactured through education. This is the key structural difference from his proven gov-portal shape.
Pricing hypothesis
$99 automated APK-only triage (impulse tier, also lead-gen), $750-1,500 full audit with repo access, $2-5k fixed-price remediation, agency batch at ~$500/app for 10+. Per-transaction, no subscription — matches buyer's one-off maintenance mindset; recurring 'compliance re-scan on each Android release' subscription ($50-100/mo per app) is the expansion play.
Technical difficulty
Moderate. The CLI/agent tooling is first-party and stable (FACT, sources 1/3), and the founder has strong AI-workflow and automation skills. Risks: headless profiler depth is unproven (HYPOTHESIS), legacy apps may not build without their original toolchains (real friction for the repo tier — the APK-only triage tier hedges this), and attributing kills to specific leaks automatically is genuinely hard; the report may sometimes say 'you exceed limits' without a clean root cause, which weakens the value prop.
Legal / regulatory risk
Low. Work is owner-authorized on their own APK/repo. Avoid analyzing apps without owner consent beyond public teardown posts of published behavior (keep teardowns to observable device-class behavior, not decompilation). No regulated data. Standard contractor liability disclaimer on patched builds.
Platform dependency
High and double-edged. The pain exists because Google created it; Google can also neutralize the business by shipping better exit diagnostics in Play Console or relaxing enforcement (HYPOTHESIS, but Google historically does improve vitals tooling within 1-2 releases). The audit pipeline also depends on the Android CLI remaining agent-friendly. Treat this as a 12-24 month window, not a durable moat — extract cash fast, which matches the founder's 30-90 day mandate anyway.
Founder fit
Good but not his proven archetype. Matches: automation, AI workflows, complaint-mining, productized reports, per-transaction pricing, demonstrated-value selling, fast low-budget prototyping. Mismatches: this is NOT the regulation-compels-filing shape (no government portal, no forced filer, no compulsory transaction to tax) — demand must be evangelized to buyers who don't know what's wrong, and he has no existing Android-ecosystem audience or portfolio. Score reflects strong execution fit minus the missing structural pull of his FMCSA win.
Breakout potential
Moderate. If it works, expands to: recurring per-release compliance re-scans (subscription), a self-serve 'will Android 17 kill my app' scanner (PLG lead-gen), white-label audits for agencies, and generalization to other platform-imposed compliance regimes (Play policy deadlines, target-SDK deadlines — the target-SDK deadline business is arguably the BETTER version of this idea since Google actually compels action there and removes apps, creating FMCSA-like forced-buyer dynamics; flag for a follow-up brief).
Final recommendation
PURSUE AS A TIME-BOXED BET, second priority behind any live gov-portal-shaped opportunity. Spend ≤2 weeks verifying the two kill-or-proceed hypotheses (headless profiler depth; absence of adequate first-party diagnostics) and running the complaint-mining pass. If both survive AND the first 30 outreach emails yield ≥2 paid triages, scale it; if not, kill it and keep the pipeline as a capability for the target-SDK-deadline variant, which has stronger forced-buyer dynamics. Rating: B — real converging signals and solo-feasible automation, held back by manufactured demand and platform-dependency risk.
Next action
Day 1-2: run the technical kill-test — use the Android CLI (stable 1.0) to headlessly profile one known-leaky open-source app against emulated 4GB/6GB/8GB RAM profiles and confirm you can produce an actionable leak attribution without Android Studio GUI; simultaneously check what ApplicationExitInfo and Play Console actually show owners for an Android 17 memory kill.