Track A — twelve weeks, full depth

Track B — four weeks, targeted

Week 1: Parts I, III, VII. Week 2: Parts XVI and XVII, six designs. Week 3: Parts VI, XI, XIX, XXIV. Week 4: Parts XXVIII, XXIII, XXV, XXVII. Skip Parts II, V and XX unless self-assessment puts you below L3 there.

Track C — one week, pre-onsite

Day 1: rubric and Part I. Day 2: the Part XVI framework and three designs. Day 3: Parts III and VI, mechanism only. Day 4: Parts XXIV and XXII. Day 5: Part XXIII, eight stories rehearsed aloud. Day 6: two mock loops. Day 7: Part XXX and the 24-hour checklist. Nothing new after day 6.

Dependencies

The parts are not strictly sequential. This is what genuinely depends on what, so you can reorder around your weak spots without reading into a prerequisite you have not covered.

flowchart LR
  I["I · Mindset"] --> VII["VII · Architecture"]
  I --> XXIII["XXIII · Behavioral"]
  I --> XXIV["XXIV · Org scale"]
  II["II · Kotlin"] --> III["III · Coroutines"]
  III --> VI["VI · Compose"]
  III --> IX["IX · Networking"]
  IV["IV · Platform"] --> V["V · Jetpack"]
  V --> VI
  V --> VII
  VII --> VIII["VIII · Modules"]
  VII --> XVI["XVI · System design"]
  IX --> XVI
  X["X · Storage"] --> XVII["XVII · Sync"]
  XVI --> XVII
  VI --> XI["XI · Performance"]
  XI --> XII["XII · Memory"]
  XI --> XIX["XIX · Incidents"]
  VIII --> XIV["XIV · Build/CI"]
  XIII["XIII · Testing"] --> XIV
  XVI --> XXVIII["XXVIII · Mocks"]
  XXIII --> XXVIII
  XXIV --> XXVIII
  

Chapter 1What a Staff Android Engineer actually does

Job descriptions describe Staff work as "technical leadership across teams," which is true and useless. The four archetypes below (following Will Larson's taxonomy, adapted for mobile organisations) are more actionable, because each one produces a different interview loop and a different set of stories you need ready.

Two consequences for interview preparation. First, find out which archetype the role is before the loop — ask the recruiter what the last two quarters of this role looked like. An Architect loop will punish you for having only delivery stories; a Tech Lead loop will punish you for having only refactoring stories. Second, your story portfolio needs coverage of at least three archetypes, because most Staff roles drift between them.

Chapter 2Senior vs Staff vs Principal vs Architect

The single most common reason a strong candidate is down-levelled: they answered every question about the code, and the interviewer was asking about the system. The ladder is not "harder questions" — it is a change in the unit of work.

The four down-levelling triggers

1. Solution-first answering. Jumping to "I'd use MVI with a sealed state class" before establishing constraints. Staff candidates spend the first 3–5 minutes of a design question on requirements and non-functionals, and interviewers explicitly score this.
2. No inversion condition. Recommending an approach without ever saying what would make you choose differently. This reads as dogma, and dogma at Staff level is dangerous because juniors copy it.
3. "We" with no "I". Behavioural answers that never isolate the candidate's own decision, or conversely claim solo credit for team outcomes. Both are calibration failures.
4. No cost awareness. Proposing a migration without engineer-months, a cache without memory budget, or an abstraction without the onboarding cost it imposes on 40 engineers.

Chapter 3Scope, ownership, and the seams between teams

Staff work concentrates in three places, all of them uncomfortable:

• Unowned surfaces. App startup, the DI graph, navigation, the design system, crash triage rotation, the release process. Everyone depends on them; no team's OKRs include them. A Staff engineer either owns one or ensures someone does.
• Contested boundaries. Two teams that disagree about where a responsibility lives. The technical answer is usually easy; the hard part is that one team must absorb work they did not plan.
• Decisions with no deadline. The migration everyone agrees is needed and nobody starts. Staff engineers convert these into sequenced, funded work with a first increment small enough to survive a sprint.

Chapter 4Decision-making under ambiguity

The most portable Staff framework is the reversibility test. Classify the decision before you agonise over it:

The associated interview skill is saying, unprompted: "This is a one-way door because the data format ships to devices we can't force-update, so I'd spend a week on it. The state-management choice inside the feature is cheap to reverse, so I'd just pick one and move." That single sentence does more for your level assessment than a perfect diagram.

Writing the decision down

Staff engineers are expected to produce ADRs. Interviewers sometimes ask you to sketch one verbally. The minimum viable shape:

Context      What is true today, what forces are in tension, what we measured.
Decision     One sentence, in the active voice. "We will …"
Alternatives Two or three real options, each with why it lost — not strawmen.
Consequences What becomes easy, what becomes hard, what we now owe.
Reversal     What signal would make us revisit, and what the exit costs.
Owner/date   Who is accountable, when it is re-evaluated.

The two sections weak ADRs omit are Alternatives with honest reasons and Reversal. Both are exactly what a Staff interviewer is listening for.

Chapter 5The thirteen judgment lenses

Applied to any design answer, these convert a competent technical description into a Staff one. You will not use all thirteen in a single answer; naming the three that dominate this problem, and saying why the others are secondary, is the actual skill.

Chapter 6Influence, mentorship, and driving architectural change

The recurring Staff interview theme is change without authority. Four mechanisms, roughly in order of effectiveness:

1. A working prototype. The strongest argument in engineering is a branch that demonstrably builds 40% faster. It converts an opinion debate into a measurement debate.
2. A written proposal with a named cost. "Three engineer-months, sequenced over two quarters, with the first increment shipping in three weeks" is arguable; "we should modularize" is not.
3. A pilot team. Prove the approach with one willing team, publish their numbers, and let the second team adopt it because it works, not because you said so.
4. Mechanisms, not memos. The change that survives you is the lint rule, the module template, the CI gate, the default in the project generator. Documentation decays; enforcement does not.

Chapter 7Type system, null safety, and the Java boundary

Kotlin's null safety is a compile-time guarantee that stops at the JVM boundary. Every production NPE in a Kotlin codebase comes from one of four places: platform types from Java, reflection-based deserialisation, lateinit, or a !! someone added under deadline pressure.

Platform types are the biggest hole

When Kotlin calls unannotated Java, the return type is a platform type (String!): the compiler declines to enforce either nullability. Assigning it to a non-null type inserts an implicit null check that throws at the assignment site — which is why the stack trace often points at code that looks obviously safe.

// Java library, no @Nullable annotations
val name: String = javaUser.getName()   // platform type
val len = name.length

// Deserialised by a reflective parser
data class Config(val apiUrl: String)
// Parser can construct this with apiUrl == null,
// bypassing the constructor's null check entirely.

// Be explicit about the boundary
val name: String = javaUser.name
    ?: error("User.name was null for id=${javaUser.id}")

// Model wire types as nullable, validate once, map inward
@Serializable
data class ConfigDto(val apiUrl: String? = null)

fun ConfigDto.toDomain(): Config =
    Config(apiUrl = requireNotNull(apiUrl) { "apiUrl missing" })

data class Config(val apiUrl: String)   // always valid

Chapter 8Generics, variance, and reified types

Variance answers one question: if Dog is a Animal, is Repo<Dog> a Repo<Animal>? By default no (invariant), because a producer-consumer type cannot safely be either.

• out T — covariant, producer. T may appear in return position only. List<out E>: a List<Dog> is a List<Animal> because you can only read.
• in T — contravariant, consumer. T in parameter position only. A Comparator<Animal> can compare dogs.
• * — star projection, "some unknown type"; safe to read as the upper bound, unsafe to write.

interface Mapper<T, R> { fun map(input: T): R }

// Caller has a Mapper<UserDto, User> but a
// pipeline typed Mapper<Any, Any> — no relation.
fun runAll(ms: List<Mapper<Any, Any>>) { /* ... */ }

// Forced to do this at every call site:
runAll(mappers as List<Mapper<Any, Any>>)  // unchecked

fun interface Mapper<in T, out R> {
    fun map(input: T): R
}

// Now a Mapper<UserDto, User> IS a Mapper<UserDto, Any>
// and a Mapper<Any, User> IS a Mapper<UserDto, User>.
fun <T> runAll(input: T, ms: List<Mapper<T, *>>): List<Any?> =
    ms.map { it.map(input) }

Reified: what it buys and what it costs

JVM generics are erased. reified works by forcing the function inline, so the concrete type is substituted at each call site. The cost is real: every call site duplicates the body.

// 400-line inline reified function, called from
// 90 places. R8 sees 90 copies of 400 lines.
inline fun <reified T> parseAndValidateAndCache(
    json: String
): T {
    /* 400 lines */
}

inline fun <reified T> parse(json: String): T =
    parse(json, T::class.java)     // tiny, inlined

// The real work is a normal function, compiled once.
fun <T> parse(json: String, type: Class<T>): T {
    /* 400 lines, one copy */
}

Chapter 9Inline, value classes, and what the compiler emits

inline exists primarily so higher-order functions do not allocate a lambda object per call, and so non-local returns work. It is not a general speed switch — inlining a function with no lambda parameters usually earns a compiler warning because the benefit is negligible.

fun transfer(
    from: String,
    to: String,
    amount: Long
)

// Compiles fine, ships a bug:
transfer(to = accountA, from = accountB, amount = cents)
transfer(userId, accountId, amount)   // wrong arg order

@JvmInline value class AccountId(val raw: String)
@JvmInline value class Cents(val raw: Long) {
    init { require(raw >= 0) { "negative amount" } }
}

fun transfer(from: AccountId, to: AccountId, amount: Cents)

transfer(userId, accountId, amount)  // ✗ won't compile

Chapter 10Sealed hierarchies, data classes, and binary compatibility

Sealed types are how you make illegal states unrepresentable. They also create a binary-compatibility hazard that only appears in modular codebases — which is exactly why it is a Staff question.

// Illegal states are impossible: no "loading with an error and data".
sealed interface CheckoutState {
    data object Idle : CheckoutState
    data object Submitting : CheckoutState
    data class Failed(val reason: FailureReason, val retryable: Boolean) : CheckoutState
    data class Succeeded(val orderId: OrderId) : CheckoutState
}

data class CheckoutState(
    val isLoading: Boolean = false,
    val error: String? = null,
    val orderId: String? = null,
    val isRetryable: Boolean = false,
)
// 16 representable combinations,
// 4 of them meaningful. Every consumer
// re-derives which is which.

when (state) {
    Idle       -> ShowForm()
    Submitting -> ShowSpinner()
    is Failed  -> ShowError(state.reason, state.retryable)
    is Succeeded -> ShowReceipt(state.orderId)
}   // compiler enforces completeness

Chapter 11Delegation, delegated properties, and scope functions

Class delegation (by) is composition with compiler-generated forwarding. It is the cleanest way to add behaviour without inheritance — and it has one trap that appears in interviews constantly.

interface Repo {
    fun load(): List<Item>
    fun loadFirst(): Item? = load().firstOrNull()
}

class Base : Repo {
    override fun load() = fetchFromNetwork()
}

class Cached(private val b: Base) : Repo by b {
    override fun load() = cache ?: b.load()
}

// Cached().loadFirst() does NOT use the cache.

class Cached(private val b: Repo) : Repo {
    private var cache: List<Item>? = null
    override fun load(): List<Item> =
        cache ?: b.load().also { cache = it }
    override fun loadFirst(): Item? =
        load().firstOrNull()      // explicit
}

A defensible scope-function house style

Chapter 12Collections, sequences, and allocation

Every collection operator on an Iterable allocates a new list. A chain of five operators over 10,000 items allocates five lists of 10,000. Sequence makes the pipeline lazy and element-at-a-time, allocating once — but it adds per-element overhead, so on small collections it is slower.

// 50k rows, called on every DB emission
val visible = rows
    .map { it.toUiModel() }      // 50k allocs
    .filter { it.isVisible }      // new list
    .sortedBy { it.rank }         // new list
    .take(20)                     // new list

// Best: let SQLite do it (index + LIMIT)
@Query("SELECT * FROM rows WHERE visible = 1 " +
       "ORDER BY rank LIMIT 20")
suspend fun visibleTop(): List<Row>

// If it must be in memory:
val visible = rows.asSequence()
    .filter { it.isVisible }      // cheap predicate first
    .sortedBy { it.rank }         // terminal-ish, unavoidable
    .take(20)
    .map { it.toUiModel() }       // only 20 mapper calls
    .toList()

Chapter 13Java interoperability

Most large Android codebases are mixed for years. The Staff-level skill is designing Kotlin APIs that are pleasant from Java without contorting the Kotlin.

object AnalyticsClient {
    fun track(
        name: String,
        props: Map<String, Any> = emptyMap(),
        immediate: Boolean = false,
    ) { }
}

// From Java:
// AnalyticsClient.INSTANCE.track("x", map, false);
// default args unusable, INSTANCE noise

object AnalyticsClient {
    @JvmStatic
    @JvmOverloads
    fun track(
        name: String,
        props: Map<String, Any> = emptyMap(),
        immediate: Boolean = false,
    ) { }
}

// From Java: AnalyticsClient.track("x");

Other interop facts worth having ready: Kotlin's checked-exception freedom means Java callers get no compiler warning unless you add @Throws; internal is public in the bytecode with a mangled name, so it is not a security boundary; and Kotlin's List is java.util.List at runtime, so a Java caller can mutate your "immutable" list.

Chapter 14DSLs, operators, and the overengineering line

Type-safe builders are Kotlin's most abused feature. A DSL is justified when the domain has genuine nesting or repetition and the DSL will be used in dozens of places by people who did not write it. It is not justified to make a three-field configuration read like English.

screen {
    +header { "Title" }
    body {
        row { col(2) { text("a") }; col(4) { text("b") } }
    }
} bindTo viewModel via mapper
// unary plus, infix chains, custom operators:
// nobody can grep for this, IDE help is poor,
// and errors surface as "expected Unit"

@DslMarker annotation class NavDsl

@NavDsl class GraphBuilder {
    fun screen(route: String, block: ScreenBuilder.() -> Unit)
}

navGraph {
    screen("home") { deepLink("app://home") }
    screen("cart")  { requiresAuth() }
}

Chapter 15Structured concurrency from first principles

Structured concurrency means every coroutine has a parent, and no parent completes before its children. Three properties follow, and they are the entire reason the model exists:

• No leaks. Cancelling a scope cancels everything beneath it, transitively.
• Error propagation. A failing child cancels its siblings and notifies the parent — failures cannot be silently dropped.
• Completion is meaningful. When coroutineScope { } returns, all work it started is genuinely finished.

flowchart TD
  VMS["viewModelScope (SupervisorJob + Main.immediate)"] --> A["launch: load profile"]
  VMS --> B["launch: load orders"]
  A --> A1["async: avatar"]
  A --> A2["async: badges"]
  B --> B1["async: page 1"]
  A1 -. "throws" .-> A
  A -. "cancels sibling" .-> A2
  A -. "SupervisorJob stops here" .-> VMS
  VMS --> B
  

class SyncRepository {
    fun sync() {
        GlobalScope.launch {
            val data = api.fetch()
            db.save(data)
        }
    }
}

class SyncRepository(
    private val api: Api,
    private val db: Db,
) {
    suspend fun sync() {          // suspend, not launch
        val data = api.fetch()
        db.save(data)
    }
}

// Caller decides the lifetime:
viewModelScope.launch { repo.sync() }        // screen-scoped
appScope.launch { repo.sync() }              // app-scoped, deliberate

Chapter 16Context, dispatchers, and main-safety

CoroutineContext is an immutable, indexed set of elements — Job, CoroutineDispatcher, CoroutineName, CoroutineExceptionHandler — combined with +. A child inherits the parent's context, with its own Job substituted.

class UserRepository(private val db: UserDao) {
    // Blocking, but nothing says so.
    fun loadBlocking(): User = db.queryBlocking()
}

// Every call site must remember:
viewModelScope.launch {
    val u = withContext(Dispatchers.IO) {
        repo.loadBlocking()
    }
}
// One forgotten withContext = a StrictMode
// violation, an ANR under load, or both.

class UserRepository(
    private val db: UserDao,
    private val io: CoroutineDispatcher,   // injected
) {
    /** Safe to call from any dispatcher. */
    suspend fun load(): User = withContext(io) {
        db.queryBlocking()
    }
}

// Call site is trivial and cannot get it wrong:
viewModelScope.launch { state = repo.load() }

Chapter 17Cancellation semantics

Cancellation is cooperative. Cancelling a job sets its state to cancelling and, at the next suspension point, the suspending function throws CancellationException. Code that never suspends is never cancelled.

viewModelScope.launch(Dispatchers.Default) {
    for (frame in frames) {          // 5k iterations
        process(frame)               // pure CPU, no suspend
    }
}

// elsewhere:
try {
    api.upload(file)
} catch (e: Exception) {             // catches CancellationException!
    log("upload failed", e)
    state = Error
}

viewModelScope.launch(Dispatchers.Default) {
    for (frame in frames) {
        ensureActive()               // cheap cancellation check
        process(frame)
    }
}

try {
    api.upload(file)
} catch (e: CancellationException) {
    throw e                          // never swallow
} catch (e: IOException) {
    state = Error(e.toMessage())
}

Cleanup that must run after cancellation

suspend fun uploadWithCleanup(file: File) {
    val session = api.beginUpload(file.name)
    try {
        api.uploadChunks(session, file)      // cancellable
    } finally {
        // Suspending calls in a cancelled scope throw immediately
        // unless we opt out. Keep this block tiny and fast.
        withContext(NonCancellable) {
            api.abortIfIncomplete(session)
        }
    }
}

Chapter 18Exception propagation and supervision

The single most-asked coroutine question in Staff loops is a variant of: three concurrent requests, one fails — what happens to the other two? The answer depends entirely on the builder and the scope.

suspend fun loadDashboard() = coroutineScope {
    val profile = async { api.profile() }
    val orders  = async { api.orders() }
    val promos  = async { api.promos() }   // optional data

    Dashboard(
        profile = profile.await(),
        orders  = orders.await(),
        promos  = try { promos.await() }   // does NOT help
                  catch (e: Exception) { emptyList() }
    )
}

suspend fun loadDashboard() = coroutineScope {
    // Required data: fail together, deliberately.
    val profile = async { api.profile() }
    val orders  = async { api.orders() }

    // Optional data: isolated failure.
    val promos = async {
        runCatching { api.promos() }.getOrDefault(emptyList())
    }

    Dashboard(profile.await(), orders.await(), promos.await())
}

Chapter 19Shared mutable state: Mutex, atomics, confinement

Three strategies, in the order you should reach for them:

1. Confinement — do not share. A single coroutine owns the state; others send it messages. Zero locking, but adds indirection.
2. Atomics — for a single independent value. AtomicInteger, MutableStateFlow.update { } (which uses a CAS loop).
3. Mutex — coroutine-aware lock; suspends instead of blocking a thread. Use when several values must change together.

private val _state = MutableStateFlow(UiState())

fun addItem(item: Item) {
    // Two concurrent calls: both read the same
    // old value, second write wins, first item lost.
    _state.value = _state.value.copy(
        items = _state.value.items + item
    )
}

// And never this in a coroutine:
private val lock = ReentrantLock()
suspend fun save() = lock.withLock { api.save() } // blocks a thread

fun addItem(item: Item) {
    _state.update { it.copy(items = it.items + item) }  // CAS loop
}

// When several pieces must change atomically:
private val mutex = Mutex()
private var session: Session? = null

suspend fun refresh(): Session = mutex.withLock {
    session?.takeIf { it.valid } ?: api.refresh().also { session = it }
}

Chapter 20Flow fundamentals: cold streams

A Flow is a suspending producer with no state of its own. The builder block does not run until collect; each collector re-runs it independently; and the whole thing is cancelled by cancelling the collecting coroutine.

Two invariants define correct Flow code:

• Context preservation. A flow must emit in the collector's context. Emitting from a different coroutine throws IllegalStateException; change context with flowOn, never with withContext around an emit.
• Exception transparency. A flow may not catch exceptions thrown downstream. try/catch around emit violates this; use the catch operator, which only sees upstream failures.

fun items(): Flow<List<Item>> = flow {
    try {
        withContext(Dispatchers.IO) {
            emit(dao.loadBlocking())      // ✗ wrong context
        }
    } catch (e: Exception) {              // ✗ catches downstream too
        emit(emptyList())
    }
}

fun items(): Flow<List<Item>> = flow {
        emit(dao.loadBlocking())
    }
    .flowOn(Dispatchers.IO)       // upstream context only
    .catch { e ->                 // upstream failures only
        Log.w(TAG, "items failed", e)
        emit(emptyList())
    }

Chapter 21Hot streams: StateFlow, SharedFlow, Channel

data class UiState(
    val items: List<Item> = emptyList(),
    val navigateTo: Route? = null,     // event in state
    val errorMessage: String? = null,  // event in state
)

// UI must remember to clear it:
LaunchedEffect(state.navigateTo) {
    state.navigateTo?.let {
        nav.navigate(it)
        vm.consumedNavigation()   // easy to forget
    }
}

// State: what the screen looks like.
val state: StateFlow<UiState> = ...

// Events: things that happen once.
private val _events = Channel<UiEvent>(Channel.BUFFERED)
val events = _events.receiveAsFlow()

// UI:
LaunchedEffect(Unit) {
    lifecycle.repeatOnLifecycle(STARTED) {
        vm.events.collect { e ->
            when (e) {
                is Navigate -> nav.navigate(e.route)
                is ShowSnack -> snackbar.showSnackbar(e.text)
            }
        }
    }
}

Chapter 22Backpressure, sharing, and stateIn

Coroutine flows apply backpressure by default: a slow collector suspends the producer. Operators change that trade-off explicitly.

private val query = MutableStateFlow("")

val results: StateFlow<SearchState> = query
    .debounce(300)                       // don't search every keystroke
    .map { it.trim() }
    .distinctUntilChanged()              // "ab " and "ab" are one query
    .filter { it.length >= 2 }
    .flatMapLatest { q ->                // cancel the previous request
        repo.search(q)                   // Flow<List<Result>>
            .map<List<Result>, SearchState> { SearchState.Results(it) }
            .onStart { emit(SearchState.Loading) }
            .catch { emit(SearchState.Failed(it.userMessage())) }
    }
    .stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5_000),
        initialValue = SearchState.Idle,
    )

