Interview guides / android

Senior Android Interview Questions

Senior Android interview questions on architecture, process death, background work, Compose, performance, and technical leadership.

Senior Android interviews test judgment under platform constraints: process death, background limits, modularization, and performance.

Bring crisp tradeoffs and production stories. AceMobileInterview mirrors these themes in projects, debugging, and system design.

1. 1.How is process death different from a configuration change?

   Config change recreates Activity but ViewModel can survive. Process death kills the process; in-memory ViewModels die. Persist truly important UI state with SavedStateHandle/disk and test with don't-keep-activities plus background kill.

2. 2.When do you choose WorkManager vs a foreground service?

   WorkManager for deferrable, constrained background work. Foreground service when the user-facing task must keep running with a notification (active navigation/trip). Respect modern background limits and battery expectations.

3. 3.What causes ANRs, and how do you diagnose them?

   ANRs happen when the main thread is blocked (~5s for input). Avoid disk/network on Main; use coroutines. Diagnose with ANR traces, StrictMode, and Systrace/Perfetto. Mention BroadcastReceiver and Service timeouts too.

4. 4.Security difference between implicit and explicit intents?

   Explicit targets a component. Implicit resolve by filters—risk of interception. Use explicit for internal navigation; validate incoming intent extras.

5. 5.Why specify FLAG_IMMUTABLE/MUTABLE on PendingIntents?

   Required on modern APIs for security. Prefer IMMUTABLE unless you must update extras; prevents intent redirection attacks.

6. 6.What are Entity, DAO, and Database in Room?

   Entity=table, DAO=queries, Database=holder. Use suspend/Flow queries; type converters carefully; migrations mandatory for schema changes.

7. 7.What belongs in a ViewModel vs UI layer?

   UI state and business orchestration surviving rotation. No Android framework Views, no Context leaks (use Application context carefully). Expose immutable UI state flows.

8. 8.How do you expose Retrofit APIs with suspend functions?

   suspend endpoints return body/Response; map errors via HttpException. Prefer repository layer; use Call adapters carefully.

9. 9.How do UI test stacks differ?

   Espresso for Views; Compose testing APIs for semantics nodes. Prefer idling resources/synchronization; keep UI tests for critical paths.

10. 10.Difference between remember and rememberSaveable?

    remember survives recomposition only. rememberSaveable also survives config change via saveable registry. Neither survives process death unless backed by SavedState.

11. 11.When do you use an Activity vs a Fragment?

    Activity is a screen entry point/window host. Fragments compose reusable UI within an activity (tabs, master-detail). Prefer single-activity + navigation component for many modern apps.

12. 12.When is ConstraintLayout still useful?

    Complex XML view hierarchies; Compose ConstraintLayout for similar relative positioning. Prefer simpler Column/Row when enough.

13. 13.Why prefer DataStore over SharedPreferences?

    Async, consistent, Coroutines/Flow API, less ANR risk from main-thread prefs. Use Preferences or Proto DataStore.

14. 14.How does RecyclerView achieve performance?

    ViewHolder recycling, DiffUtil partial binds, stable IDs optional. Prefer ListAdapter. Avoid nested scrolling pitfalls and payload-less full rebinds.

15. 15.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.

16. 16.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.

17. 17.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.