Interview guides / android

Android System Design Interview Questions

Android system design interview questions on offline sync, trip clients, modularization, WorkManager, and tradeoffs with example answers.

Android system design interviews emphasize lifecycle, process death, WorkManager, Room as source of truth, and modularization for team scale.

Speak in components and tradeoffs. Show you understand battery, background limits, and configuration changes.

1. 1.Design an Uber-lite rider Android client.

   Server-authoritative trip state machine, map UI over ViewModel, location streaming separated from command APIs, Room for history, foreground service only while an active trip requires it. Degrade honestly offline. Discuss WebSocket vs polling tradeoffs.

2. 2.Design an offline-first sync engine on Android.

   Room as SoT, outbox for writes, WorkManager for sync with network constraints, pull changelog since cursor, conflict policy as product behavior. UI observes Room only. Avoid GlobalScope; keep sync off the main thread.

3. 3.How would you modularize a large Android app?

   app → features → cores with API/impl splits. Prevent feature cycles. Shared network/ui/database cores. Tune module granularity for team ownership without destroying build times.

4. 4.Design the rider Android app: maps, realtime location, trip state machine, payments, offline resilience. Thorough client design with diagram-level components and explicit tradeoffs.

   ## Overview Mirror a server-authoritative trip state machine on device, stream location separately from command APIs, and degrade honestly offline. ## Architecture diagram ```mermaid flowchart TB UI[Map + Trip Compose UI] --> VM[TripViewModel] VM --> Domain[TripSession use case] Domain --> Repo[TripRepository] Repo --> REST[Trip REST] Repo --> RT[Location Flow/WebSocket] Repo --> Room[(Room)] Pay[Payments] --> VM ``` ## Architecture UDF/MVVM: TripViewModel exposes immutable UI state; TripSession domain owns transitions. Maps SDK behind an interface. Hilt injection. Foreground service only while trip requires it and policy allows. ## Networking REST commands with idempotency; realtime socket for locations/events; OkHttp authenticator; reconnect backoff; polling fallback. ## Storage & caching Room history; DataStore activeTripId; last location cache; no sensitive payment storage. ## Offline mode Show last state offline; queue cancel; block new requests; reconcile version on reconnect. ## Performance Throttle map invalidations; fused location intervals by phase; sample UI collect at 1–2 Hz; battery budgets; Baseline profiles. ## Tradeoffs ### Trip authority **Option A — Server authoritative:** Correct dispatch/money; client may lag. **Option B — Client authoritative:** Feels instant; desync risk. **Pick A when:** Always. **Pick B when:** Never for dispatch. ### Realtime transport **Option A — WebSocket:** Low latency; connection ops. **Option B — Polling:** Simple; laggy. **Pick A when:** Live tracking core. **Pick B when:** Early MVP. ### Foreground service **Option A — In-trip FS:** Reliable updates; UX/notification cost. **Option B — No FS:** Less reliable background. **Pick A when:** Active ongoing trip. **Pick B when:** Browsing only.

5. 5.Design a robust Android networking layer: auth, refresh, retries, errors, caching, testability.

   ## Overview A single APIClient with interceptor pipeline and protocol boundaries keeps features testable and consistent. ## Architecture diagram ```mermaid flowchart TB VM --> Repo --> APIClient APIClient --> Auth[Auth Interceptor] APIClient --> Retry[Retry Policy] APIClient --> Session[OkHttp/Retrofit] Auth --> EncryptedStorage/DataStore Repo --> DTO[DTO mapper] ``` ## Architecture Features depend on repositories/protocols. APIClient handles auth header, redacted logs, refresh single-flight (actor). Map transport errors to domain errors for ViewModels. ## Networking One session config; refresh-on-401 once; retry idempotent GETs only by default; timeouts; optional pinning for high risk. ## Storage & caching Tokens EncryptedStorage/DataStore; URLCache where safe; DTO≠domain; per-endpoint TTL policies. ## Offline mode ConnectivityManager fail-fast OfflineError; writes use feature outboxes—not generic HTTP magic. ## Performance Cancel on disappear; coalesce duplicate GETs; measure p95; HTTP/2. ## Tradeoffs ### Refresh strategy **Option A — Refresh on 401:** Lazy; can stampede without single-flight. **Option B — Proactive refresh:** Fewer mid-flight failures; more refresh traffic. **Pick A when:** With single-flight lock. **Pick B when:** Short-lived tokens with predictable expiry. ### Library vs OkHttp/Retrofit **Option A — OkHttp/Retrofit:** First-party, enough for most. **Option B — Alamofire/etc:** Faster extras; dependency cost. **Pick A when:** Default modern apps. **Pick B when:** Team already standardized on a lib.

6. 6.How would you modularize a large Android codebase for build speed, ownership, and clean architecture? Include module diagram thinking and tradeoffs.

   ## Overview Gradle modules encode architecture: app → features → cores, with API/impl splits to prevent cycles. ## Architecture diagram ```mermaid flowchart TB app[:app] --> featureFeed[:feature:feed] app --> featureAuth[:feature:auth] featureFeed --> coreNet[:core:network] featureAuth --> coreNet featureFeed --> coreUI[:core:ui] featureFeed --> coreDB[:core:database] ``` ## Architecture MVVM/UDF inside features. :core:network/:ui/:database/:domain. Features expose entry points only. Navigation abstractions prevent feature↔feature cycles. Hilt aggregation at app. ## Networking Shared OkHttp/Retrofit in core; feature API interfaces; optional dynamic features. ## Storage & caching Document Room ownership; single DB vs multi-DB; migrations owned by schema owners. ## Offline mode core:sync primitives; features plug payload codecs. ## Performance Config cache; parallel builds; Baseline Profile in app; R8 consumer rules; watch AGP costs of too many modules. ## Tradeoffs ### Granularity **Option A — Many modules:** Ownership/build parallel; overhead. **Option B — Few modules:** Simpler; merge conflicts. **Pick A when:** Multi-team. **Pick B when:** Small team. ### Dynamic features **Option A — On-demand modules:** Smaller base; install friction. **Option B — All in base:** Simpler UX; larger download. **Pick A when:** Large optional features. **Pick B when:** Most users need everything.