Chapter 23Concurrency design problems

Request deduplication — five screens, one call

class SingleFlight<K : Any, V>(private val scope: CoroutineScope) {
    private val mutex = Mutex()
    private val inFlight = mutableMapOf<K, Deferred<V>>()

    suspend fun run(key: K, block: suspend () -> V): V {
        val deferred = mutex.withLock {
            inFlight[key] ?: scope.async(start = CoroutineStart.LAZY) {
                try { block() } finally { mutex.withLock { inFlight.remove(key) } }
            }.also { inFlight[key] = it }
        }
        // await() from the *caller's* coroutine: if this caller is
        // cancelled, the shared work continues for the others.
        return deferred.await()
    }
}

Why the shared scope matters: if the work were launched in the first caller's scope, that caller navigating away would cancel the request for the other four. Hosting it in a shared scope decouples the work's lifetime from any one consumer — the trade-off being that you must remove entries in a finally or the map grows forever.

Token refresh — one refresh, not five

class AuthAuthenticator(
    private val tokens: TokenStore,
    private val refreshApi: RefreshApi,
) : Authenticator {
    private val mutex = Mutex()

    override fun authenticate(route: Route?, response: Response): Request? {
        if (responseCount(response) >= 2) return null   // stop retry loops
        val stale = response.request.header("Authorization")
            ?.removePrefix("Bearer ")

        val fresh = runBlocking {          // Authenticator is a blocking API
            mutex.withLock {
                val current = tokens.access()
                // Another thread already refreshed while we waited.
                if (current != null && current != stale) return@withLock current
                val new = runCatching { refreshApi.refresh(tokens.refresh()) }
                    .getOrElse { tokens.clear(); return@withLock null }
                tokens.save(new); new.access
            }
        } ?: return null                   // force logout upstream

        return response.request.newBuilder()
            .header("Authorization", "Bearer $fresh")
            .build()
    }
}

The critical line is the comparison against the stale token: five requests fail concurrently, all enter the mutex in turn, and only the first performs a refresh — the rest observe that the stored token has changed and reuse it. Without that check you get five refreshes, and with rotating refresh tokens, four of them fail and log the user out.

Chapter 24Process model, zygote, and Binder

Your app is a process forked from zygote, a warm VM with the framework classes and shared resources already loaded and pages shared copy-on-write. That is why an Android process starts in tens of milliseconds rather than seconds, and why anything you add to Application.onCreate is paid on every cold start with no sharing.

Binder is the IPC mechanism behind essentially every framework call that touches another process — PackageManager, ActivityManager, ContentResolver, starting activities, showing notifications. Three consequences worth naming in an interview:

• Transactions are size-limited. The per-process Binder buffer is about 1 MB, shared across all in-flight transactions. Exceeding it throws TransactionTooLargeException — most often from a large Bundle in onSaveInstanceState or an oversized Intent extra.
• Binder calls are synchronous and finite. The thread pool has ~16 threads; a system_server under load makes your "cheap" call slow. Binder contention is a common and under-diagnosed ANR cause.
• Binder can block the main thread. ContentResolver.query on main is a blocking IPC, not a local call.

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putParcelableArrayList(
        "feed", ArrayList(viewModel.allLoadedItems)  // 2,000 items
    )
}
// TransactionTooLargeException, usually only on
// devices where users scroll a lot — so it reaches production.

// In the ViewModel:
val listState = savedStateHandle.getStateFlow("firstVisible", 0)
val query = savedStateHandle.getStateFlow("query", "")

// Data comes back from the local database / Paging,
// which survives process death anyway.
val items = query.flatMapLatest { repo.page(it) }

Chapter 25The main thread: Looper, MessageQueue, Choreographer

The main thread is a loop: Looper.loop() pulls Message objects from a MessageQueue ordered by target timestamp and dispatches them to Handlers. Everything — lifecycle callbacks, input events, view invalidation, your post {} — is a message.

Choreographer registers for the display's VSYNC signal and, once per frame, runs callbacks in a fixed order: input → animation → insets → traversal (measure, layout, draw) → commit. At 120 Hz you have 8.3 ms; at 60 Hz, 16.7 ms. Anything that overruns delays the next frame, which the user sees as jank.

sequenceDiagram
  participant D as Display VSYNC
  participant C as Choreographer
  participant M as MessageQueue
  participant A as App code
  D->>C: VSYNC (every 8.3ms @120Hz)
  C->>M: post frame callback (async, front of queue)
  M->>A: INPUT callbacks
  M->>A: ANIMATION callbacks
  M->>A: TRAVERSAL — measure / layout / draw
  A-->>M: your 40ms JSON parse runs here
  Note over D,A: next VSYNC missed → dropped frame
  

Chapter 26Activities, tasks, launch modes, and the back stack

The Staff framing: launch modes are a legacy multi-activity concern. The modern paved road is a single activity plus a navigation graph, where the back stack is application state you control rather than an OS structure you negotiate with. When an interviewer asks about launch modes, the strongest answer covers the mechanism and says "in a single-activity app, this reduces to how onNewIntent feeds the nav controller, which is a much smaller surface to get right."

<activity android:name=".MainActivity"
    android:launchMode="singleTask">
    <intent-filter> ... </intent-filter>
</activity>

// User is 4 screens deep in checkout, taps a
// marketing push → task cleared, checkout lost.

<activity android:name=".MainActivity"
    android:launchMode="singleTop" />

override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)
    setIntent(intent)
    val route = deepLinks.resolve(intent) ?: return
    when (route.policy) {
        // Interruptible content: push on top of the stack.
        Policy.PUSH -> navController.navigate(route.dest)
        // Session-critical flow in progress: defer or confirm.
        Policy.DEFER -> if (navController.inCheckout()) pending = route
                        else navController.navigate(route.dest)
    }
}

Chapter 27Lifecycle, configuration change, and process death

There are three tiers of state, and confusing them causes most "it works on my phone" bugs.

flowchart TD
  E["Event"] --> R{"What happened?"}
  R -- "rotation / locale / dark mode" --> CC["Activity destroyed, process alive"]
  R -- "system reclaims memory" --> PD["Process killed, task record kept"]
  R -- "user swipes away / force-stop" --> FS["Task cleared"]
  CC --> K1["ViewModel: kept
SavedStateHandle: kept
disk: kept"]
  PD --> K2["ViewModel: GONE
SavedStateHandle: restored from Bundle
singletons: reconstructed EMPTY
disk: kept"]
  FS --> K3["everything in memory gone
saved state discarded
disk: kept"]
  

The middle branch is the one that reaches production: singletons come back empty while the UI assumes they are populated. It is also the branch nobody tests, because it needs the OS to kill a backgrounded process — constant on a low-end device, almost never on a developer's phone.

# 1. Put the app in the background (Home, not Back).
# 2. Kill the process without clearing the task record:
adb shell am kill com.example.app
# 3. Return via Recents. Note: `am force-stop` is WRONG —
#    it clears the task and does not exercise restoration.

# In CI, exercise the saved-state path directly:
@Test fun surviving_process_death() {
    val handle = SavedStateHandle(mapOf("query" to "shoes"))
    val vm = SearchViewModel(handle, repo)
    assertEquals("shoes", vm.state.value.query)
}

# Instrumented: StateRestorationTester (Compose) or
# recreate() plus a simulated bundle round-trip.

Chapter 28Context, and leak topology

object ImageCache {
    private lateinit var context: Context
    fun init(c: Context) { context = c }   // Activity passed in
}

class MainActivity : Activity() {
    override fun onCreate(b: Bundle?) {
        ImageCache.init(this)   // leaks the Activity forever
    }
}

@Singleton
class ImageCache @Inject constructor(
    @ApplicationContext private val context: Context,
)

Chapter 29Intents, PendingIntents, and package visibility

A PendingIntent is a token granting another process permission to execute an intent as your app. That is why mutability flags are mandatory on modern Android and why getting them wrong is a real vulnerability.

val pi = PendingIntent.getActivity(
    ctx, 0,
    Intent(ACTION_HANDLE),          // implicit
    PendingIntent.FLAG_MUTABLE      // fillable by the receiver
)

val pi = PendingIntent.getActivity(
    ctx, requestCode,
    Intent(ctx, DetailActivity::class.java).apply {
        putExtra(EXTRA_ID, id)
    },
    PendingIntent.FLAG_IMMUTABLE or
        PendingIntent.FLAG_UPDATE_CURRENT
)

Chapter 30Background execution in the restriction era

Modern Android's default position is that a backgrounded app should not run. The design question is therefore never "how do I run in the background" but "what class of work is this, and what guarantee does it actually need?"

fun scheduleSync() {
    WorkManager.getInstance(ctx).enqueue(
        OneTimeWorkRequestBuilder<SyncWorker>().build()
    )
}
// Called from onStart(). After ten launches,
// ten sync workers race each other.

fun scheduleSync() {
    WorkManager.getInstance(ctx).enqueueUniqueWork(
        "sync",
        ExistingWorkPolicy.KEEP,        // or REPLACE — decide deliberately
        OneTimeWorkRequestBuilder<SyncWorker>()
            .setConstraints(
                Constraints(requiredNetworkType = NetworkType.CONNECTED)
            )
            .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 30, SECONDS)
            .build()
    )
}

Chapter 31Permissions and the modern privacy surface

• Runtime permissions are revocable at any time, including while your app is backgrounded. Every permission-gated call needs a "not granted right now" path, not just a request-at-startup flow.
• Notifications are permission-gated from Android 13. Requesting at first launch produces the worst grant rates; request in context, after the user has done something that makes the value obvious.
• Scoped storage and the photo picker removed the legitimate reasons to request broad media permissions. Asking for them now is both a UX cost and a Play review risk.
• Background location requires a separate, later grant and a policy justification. Designing a feature that needs it is a product decision with a compliance cost, and a Staff engineer should say so before the design is committed.
• Package visibility means queryIntentActivities returns a filtered list unless you declare <queries>. A "share sheet is empty on Android 11+" bug is almost always this.

Chapter 32Notifications, deep links, and app links

Deep-link routing in a 200-screen app should be a first-class subsystem, not a manifest of intent filters. The Staff-level design has four properties:

1. One resolver. A single component maps URI → typed route, so links are testable without launching an activity.
2. Validated input. Any ID or URL in the link is untrusted. A link that opens an in-app WebView at an arbitrary URL is a phishing vector; allow-list the host.
3. Auth-aware. Routes declare whether they require a session; the router handles the login-then-continue flow centrally rather than each screen re-implementing it.
4. Verified App Links. With a hosted assetlinks.json, your app opens the URL without a disambiguation dialog — and no other app can claim it.

sealed interface Route {
    val requiresAuth: Boolean
    data class Product(val id: ProductId) : Route { override val requiresAuth = false }
    data class Order(val id: OrderId)     : Route { override val requiresAuth = true }
}

class DeepLinkResolver(private val allowedHosts: Set<String>) {
    fun resolve(uri: Uri): Route? {
        if (uri.host !in allowedHosts) return null          // untrusted
        val seg = uri.pathSegments
        return when {
            seg.size == 2 && seg[0] == "p" -> ProductId.parse(seg[1])?.let(Route::Product)
            seg.size == 2 && seg[0] == "o" -> OrderId.parse(seg[1])?.let(Route::Order)
            else -> null
        }
    }
}

// Unit-testable in milliseconds, no emulator:
@Test fun rejects_foreign_host() =
    assertNull(resolver.resolve(Uri.parse("https://evil.com/p/123")))

Chapter 33ViewModel and state ownership

ViewModel exists for exactly one reason: to hold state across configuration changes without leaking the Activity. Everything else attributed to it — "it's the presentation layer", "it's where business logic goes" — is convention, not mechanism.

The mechanism: ViewModelStore is retained across recreation by the ComponentActivity's NonConfigurationInstance. onCleared() is called when the store's owner is finished, not when it is recreated. This is why holding a Context or a View in a ViewModel leaks: the ViewModel outlives them by design.

Chapter 34Lifecycle-aware collection

sequenceDiagram
  participant UI as Composable / Fragment
  participant L as Lifecycle
  participant VM as ViewModel StateFlow
  participant R as Repository (upstream)
  UI->>L: repeatOnLifecycle(STARTED)
  L->>VM: collect starts
  VM->>R: subscriptionCount 0 → 1, upstream starts
  Note over UI,R: user backgrounds the app
  L-->>VM: STOP → block cancelled, collector gone
  VM-->>R: WhileSubscribed(5s) grace, then upstream stops
  Note over UI,R: rotation instead: STOP then START inside 5s
  L->>VM: collect restarts, cached value replayed, no refetch
  

The single most consequential Jetpack detail: a coroutine launched in lifecycleScope is cancelled only at onDestroy. A flow collected there keeps running while the app is backgrounded — updating a UI nobody sees, holding a socket open, draining battery.

lifecycleScope.launch {
    viewModel.state.collect { render(it) }
}

// Also wrong: launchWhenStarted, which *suspends*
// the coroutine but keeps the upstream flow active.
lifecycleScope.launchWhenStarted {
    viewModel.locations.collect { ... }
}

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.state.collect { render(it) }
    }
}

// Compose equivalent:
val state by viewModel.state
    .collectAsStateWithLifecycle()

Chapter 35Room

Room is a compile-time-verified SQLite wrapper. The interview value is in the parts that are not obvious from the docs.

• Observable queries are table-scoped. Flow<List<T>> re-runs on any write to any table it touches, not on a change to the returned rows. A frequently-written table therefore re-queries constantly; that is a common jank source on list screens.
• Suspend DAO functions are already main-safe. Room dispatches to its own executor.
• @Transaction matters for relations. A @Relation query issues multiple statements; without @Transaction you can observe a torn read.
• Migrations are permanent public API. Every schema version that shipped must have a path forward, from any version, forever — users skip releases.

Room.databaseBuilder(ctx, Db::class.java, "app.db")
    .fallbackToDestructiveMigration()   // silent data loss
    .build()

// And a query that re-runs on every unrelated write:
@Query("SELECT * FROM messages ORDER BY ts DESC")
fun all(): Flow<List<Message>>   // 5k rows, re-read constantly

Room.databaseBuilder(ctx, Db::class.java, "app.db")
    .addMigrations(MIGRATION_7_8, MIGRATION_8_9)
    .build()

val MIGRATION_8_9 = object : Migration(8, 9) {
    override fun migrate(db: SupportSQLiteDatabase) {
        db.execSQL("ALTER TABLE messages ADD COLUMN read INTEGER NOT NULL DEFAULT 0")
        db.execSQL("CREATE INDEX idx_messages_ts ON messages(ts)")
    }
}

@Query("SELECT * FROM messages WHERE chat_id = :id ORDER BY ts DESC LIMIT 50")
fun page(id: String): Flow<List<Message>>

Chapter 36DataStore vs SharedPreferences

SharedPreferences has two defects that DataStore exists to fix: commit() blocks the calling thread on disk I/O, and apply(), while async, is drained synchronously on the main thread during onPause/onStop via QueuedWork — a well-documented ANR source in apps with many preference writes. There is also no error channel: a failed write is silent.

prefs.edit().putString(KEY_TOKEN, token).commit()  // blocks main

// Reading on the main thread the first time also
// blocks: the whole file is parsed on first access.
val theme = prefs.getString("theme", "dark")

val theme: Flow<Theme> = dataStore.data
    .catch { e ->
        if (e is IOException) emit(emptyPreferences()) else throw e
    }
    .map { Theme.from(it[THEME_KEY]) }

suspend fun setTheme(t: Theme) {
    dataStore.edit { it[THEME_KEY] = t.name }
}

Chapter 37WorkManager, Paging, Navigation

WorkManager guarantees, stated precisely

WorkManager guarantees the work will eventually run subject to its constraints, surviving process death and reboot. It does not guarantee when. On aggressively-optimising OEM firmware, deferred work can be delayed by hours or suppressed until the app is opened. Any product requirement of the form "this must happen within N minutes" cannot be met by WorkManager alone — it needs a server-side push as the trigger.

Paging 3 with a RemoteMediator — the shape interviewers expect

@OptIn(ExperimentalPagingApi::class)
class FeedMediator(
    private val api: FeedApi,
    private val db: AppDatabase,
) : RemoteMediator<Int, FeedEntity>() {

    override suspend fun load(
        loadType: LoadType,
        state: PagingState<Int, FeedEntity>,
    ): MediatorResult = try {
        val key = when (loadType) {
            LoadType.REFRESH -> null
            LoadType.PREPEND -> return MediatorResult.Success(endOfPaginationReached = true)
            LoadType.APPEND  -> db.keys().nextKeyFor(state.lastItemOrNull()?.id)
                ?: return MediatorResult.Success(endOfPaginationReached = true)
        }
        val page = api.feed(cursor = key, limit = state.config.pageSize)
        db.withTransaction {
            if (loadType == LoadType.REFRESH) { db.feed().clear(); db.keys().clear() }
            db.feed().insertAll(page.items.map { it.toEntity() })
            db.keys().insert(RemoteKey(page.items.lastOrNull()?.id, page.nextCursor))
        }
        MediatorResult.Success(endOfPaginationReached = page.nextCursor == null)
    } catch (e: IOException) {
        MediatorResult.Error(e)          // Paging surfaces this as LoadState.Error
    }
}

Two details that separate levels: the write is inside withTransaction so a crash mid-insert cannot leave the list and the keys table disagreeing; and REFRESH clears before inserting so a server-side reorder does not produce duplicates. Cursor-based keys rather than page numbers are also the correct choice for a feed where items are inserted at the head — page-number pagination on a live feed shows duplicates and skips items, which is a classic follow-up.

Chapter 38Dependency injection

The honest Staff position: the compile-time-validation argument is decisive at scale — a runtime DI failure in a rarely-visited screen reaches production, and with 40 engineers that will happen. Below roughly ten engineers, Koin's build-time saving and simplicity often wins. And for a library you publish, no DI framework at all: expose constructors and let the consumer wire them, because forcing your DI choice on consumers is a hostile API decision.

class OrderRepository {
    @Inject lateinit var api: Api
    @Inject lateinit var db: Dao
    @Inject lateinit var clock: Clock

    init { AppComponent.inject(this) }   // service locator
}
// Cannot construct in a unit test without the graph.
// Dependencies are invisible at the call site.

class OrderRepository @Inject constructor(
    private val api: Api,
    private val db: Dao,
    private val clock: Clock,
    private val io: CoroutineDispatcher,
)

// Test needs no framework at all:
val repo = OrderRepository(FakeApi(), InMemoryDao(),
    Clock.fixed(...), UnconfinedTestDispatcher())

Chapter 39The runtime: slot table and composition

A composable function is not a normal function call. The Compose compiler rewrites it to accept a Composer and to emit groups into the slot table — a gap buffer that records, positionally, what was composed and what values were remembered.

Three consequences that explain most Compose behaviour:

• Identity is positional. remember is keyed by the call site's position in the tree, not by variable name. Move the call inside an if and it is a different slot.
• Recomposition is scoped. The runtime invalidates the smallest enclosing restartable scope that read the changed state, not the whole tree. This is why reading state as late as possible is the core performance discipline.
• Composition is not the frame. Composition produces a description; layout and draw happen afterwards. A screen can be slow with almost no recomposition, because the cost is in measurement or drawing.

