android-memory-storage-pro

Audit Android code for memory and storage problems. This is the deep-review companion to the always-on android-memory-management.md and android-storage-management.md rules: the rules steer while writing; this skill traces ownership, footprint, and file placement across whole features and the manifest. Report only genuine problems.

Applies to Compose and View-based apps. If asked to fix rather than review, make the changes directly and summarize them in the same file-by-file format.

Review process:

1. Leaks. For every long-lived object (singletons, objects, companion objects, ViewModels, Hilt @Singletons, services), check what it holds and what it registers, using references/leaks.md. Confirm the reference chain from a GC root before reporting.
2. Footprint. Check image loading, in-memory caches, list loading, trim-memory handling, and manifest heap flags using references/memory-footprint.md.
3. Storage. For every file write, preference, database, permission, and backup rule, check location, API, threading, size caps, and backup behavior using references/storage-layout.md.
4. Evidence. When the user reports a symptom (OOM, LMK kills, ANRs on disk, storage growth), or before you claim a fix worked, use references/measuring.md to reproduce and confirm it with LeakCanary, the Memory Profiler, dumpsys, StrictMode, or ApplicationExitInfo.

For a partial review (only leaks, only storage), load only the matching reference.

Core Instructions

• A leak finding names the chain: AnalyticsTracker (singleton) → listener → ProfileFragment → its view tree. "Might leak" without a chain isn't a finding.
• Size findings in bytes: "decodes a 4000×3000 photo as ARGB_8888 for a 64dp avatar: ~48 MB" is actionable.
• Storage findings name the consequence: Play rejection (broad storage or media permissions), restore crash (Keystore-encrypted file in backup), data loss (needed files in cacheDir), ANR (commit() on the main thread), or growth without bound.
• Severity by user impact: crash or data loss (OOM on a common flow, restore crash, Play policy violation, secrets in plain files) > degraded (leaked screens, unbounded caches, main-thread I/O, backup bloat) > hygiene (no StrictMode in debug, missing cache cap on a small cache).
• Cross-reference, don't duplicate: coroutine scope lifetime belongs to android-coroutines-pro; recomposition cost to android-compose-pro; R8 and resource shrinking to r8-shrink-pro; module placement of data sources to android-modularization-pro.