Android Architecture's Seven Iron Rules: The Architect's Real Deliverable Is Order

Android teams get a concrete checklist for the failures that actually kill large apps: orphaned tasks, hidden dependencies, swallowed exceptions, and blocked threads. Each rule is enforceable in code review, not aspirational advice, and they map directly to common production incidents like leaked coroutines and unrecoverable state.

Android projects fall apart not from a missing diagram but from unclear responsibility: tasks nobody owns, dependencies nobody sees, errors that vanish silently. These seven rules convert architecture from a drawing exercise into enforceable behavioral contracts. The Repository must be main-safe and manage its own thread strategy; any launched coroutine must have an explicit lifecycle owner; each piece of business data needs one authoritative source like Room; one-shot operations use suspend while continuous streams use Flow; global event buses cannot hide business dependencies; exceptions must be handled, narrowed, and rethrown for cancellation; and waiting on async work should suspend threads, not block them.

Each rule attaches to a concrete failure mode and a specific code pattern. The article walks through a real example of a Repository that fires a coroutine with no owner, then shows the fix where the ViewModel's scope owns the task. It flags the CancellationException trap in catch-all handlers and distinguishes thread blocking from coroutine suspension, noting that coroutines don't magically make blocking APIs non-blocking.

The closing argument reframes the architect's job: not layers, not frameworks, but rules that create boundaries, boundaries that assign responsibility, and responsibility that yields order. Clean Architecture provides code boundaries; these engineering rules provide behavioral boundaries. Both together decide whether a system can survive its own growth.