Column {
    messages.forEach { msg ->
        // Position-based identity. Insert at the head and
        // every item's remembered state shifts down one.
        MessageRow(msg)
    }
}

LazyColumn {
    items(messages) { MessageRow(it) }   // no key
}

LazyColumn {
    items(
        items = messages,
        key = { it.id },                 // stable identity
        contentType = { it.type },       // better reuse
    ) { MessageRow(it) }
}

// Non-lazy loops:
messages.forEach { msg ->
    key(msg.id) { MessageRow(msg) }
}

Chapter 40The snapshot system

Compose state is built on a multi-version concurrency control system. Each snapshot sees a consistent view of all state; writes are recorded per-snapshot and applied atomically. Reading a State object inside a composition registers the reading scope as an observer of that object.

Practical implications interviewers probe:

• You can safely read Compose state from a background thread inside Snapshot.withMutableSnapshot; the changes apply atomically or conflict.
• snapshotFlow { } converts state reads into a cold Flow, emitting when the values read inside it change — the correct bridge from Compose state to coroutine world.
• A MutableState holding a MutableList does not notify on list.add(), because the state object itself never changed. This is the single most common "why didn't my UI update" bug.

var items by remember { mutableStateOf(mutableListOf<Item>()) }

fun add(i: Item) {
    items.add(i)      // no recomposition: the State never changed
}

// Option A: observable collection
val items = remember { mutableStateListOf<Item>() }
items.add(i)                              // notifies

// Option B: immutable value, replaced
var items by remember { mutableStateOf(persistentListOf<Item>()) }
items = items.add(i)                      // new reference

// Option C (preferred for screen state): it lives in the
// ViewModel as an immutable UiState, not in the composable.

Chapter 41Effects — which one, and why

@Composable
fun AutoDismiss(onDismiss: () -> Unit) {
    LaunchedEffect(Unit) {
        delay(5_000)
        onDismiss()      // captured on first composition
    }
}
// If the parent recomposes with a new onDismiss
// (a different navigation target), the OLD one fires.

@Composable
fun AutoDismiss(onDismiss: () -> Unit) {
    val current by rememberUpdatedState(onDismiss)
    LaunchedEffect(Unit) {
        delay(5_000)
        current()        // always the latest
    }
}

Chapter 42Stability, skipping, and strong skipping

The runtime skips recomposing a composable when all its parameters are equal and stable. Stable means: the type's equals is consistent, its public properties do not change without notifying composition, and all its public property types are themselves stable.

The compiler infers stability. It cannot infer it for types it cannot see — which historically made every class from a module without the Compose compiler unstable, including List, Set and Map (the interface could be backed by a mutable implementation).

data class UiState(
    val items: List<Item>,          // interface: unstable
    val onClick: (Item) -> Unit,     // new lambda each recomposition
    val config: ConfigFromOtherModule // not Compose-compiled: unstable
)

@Composable fun Screen(state: UiState) { ... }
// Never skips. Recomposes on every parent recomposition.

@Immutable
data class UiState(
    val items: ImmutableList<Item>,  // kotlinx.collections.immutable
    val config: Config,
)

@Composable
fun Screen(
    state: UiState,
    onClick: (Item) -> Unit,         // hoisted, remembered by caller
)

// For third-party types you cannot annotate:
// stability configuration file (Compose compiler option)
// listing them as stable.

Chapter 43State hoisting and screen architecture

flowchart TD
  VM["CartViewModel"] -- "StateFlow<CartUiState>" --> R["CartRoute — stateful"]
  VM -- "Channel<CartEvent>" --> R
  R -- "state: CartUiState" --> S["CartScreen — stateless"]
  S -- "onIntent(CartIntent)" --> R
  R -- "viewModel::onIntent" --> VM
  S --> P["@Preview"]
  S --> T["Screenshot test"]
  

The split exists so the two boxes on the right are reachable: a stateless screen can be rendered from a hand-built state with no ViewModel, DI or navigation, which is the only affordable way to cover 200 screens' visual states.

// 1. State: immutable, exhaustive, no events inside.
@Immutable
data class CartUiState(
    val lines: ImmutableList<CartLine> = persistentListOf(),
    val total: Money = Money.ZERO,
    val isSubmitting: Boolean = false,
    val error: CartError? = null,
)

// 2. Stateful entry point: knows about the ViewModel.
@Composable
fun CartRoute(
    onCheckout: (OrderId) -> Unit,
    viewModel: CartViewModel = hiltViewModel(),
) {
    val state by viewModel.state.collectAsStateWithLifecycle()
    LaunchedEffect(Unit) {
        viewModel.events.collect { e ->
            when (e) { is CartEvent.Checkout -> onCheckout(e.orderId) }
        }
    }
    CartScreen(state = state, onIntent = viewModel::onIntent)
}

// 3. Stateless UI: previewable, screenshot-testable, no DI.
@Composable
fun CartScreen(
    state: CartUiState,
    onIntent: (CartIntent) -> Unit,
    modifier: Modifier = Modifier,
) { /* pure UI */ }

Why this shape rather than a single composable: the stateless layer can be rendered in a @Preview and a screenshot test with a hand-built state, which is the only affordable way to test 200 screens' visual states; and the route layer isolates every framework dependency, so the UI module does not depend on Hilt or navigation.

CompositionLocal — when it is right

Legitimate uses: theme, typography, density, a locale-aware formatter — things that are ambient, rarely change, and would pollute every signature. Illegitimate: passing a ViewModel, a repository, or screen data. The test: if a reader of the composable would be surprised that the value can change the output, it should be a parameter. Implicit data flow is the thing Compose's model exists to remove.

Chapter 44The three phases: composition, layout, drawing

Each frame runs up to three phases. State read in a later phase does not invalidate the earlier ones — which is the single highest-leverage Compose performance technique.

flowchart LR
  S["State change"] --> C["Composition
what to show"]
  C --> L["Layout
measure & place"]
  L --> D["Drawing
render commands"]
  D --> F["Frame"]
  S -. "read in Modifier.offset { }" .-> L
  S -. "read in graphicsLayer { }" .-> D
  

The dotted paths are the point: a state value read inside a lambda-taking modifier is read during layout or draw, so a change to it re-runs only that phase. The same value read in the composable body invalidates all three.

val offset = scrollState.firstVisibleItemScrollOffset

Box(
    Modifier.offset(y = (offset / 2).dp)   // recomposes every frame
        .alpha(1f - offset / 500f)
)

Box(
    Modifier
        .offset { IntOffset(0, scrollState.offset / 2) }  // lambda: layout phase
        .graphicsLayer { alpha = 1f - scrollState.offset / 500f } // draw phase
)

Chapter 45Lazy layouts and a 10,000-item feed

The question "how would you optimise a LazyColumn rendering 10,000 items?" has a wrong premise, and saying so is the first point scored: you never render 10,000 items — lazy layouts compose only what is visible. If it is slow, the problem is per-item cost, key stability, or something above the list.

1. Do not page the whole dataset into memory. Use Paging 3 so the list holds a window, not the corpus.
2. Provide key and contentType. Keys preserve state and enable animation; content types make reuse effective across heterogeneous rows.
3. Make item state immutable and stable, so scrolling does not recompose visible items.
4. Fix the item's own cost: no allocation in the item body, no date formatting per frame, image sizes constrained so decode does not resize on the main thread.
5. Never nest a scrollable in the same direction — a LazyColumn inside a vertically-scrolling Column forces infinite-constraint measurement and composes every item.
6. Baseline profile the scroll path, otherwise the first scroll runs interpreted and janks on exactly the impression that matters.

items(rows, key = { it.id }) { row ->
    val fmt = SimpleDateFormat("dd MMM", Locale.getDefault())
    Text(fmt.format(row.date))            // alloc + parse per item per frame
    AsyncImage(model = row.url)           // unbounded size
}

// Formatting happens once, in the mapper, off the main thread:
data class RowUi(val id: String, val dateLabel: String, val url: String)

items(rows, key = { it.id }, contentType = { it.type }) { row ->
    Text(row.dateLabel)
    AsyncImage(
        model = ImageRequest.Builder(ctx).data(row.url)
            .size(width = 320, height = 180)   // decode to display size
            .crossfade(false)
            .build(),
        modifier = Modifier.size(160.dp, 90.dp),
    )
}

Chapter 46Recomposition debugging

// build.gradle.kts
composeCompiler {
    reportsDestination = layout.buildDirectory.dir("compose_reports")
    metricsDestination = layout.buildDirectory.dir("compose_metrics")
}

// Produces, per module:
//   *-composables.txt  → restartable / skippable per function
//   *-classes.txt      → stable / unstable per class, with the reason
//
// Read the classes file first: one unstable class usually
// explains a dozen unskippable composables.

Chapter 47Testing, semantics, and accessibility

Compose's semantics tree is simultaneously the accessibility tree and the test tree — a design decision with a useful consequence: a screen that is hard to test is usually inaccessible. Treating them as the same problem is a Staff framing worth stating.

Box(
    Modifier
        .size(32.dp)                    // below 48dp touch target
        .clickable { onDelete() }       // no role, no label
) { Icon(Icons.Default.Delete, contentDescription = null) }

// Test must resort to:
composeRule.onNodeWithTag("del_3").performClick()

IconButton(                             // 48dp target, Role.Button
    onClick = onDelete,
    modifier = Modifier.semantics {
        contentDescription = "Delete ${item.name}"
    }
) { Icon(Icons.Default.Delete, contentDescription = null) }

// Test reads like the user's intent:
composeRule.onNodeWithContentDescription("Delete Milk")
    .assertHasClickAction()
    .performClick()

Chapter 48Boundaries: what they cost and what they buy

Every layer boundary buys one thing — the ability to change one side without the other — and charges three: indirection, mapping code, and a decision every engineer must make correctly ("where does this go?"). A boundary is justified when the change it isolates is likely and the cost of the change without it is high.

Chapter 49Clean Architecture, honestly assessed

flowchart LR
  subgraph UI["UI layer"]
    C["Composable"] --> VM["ViewModel / state holder"]
  end
  subgraph D["Domain layer — pure Kotlin, no Android"]
    UC["UseCase"] --> RI["Repository interface"]
  end
  subgraph DA["Data layer"]
    RImpl["Repository impl"] --> R["Remote source"]
    RImpl --> L["Local source"]
  end
  VM --> UC
  RImpl -. "implements" .-> RI
  

The arrow that matters is the dotted one: the data layer depends on the domain's interface, not the reverse. That single inversion is 80% of the value — the domain becomes a pure-Kotlin module with no Android dependency, so its tests run in milliseconds on the JVM and it can be shared with KMP later.

class GetUserUseCase(private val repo: UserRepository) {
    suspend operator fun invoke(id: String) = repo.getUser(id)
}
class GetOrdersUseCase(private val repo: OrderRepository) {
    suspend operator fun invoke() = repo.getOrders()
}
// 40 of these. Each adds a file, a DI binding,
// a test that asserts delegation, and zero logic.

/**
 * Combines entitlement, local drafts and remote orders,
 * applies the refund-eligibility rules, and is used by
 * three screens.
 */
class GetRefundableOrdersUseCase(
    private val orders: OrderRepository,
    private val entitlements: EntitlementRepository,
    private val clock: Clock,
) {
    operator fun invoke(): Flow<List<RefundableOrder>> =
        combine(orders.all(), entitlements.current()) { os, ent ->
            os.filter { it.isRefundable(ent, clock.now()) }
              .map { it.toRefundable() }
        }
}
// Elsewhere, the ViewModel calls repo.getUser(id) directly.

Chapter 50MVVM vs MVI

The trap: "MVI is better" is not an answer. Both put immutable state in a holder and drive UI unidirectionally; the difference is whether input is funnelled through one channel. That funnel buys traceability and costs boilerplate. On a settings screen it is pure cost; on a checkout flow with payment, address validation and inventory reservation racing each other, the replayable transition log is worth the files.

class CheckoutViewModel(...) : ViewModel() {

    private val _state = MutableStateFlow(CheckoutUiState())
    val state: StateFlow<CheckoutUiState> = _state.asStateFlow()

    private val _events = Channel<CheckoutEvent>(Channel.BUFFERED)
    val events = _events.receiveAsFlow()

    // Single input channel (MVI), but no ceremony reducer class:
    fun onIntent(intent: CheckoutIntent) {
        when (intent) {
            is SetAddress  -> _state.update { it.copy(address = intent.a, error = null) }
            is Submit      -> submit()
            is Retry       -> submit()
        }
    }

    private fun submit() = viewModelScope.launch {
        _state.update { it.copy(isSubmitting = true) }
        submitOrder(_state.value.toRequest())
            .onSuccess { _events.send(CheckoutEvent.Done(it.orderId)) }
            .onFailure { e -> _state.update {
                it.copy(isSubmitting = false, error = e.toCheckoutError()) } }
    }
}

Chapter 51UI state modelling and state machines

Where do loading and error live? The question is really "is this state or an event?" — and the answer follows a rule: if it should still be true after rotation, it is state; if it should happen exactly once, it is an event.

• A full-screen loading spinner: state.
• A validation error under a field: state.
• A one-off snackbar or navigation: event.
• A retryable network failure that replaces the content: state (with a retry intent), because it must survive rotation.

data class ProfileUi(
    val isLoading: Boolean,
    val user: User?,
    val orders: List<Order>?,
    val error: String?,
)
// User loads in 80ms, orders in 2s.
// The whole screen spins for 2s, and the
// "user is null but not loading" case is unrepresentable-but-reachable.

@Immutable
data class ProfileUi(
    val header: Section<User> = Section.Loading,
    val orders: Section<ImmutableList<Order>> = Section.Loading,
)

sealed interface Section<out T> {
    data object Loading : Section<Nothing>
    data class Ready<T>(val value: T) : Section<T>
    data class Failed(val retryable: Boolean) : Section<Nothing>
}

Chapter 52The repository under pressure

Chapter 53Architecting a 200-screen application

This is a common Staff design prompt. The trap is designing the screen architecture; what is being asked is the system that lets 40 teams build 200 screens without collision.

flowchart TD
  App[":app — assembly only"] --> F1[":feature:cart"]
  App --> F2[":feature:search"]
  App --> F3[":feature:orders"]
  F1 --> NavApi[":core:navigation-api"]
  F2 --> NavApi
  F3 --> NavApi
  F1 --> DomC[":core:domain-cart"]
  F3 --> DomO[":core:domain-orders"]
  DomC --> DataC[":core:data-cart"]
  DomO --> DataO[":core:data-orders"]
  DataC --> Net[":core:network"]
  DataO --> Net
  DataC --> DB[":core:database"]
  DataO --> DB
  F1 --> DS[":core:designsystem"]
  F2 --> DS
  F3 --> DS
  

Seven decisions that constitute the answer:

1. Feature modules never depend on each other. Cross-feature navigation goes through a route contract in :core:navigation-api; the implementation is wired in :app. This is the single most important rule and the one most often broken.
2. One screen contract (Route/Screen/UiState/Intent), generated from a template, so a reviewer moving between features recognises the shape instantly.
3. Data ownership is explicit. Each domain concept has exactly one owning module and one source of truth. Two modules caching entitlement is the bug class from Part I.
4. The design system is a real module with an API review. Otherwise 200 screens produce 200 buttons.
5. Boundaries are enforced mechanically — dependency rules in the build logic, a lint rule for illegal imports. A documented rule is a suggestion.
6. State scoping is defined: screen state in a ViewModel; flow state in a nav-graph ViewModel; app state in a repository with a single source of truth. No activity-scoped shared ViewModels.
7. The paved road is a generator. New feature = one command producing module, DI wiring, screen contract, tests and a CI entry. Consistency at 200 screens comes from defaults, not review.

Chapter 54Multi-surface architecture

Foldables, tablets, Wear, TV and Auto do not need parallel apps; they need a shared domain and a deliberately separate presentation layer.

• Share: domain, data, sync, auth. These are surface-independent and duplicating them causes divergent bugs.
• Do not share: navigation topology, layout, input model. A list-detail on a foldable is a two-pane layout with one back-stack entry; on a phone it is two entries. Forcing one navigation model onto both produces the "back button does the wrong thing on a tablet" bug.
• Drive layout from window size classes, never from isTablet booleans or screen-width dp thresholds sprinkled through the code — a folding phone changes class at runtime, and a resizable window on a large screen changes it continuously.
• Test the transition, not just the states. Fold/unfold mid-flow is where state loss appears, because it is a configuration change plus a layout topology change at once.

Chapter 55Module taxonomy and dependency rules

// core/data-cart/build.gradle.kts
dependencies {
    api(project(":core:network"))     // leaks Retrofit to every consumer
    api(project(":core:database"))    // leaks Room entities too
    api(libs.okhttp)
}

dependencies {
    // Only types that appear in this module's public signatures:
    api(project(":core:domain-cart"))

    implementation(project(":core:network"))
    implementation(project(":core:database"))
    implementation(libs.okhttp)
}

Chapter 56Breaking cycles: feature-to-feature navigation

The recurring problem: :feature:cart must open a product detail owned by :feature:catalog, and :feature:catalog must open the cart. A direct dependency in both directions is a cycle Gradle refuses.

flowchart TD
  subgraph BAD["cycle — Gradle refuses"]
    C1[":feature:cart"] --> C2[":feature:catalog"]
    C2 --> C1
  end
  subgraph GOOD["contract owned by nobody's team"]
    A[":app — the only module that knows both"] --> D1[":feature:cart"]
    A --> D2[":feature:catalog"]
    D1 --> NAV[":core:navigation-api
sealed Dest, interface Navigator"]
    D2 --> NAV
  end
  

// Everyone depends on :core:shared, which grows to
// hold ProductScreen, CartScreen, the analytics client,
// the date formatter and 400 other things.
:feature:cart    -> :core:shared
:feature:catalog -> :core:shared

// :core:navigation-api  (depends on nothing)
sealed interface Dest {
    data class Product(val id: String) : Dest
    data object Cart : Dest
}
interface Navigator { fun go(dest: Dest) }

// :feature:cart — depends only on the api
class CartViewModel(private val nav: Navigator) {
    fun onLineClick(id: String) = nav.go(Dest.Product(id))
}

// :app — the only module that knows both features
navController.graph {
    composable<Dest.Product> { ProductRoute(...) }
    composable<Dest.Cart>    { CartRoute(...) }
}

Chapter 57Build performance and graph shape

Two graphs with the same module count can differ by minutes per build. What matters:

• Depth beats width. A deep chain serialises: nothing downstream compiles until upstream finishes. A wide, shallow graph parallelises across cores. Prefer many small leaf modules over a five-level pyramid.
• ABI stability decides incremental cost. Changing a function body recompiles one module; changing a public signature recompiles every dependent. This is why implementation and api/impl splits pay off — they shrink the set of modules that can be invalidated.
• Annotation processing is the usual bottleneck. Migrating kapt → KSP is typically the single largest available win in a Dagger/Room codebase.
• Measure before restructuring. A build scan tells you which tasks dominate; intuition is reliably wrong. Restructuring a graph on a hunch is weeks of work for a possible regression.

# 1. Where does the time actually go?
./gradlew assembleDebug --scan            # task timeline, cache hits/misses

# 2. Is the configuration phase the problem? (large graphs: often yes)
./gradlew help --scan                     # config time with no work

# 3. What does a one-line change actually recompile?
touch core/domain-cart/src/.../Cart.kt
./gradlew assembleDebug --scan            # count invalidated modules

# 4. Turn on the cheap wins before restructuring anything:
org.gradle.caching=true
org.gradle.configuration-cache=true
org.gradle.parallel=true

Chapter 58Convention plugins and version catalogs

// repeated in every module, drifting over time
android {
    compileSdk = 35
    defaultConfig { minSdk = 24 }
    compileOptions { /* ... */ }
}
kotlin { jvmToolchain(17) }
dependencies {
    implementation("androidx.core:core-ktx:1.13.1")  // version drift
}

// build-logic/.../AndroidFeatureConventionPlugin.kt
class AndroidFeatureConventionPlugin : Plugin<Project> {
    override fun apply(target: Project) = with(target) {
        pluginManager.apply("com.android.library")
        pluginManager.apply("org.jetbrains.kotlin.android")
        configureKotlinAndroid()
        dependencies {
            add("implementation", project(":core:designsystem"))
            add("implementation", libs.findLibrary("hilt").get())
        }
    }
}

// feature/cart/build.gradle.kts — the whole file
plugins { id("myapp.android.feature") }

Chapter 59Exercise — a travel app, 100+ engineers

:app                                  platform team — assembly only

:vertical:flights:feature-search      flights team
:vertical:flights:feature-booking     flights team
:vertical:flights:domain              flights team  (pure Kotlin)
:vertical:flights:data                flights team
:vertical:hotels:*                    hotels team
:vertical:cars:*                      cars team

:shared:booking-flow-api              platform (contract only)
:shared:payments-api / -impl          payments team
:shared:loyalty-api / -impl           loyalty team
:shared:identity-api / -impl          identity team

:core:designsystem                    design-systems team, API-reviewed
:core:network :core:database          platform team
:core:navigation-api                  platform team
:test:fixtures-*                      per owning team

Chapter 60The transport stack for mobile engineers

The facts that change client design:

• Connection setup dominates. On LTE, DNS + TCP handshake + TLS can cost 200–600 ms before a byte of your payload moves. On a cold connection, five sequential requests cost five round-trip penalties — which is why request count matters far more than payload size on mobile.
• Radio state is a battery cost. The cellular radio ramps to a high-power state for a transfer and stays there for a tail period (seconds) afterwards. Ten small requests spread over a minute cost far more battery than one batched request, even with identical bytes.
• HTTP/2 multiplexes over one connection, removing head-of-line blocking at the HTTP layer but not at TCP. HTTP/3 (QUIC) removes it at the transport layer too and survives network changes via connection IDs — genuinely valuable when a user walks from Wi-Fi to cellular.
• TLS 1.3 cuts the handshake to one round trip, and session resumption to zero. Enabling it is usually a server-side change with a measurable client-side latency win.

Chapter 61REST, GraphQL, gRPC

The Staff answer is per-surface, not per-company: GraphQL where a screen aggregates many resources and the field set varies by client version; gRPC for high-frequency streaming (location, telemetry) where binary size and bidirectional streams pay; REST for everything else, because its caching and debuggability are free. And name the hidden cost: a GraphQL client without a normalised cache re-fetches everything, and with one you have taken on cache-consistency bugs.

Chapter 62OkHttp and Retrofit

Interceptor placement is the detail interviewers use to check whether you have really operated this stack.

Chapter 63Auth, token refresh, and single-flight coordination

The most-asked networking scenario at Staff level: a token expires while five requests are in flight — design a solution that produces one refresh, not five. It is asked because the naive implementation is both obvious and wrong, and because the failure mode (users randomly logged out) is one most candidates have actually seen without diagnosing.

sequenceDiagram
  participant A as Request A
  participant B as Requests B–E
  participant Au as Authenticator (Mutex)
  participant S as Auth server
  A->>Au: 401, stale = T0
  B->>Au: 401, stale = T0 (queued on the mutex)
  Au->>S: refresh(T0) — one call only
  S-->>Au: T1
  Au-->>A: retry with T1
  Note over Au,B: B–E enter the lock, see stored != T0
  Au-->>B: retry with T1, no second refresh
  

class AuthInterceptor(...) : Interceptor {
    override fun intercept(chain: Chain): Response {
        var res = chain.proceed(withToken(chain.request()))
        if (res.code == 401) {
            val new = runBlocking { api.refresh() }   // no coordination
            res.close()
            res = chain.proceed(withToken(chain.request(), new))
        }
        return res
    }
}

class TokenAuthenticator(
    private val store: TokenStore,
    private val api: RefreshApi,
) : Authenticator {
    private val mutex = Mutex()

    override fun authenticate(route: Route?, response: Response): Request? {
        if (response.priorResponseCount() >= 2) return null   // give up
        val stale = response.request.bearer()

        val fresh = runBlocking {
            mutex.withLock {
                store.access()
                    ?.takeIf { it != stale }        // someone already refreshed
                    ?: runCatching { api.refresh(store.refresh()) }
                        .onSuccess { store.save(it) }
                        .map { it.access }
                        .getOrElse { store.clear(); null }
            }
        } ?: return null

        return response.request.newBuilder()
            .header("Authorization", "Bearer $fresh").build()
    }
}

Chapter 64Resilience: retries, backoff, idempotency

suspend fun <T> retrying(
    attempts: Int = 4,
    baseMs: Long = 300,
    maxMs: Long = 8_000,
    isRetryable: (Throwable) -> Boolean,
    block: suspend () -> T,
): T {
    var last: Throwable? = null
    repeat(attempts) { i ->
        try { return block() } catch (e: CancellationException) {
            throw e                                  // never swallow
        } catch (e: Throwable) {
            if (!isRetryable(e) || i == attempts - 1) throw e
            last = e
            val ceiling = min(maxMs, baseMs shl i)   // 300, 600, 1200, 2400
            delay(Random.nextLong(0, ceiling))       // FULL jitter
        }
    }
    throw last!!
}

Why jitter matters at scale: a backend blip fails a million clients simultaneously. Without jitter they all retry at exactly t+300 ms, then t+900 ms — a synchronised thundering herd that keeps the backend down. Full jitter spreads the retries uniformly. This is the difference between a 30-second blip and a 20-minute outage, and it is a favourite Staff follow-up.

Chapter 65Caching and conditional requests

class ProductRepo(private val api: Api) {
    private val memo = mutableMapOf<String, Product>()   // never invalidated

    suspend fun get(id: String): Product =
        memo.getOrPut(id) { api.product(id) }
}

// OkHttp handles conditional requests automatically when
// the server sends ETag / Last-Modified.
OkHttpClient.Builder()
    .cache(Cache(File(ctx.cacheDir, "http"), 20L * 1024 * 1024))
    .build()

// The app's source of truth is the database; the network
// updates it, and the UI observes only the database.
fun product(id: String): Flow<Product> = dao.observe(id)

suspend fun refresh(id: String) {
    val dto = api.product(id)     // 304 → served from HTTP cache, cheap
    dao.upsert(dto.toEntity())
}

Connectivity is not a boolean

A frequent design flaw is gating requests on isConnected. Real states include: no interface; connected to Wi-Fi with no internet (captive portal); connected but metered; connected with high latency; and mid-handover between Wi-Fi and cellular where sockets die but the network is "available". The right posture is attempt and handle failure, using connectivity signals only to schedule retries and to inform the UI — never as a precondition. NetworkCapabilities.NET_CAPABILITY_VALIDATED is the closest thing to "the internet actually works," and even that lags reality.

Chapter 66SQLite mechanics that matter

• WAL mode (Room's default) lets readers proceed during a write. Without it, a write blocks every reader — a classic source of jank when a sync worker writes while a list scrolls. There is still only one writer at a time.
• Transactions are the unit of durability and speed. 1,000 individual inserts mean 1,000 fsyncs; the same inserts in one transaction mean one. This is routinely a 50–100× difference and is the correct answer to "the initial sync takes 40 seconds."
• Index or scan. Without an index, a WHERE is a full table scan. With 200 rows nobody notices; with 200,000 on a low-end device it is seconds.
• Room's observable queries invalidate per table, so a write to any row of a watched table re-runs the query. Watching a hot table with an unbounded query is a self-inflicted CPU load.

suspend fun saveAll(items: List<Item>) {
    items.forEach { dao.insert(it) }        // 5,000 transactions
}

@Query("SELECT * FROM items WHERE category = :c ORDER BY updated DESC")
fun byCategory(c: String): Flow<List<Item>>   // full scan + sort, unbounded

@Insert(onConflict = OnConflictStrategy.REPLACE)
suspend fun insertAll(items: List<Item>)     // one transaction

@Entity(indices = [Index(value = ["category", "updated"])])
data class ItemEntity(...)

@Query("SELECT * FROM items WHERE category = :c " +
       "ORDER BY updated DESC LIMIT :limit")
fun byCategory(c: String, limit: Int = 100): Flow<List<Item>>

Chapter 67Schema design and migrations

Migrations are permanent public API: users skip releases, so version 3 must be able to reach version 12. Every shipped version is a path you own forever.

// 1. Commit the exported schema JSON — it is the contract.
room { schemaDirectory("$projectDir/schemas") }

// 2. Test EVERY adjacent pair, plus a full-chain run.
@Test fun migrate_8_to_9() {
    helper.createDatabase(TEST_DB, 8).apply {
        execSQL("INSERT INTO messages VALUES ('m1','hello',1700000000)")
        close()
    }
    val db = helper.runMigrationsAndValidate(TEST_DB, 9, true, MIGRATION_8_9)
    db.query("SELECT read FROM messages WHERE id='m1'").use {
        it.moveToFirst()
        assertEquals(0, it.getInt(0))         // default applied
    }
}

@Test fun migrate_all_the_way() =
    helper.runMigrationsAndValidate(TEST_DB, LATEST, true, *ALL_MIGRATIONS)

Chapter 68Cache architecture

"Should we cache?" is the wrong question. The real questions are: what is the source of truth, what staleness is acceptable, and how does a stale entry get corrected? A cache without an answer to the third is a bug generator.

flowchart LR
  UI["UI"] -- observes --> DB[("Room — source of truth")]
  API["Network"] -- writes --> DB
  HTTP["OkHttp cache"] -. "revalidation bytes only" .- API
  MEM["Bounded memory cache"] -- derived from --> DB
  UI -. "never reads" .-x API
  

The rule that makes this coherent: the network never returns data to the UI. It writes to the store, and the UI observes the store. Each tier then has one job — truth, bandwidth, speed — instead of three tiers competing to answer the same question.

// Memory map in the repository (never bounded, never invalidated)
// + OkHttp disk cache (its own TTL from server headers)
// + Room (written on some paths, not others)
//
// Result: pull-to-refresh updates two of the three,
// and which value the UI shows depends on which
// screen the user opened first.

// Truth:      Room (survives process death, offline-capable)
// Bandwidth:  OkHttp cache (revalidation only)
// Speed:      in-memory, bounded, derived from Room

class ProductRepository(
    private val dao: ProductDao,
    private val api: ProductApi,
) {
    // UI observes only this.
    fun product(id: String): Flow<Product> =
        dao.observe(id).map { it.toDomain() }

    suspend fun refresh(id: String) {
        dao.upsert(api.product(id).toEntity())   // network writes to truth
    }
}

Chapter 69Media, files, and bitmap memory

Bitmap arithmetic is a favourite quick interview probe because it is exact: a bitmap costs width × height × bytes-per-pixel. In ARGB_8888 that is 4 bytes per pixel, so a 4000×3000 photo is 48 MB decoded — several times a typical app's entire heap budget, from one image.

val bmp = BitmapFactory.decodeFile(path)     // 48 MB for a 12MP photo
imageView.setImageBitmap(bmp)

AsyncImage(model = url)                       // unbounded in a list

// Coil/Glide size the request to the target automatically,
// but be explicit in lists where the target is known:
AsyncImage(
    model = ImageRequest.Builder(ctx)
        .data(url)
        .size(320, 180)              // decode dimensions
        .build(),
    modifier = Modifier.size(160.dp, 90.dp),
)

// Manual decode: two passes.
val opts = BitmapFactory.Options().apply { inJustDecodeBounds = true }
BitmapFactory.decodeFile(path, opts)
opts.inSampleSize = calculateInSampleSize(opts, 320, 180)
opts.inJustDecodeBounds = false
val bmp = BitmapFactory.decodeFile(path, opts)   // ~0.2 MB

Disk budget as a designed constraint

An app that caches media without a quota eventually gets uninstalled for "using 4 GB". The Staff-level position: give every disk cache an explicit budget, an eviction policy (LRU by access time), and a response to onTrimMemory/low-storage broadcasts. Then measure the cache-hit rate — if a 500 MB cache and a 100 MB cache have the same hit rate, you are spending the user's storage for nothing, and that is an argument you can take to a product review with data.

Chapter 70A performance methodology

The reflex that marks a Senior answer is naming a fix ("add a baseline profile"). The reflex that marks a Staff answer is naming a measurement first. The seven-step protocol used throughout this part:

1. Quantify. Which metric, at which percentile, on which devices, changed by how much and when. "The app is slow" is not actionable; "p90 TTID on Android 13, mid-tier, up 1.4 s since 8.4.0" is.
2. Hypothesise. Three candidate causes, ranked, each with a prediction that would distinguish it.
3. Instrument or trace. Perfetto/system trace on a physical mid-tier device, release build, in the failing condition.
4. Diagnose. Identify the specific frames or spans that account for the regression. Confirm it explains the whole delta, not a plausible slice.
5. Fix. Smallest change that addresses the cause.
6. Verify. Same measurement, same conditions, plus a field check after rollout — lab wins that do not reproduce in the field are common.
7. Prevent. A CI benchmark or a Vitals alert so the regression cannot silently return. Without this you will do the whole investigation again next year.

Chapter 71App startup

flowchart LR
  Z["zygote fork"] --> AC["Application.onCreate
tier 1 only"]
  AC --> ACT["Activity onCreate"]
  ACT --> M["measure / layout / draw"]
  M --> TTID["TTID — first frame"]
  TTID --> DATA["data arrives"]
  DATA --> TTFD["TTFD — reportFullyDrawn()"]
  AC -. "tier 2: appScope, off the critical path" .-> BG["Analytics, experiments"]
  ACT -. "tier 3: by lazy, on first use" .-> LZ["Ads, maps, video"]
  

Cold = process creation + Application + first Activity + first frame. Warm = process alive, activity recreated. Hot = activity resumed. Only cold start is worth optimising as a programme; it correlates with install-day retention and is the one users notice.

Two metrics: TTID (time to initial display — first frame drawn) and TTFD (time to full display — content actually usable). Optimising TTID alone produces the cheat of drawing an empty skeleton fast; report both, and call reportFullyDrawn() so TTFD is measurable.

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Analytics.init(this)         // 120 ms
        CrashReporter.init(this)     // 40 ms
        AdsSdk.initialize(this)      // 300 ms, network on main
        ExperimentSdk.fetchSync()    // 250 ms, blocking network!
        Timber.plant(DebugTree())
        preloadEverything()
    }
}
// Every SDK team adds "just one more init".

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        // Tier 1: required before the first frame. Keep tiny.
        CrashReporter.init(this)            // must catch startup crashes

        // Tier 2: needed soon, not now.
        appScope.launch(Dispatchers.Default) {
            Analytics.init(this@App)
            ExperimentSdk.warm()            // async; use cached values meanwhile
        }
    }
}

// Tier 3: on first use.
val ads by lazy { AdsSdk.create(context) }

// Enforced in CI:
@Test fun startup_budget() = benchmarkRule.measureRepeated(
    metrics = listOf(StartupTimingMetric()),
    startupMode = StartupMode.COLD, iterations = 15,
) { pressHome(); startActivityAndWait() }
// fails the build if p50 TTID regresses > 10%

Baseline profiles

Without a baseline profile, code runs interpreted until the JIT warms up — so the first launch and first scroll, the impressions that matter most, are the slowest the app will ever be. A baseline profile ships AOT-compiled hot paths in the APK, typically improving cold start by 15–30% and largely eliminating first-scroll jank. Generate them from a Macrobenchmark journey that covers startup and the primary scroll, and regenerate when the hot paths change — a stale profile silently stops helping.

Chapter 72Rendering and jank

A frame must complete within the refresh budget: 16.7 ms at 60 Hz, 8.3 ms at 120 Hz. Note that a high-refresh-rate device makes previously-fine code janky — a common cause of "it only stutters on the newer phones."

Chapter 73ANRs

An ANR fires when the main thread cannot service an event in time: ~5 s for input dispatch, ~20 s for a foreground service start, ~10 s for a broadcast. The trap is that the stack trace shows where the main thread was when the timer expired, not what caused the delay — so the top frame is frequently innocent.

Chapter 74Battery and background cost

• Wakelocks held past their need are the classic drain. Any wakelock should be timeout-bounded and released in a finally.
• Wakeups cost more than the work: waking the radio and CPU every minute for a 20 ms sync is far worse than one batched sync every 30 minutes. Batch, and let WorkManager coalesce.
• Location is the largest single drain available to an app. Match accuracy and interval to the actual product need, use passive/balanced modes where possible, and stop when the screen is off unless the product genuinely requires tracking.
• Attribution: Battery Historian on a dogfood build and Vitals' excessive-wakeup metrics in the field. Users cannot tell you which subsystem drained their battery, but the OS can.

// Every 60 s, forever, whether or not anything changed
PeriodicWorkRequestBuilder<SyncWorker>(15, MINUTES)
    .build()
    .also { wm.enqueue(it) }          // duplicated on every launch

wakeLock.acquire()                     // no timeout
doSync()                               // may throw
wakeLock.release()                     // never reached on failure

// Server tells us when there is something to sync.
// Periodic work is a safety net, not the mechanism.
wm.enqueueUniquePeriodicWork(
    "sync-safety-net",
    ExistingPeriodicWorkPolicy.KEEP,
    PeriodicWorkRequestBuilder<SyncWorker>(6, HOURS)
        .setConstraints(Constraints(
            requiredNetworkType = NetworkType.UNMETERED,
            requiresBatteryNotLow = true,
        )).build()
)

wakeLock.acquire(30_000)               // hard timeout
try { doSync() } finally { if (wakeLock.isHeld) wakeLock.release() }

Chapter 75App size and delivery

Install size measurably affects install conversion, particularly in markets with expensive data — which makes it a business metric, not a hygiene metric. Where the bytes go, and what actually works:

• R8 in full mode with resource shrinking. Verify it is genuinely on in release — a stray -dontoptimize or an over-broad keep rule from an SDK's consumer rules commonly disables most of the benefit.
• App Bundle splits by density, ABI and language: typically the single largest win, and free.
• Native libraries are usually the biggest line item in a media app. Check whether you ship four ABIs when the bundle already splits them.
• Images: WebP/AVIF over PNG, vector drawables where the asset allows.
• Dynamic feature delivery only when a large, rarely-used feature is demonstrably costing conversion — it complicates DI, navigation and testing considerably.
• Gate it in CI: report the size delta on every pull request. Size regresses one library at a time, and nobody notices a 400 KB dependency until the total is 90 MB.

Chapter 76Running a performance programme

A Staff engineer is not asked to fix one screen; they are asked why the app keeps getting slower. The answer is always the same: performance has no owner and no budget, so it loses every trade-off individually while losing badly in aggregate.

1. Define SLIs and targets per tier. "p90 cold start under 1.5 s on mid-tier devices" — not one number for all hardware.
2. Give each team a budget for the surfaces they own, visible on a dashboard they see weekly.
3. Gate in CI with Macrobenchmarks on the top journeys, so regressions are caught before rollout rather than in Vitals.
4. Halt criteria on staged rollout: a startup or ANR regression stops the rollout automatically.
5. A standing budget for fixes — commonly 10–20% of capacity. Without it, the ratchet only turns one way.
6. Report in business terms. "Cold start down 600 ms; day-1 retention up 0.4%" funds the next quarter of work. "We reduced recompositions" does not.

Chapter 77The runtime memory model

• ART uses a concurrent, mostly-generational collector. Short-lived objects are cheap; long-lived ones that survive several collections are promoted and become expensive to collect. Allocation itself is cheap — the cost is the collection pressure it creates.
• Your heap is capped per app (ActivityManager.memoryClass, commonly 128–512 MB depending on device). Exceeding it is OutOfMemoryError, regardless of how much RAM the device has.
• Native memory is separate. Hardware bitmaps, native libraries, and NDK allocations do not count toward the Java heap but do count toward the process's overall footprint — so a process can be killed by the low-memory killer with a nearly-empty Java heap.
• onTrimMemory is the OS asking you to release caches before it kills you. Apps that ignore it get killed sooner, which shows up as a worse warm-start rate.
• GC pauses cause jank when they land inside a frame. Per-frame allocation in a scrolling list is the usual source.

Chapter 78Leak topology

flowchart LR
  GC(["GC root"]) --> ST["static / object / companion"]
  GC --> TH["live thread, Handler queue"]
  GC --> SVC["service, app-scoped coroutine"]
  ST --> LST["listener list in a singleton"]
  LST --> VM2["ViewModel or Fragment"]
  TH --> RUN["delayed Runnable"]
  RUN --> V["View"]
  V --> ACT["Activity"]
  ACT --> TREE["whole view hierarchy — megabytes"]
  VM2 --> ACT
  

Read it right to left: anything still reachable from a GC root cannot be collected. Every fix cuts exactly one edge — unregister the listener, cancel the Runnable, null the binding — and none of them involve nulling the Activity.

Every leak is the same shape: a long-lived object holds a reference to a short-lived one. Learning the six common paths lets you spot them in review rather than in a heap dump.

class DetailFragment : Fragment() {
    private lateinit var binding: FragmentDetailBinding
    private val handler = Handler(Looper.getMainLooper())

    override fun onViewCreated(v: View, s: Bundle?) {
        // 1. Singleton keeps a strong ref to this fragment forever
        LocationManagerSingleton.addListener(this)

        // 2. Delayed runnable holds the view for 30 s past destruction
        handler.postDelayed({ binding.banner.isVisible = true }, 30_000)

        // 3. Binding survives onDestroyView → leaks the whole view tree
    }
}

class DetailFragment : Fragment(R.layout.fragment_detail) {
    private var binding: FragmentDetailBinding? = null

    override fun onViewCreated(v: View, s: Bundle?) {
        binding = FragmentDetailBinding.bind(v)

        viewLifecycleOwner.lifecycle.addObserver(
            LocationObserver(locationManager)      // self-unregistering
        )

        viewLifecycleOwner.lifecycleScope.launch {
            delay(30_000)
            binding?.banner?.isVisible = true      // cancelled on destroy
        }
    }

    override fun onDestroyView() {
        binding = null
        super.onDestroyView()
    }
}

Chapter 79Diagnosing with heap dumps

1. Reproduce:  navigate in and out of the suspect screen 10×,
               with a manual GC between (Profiler → trash icon).
2. Dump:       Studio Memory Profiler → capture heap dump,
               or  adb shell am dumpheap <pid> /data/local/tmp/h.hprof
3. Filter:     group by class, sort by retained size, filter to
               your package. Look for N instances of an Activity
               where N should be 1.
4. Path:       inspect "references to this" → find the shortest
               strong path from a GC root. That path IS the bug.
5. Confirm:    fix, repeat step 1–3, assert the count is 1.

Retained vs shallow size is the distinction interviewers check. Shallow size is the object's own fields; retained size is everything that would be freed if it went away. An Activity has a small shallow size and an enormous retained size — which is why one leaked Activity matters and one leaked String does not.

LeakCanary in CI: beyond the debug-build toast, its detection can run in instrumented tests and fail the build on a new leak. That converts leaks from "someone notices eventually" to a gate — the Staff-level move.

Chapter 80Exercises — five leaks to find

class AnalyticsBus {
    companion object {
        private val listeners = mutableListOf<(Event) -> Unit>()
        fun subscribe(l: (Event) -> Unit) { listeners += l }
        fun publish(e: Event) { listeners.forEach { it(e) } }
    }
}

class CartViewModel(private val repo: CartRepo) : ViewModel() {
    init {
        AnalyticsBus.subscribe { event ->
            if (event is PriceChanged) refresh()   // captures `this`
        }
    }
}

@Composable
fun LocationBanner(manager: LocationManager) {
    var location by remember { mutableStateOf<Location?>(null) }

    LaunchedEffect(Unit) {
        manager.registerListener { location = it }
    }

    location?.let { Text("Near ${it.name}") }
}

@Singleton
class ImageLoader @Inject constructor() {
    private val cache = mutableMapOf<String, Bitmap>()

    fun load(url: String, into: ImageView) {
        cache[url]?.let { into.setImageBitmap(it); return }
        thread {
            val bmp = decode(url)
            cache[url] = bmp
            into.post { into.setImageBitmap(bmp) }
        }
    }
}

class ChatViewModel(socket: ChatSocket) : ViewModel() {
    private val _messages = MutableStateFlow<List<Message>>(emptyList())
    val messages = _messages.asStateFlow()

    init {
        viewModelScope.launch {
            socket.incoming.collect { msg ->
                _messages.update { it + msg }     // grows forever
            }
        }
    }
}

class MainActivity : ComponentActivity() {
    private val receiver = object : BroadcastReceiver() {
        override fun onReceive(c: Context, i: Intent) { refresh() }
    }

    override fun onCreate(s: Bundle?) {
        super.onCreate(s)
        applicationContext.registerReceiver(receiver, filter)
    }

    override fun onDestroy() {
        super.onDestroy()
        // unregister forgotten
    }
}

Chapter 81What to test, and what not to

Every test has a price: authoring, runtime on every CI job, and — the largest — maintenance when the code changes. A test is worth it when expected defect cost prevented exceeds that. This produces some unpopular conclusions worth stating plainly in an interview:

Chapter 82Test doubles: why fakes beat mocks at scale

@Test fun loads_user() = runTest {
    val repo = mockk<UserRepository>()
    coEvery { repo.getUser("1") } returns user
    coEvery { repo.getPrefs("1") } returns prefs
    coEvery { repo.trackView(any()) } just Runs

    val vm = ProfileViewModel(repo)
    vm.load("1")

    coVerify(exactly = 1) { repo.getUser("1") }   // implementation detail
    coVerify { repo.trackView(any()) }
}

// Shipped from the module's test-fixtures, reused by every consumer.
class FakeUserRepository : UserRepository {
    private val users = MutableStateFlow(mapOf<String, User>())
    var failNext: Throwable? = null

    fun seed(u: User) { users.update { it + (u.id to u) } }
    override fun observe(id: String) = users.map { it[id] }
    override suspend fun getUser(id: String): User {
        failNext?.let { failNext = null; throw it }
        return users.value.getValue(id)
    }
}

@Test fun shows_user_then_error_on_refresh_failure() = runTest {
    val repo = FakeUserRepository().apply { seed(user) }
    val vm = ProfileViewModel(repo)

    vm.state.test {
        assertEquals(Loading, awaitItem())
        assertEquals(Ready(user), awaitItem())
        repo.failNext = IOException()
        vm.refresh()
        assertEquals(Failed(retryable = true), awaitItem())
    }
}

When mocks are right: verifying that a side-effecting collaborator you do not own was called (an analytics SDK, a payment gateway), or standing in for an interface with too many methods to fake in a one-off test. The rule: fake the things you own and reuse; mock the things you neither own nor reuse.

Chapter 83Testing coroutines and Flow

class SearchViewModel(repo: Repo) : ViewModel() {
    fun search(q: String) {
        viewModelScope.launch(Dispatchers.IO) { ... }   // not injectable
    }
}

@Test fun searches() = runBlocking {
    vm.search("shoes")
    delay(500)                      // real sleep; flaky and slow
    assertEquals(2, vm.state.value.results.size)
}

class SearchViewModel(
    private val repo: Repo,
    private val io: CoroutineDispatcher,
) : ViewModel()

class MainDispatcherRule(
    private val d: TestDispatcher = UnconfinedTestDispatcher()
) : TestWatcher() {
    override fun starting(d0: Description) = Dispatchers.setMain(d)
    override fun finished(d0: Description) = Dispatchers.resetMain()
}

@get:Rule val dispatcherRule = MainDispatcherRule()

@Test fun debounces_and_cancels_previous() = runTest {
    val vm = SearchViewModel(repo, StandardTestDispatcher(testScheduler))
    vm.state.test {
        assertEquals(Idle, awaitItem())
        vm.onQuery("sh"); advanceTimeBy(100)
        vm.onQuery("sho"); advanceTimeBy(100)
        vm.onQuery("shoe")
        advanceTimeBy(300)               // virtual: instant
        assertEquals(Loading, awaitItem())
        assertEquals(Results(shoeResults), awaitItem())
        assertEquals(1, repo.callCount)  // debounce actually worked
    }
}

The StateFlow/Turbine gotcha worth knowing: a StateFlow created with WhileSubscribed does not start until collected, so a test that reads .value without collecting sees only the initial value and appears broken. Inside .test { } the collection exists, which is one reason Turbine is the standard tool rather than a convenience.

Chapter 84UI, screenshot, and end-to-end tests

flowchart TD
  E2E["End-to-end · minutes · highest flake
a handful of revenue-critical journeys"]
  UIT["UI + screenshot · seconds · on device
screen states across theme, locale, font scale"]
  INT["Integration · tens of ms · Robolectric
repository + DAO + mappers, with fakes"]
  UNIT["Unit · milliseconds · JVM
domain rules, reducers, state holders"]
  E2E --- UIT --- INT --- UNIT
  

The ordering is economic, not moral: value is confidence bought divided by authoring plus maintenance plus flake, and that ratio collapses as you climb. Which is why the top tier is a few journeys rather than a suite.

Screenshot testing is the highest-leverage addition for a large app because it covers the combinatorial surface — light/dark, RTL, large font scale, small screen — that nobody tests manually. Its failure mode is nondeterminism: pin the font, disable animation and blinking cursors, use a fixed clock, and render off-device where possible. A flaky screenshot suite gets muted within a month, and then you are paying for nothing.

Chapter 85Contract testing the mobile/backend seam

The most expensive mobile bugs frequently originate in a backend change that no mobile test could catch: a field becomes nullable, an enum gains a value, a list becomes paginated. Both sides' tests pass; production breaks.

// 1. Parse real recorded payloads, not hand-written happy-path JSON.
@Test fun parses_production_sample() {
    val dto = json.decodeFromString<OrderDto>(readResource("order_prod_sample.json"))
    assertNotNull(dto.toDomain())
}

// 2. Assert the client tolerates the changes the server is allowed to make.
@Test fun unknown_enum_value_does_not_crash() {
    val dto = json.decodeFromString<OrderDto>("""{"status":"QUANTUM_PENDING"}""")
    assertEquals(OrderStatus.Unknown, dto.toDomain().status)
}

// 3. Schema check in CI: fail the mobile build when the published
//    OpenAPI/GraphQL schema removes a field the client still reads.
//    This is the one that actually prevents the incident.

The Staff framing: this is an organisational contract, not a test file. Somebody must own the rule "the mobile client's supported schema range is checked in the backend's CI" — because mobile cannot force-update installed clients, so the backend is always the party that must remain compatible.

Chapter 86Strategy for a large organisation

Chapter 87Gradle mechanics

Gradle runs in phases, and knowing which phase your cost is in is most of the diagnosis:

1. Initialisation — settings, which projects exist.
2. Configuration — every build script runs, every task is created. On a 300-module project this can be 30+ seconds before any work, and it happens on every invocation unless the configuration cache is on.
3. Execution — tasks run, subject to up-to-date checks and the build cache.

// Runs on EVERY build, including `./gradlew tasks`
val gitSha = "git rev-parse HEAD".execute().text.trim()
val buildTime = System.currentTimeMillis()

android {
    defaultConfig {
        buildConfigField("String", "GIT_SHA", "\"$gitSha\"")
        buildConfigField("long", "BUILD_TIME", "${buildTime}L")
    }
}

val gitSha: Provider<String> = providers.exec {
    commandLine("git", "rev-parse", "--short", "HEAD")
}.standardOutput.asText.map { it.trim() }        // evaluated on demand, cached

android {
    defaultConfig {
        buildConfigField("String", "GIT_SHA", "\"${gitSha.get()}\"")
        // No timestamp: it would defeat every cache. If you need one,
        // inject it at packaging time only for release builds.
    }
}

Chapter 88Variants and build logic

Variants multiply: 3 flavours × 2 build types = 6 variants, each with its own compile, resource-merge and lint task per module. Teams routinely create dimension combinations nobody builds, and pay for them in configuration time and IDE sync.

androidComponents {
    beforeVariants { variant ->
        // Only `internal` needs the debuggable+staging combination.
        variant.enable = !(variant.flavorName == "demo" &&
                           variant.buildType == "release")
    }
}

The Staff-level point: every variant is a build-time and test-matrix cost paid by every engineer on every sync. A dimension needs a named owner and a reason, or it should not exist.

Chapter 89Cutting build times across an organisation

Chapter 90Pipelines and static analysis

flowchart LR
  L["Local pre-commit
seconds — format only"] --> PR["Pre-merge
<10 min — compile, lint,
affected-module tests, size diff"]
  PR --> PM["Post-merge
<30 min — full unit suite,
smoke tests, benchmarks"]
  PM --> N["Nightly
hours — E2E, screenshots,
device matrix, dep audit"]
  N --> REL["Release
signed bundle, mapping upload,
baseline profile, staged rollout"]
  

The budgets are the design. Anything slower than about ten minutes pre-merge gets routed around — engineers batch changes into larger pull requests, which are harder to review, which costs more quality than the extra checks bought.

Static analysis as architecture enforcement

The highest-value custom rules are the ones encoding decisions from other parts of this book — this is how an architectural agreement becomes real rather than aspirational:

ban  GlobalScope                        → Part III
ban  Dispatchers.IO referenced directly → inject the dispatcher
ban  feature-to-feature imports          → Part VIII boundary rule
ban  android.* imports in :core:domain-* → keeps the domain pure
warn Composable with > 6 parameters      → hoisting smell
ban  runBlocking outside tests/main()
ban  PendingIntent without FLAG_IMMUTABLE→ Part IV / XV
ban  Gson reflective adapters            → Part II null-safety hole

Signal-to-noise is the whole game. A ruleset with 400 warnings is a ruleset everyone ignores. Introduce rules at error severity with a baseline file for existing violations, so new code is clean and legacy debt is visible but non-blocking.

Chapter 91Release engineering

The defining constraint of mobile release: you cannot recall a binary. A bad server deploy is reverted in minutes; a bad app release is on users' devices until they update, and some never will. Every release practice follows from this.

1. Merge everything ready on Friday
2. Build, upload, 100% rollout
3. Watch Crashlytics over the weekend
4. If it's bad: hotfix, 2-day review anxiety, staged panic

1. Release train: branch cuts on a fixed schedule.
   Missing the train is cheap; blocking it is expensive.
2. Internal → closed → 1% → 5% → 20% → 50% → 100%,
   with a soak at each step.
3. Automated halt criteria evaluated per step:
     crash-free sessions  < baseline − 0.1%   → halt
     ANR rate             > baseline + 20%     → halt
     p90 cold start       > baseline + 15%     → halt
     checkout conversion  < baseline − 2%      → halt
4. Every risky feature behind a remote flag, so
   mitigation does not require a new binary.
5. Hotfix path rehearsed: cherry-pick, expedited
   review, targeted rollout. Practised, not improvised.

Chapter 92Threat modelling a mobile client

The foundational premise, and the sentence that most improves a security answer: the client runs on hardware the attacker controls. Everything shipped in the APK is readable; everything computed on-device can be altered; every network call can be observed and replayed. Security decisions follow from what that does and does not mean.

Chapter 93Keystore, crypto, and secure storage

The Android Keystore stores keys in hardware (TEE, or StrongBox on supported devices) so the key material never enters your process. You ask the Keystore to perform operations; you never hold the key. That is the entire security value, and it is why "we encrypt with a key in SharedPreferences" is not equivalent.

object Crypto {
    private const val KEY = "MySuperSecretKey123!"   // in the APK
    fun encrypt(s: String): String =
        Base64.encodeToString(xor(s.toByteArray(), KEY.toByteArray()), 0)
}

// Also common and also wrong:
prefs.edit().putString("auth_token", token).apply()   // plaintext
Log.d(TAG, "Login ok, token=$token")                  // in logcat, in bug reports

private fun getOrCreateKey(): SecretKey =
    (KeyStore.getInstance("AndroidKeyStore").apply { load(null) }
        .getEntry(ALIAS, null) as? KeyStore.SecretKeyEntry)?.secretKey
        ?: KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
            .apply {
                init(KeyGenParameterSpec.Builder(ALIAS, PURPOSE_ENCRYPT or PURPOSE_DECRYPT)
                    .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
                    .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
                    .setUserAuthenticationRequired(true)        // biometric gate
                    .setInvalidatedByBiometricEnrollment(true)  // new fingerprint ⇒ key dies
                    .setIsStrongBoxBacked(hasStrongBox)
                    .build())
            }.generateKey()

// GCM: never reuse an IV with the same key. Store the IV with the ciphertext.
fun encrypt(plain: ByteArray): Pair<ByteArray, ByteArray> {
    val c = Cipher.getInstance("AES/GCM/NoPadding")
    c.init(Cipher.ENCRYPT_MODE, getOrCreateKey())
    return c.iv to c.doFinal(plain)
}

Chapter 94Identity: OAuth2, tokens, biometrics

sequenceDiagram
  participant App
  participant CT as Custom Tab
  participant IdP as Identity provider
  participant API
  App->>App: generate code_verifier, derive challenge
  App->>CT: authorize?code_challenge=…&S256
  CT->>IdP: user authenticates (App never sees credentials)
  IdP-->>App: redirect with authorization code
  App->>IdP: token(code, code_verifier) — no client secret
  IdP-->>App: short access token + rotating refresh token
  App->>App: store refresh token under a Keystore key
  App->>API: Bearer access token
  Note over App,IdP: refresh reuse detected ⇒ IdP revokes the whole family
  

The correct mobile flow is Authorization Code with PKCE, in a Custom Tab — not an embedded WebView. The reasons matter in interviews: an embedded WebView means your app can read the user's credentials (so an identity provider cannot trust you, and increasingly blocks it), it does not share the system's session, and users cannot verify the URL bar to detect phishing.

biometricPrompt.authenticate(promptInfo)
// onAuthenticationSucceeded:
override fun onAuthenticationSucceeded(r: AuthenticationResult) {
    unlockApp()                     // patch this branch out: done
    showBalance(cachedBalance)
}

val cipher = Cipher.getInstance(TRANSFORM).apply {
    init(Cipher.DECRYPT_MODE, keystoreKey, GCMParameterSpec(128, iv))
}
biometricPrompt.authenticate(promptInfo, CryptoObject(cipher))

override fun onAuthenticationSucceeded(r: AuthenticationResult) {
    // The cipher is only usable BECAUSE the user authenticated.
    val token = r.cryptoObject!!.cipher!!.doFinal(encryptedToken)
    session.restore(token)
}

Chapter 95Transport and platform hardening

Certificate pinning — and its operational risk

Pinning defends against a compromised or user-installed CA. It also creates a way to brick your app remotely: if the pinned certificate is rotated and clients have not updated, every request fails and no app-side fix is possible. The Staff position is that pinning is a decision with an operational cost, and the answer must include: pin to an intermediate or use multiple pins including a backup key; set an expiry; have a remote-config kill switch for the pinning itself; and monitor pin-failure rates so a botched rotation is visible within minutes rather than after the app-store reviews.

// "Fixing" a staging certificate error
val trustAll = object : X509TrustManager {
    override fun checkServerTrusted(c: Array<X509Certificate>, a: String) {}
    override fun checkClientTrusted(c: Array<X509Certificate>, a: String) {}
    override fun getAcceptedIssuers() = arrayOf<X509Certificate>()
}
builder.hostnameVerifier { _, _ -> true }

<!-- res/xml/network_security_config.xml (debug flavour only) -->
<network-security-config>
  <domain-config cleartextTrafficPermitted="false">
    <domain includeSubdomains="true">staging.example.com</domain>
    <trust-anchors>
      <certificates src="@raw/staging_ca"/>   <!-- specific, not "all" -->
    </trust-anchors>
  </domain-config>
</network-security-config>

<!-- release: pins with a backup and an expiry -->
<pin-set expiration="2027-01-01">
  <pin digest="SHA-256">base64PrimaryKeyHash=</pin>
  <pin digest="SHA-256">base64BackupKeyHash=</pin>
</pin-set>

WebView

If a WebView loads any content you do not fully control: disable JavaScript unless required; never enable allowFileAccessFromFileURLs; treat @JavascriptInterface as remote code execution surface and expose the absolute minimum; and allow-list the loadable hosts. A WebView with a JS bridge and an attacker-controlled URL is the most severe vulnerability commonly found in Android apps.

Chapter 96Integrity and realistic expectations

Chapter 97A repeatable framework

Forty-five minutes, six phases. The timings are deliberate: candidates lose the round by spending twenty minutes on requirements or by drawing boxes in minute two.

The scale estimation nobody does — and it is free marks

10M DAU · 40 messages sent per active user per day
  → 400M messages/day ≈ 4,600 msg/s average, ~15k/s peak

Per device: 20 conversations × 500 messages retained
  → 10k rows × ~400 bytes ≈ 4 MB text + media separately
  → comfortably fits SQLite; media needs its own quota

Socket: 10M DAU, ~15% concurrent → 1.5M live connections
  → that is a backend cost, and it justifies asking whether
    we need a socket at all or whether push + fetch suffices
    for the 85% who are not actively chatting.

The point is not arithmetic accuracy. It is that the numbers drive a design decision — here, "socket only while a conversation is open, push otherwise," which is a real architectural conclusion reached from an estimate rather than from taste.

Chapter 98How mobile design interviews are scored

Chapter 99API design and the mobile/backend contract

The asymmetry that defines this contract: the server can deploy hourly; installed clients cannot be updated. Every compatibility obligation therefore falls on the server, and a Staff engineer is expected to negotiate that explicitly.

• Additive-only changes. New optional fields are safe; removing or retyping a field breaks old clients permanently. The client should ignore unknown fields and tolerate unknown enum values by mapping them to an explicit Unknown.
• Cursor pagination, not offsets. Offsets duplicate and skip items when the underlying list changes — guaranteed on any live feed.
• Screen-shaped endpoints reduce round trips but couple the server to UI. The honest trade: aggregate where the screen is stable and latency-critical, keep resources granular where the UI churns.
• Errors need a machine-readable code, not just a message. Clients must branch on code; a localised string is for display only.
• Every mutation takes an idempotency key. Establish this once, globally, rather than per endpoint.
• Minimum supported version must be an explicit, agreed policy with a forced-upgrade mechanism — otherwise "old clients" is an unbounded liability.

GET /v1/feed?cursor=eyJ0cyI6MTcwfQ&limit=20
200 {
  "items": [ { "id": "...", "type": "post", "payload": { ... } } ],
  "next_cursor": "eyJ0cyI6MTY5fQ",     // null ⇒ end
  "server_time": "2026-08-12T10:00:00Z" // clock-skew correction
}

POST /v1/orders
Idempotency-Key: 8f14e45f-ea5c-4f2b-9d6b-7c1a2b3c4d5e
409 {
  "code": "INVENTORY_UNAVAILABLE",      // client branches on this
  "message": "That size just sold out", // display only, localised
  "retryable": false,
  "details": { "sku": "A-42" }
}

Chapter 100Design: ride-hailing with live tracking

Requirements: request a ride, see the driver approach in real time, trip state through pickup and drop-off, fare and receipt. Dominant constraint: the app must be correct and cheap in battery while running for 20+ minutes with the screen sometimes off and connectivity varying.

Scale: driver position at 1 Hz; a 20-minute trip is ~1,200 updates. At 1M concurrent trips that is 1M msg/s to the backend — so the rider's client should not receive 1 Hz; 2–4 second interpolated updates are indistinguishable to the user and cut socket traffic by 75%.

flowchart TD
  UI["Trip screen (Compose)"] --> VM["TripViewModel — trip state machine"]
  VM --> TR["TripRepository (source of truth)"]
  TR --> WS["Socket client — driver position, trip events"]
  TR --> API["REST — request, cancel, receipt"]
  TR --> DB[("Room: trip, positions ring buffer")]
  FGS["Foreground service (driver app)"] --> LOC["FusedLocation, batched"]
  LOC --> UP["Upload batcher — 5s batches, compressed"]
  PUSH["FCM"] -. "wake on trip event" .-> TR
  

Client architecture. The trip is an explicit state machine — Requesting → Matched → DriverEnRoute → Arrived → InProgress → Completed — persisted in Room, because it must survive process death mid-trip. The socket delivers position and state transitions; FCM is the fallback that wakes the app when the socket is dead. Position updates feed an interpolator so the marker animates smoothly between sparse updates rather than teleporting.

Failure modes and behaviour: socket drops → exponential reconnect with a resume token, and the UI shows last-known position with a staleness indicator rather than a frozen lie; connectivity lost entirely → trip state persists, UI degrades to "reconnecting", and on resume the client fetches trip state by ID rather than replaying missed events; app killed mid-trip → state restored from Room and reconciled with a single authoritative fetch; driver's app backgrounded → foreground service with a location type keeps uploads alive, batched to protect battery.

Trade-offs to state: socket vs polling (socket for the active trip only, because 1.5M idle sockets is a real cost); server-side vs client-side ETA (server, so all parties agree); precision vs battery on the driver side (batch uploads at 5 s, accept a small staleness).

Chapter 101Design: food delivery

Dominant constraint: three actors (customer, restaurant, courier) observing one order whose state changes from outside the app. Correctness of state matters more than latency.

Design: the order is a server-authoritative state machine; the client never infers a transition locally. Push carries the transition; the client fetches the order to confirm rather than trusting the payload, so a lost or reordered push cannot corrupt state. Menu and pricing are cached with a short TTL and revalidated at cart-open and at checkout — the failure to design for is a price change between browsing and paying, which is a trust and support-cost issue.

Cart consistency: local-first with server reconciliation. The cart is a local draft; validation (item availability, price, minimum order) happens server-side at checkout and returns a structured diff the UI explains, rather than a generic failure.

Follow-ups: "Restaurant goes offline with an order in flight" — the order state machine has an explicit RestaurantUnresponsive state with a timeout and an auto-refund path; do not leave it in Preparing forever. "Courier tracking when the app is backgrounded?" — push-driven state, socket only while the tracking screen is visible.

Chapter 102Design: chat and messaging

sequenceDiagram
  participant U as User
  participant DB as Local DB (truth)
  participant Q as Outbox
  participant S as Server
  U->>DB: insert local_id, state = pending
  DB-->>U: message visible immediately, clock icon
  Q->>S: send(local_id, body)
  S-->>Q: ack(local_id → server_id, server_seq)
  Q->>DB: state = sent, re-sort by server_seq
  Note over S,DB: socket broadcast of the same message arrives
  S-->>DB: upsert keyed by local_id — collapses, no duplicate row
  

Dominant constraints: message ordering, exactly-once display, offline send, and multi-device convergence.

messages(
  local_id      TEXT PRIMARY KEY,   -- client UUID, created at send time
  server_id     TEXT UNIQUE,        -- null until acked
  conversation  TEXT NOT NULL,
  sender        TEXT NOT NULL,
  body          TEXT,
  created_at    INTEGER NOT NULL,   -- client clock, for local ordering
  server_seq    INTEGER,            -- authoritative order within conversation
  state         TEXT NOT NULL,      -- pending | sent | delivered | read | failed
  INDEX(conversation, server_seq),
  INDEX(state)                      -- the outbox query
)
conversations(id, last_seq_synced, unread_count, updated_at)

Ordering: never order by timestamp — device clocks are wrong, sometimes by hours. Order by the server-assigned monotonic server_seq per conversation, and display pending messages optimistically at the tail until they are acked and re-sorted. Deduplication: the client-generated local_id is echoed by the server, so a message that arrives both as an ack and as a socket broadcast collapses to one row.

Sync: per-conversation cursor (last_seq_synced); on reconnect, fetch the gap rather than replaying everything. If the gap exceeds a threshold, fall back to a bounded resync rather than paging through months of history.

Offline send: the message is written locally as pending and enqueued; the UI shows it immediately with a clock icon. WorkManager drains the queue. A permanently-failed message must reach a failed state with a retry affordance — silently retrying forever is the worse bug.

Chapter 103Design: an Instagram-style feed

Dominant constraint: scroll performance with heavy media, and cursor stability on a list that changes underneath you.

Pagination: cursor-based, with the cursor encoding a snapshot boundary so newly-inserted posts do not cause duplicates mid-scroll; new content surfaces as a "new posts" pill rather than being spliced in, which also avoids scroll-position jumps. Storage: Paging 3 with a RemoteMediator into Room, so the feed is available offline and survives process death with scroll position intact.

Media pipeline: server returns multiple renditions; the client requests the one matching its display size — never the original. Prefetch two screens ahead on unmetered connections only. Memory cache sized from memoryClass, disk cache with a hard quota.

Optimistic interactions: a like writes locally, updates the UI immediately, and enqueues the mutation with an idempotency key. On failure it reverts with a quiet indicator. Never block the UI on a like round-trip.

Follow-ups: "Ranking changes between pages, and the user sees a duplicate" — the snapshot cursor is the answer; if the backend cannot provide one, dedupe client-side by ID and log the rate, because a high rate means the backend contract is wrong. "Memory during fast scroll?" — bounded caches, decode to display size, and verify with a Macrobenchmark scroll journey, not by inspection.

Chapter 104Design: video streaming

Constraints: start-up latency, rebuffer ratio, and data cost. Those three are the product.

Design: adaptive bitrate over HLS/DASH with ExoPlayer/Media3; start at a conservative rendition for fast first-frame and step up once the buffer is healthy. Buffer policy differs by network: larger buffer on unmetered, smaller on cellular to avoid wasting data the user never watches. Prefetch only the first few seconds of likely-next items, and only on Wi-Fi.

Downloads: WorkManager with an unmetered constraint, DRM licence acquisition and renewal handled separately from the media (a downloaded file with an expired licence is a common support case), and playback-position sync so resume works across devices.

Observability is the differentiator here: the metrics that matter are join time, rebuffer ratio, average bitrate delivered, and playback failure rate, segmented by network type and device tier. Say those unprompted.

Follow-ups: "Network drops mid-playback" — keep the buffered content playing, retry segment fetches with backoff, and only surface an error when the buffer is exhausted. "How do you avoid wasting the user's data?" — quality caps on cellular by default, an explicit user setting, and never prefetching on metered connections.

Chapter 105Design: a subscription streaming app (multi-surface)

Requirements: browse a catalogue, play on phone/tablet/TV, download for offline, multiple profiles per account, resume position synced across devices. Dominant constraint: the same account is used on several surfaces with different input models and wildly different network conditions, and entitlement must be correct without making the app unusable during a brief outage.

Entitlement. Checked server-side at playback start — a client-side subscription boolean is trivially bypassed and is the first thing an attacker patches. But a hard server dependency means a backend blip stops all playback, so the client caches a signed entitlement token with a bounded grace period (typically hours, not days) and degrades to cached rights if the check fails. Downloads carry their own offline licence with an explicit expiry, which is why "I downloaded it but it won't play" is almost always a licence-renewal bug rather than a media bug — worth naming, because interviewers who work on streaming have all seen it.

Profiles are a schema decision, not a UI one. Continue-watching, recommendations, maturity rating and download ownership are all per profile, so every relevant table is keyed by profile_id and every query filters on the active profile. The bug class to design out: switching profiles without clearing in-memory caches, so the previous profile's continue-watching row briefly appears — embarrassing, and on a kids' profile it is a policy violation rather than a cosmetic bug. The safe pattern is to treat a profile switch as a scoped teardown, closer to a logout than to a filter change.

profiles(id, account_id, name, is_kids, maturity_rating)
watch_state(profile_id, title_id, position_ms, updated_at_server_seq,
            PRIMARY KEY(profile_id, title_id))
downloads(profile_id, title_id, file_path, licence_expires_at, bytes,
          PRIMARY KEY(profile_id, title_id))
catalogue(title_id, ...)        -- shared, not profile-scoped

Resume position across devices is a convergence problem with a forgiving conflict policy: highest position_ms per (profile, title) does not work — a user who rewatches from the start would have their position dragged forward. Use a server sequence number, last-write-wins by server order, and write positions at a throttled cadence (every 15–30 seconds and on pause/stop) rather than continuously, or you generate one write per second per viewer.

Surface divergence. TV is not a layout variation — D-pad focus navigation is a different input model, with focus order, focus memory when returning to a row, and no touch affordances. Wear and Auto differ again. The design that works: share domain, data, entitlement and playback-state logic; write presentation and navigation separately per surface; and test focus traversal on TV as a first-class requirement. Saying "it's responsive" here is a Senior answer and interviewers who own a TV app will say so.

Chapter 106Design: maps and navigation

Dominant constraint: battery and thermal, during long foreground use with the screen on and GPS active.

Design: vector tiles cached on disk with an LRU quota and explicit offline-region downloads; the route is computed server-side and returned as a polyline plus manoeuvres, so recalculation is a server call — but the client must handle the offline case by continuing along the last route and queueing the recalculation. Location at the coarsest accuracy the current mode allows, with sensor fusion for dead-reckoning in tunnels.

Foreground service with a location type, a persistent notification, and adaptive update intervals by speed. Thermal: listen to thermal status and degrade — reduce frame rate, drop map effects, lengthen GPS interval — before the OS throttles you, because uncontrolled throttling looks like a crash-quality bug to users.

Chapter 107Design: e-commerce

Key tensions: catalogue staleness versus freshness, cart consistency across devices, and checkout correctness.

• Catalogue: aggressively cached, revalidated with ETags. Stale product copy is acceptable; stale price or availability is not — so price and stock are fetched fresh on the product page and re-validated at checkout.
• Cart: server-owned when signed in (so it follows the user across devices), local draft when anonymous, with a defined merge rule at sign-in. That merge rule is a question interviewers love: union with quantity max, and surface the change rather than silently overwriting.
• Checkout: a resumable, idempotent, server-driven step machine. The client asks "what is the next step" rather than encoding the flow, because payment and compliance steps vary by market and change without an app release.
• Search: server-side, debounced, with cancellation of superseded queries (flatMapLatest), and a local recent-searches cache for instant perceived response.

Chapter 108Design: travel booking (flights)

Distinguishing features: search is slow (multi-supplier aggregation, seconds not milliseconds), results expire, and inventory is held rather than owned.

Design: async search — POST creates a search, the client polls or subscribes and renders results progressively as suppliers respond, so the user sees something in 500 ms rather than nothing for 6 seconds. Results carry an explicit expiry; the UI shows a countdown and re-prices on selection rather than failing at payment. The booking flow is a resumable server-side state machine with a held-inventory timer, because a user who backgrounds the app mid-booking must be able to return.

Follow-ups: "The price changed between selection and payment" — a mandatory re-price step before payment, with an explicit confirmation UI. Never silently charge a different amount; it is both a trust and a regulatory problem. "Process death mid-booking?" — the booking ID and step are persisted; on relaunch the client resumes from the server's authoritative step.

Chapter 109Design: hotel booking

Requirements: search by destination and dates, filter and sort, view on a map, book, manage the reservation. Dominant constraints: availability is volatile and supplier-owned, and the result set must be presented two ways at once without the views disagreeing.

Map/list duality is the design's core. The failure everyone hits: list and map maintained as separate states, so panning the map filters one and not the other, and a property tapped on the map is missing from the list. One source of truth for the result set, two projections driven from it, and a single explicit rule for what a map pan does — either it re-queries by viewport (and the list follows) or it does not filter at all. Ambiguity here is the bug.

@Immutable
data class SearchUiState(
    val query: SearchQuery,                    // destination, dates, guests
    val results: ImmutableList<Property>,      // THE source of truth
    val viewport: MapViewport?,                // null until the map moves
    val selectedId: PropertyId?,               // shared selection
    val mode: Mode,                            // List | Map | Split (tablet)
)
// List renders `results`; the map renders the same `results` as pins.
// Selection is one field, so tapping a pin highlights the list row.

Filtering is split deliberately: filters that affect correctness or price (dates, guests, refundability) are server-side, because the client cannot know availability. Filters that merely narrow already-loaded results (star rating, amenities present in the payload) are applied locally for instant feedback, with a clear indication when the local subset is incomplete. Mixing these silently is how users end up believing a property is unavailable when it was simply not in the loaded page.

Inventory and price behave as in Chapter 108: results carry an expiry, selection triggers a re-price, and booking holds inventory on a timer. The client shows the countdown rather than failing at payment.

Offline requirements are asymmetric and worth stating. Search is useless offline — do not fake it. But a confirmed booking must be fully available with no network: confirmation number, property address and phone, check-in time, cancellation policy, and a map snapshot if you can afford one. The user will open this in an airport, in another country, with no data and a nearly-flat battery. Designing the reservation record as a self-contained offline document, rather than as a view over cached API responses, is the difference between an app that works when it matters and one that shows a spinner.

Chapter 110Design: a news reader

Requirements: browse sections, read articles, offline reading, breaking-news alerts, read state synced across devices. Dominant constraints: prefetch economics (you are spending the user's storage and data speculatively) and content licensing, which for some publishers forbids caching at all.

Prefetch is a budget decision, not a feature. Scheduled work on unmetered connections with a hard storage quota, prioritised by the sections the user actually opens. Articles stored with a TTL and an explicit "available offline" indicator, so the offline experience is honest rather than a surprise. The metric that justifies the whole subsystem is the prefetch hit rate — the fraction of prefetched articles actually read. If it is low, you are burning storage and data for nothing, and that is an argument you can take to a product review with numbers rather than opinion.

Read state is a small, high-churn dataset: a set of article IDs with timestamps. Sync it as a delta with last-write-wins per article, and say explicitly why that policy is acceptable here — the cost of a wrong resolution is that an article shows as unread. Contrast this with the notes app in Chapter 115, where the same policy would destroy user writing. Being able to justify a cheap conflict policy is as much a signal as designing an expensive one.

Breaking news uses high-priority push, which is a finite reputational resource: abuse it for engagement and the platform degrades your delivery for the messages that matter. Practically that means a governance rule — high priority for genuine time-critical alerts, normal priority for editorial pushes — and a metric tracking the ratio.

Licensing is the constraint outsiders miss. Some content is display-only with no caching permitted, some has a retention limit, some must be removed on takedown. The data model therefore needs a per-article caching policy field, and takedown must purge local copies — which means the sync protocol needs tombstones for content removal, not just for user deletions.

Chapter 111Design: a social network

The feed itself is Chapter 103. What makes a social client distinct are four client-side problems that are each a common production bug.

Notification coherence. A notification must not persist after the user has seen the content elsewhere. That requires server-side dismissal: the server tracks notification state and pushes a dismissal to other devices, because a client cannot know what happened on a different phone. Without it, users clear the same notification on three devices — a small annoyance that generates a surprising volume of complaints.

Account switching is where the serious bugs live. Local storage must be fully partitioned per account — separate database files or a mandatory account column enforced at the DAO level — plus separate image caches, separate outboxes, and separate in-memory state. The catastrophic version of this bug is a queued post from account A being sent from account B after a switch. The safe design treats a switch as a full teardown and rebuild of the object graph, not as a variable change.

// Every user-scoped dependency is created in an account-scoped
// component that is destroyed on switch or logout.
@AccountScope
class AccountComponent(val accountId: AccountId) {
    val db: AppDatabase          // separate file per account
    val outbox: SyncQueue        // never shared
    val imageCache: DiskCache    // separate directory
}

fun switchAccount(to: AccountId) {
    current.outbox.pause()       // do NOT drain into the new account
    current.close()              // tear down everything user-scoped
    current = AccountComponent(to)
}

Privacy state must be enforced server-side. Client-side filtering of blocked users leaks the existence of the content — it is visible in the payload, in a proxy, and to anyone who patches the client. Blocking, private accounts and restricted visibility are authorisation decisions, and authorisation on the client is not authorisation.

Moderation surfaces impose an unusual requirement: removed content must disappear from local caches too. That means content removal is a synced event with a tombstone, image caches are purgeable by content ID, and there is a path for an urgent global purge. Most offline-first designs only consider user-initiated deletion; a moderation takedown is a deletion the user did not perform and cannot decline, and the sync protocol has to accommodate it.

Chapter 112Design: a banking application

Dominant constraint: never display a number that is wrong. Correctness dominates latency, which inverts most of the caching intuition from consumer apps.

• Balance: shown with an explicit "as of" timestamp when served from cache, and refreshed on foreground. A stale balance presented as current is a complaint and potentially a regulatory issue.
• Session: short, with step-up authentication for transfers and payee changes. Biometrics gate a Keystore key (Part XV), not a boolean.
• Local storage: encrypted; transaction history cached for offline viewing but pending transfers never stored as "complete" until server-confirmed.
• Screenshot and background: FLAG_SECURE on sensitive screens, and a privacy overlay in the recents preview.
• Audit: security-relevant client events (device change, biometric enrolment change, failed auth) reported server-side, because the client's own log is not trustworthy evidence.

Chapter 113Design: payments

stateDiagram-v2
  [*] --> Draft
  Draft --> Committed: user confirms — key generated and PERSISTED
  Committed --> Submitted: POST with Idempotency-Key
  Submitted --> Succeeded: 2xx
  Submitted --> Failed: 4xx, deterministic
  Submitted --> Unknown: timeout / no response / process death
  Unknown --> Submitted: retry, same key
  Unknown --> Succeeded: reconciliation says it landed
  Unknown --> Failed: reconciliation says it did not
  Succeeded --> [*]
  Failed --> [*]
  note right of Unknown
    UI shows "processing", never "failed".
    Showing failure here is what makes
    users pay twice.
  end note
  

This is Chapter 63's idempotency problem as a full design. The core state machine: Draft → Committed(key persisted) → Submitted → Unknown | Succeeded | Failed, where Unknown is a first-class state rather than an error.

// 1. Key is created when the USER commits, persisted BEFORE the call.
val op = PendingPayment(
    id = UUID.randomUUID().toString(),   // == Idempotency-Key
    amount = amount, payeeId = payee.id,
    state = Committed,
)
db.pending().insert(op)                  // survives process death

// 2. Every attempt — including after a restart — reuses op.id.
// 3. No response ⇒ state = Unknown, NOT Failed. Reconcile by polling
//    status with the same key, or wait for push confirmation.
// 4. UI never shows "failed" for an Unknown; it shows "processing".

3DS and app switching add a re-entry problem: the user leaves to a bank app or a browser and returns, possibly after process death. The payment state must be recoverable from the persisted key alone, and the return deep link must be validated. Follow-ups: "What if the server's key retention is shorter than your offline queue's lifetime?" — a correctness gap; either bound the queue's lifetime to match, or require reconciliation by order status rather than by key. Spotting that mismatch is a strong L4/L5 signal.

Chapter 114Design: real-time fleet tracking

The inverse of ride-hailing: the client is a producer of high-frequency data. Design: batch positions into 5–30 second windows depending on speed and battery; compress (delta-encode coordinates, which typically shrinks payloads by an order of magnitude); persist the batch locally before upload so nothing is lost to a crash; and apply client-side backpressure — when the queue exceeds a threshold, downsample rather than growing unboundedly, keeping every N-th point plus all points where direction changed sharply.

That downsampling policy is the whole answer to "the driver was in a dead zone for two hours": you cannot upload everything, so decide in advance what fidelity you sacrifice.

Chapter 115Design: an offline-first notes app

The canonical local-first design. Local database is the source of truth; the UI never waits on the network. Every mutation writes locally and appends to an outbox. Sync is a delta protocol with a server cursor.

suspend fun sync() {
    // 1. Push: drain the outbox in order, idempotently.
    outbox.pending().forEach { op ->
        when (val r = api.apply(op.toRequest(), key = op.id)) {
            is Applied  -> outbox.markDone(op.id)
            is Conflict -> resolve(op, r.serverVersion)   // see below
            is Retryable-> return                        // stop; try later
            is Permanent-> outbox.markFailed(op.id, r.reason)  // surface to user
        }
    }
    // 2. Pull: delta since the cursor, applied in one transaction.
    var cursor = meta.cursor()
    do {
        val page = api.changes(since = cursor, limit = 200)
        db.withTransaction {
            page.changes.forEach { applyRemote(it) }
            meta.setCursor(page.nextCursor)
        }
        cursor = page.nextCursor
    } while (page.hasMore)
}

Conflict policy for notes: per-note last-write-wins loses text, which users notice immediately. The defensible options are three-way merge on the text (base, local, remote), or — the pragmatic one — keep both as a conflict copy and tell the user. Silently discarding a user's writing is the one outcome that is never acceptable, and saying that explicitly matters more than the algorithm you choose.

Chapter 116Design: collaborative documents

OT vs CRDT: OT needs a central server to transform and order operations, which is simpler on the client but useless offline. CRDTs converge without coordination — the right choice for a mobile client that is regularly offline — at the cost of metadata growth and a much harder debugging story.

Mobile-specific realities to raise: CRDT metadata for a long-lived document can exceed the document itself, so you need compaction or a snapshot-plus-tail model; presence and cursors go over a socket and are ephemeral (never persisted); and a large document cannot be held fully in memory on a low-end device, so you need windowed loading, which interacts badly with naive CRDT implementations. Being able to name that interaction is what distinguishes an L5 answer from a recital of "CRDTs converge."

Chapter 117Design: large-scale search

Latency budget: typeahead feels instant under ~100 ms, acceptable to ~300 ms. Since a network round trip alone is often 200 ms, the design must hide latency: show local recent and popular searches instantly, render results progressively, and never clear the current results while the next query is in flight (the flicker that makes search feel broken).

Pipeline: debounce 250–300 ms → distinct → minimum length → flatMapLatest to cancel superseded requests → results. Local index (SQLite FTS) for user-owned content, which works offline and is genuinely instant; remote for the corpus.

Instrumentation: the metrics that matter are time-to-first-result, abandonment rate, zero-result rate, and result-click position. Zero-result rate is the one that drives product change, and it is usually not instrumented.

Chapter 118Local-first architecture

Offline-first is not "cache the responses." It is an inversion of control: the local database is the source of truth, and the network is a background process that reconciles it with the server. The UI never awaits the network for a read, and never awaits it for a write either.

flowchart LR
  UI["UI"] --> S["State holder"]
  S --> R["Repository"]
  R --> DB[("Local DB — source of truth")]
  DB --> R
  R --> OB[["Outbox"]]
  OB --> SY["Sync engine (WorkManager)"]
  SY --> API["Server"]
  API --> SY
  SY --> DB
  PUSH["Push"] -. "wake" .-> SY
  

Chapter 119Sync engines and delta synchronisation

A sync engine has four responsibilities and they must be separable in code, because they fail differently: push local changes, pull remote changes, resolve conflicts, and reconcile after failure.

val since = prefs.getLong("last_sync", 0)
val changes = api.changes(since = since)
applyAll(changes)
prefs.putLong("last_sync", System.currentTimeMillis())  // client clock!

var cursor = meta.cursor()          // opaque; the server defines it
do {
    val page = api.changes(since = cursor, limit = 200)
    db.withTransaction {
        page.changes.forEach(::applyRemote)
        meta.setCursor(page.nextCursor)   // advances ONLY with the data
    }
    cursor = page.nextCursor
} while (page.hasMore)

Tombstones

Deletions must be synced as explicit tombstone records. Without them, a client that was offline during a deletion never learns about it and the row lives forever — which presents as "deleted items keep coming back," one of the most reported sync bugs. Tombstones need a retention window agreed with the backend, and a client that has been offline longer than that window must perform a full resync rather than a delta.

Chapter 120Conflict resolution

sequenceDiagram
  participant A as Device A (offline)
  participant S as Server
  participant B as Device B (offline)
  Note over A,B: both hold base version 7
  A->>S: PATCH note 42, version 7
  S-->>A: 200, now version 8
  B->>S: PATCH note 42, version 7
  S-->>B: 409 VERSION_CONFLICT + current record (v8)
  Note over B: resolve by the TYPE's policy —
LWW, per-field merge, server wins,
or keep both as a conflict copy
  B->>S: PATCH note 42, version 8
  S-->>B: 200, now version 9
  

Device B needs three things to merge rather than overwrite: its local edit, the server's current record, and the base it started from. Clients that keep only the first two can overwrite but can never merge.

The clock problem: never resolve conflicts with client timestamps. Devices have wrong clocks — users change them, timezones shift, and some devices drift by minutes. Use server-assigned versions or sequence numbers. If you must use a client timestamp for ordering, correct it against a server-provided server_time on every response and store the offset.

// Client sends the version it last saw.
PATCH /notes/42        { "version": 7, "title": "Groceries" }

// Server: if current version != 7 → 409 with the current record.
409 { "code": "VERSION_CONFLICT", "current": { "version": 9, ... } }

// Client resolves according to the type's policy:
when (val r = api.patch(note, version = local.version)) {
    is Ok       -> db.upsert(r.record)                 // version advances
    is Conflict -> when (policy) {
        ServerWins  -> db.upsert(r.current)
        FieldMerge  -> db.upsert(merge(local, r.current, base))
        KeepBoth    -> { db.upsert(r.current); db.insert(local.asCopy()) }
    }
}

Chapter 121Idempotency and the unknown outcome

Distributed systems deliver at least once. Exactly-once delivery does not exist; exactly-once effect is achievable, and only through idempotency. The three places this bites a mobile client:

1. Client → server writes. Solved with a persisted idempotency key (Parts IX and XVI).
2. Server → client push. FCM may deliver a message more than once, or reorder it. Push handlers must be idempotent — which is another argument for treating push as a signal to fetch rather than as data to apply.
3. Sync replay. Applying the same delta page twice must be a no-op, which means upserts keyed by server ID, never blind inserts.

override fun onMessageReceived(msg: RemoteMessage) {
    val m = msg.data.toMessage()
    db.insert(m)                  // duplicate on re-delivery
    unread++                      // and the count drifts forever
}

override fun onMessageReceived(msg: RemoteMessage) {
    val conversationId = msg.data["cid"] ?: return
    // Idempotent by construction: fetching twice is harmless.
    SyncWorker.enqueueUnique(context, conversationId)
}

Chapter 122Real-time transport

The standard Staff answer: hybrid. Socket only while the relevant screen is foregrounded; push as the wake signal when backgrounded; a delta fetch on every resume to close gaps. Explain the reconnection protocol — exponential backoff with jitter, a resume token so the server can replay missed events, and a bounded gap after which you resync rather than replay.

Chapter 123Multi-device consistency and client-side backpressure

Multi-device turns several single-client problems into distributed ones: read state must converge (use a monotonic high-water mark, which is conflict-free); notifications must be dismissible across devices (server-side dismissal); and logout on one device must not silently invalidate a pending write queue on another.

Logout is the underrated case. The correct behaviour needs a product decision, and a Staff candidate should force it: block logout while the outbox is non-empty, warn and discard, or complete the queue in the background before clearing. What is never acceptable is clearing local data with pending writes still queued, because the user believes their work was saved.

Client-side backpressure and rate limiting matter because your app can be the source of an outage. A client that retries aggressively on failure, multiplied by ten million devices, is a denial-of-service against your own backend. Every client needs: jittered backoff (Part IX), a circuit breaker that stops hammering a failing endpoint, a cap on queued operations with a downsampling policy, and respect for Retry-After.

Chapter 124The case against rewrites

The rewrite argument is always the same: the old system is unknowable, the new one will be clean, and it will take one quarter. The observed outcome is also always the same. Three reasons, worth being able to articulate:

• The old system encodes years of undocumented requirements — the edge cases, the OEM workarounds, the regulatory rule added after an incident. A rewrite rediscovers them one production bug at a time.
• Two systems must be maintained during the transition, so velocity halves precisely when the organisation is being asked to be patient.
• There is no incremental value. A rewrite delivers nothing until it delivers everything, which makes it the first thing cut when priorities shift — leaving you with two half-systems, the worst possible state.

interface PaymentClient { suspend fun charge(req: ChargeRequest): ChargeResult }

class LegacyPaymentClient(...) : PaymentClient
class NewPaymentClient(...)    : PaymentClient

class RoutingPaymentClient(
    private val legacy: PaymentClient,
    private val new: PaymentClient,
    private val flags: FeatureFlags,
) : PaymentClient {
    override suspend fun charge(req: ChargeRequest): ChargeResult =
        if (flags.isEnabled("payments.new_client", req.userId)) {
            runCatching { new.charge(req) }
                .onFailure { metrics.count("new_client_failure") }
                .getOrElse { legacy.charge(req) }      // automatic fallback
        } else legacy.charge(req)
}

Three properties this gives you and a rewrite does not: rollout by percentage, instant rollback without a release, and a metric comparing the two paths. That is what makes a migration safe rather than merely planned.

Chapter 125The eight canonical Android migrations

// Rx: error terminates this stream only; the screen survives.
repo.observeUser()
    .subscribe({ render(it) }, { showError(it) })

// Naive port: an exception here cancels viewModelScope,
// killing every other collector in the ViewModel.
viewModelScope.launch {
    repo.observeUser().collect { render(it) }
}

viewModelScope.launch {
    repo.observeUser()
        .map<User, UserState> { UserState.Ready(it) }
        .catch { emit(UserState.Failed(it.retryable)) }   // contained
        .collect { _state.update { s -> s.copy(user = it) } }
}

Chapter 126Technical debt as a managed portfolio

The word "debt" is useful precisely because it implies interest. The Staff skill is quantifying that interest so it competes fairly with feature work.

When debt is the right answer: for code that is about to be deleted, for a validated-then-discarded experiment, or when time-to-market genuinely dominates. The failure is not taking the shortcut; it is taking it without recording the decision, the cost and the expiry. A candidate who says "I always pay down debt immediately" is describing a preference, not a judgment.

Chapter 127Evaluating Kotlin Multiplatform

Chapter 128Incident response for mobile

Mobile incidents differ from server incidents in one decisive way, and stating it early in any incident question is a strong signal: you cannot recall the binary. Everything follows from that.

flowchart LR
  D["Detect
Vitals, Crashlytics, support"] --> T["Triage
severity, blast radius, is it us?"]
  T --> M1["Halt the rollout
seconds, free, reversible"]
  M1 --> M2["Kill switch / remote config
minutes"]
  M2 --> M3["Server-side fix
hours"]
  M3 --> M4["Forward hotfix
days, never reaches everyone"]
  M4 --> P["Blameless postmortem
fix the class, not the instance"]
  T -. "not us: OS or Play Services rollout" .-> W["Watch and communicate"]
  

The order matters and it is the opposite of a server incident: the cheapest, most reversible mitigation is first, and the code fix is last because it is the slowest and never reaches 100% of users.

Severity, defined before you need it: SEV1 — data loss, security exposure, or a core flow broken for a large cohort. SEV2 — significant degradation with a workaround. SEV3 — contained, non-blocking. Publish the definitions, because arguing about severity during an incident is how thirty minutes disappear.

Chapter 129Twelve incidents

Chapter 130Observability that makes incidents survivable

Telemetry cost is a real budget line. A verbose analytics client can generate gigabytes per user per year, costing money on both the ingestion bill and the user's data plan. Sampling policy, event schema review, and a cost-per-event dashboard belong to whoever owns observability — and at Staff level, that is often you.

Chapter 131How Staff coding rounds are scored

A correct answer can still fail the round. Interviewers score the process, roughly in this order:

1. Clarification. Bounded or unbounded? Thread-safe? What is the eviction policy? Silence here reads as an engineer who codes before understanding.
2. API before implementation. Write the signatures first and ask whether they are right. This is the single highest-signal habit in a Staff coding round.
3. Reasoning aloud about concurrency. "Two callers hit this line simultaneously — what happens?" said unprompted.
4. Edge cases named before being asked. Empty input, cancellation mid-flight, failure of the underlying operation, capacity zero.
5. Testing. What you would test, and how you would make it deterministic.
6. Complexity and trade-offs, including what you would change in production.

Chapter 132Problem: thread-safe LRU cache

Requirements to establish: bounded by count or by size? Accessed from multiple threads? Do we need TTL? Must reads be lock-free? For this version: bounded by count, thread-safe, O(1) get and put.

class LruCache<K : Any, V : Any>(private val maxSize: Int) {
    init { require(maxSize > 0) { "maxSize must be positive" } }

    // accessOrder = true makes iteration order = access order,
    // so the eldest entry is the least recently *used*, not inserted.
    private val map = object : LinkedHashMap<K, V>(16, 0.75f, true) {
        override fun removeEldestEntry(eldest: MutableMap.MutableEntry<K, V>) =
            size > maxSize
    }
    private val lock = Any()

    fun get(key: K): V? = synchronized(lock) { map[key] }

    fun put(key: K, value: V): V? = synchronized(lock) { map.put(key, value) }

    fun remove(key: K): V? = synchronized(lock) { map.remove(key) }

    val size: Int get() = synchronized(lock) { map.size }
}

Why get must also be synchronised — the question interviewers ask to check depth: with accessOrder = true, a read mutates the linked list. An unsynchronised get can corrupt the structure or throw ConcurrentModificationException. Candidates who synchronise only writes have a subtle, intermittent bug.

Complexity: O(1) for both, with lock contention as the practical bottleneck. Follow-ups and answers: "Make reads concurrent" — segment the map, or accept approximate LRU (Caffeine's approach: buffer access records and replay them in batches). "Bound by bytes" — supply a size function and evict in a loop rather than by count. "Add TTL" — store the insert time and treat expired entries as absent on read, plus a periodic sweep so expired entries do not occupy capacity indefinitely.

Chapter 133Problem: concurrent request deduplicator

The scenario: five composables ask for the same user simultaneously on a cold start. You want one network call, five results, and correct cancellation semantics.

class RequestDeduplicator<K : Any, V>(
    private val scope: CoroutineScope,       // shared, NOT a caller's scope
) {
    private val mutex = Mutex()
    private val inFlight = mutableMapOf<K, Deferred<V>>()

    suspend fun execute(key: K, block: suspend () -> V): V {
        val deferred = mutex.withLock {
            inFlight[key]?.takeIf { it.isActive }
                ?: scope.async {
                    try { block() }
                    finally { mutex.withLock { inFlight.remove(key) } }
                }.also { inFlight[key] = it }
        }
        return deferred.await()
    }
}

The design decision to articulate: the work runs in a shared scope, not the first caller's. If it ran in the first caller's scope, that caller navigating away would cancel the request for the other four — a genuinely nasty production bug, because it only appears when the first subscriber leaves early. The cost of the shared scope is that the work continues even if every caller leaves; if that matters, add reference counting and cancel when the count reaches zero, but say why you did it.

Edge cases: a failure must remove the entry so the next caller retries rather than awaiting a permanently-failed Deferred (the finally handles it); isActive guards against a completed-but-not-yet-removed entry; and each caller's own cancellation only cancels its await, which is exactly what you want.

Tests: launch five concurrent calls with a TestDispatcher, assert the block ran once and all five got the value; cancel the first caller and assert the others still complete; make the block throw and assert the next call re-executes.

Chapter 134Problem: debounce and throttle as Flow operators

fun <T> Flow<T>.debounceManual(timeoutMs: Long): Flow<T> = channelFlow {
    var job: Job? = null
    collect { value ->
        job?.cancel()                       // supersede the pending emission
        job = launch {
            delay(timeoutMs)
            send(value)                     // only if nothing arrived meanwhile
        }
    }
    job?.join()                             // let the last one through
}

// Throttle-first: emit immediately, then ignore for a window.
fun <T> Flow<T>.throttleFirst(windowMs: Long): Flow<T> = flow {
    var lastEmit = 0L
    collect { value ->
        val now = currentCoroutineContext()[TestTimeSource]?.now() ?: System.currentTimeMillis()
        if (now - lastEmit >= windowMs) { lastEmit = now; emit(value) }
    }
}

The distinction that gets asked: debounce waits for silence (right for search-as-you-type — you want the final query); throttle-first emits immediately then suppresses (right for a button that must not double-fire — you want the first event, and debounce would add latency to every tap). Choosing the wrong one produces either a laggy search or a double-submitted order.

The job?.join() line is what makes the trailing value survive when the upstream completes — omitting it silently drops the last query, which is the classic bug in hand-rolled debounce.

Chapter 135Problem: rate limiter (token bucket)

class TokenBucket(
    private val capacity: Int,
    private val refillPerSecond: Double,
    private val clock: () -> Long = System::nanoTime,
) {
    private val mutex = Mutex()
    private var tokens = capacity.toDouble()
    private var last = clock()

    /** Suspends until a token is available. Cancellable. */
    suspend fun acquire() {
        while (true) {
            val waitMs = mutex.withLock {
                refill()
                if (tokens >= 1.0) { tokens -= 1.0; return }
                ((1.0 - tokens) / refillPerSecond * 1000).toLong().coerceAtLeast(1)
            }
            delay(waitMs)                   // outside the lock — important
        }
    }

    private fun refill() {
        val now = clock()
        val elapsedSec = (now - last) / 1_000_000_000.0
        if (elapsedSec <= 0) return
        tokens = min(capacity.toDouble(), tokens + elapsedSec * refillPerSecond)
        last = now
    }
}

Two details that separate levels: delay is called outside the lock — holding a mutex across a delay serialises every waiter and destroys throughput; and the clock is injected, so the test uses virtual time instead of sleeping. Follow-up: "Why token bucket over a fixed window?" — a fixed window allows a double-rate burst across the boundary; token bucket permits a controlled burst up to capacity and then a smooth rate, which is what you actually want for API politeness.

Chapter 136Problem: offline sync queue

The most representative Staff Android coding problem, because it touches persistence, concurrency, retry and idempotency at once.

@Entity(tableName = "outbox")
data class Operation(
    @PrimaryKey val id: String,          // == idempotency key
    val type: String,
    val payload: String,
    val createdAt: Long,
    val attempts: Int = 0,
    val nextAttemptAt: Long = 0,
    val state: State = State.Pending,    // Pending | InFlight | Failed | Done
    val lastError: String? = null,
)

class SyncQueue(
    private val dao: OutboxDao,
    private val api: Api,
    private val clock: Clock,
) {
    /** Drains in FIFO order. Stops on the first retryable failure so
     *  ordering is preserved — critical when operations are dependent. */
    suspend fun drain(): DrainResult {
        while (true) {
            val op = dao.nextReady(now = clock.millis()) ?: return DrainResult.Empty
            dao.update(op.copy(state = State.InFlight))
            when (val r = runCatching { api.apply(op.type, op.payload, key = op.id) }
                    .fold({ Outcome.Ok }, { it.toOutcome() })) {

                Outcome.Ok        -> dao.delete(op.id)
                Outcome.Duplicate -> dao.delete(op.id)          // idempotent replay
                Outcome.Permanent -> dao.update(op.copy(
                        state = State.Failed, lastError = "permanent"))  // surface to user
                Outcome.Retryable -> {
                    val n = op.attempts + 1
                    if (n >= MAX_ATTEMPTS) {
                        dao.update(op.copy(state = State.Failed, attempts = n))
                    } else {
                        dao.update(op.copy(
                            state = State.Pending, attempts = n,
                            nextAttemptAt = clock.millis() + backoffWithJitter(n)))
                        return DrainResult.RetryLater          // preserve order
                    }
                }
            }
        }
    }
}

Design points to say aloud: the row ID is the idempotency key, so a replay after process death is safe; InFlight must be recoverable — on startup, reset stale InFlight rows to Pending, because a crash mid-request leaves them stranded; draining stops on the first retryable failure to preserve ordering when operations are dependent (if they are independent, you can parallelise, and you should say which assumption you made); and a permanently-failed operation must be visible to the user, not retried forever or silently dropped.

Follow-ups: "How do you handle operations that depend on each other?" — either FIFO with stop-on-failure as here, or an explicit dependency field. "What if the payload references a local ID the server has not seen?" — ID mapping: when the create succeeds, rewrite queued operations that reference the local ID with the server's. That is a real and commonly-missed requirement.

Chapter 137Problem: a typed state machine

stateDiagram-v2
  [*] --> Idle
  Idle --> Loading: Search(q) / Fetch(q)
  Loading --> Ready: Loaded(items)
  Loading --> Failed: Errored(retryable)
  Loading --> Loading: Search(q2) / Fetch(q2)
  Failed --> Loading: Retry / Fetch(q)
  Failed --> Loading: Search(q2) / Fetch(q2)
  Ready --> Loading: Search(q2) / Fetch(q2)
  

Every edge is one line of the reducer, and every edge is one unit test with no coroutines, no mocks and no clock. Events with no edge from the current state are ignored rather than crashing — which is what makes a stale Loaded from a superseded query harmless.

sealed interface State {
    data object Idle : State
    data class Loading(val query: String) : State
    data class Ready(val items: List<Item>, val query: String) : State
    data class Failed(val query: String, val retryable: Boolean) : State
}
sealed interface Event {
    data class Search(val query: String) : Event
    data class Loaded(val items: List<Item>) : Event
    data class Errored(val retryable: Boolean) : Event
    data object Retry : Event
}
sealed interface Effect { data class Fetch(val query: String) : Effect }

/** Pure function: (State, Event) -> (State, Effects). No coroutines, no I/O. */
fun reduce(state: State, event: Event): Pair<State, List<Effect>> =
    when (state) {
        is State.Idle -> when (event) {
            is Event.Search -> State.Loading(event.query) to listOf(Effect.Fetch(event.query))
            else -> state to emptyList()          // ignore impossible events
        }
        is State.Loading -> when (event) {
            is Event.Loaded  -> State.Ready(event.items, state.query) to emptyList()
            is Event.Errored -> State.Failed(state.query, event.retryable) to emptyList()
            is Event.Search  -> State.Loading(event.query) to listOf(Effect.Fetch(event.query))
            Event.Retry      -> state to emptyList()
        }
        is State.Failed -> when (event) {
            Event.Retry     -> State.Loading(state.query) to listOf(Effect.Fetch(state.query))
            is Event.Search -> State.Loading(event.query) to listOf(Effect.Fetch(event.query))
            else -> state to emptyList()
        }
        is State.Ready -> when (event) {
            is Event.Search -> State.Loading(event.query) to listOf(Effect.Fetch(event.query))
            else -> state to emptyList()
        }
    }

Why separate effects from state: the reducer stays pure, so every transition is a one-line unit test with no coroutines, no mocks and no time. The runtime executes the effects and feeds results back as events. This is the structure that makes complex screens testable, and being able to explain why the effect list is returned rather than executed is the point of the question.

Edge case worth naming: a stale Loaded arriving for a superseded query. Either the effect runner cancels superseded fetches (flatMapLatest), or Loaded carries the query and the reducer ignores mismatches. Say which you chose.

Chapter 138Problem: multi-level cache with coherent invalidation

Requirements to establish: which tier is the source of truth? Must a write be visible immediately to other readers? Is the memory tier shared across screens? For this version: disk is truth, memory is a bounded read-through cache, and all readers must see a write immediately.

class ProfileStore(
    private val dao: ProfileDao,             // source of truth
    private val api: ProfileApi,
    maxMemoryEntries: Int = 64,
) {
    private val memory = LruCache<UserId, Profile>(maxMemoryEntries)
    private val single = SingleFlight<UserId, Unit>(appScope)

    /** Reads never bypass the source of truth's change stream. */
    fun observe(id: UserId): Flow<Profile?> =
        dao.observe(id)                       // ← invalidation comes free
            .map { it?.toDomain() }
            .onEach { it?.let { p -> memory.put(id, p) } }

    /** Fast path for a non-observing caller (e.g. a list mapper). */
    fun peek(id: UserId): Profile? = memory.get(id)

    /** The ONLY write path. Every tier updates from here. */
    suspend fun refresh(id: UserId) = single.run(id) {
        val dto = api.profile(id)
        dao.upsert(dto.toEntity())            // triggers observe() → memory
    }

    suspend fun clear(id: UserId) {
        memory.remove(id)
        dao.delete(id)
    }
}

The design point that scores: the memory tier is populated from the database's change stream, not from the network. That single decision makes incoherence structurally impossible — there is no path where the network updates memory without the database seeing it, which is the bug in almost every hand-rolled two-tier cache. SingleFlight prevents N concurrent refreshes for the same key (Chapter 133).

Follow-ups: "What if the memory cache is stale after a write from another process?" — Room's invalidation is process-local, so a multi-process app needs a ContentProvider or an explicit invalidation broadcast; say this rather than assuming. "How do you bound memory by bytes?" — an LruCache with a size function, sized from ActivityManager.memoryClass, and cleared on onTrimMemory.

Chapter 139Problem: bounded parallel execution

Scenario: upload 200 images. Unbounded concurrency exhausts connections and memory; sequential is too slow. Run at most N at a time, preserve failures individually, and cancel cleanly.

suspend fun <T, R> Iterable<T>.mapParallel(
    concurrency: Int,
    transform: suspend (T) -> R,
): List<Result<R>> = coroutineScope {
    val gate = Semaphore(concurrency)
    map { item ->
        async {
            // withPermit releases on cancellation as well as completion.
            gate.withPermit {
                runCatching { transform(item) }
                    .onFailure { if (it is CancellationException) throw it }
            }
        }
    }.awaitAll()
}

// Usage: 4 at a time, one failure does not abort the rest.
val results = files.mapParallel(concurrency = 4) { uploader.upload(it) }
val failed = results.count { it.isFailure }

Two details interviewers probe. withPermit rather than manual acquire/release, because a cancellation between them leaks a permit and the pool silently shrinks to zero over time — a genuinely nasty production bug. And rethrowing CancellationException out of runCatching, which otherwise captures it as a failure and breaks structured concurrency.

Follow-up: "Why not Dispatchers.IO.limitedParallelism(4)?" — That bounds threads, not in-flight operations. For suspending network calls the coroutine is not holding a thread while awaiting, so a dispatcher limit does not bound concurrency at all. This distinction is a reliable Staff discriminator.

Chapter 140Problem: merge sources with per-source failure isolation

Scenario: a dashboard combines profile, orders and recommendations. One source failing must degrade that section only — never blank the screen.

sealed interface Section<out T> {
    data object Loading : Section<Nothing>
    data class Ready<T>(val value: T) : Section<T>
    data class Failed(val retryable: Boolean) : Section<Nothing>
}

private fun <T> Flow<T>.asSection(): Flow<Section<T>> =
    map<T, Section<T>> { Section.Ready(it) }
        .onStart { emit(Section.Loading) }
        .catch { e ->
            if (e is CancellationException) throw e
            emit(Section.Failed(retryable = e.isRetryable()))   // contained
        }

val state: StateFlow<DashboardUi> = combine(
    profileRepo.observe().asSection(),
    orderRepo.observe().asSection(),
    recsRepo.observe().asSection(),
) { profile, orders, recs -> DashboardUi(profile, orders, recs) }
    .stateIn(viewModelScope, WhileSubscribed(5_000), DashboardUi())

Why catch per source, before combine: an exception reaching combine terminates the combined flow and the whole screen goes blank. Converting failure into a value inside each branch is what makes partial degradation possible. This is the same principle as Part VII's per-section state, expressed in operators.

Follow-ups: "How does retry work per section?" — each repository exposes a refresh command; the failed section's retry button calls only that one. "What if two sources are logically dependent?" — then they are one source; combine across a dependency produces an intermediate state that is briefly inconsistent, and the fix is to model the dependency upstream rather than in the UI.

Chapter 141Further problems, with the key insight for each

Chapter 142What a Staff review looks for

Junior reviewers find style issues. Senior reviewers find bugs. Staff reviewers find the precedent a change sets — because in a 300-module codebase, a pattern merged once is a pattern copied fifty times.

Label every comment. An unlabelled review is a wall of equally-weighted opinions, and the author cannot tell what blocks the merge. In an interview, saying "these two are blocking, the rest are optional" is itself a strong signal — it demonstrates you can be reviewed by as well as review.

Chapter 143Fifteen snippets

class OrderViewModel(private val context: Context) : ViewModel() {
    val orders = MutableLiveData<List<Order>>()

    fun load() {
        GlobalScope.launch(Dispatchers.Main) {
            try {
                val result = withContext(Dispatchers.IO) { Api.service.getOrders() }
                orders.value = result
                Log.d("Orders", "Loaded for ${Session.token}")
            } catch (e: Exception) {
                Toast.makeText(context, "Error", Toast.LENGTH_SHORT).show()
            }
        }
    }
}

@Composable
fun ProductList(viewModel: ProductViewModel) {
    val state by viewModel.state.collectAsState()
    val formatter = SimpleDateFormat("dd MMM yyyy", Locale.getDefault())

    LaunchedEffect(state) { viewModel.trackScreenView() }

    LazyColumn {
        items(state.products) { product ->
            Row(Modifier.clickable { viewModel.onClick(product) }) {
                Text(product.name)
                Text(formatter.format(product.releaseDate))
                AsyncImage(model = product.imageUrl, contentDescription = null)
            }
        }
    }
}

@Singleton
class UserRepository @Inject constructor(private val api: Api) {
    private val cache = mutableMapOf<String, User>()

    suspend fun getUser(id: String): User? {
        cache[id]?.let { return it }
        return try {
            val user = api.getUser(id)
            cache[id] = user
            user
        } catch (e: Exception) {
            null
        }
    }

    fun clearCache() { cache.clear() }
}

class UploadManager(private val api: Api) {
    private var isUploading = false
    private val queue = mutableListOf<File>()

    suspend fun upload(file: File) {
        queue.add(file)
        if (isUploading) return
        isUploading = true
        while (queue.isNotEmpty()) {
            val f = queue.removeAt(0)
            api.upload(f)
        }
        isUploading = false
    }
}

class FeedViewModel(private val repo: FeedRepository) : ViewModel() {
    val feed: Flow<List<Post>> = repo.observeFeed()

    val unreadCount: Flow<Int> = repo.observeFeed().map { it.count { p -> !p.read } }

    private val _events = MutableSharedFlow<Event>(replay = 1)
    val events: SharedFlow<Event> = _events
}

Chapter 144Review as a leadership instrument

At Staff level, review is one of the few mechanisms that scales your judgment. Four practices worth being able to describe:

• Encode repeated feedback. If you have left the same comment three times, it becomes a lint rule, a template, or a documented default. Repeating yourself in review does not scale and eventually reads as nitpicking.
• Review the design, not the diff, when the diff is too late. A 2,000-line PR implementing the wrong architecture cannot be fixed in review. Push the conversation earlier — a design doc or a 20-minute call before the work starts.
• Disagreeing with a senior author: state the concern, the concrete failure scenario, and the cost — then explicitly say whether it blocks. "I think this races when two screens load simultaneously; here's the interleaving. If you disagree, I'm fine merging — but I'd want a test either way."
• Review SLAs matter more than review depth. A team where PRs wait two days ships worse code overall, because authors batch changes into larger PRs that are harder to review. Advocating for fast review is a quality intervention, not a velocity one.

Chapter 145A critique method

Use the same five steps every time. It stops you from listing preferences and forces you to distinguish real problems from taste.

1. What breaks, concretely? Name a failure scenario, not a principle. "This violates SRP" is weak; "two teams editing this file conflict every sprint, and last quarter it caused three revert-and-reland cycles" is not.
2. Who pays, and how often? Every build, every new hire, every incident, every feature.
3. What would you change? The target state, in one diagram.
4. How do you get there without stopping? Sequence, first increment, rollback.
5. What is the trade-off of your own proposal? If you cannot name one, you have not thought about it and the interviewer will notice.

Chapter 146Ten broken architectures

interface ProductRepository {
    fun observe(id: String): Flow<ProductUiState>   // Loading / Error / Ready
}

flowchart LR
  subgraph BEFORE["before — one edit rebuilds everything"]
    F1[":feature:a"] --> C1[":core (200 files, no owner)"]
    F2[":feature:b"] --> C1
    F3[":feature:c"] --> C1
  end
  subgraph AFTER["after — split by capability, one owner each"]
    G1[":feature:a"] --> N[":core:network"]
    G1 --> DS[":core:designsystem"]
    G2[":feature:b"] --> DS
    G2 --> DB[":core:database"]
    G3[":feature:c"] --> N
  end
    

Chapter 147Writing the ADR that makes it stick

A critique that ends in a conversation changes nothing. The artefact that changes behaviour is a short written decision, and interviewers sometimes ask you to produce one verbally.

Status      Accepted · 2026-03-14 · Owner: @mobile-arch · Review: 2027-Q1

Context     Three repositories emit Flow<XUiState>. Two screens now need
            different loading behaviour and cannot share them. Worker code
            duplicates the data path. Error strings are localised in the
            data layer, so tests assert on user-facing copy.

Decision    Repositories expose domain models and throw/emit domain errors.
            Mapping to UI state happens in the state holder.

Alternatives
  Keep as is           — rejected: blocks reuse, couples layers.
  UI state in domain   — rejected: same coupling, moved.
  Per-screen repos     — rejected: multiplies sources of truth (see ADR-009).

Consequences
  + Repositories reusable by Workers and widgets; faster tests.
  − One mapping layer per screen; ~15 files to migrate.
  Enforcement: lint rule bans `UiState` types in :core:data-* signatures.

Reversal    If mapping proves to be pure duplication across >80% of screens,
            revisit with a shared mapper rather than by re-coupling layers.

Migration   New code follows immediately. Existing: additive method, migrate
            per screen, delete old method when callers reach zero. ~2 sprints,
            no flag required (no behaviour change).

The two sections that make it real are Enforcement and Reversal. Without enforcement it is a preference; without a reversal condition it is dogma. Both are what a Staff interviewer is listening for.

Chapter 148How Staff behavioral rounds are evaluated

Interviewers are filling in a rubric with roughly these rows. Everything you say is being sorted into them.

STAR, adapted for technical leadership

Standard STAR under-serves Staff answers because it has no slot for the two things being assessed: the alternatives you weighed and the mechanism you left behind. Use STAR-DL:

Situation   20s   Context and stakes. Include the scale: users, teams, money.
Task        15s   What was actually yours, and why it was ambiguous or hard.
Action      60s   What YOU did. Include the alternatives you rejected.
Result      30s   A measured outcome. A number, with how you measured it.
Decision    20s   The key judgment call and what would have changed it.
Learning    20s   What you do differently now — and where you have applied it since.

Chapter 149Ten questions, fully graded

Chapter 150Forty more questions, grouped

Chapter 151Building your story portfolio

You need eight stories, not forty. Each strong story answers four or five questions with a shift of emphasis. Build the matrix explicitly:

Story                         Scope  Influence Conflict Failure Ambiguity Metric
1. Shared networking client     ✓✓      ✓✓        ✓                ✓        ✓
2. Sync data-loss incident      ✓                  ✓      ✓✓                ✓✓
3. Modularization programme     ✓✓      ✓         ✓               ✓✓        ✓✓
4. KMP disagreement                     ✓         ✓✓              ✓
5. Mentee who plateaued                 ✓         ✓       ✓
6. Said no to a redesign date           ✓✓        ✓✓              ✓         ✓
7. Startup performance push     ✓       ✓                         ✓        ✓✓
8. Deprecating a loved system   ✓✓      ✓✓        ✓✓      ✓
                                                 ↑ every column needs 2+

Extracting the numbers. Most candidates have the impact but not the figure. Before the loop, dig: crash-free rate before and after, build time, incident counts, support ticket volume, conversion or retention deltas, engineer-hours saved. An approximate honest number ("roughly a day per team per quarter, from asking the four leads") is far stronger than no number, and interviewers do not expect audited precision.

Rehearsal. Out loud, timed, to three minutes. The gap between a story you can recall and one you can tell is enormous under pressure. Record yourself once — it is unpleasant and it is the fastest correction available.

If a story is weak, do not inflate it. "This one didn't have the impact I hoped, and here's what I misjudged" scores better than an exaggerated outcome, because interviewers cross-check details across rounds and inconsistency is fatal.

Chapter 152Governance without becoming a bottleneck

Every architecture-governance model sits on a spectrum between two failure modes: anarchy (twelve teams, twelve architectures, nothing shared) and the bottleneck (one person approves everything, and they are on holiday). The mechanisms below are ordered by how well they scale.

Rule: "All architectural changes must be approved
       by the Architecture Council, which meets Thursdays."

Outcome after two quarters:
 · A two-week queue for a one-day decision
 · Teams reclassify work to avoid the label
 · The council reviews trivia and misses the real drift
 · The architect becomes a full-time reviewer and stops building

Default path (no approval needed):
 · Generate the module from the template
 · Build rules enforce dependency boundaries automatically
 · Lint encodes the decisions from published ADRs

Escalation required only for:
 · A new cross-team dependency
 · A new persistence or transport technology
 · Anything shipped to users that cannot be reversed
   (data format, public SDK API, sync protocol)

Escalation is: write a one-page ADR, get two named
reviewers, 48-hour SLA. Not a meeting.

Chapter 153Funding change with no immediate product value

Chapter 154Measuring architecture and preventing drift

"How do you know your architecture is working?" is the question most candidates cannot answer, because architecture feels unmeasurable. It is not — you just have to measure its effects.

Drift is what happens between reviews: a boundary crossed "just this once", a lint suppression added under deadline, a second source of truth introduced by a team who did not know about the first. The counter-measures are mechanical, because vigilance is not a strategy — dependency rules in the build, a lint baseline that can only shrink, a periodic report of new suppressions with owners, and a standing budget so teams have a way to fix drift that does not require permission.

Chapter 155Twenty org-scale scenarios

Chapter 156The answer shape that works every time

Every question in this part has the same structure underneath, so the answer has the same shape:

1. Reject the universal.  "No — and the interesting part is when it's wrong."
2. Name the criterion.    "The decision turns on X, not on the technology."
3. Apply it here.         "For a screen like this, X says …"
4. State the inversion.   "It flips when Y — for example …"

Chapter 157Thirty questions where the obvious answer is wrong

Chapter 158Disagreeing with the interviewer's premise

Sometimes the trap is embedded in the question: "How would you make sure the app never shows stale data?" or "How would you guarantee push notifications arrive within a minute?" Both premises are unachievable, and accepting them leads you into an answer that is confidently wrong.

1. Acknowledge the underlying goal.
   "The goal is that users trust what they see — agreed, that matters."
2. Name the constraint plainly, without lecturing.
   "Guaranteed freshness isn't achievable on a device that can be offline."
3. Offer the achievable version.
   "What we can do is bound the staleness and make it visible: refresh
    on foreground, show an 'as of' timestamp, and push-invalidate."
4. Check you've understood the intent.
   "Is that the shape you're after, or is there a hard requirement
    behind it I should design to?"

That last step is what keeps it collaborative. Some interviewers are testing whether you push back; others genuinely have a constraint in mind. Asking distinguishes them, and costs nothing.

Chapter 159How to speak a comparison

Reciting a table is a Senior answer. The Staff version leads with the criterion, gives the answer, then the caveat:

Criterion  "The decision turns on whether the data has other writers."
Answer     "So: Flow for the observable case, suspend for commands."
Mechanism  "Because a cold Flow re-executes per collector, five screens
            means five calls unless you share it — that's the trap."
Inversion  "It flips if we add offline sync, because then everything
            has another writer."

Chapter 160Reactive and concurrency

Flow vs LiveData

StateFlow vs SharedFlow vs Channel

suspend vs Flow · RxJava vs Coroutines

Chapter 161UI and architecture

XML Views vs Jetpack Compose

MVVM vs MVI

Repository vs UseCase · Singleton vs DI

Chapter 162Infrastructure

Hilt vs Koin vs manual

Room vs raw SQLite · DataStore vs SharedPreferences

WorkManager vs Foreground Service vs coroutine

Chapter 163Networking and system shape

REST vs GraphQL vs gRPC

WebSocket vs polling vs push

Offline-first vs online-first · Modular vs monolithic · Clean vs simple layering

Chapter 164Ten-second answers

Roughly 300 definitions and distinctions that must be instant. Hesitation here costs credibility for the rest of the round, because the interviewer starts wondering what else is shaky.

Kotlin language

Coroutines

Flow

Android platform

Jetpack

Compose

Architecture and modularization

Networking, storage, sync

Performance, testing, security, build

Chapter 165Thirty-second answers

Mechanism plus one consequence. If you exceed 45 seconds you are explaining rather than answering.