Android Developer interview questions & answers — India 2026

Model answer

Activity lifecycle: onCreate → onStart → onResume (active) → onPause → onStop → onDestroy. When the screen rotates: the current Activity is destroyed and recreated (onDestroy → onCreate). This causes data loss unless preserved. Solutions: (1) ViewModel (Jetpack): survives configuration changes; the ViewModel is NOT destroyed on rotation, so UI state stored in ViewModel is preserved; (2) onSaveInstanceState(): bundle-based state preservation for simple data (strings, primitives) — called before onStop; (3) rememberSaveable in Jetpack Compose: equivalent to onSaveInstanceState for Compose state. Best practice: store ephemeral UI state in ViewModel (user input, list scroll position), persistent data in Room or DataStore, and avoid putting large objects in savedInstanceState bundles. In Jetpack Compose, Activity is often used as a host; composables manage their own lifecycle through LaunchedEffect, DisposableEffect, and LifecycleOwner.

Model answer

MVVM (Model-View-ViewModel): ViewModel exposes state via LiveData or StateFlow; View observes and renders; user actions call ViewModel methods directly. Bidirectional data flow — View can directly call ViewModel methods. MVI (Model-View-Intent): strict unidirectional data flow; user interactions produce Intents; Reducer function maps current State + Intent → new State; View only renders State. More predictable, easier to test, better for complex screens. Differences: MVI enforces single source of truth (one immutable state object), prevents multiple subscribers from seeing inconsistent state, and makes debugging easier (replay events to reproduce bugs). MVVM is simpler for straightforward screens. In production Android (India 2026): MVVM with Kotlin StateFlow is the most common pattern; MVI is increasingly preferred for complex screens (checkout flows, form-heavy UIs). Jetpack Compose pairs naturally with both — prefer MVI for composable screens with complex state interactions.

Model answer

Coroutines are Kotlin's approach to asynchronous programming. Key concepts: CoroutineScope (defines the lifetime — viewModelScope, lifecycleScope), CoroutineContext (Dispatchers: Main for UI, IO for network/disk, Default for CPU), and suspension points (functions marked with suspend). Launch vs async: launch fires and forgets; async returns a Deferred that you await for a result. Error handling: (1) try/catch inside the coroutine: catches exceptions at the point of failure; (2) CoroutineExceptionHandler: catches uncaught exceptions in the coroutine scope (last resort); (3) SupervisorScope vs CoroutineScope: in a regular CoroutineScope, a child failure cancels all siblings; in a SupervisorScope, child failures are independent. For Android ViewModel: use viewModelScope.launch { try { /* network call */ } catch (e: Exception) { /* update error state */ } }. Structured concurrency ensures that when a scope is cancelled (e.g., ViewModel cleared), all coroutines in it are cancelled.

Model answer

Use STAR. Performance improvement examples: (1) Cold start time: measured with Android Studio Profiler and reportFullyDrawn() API; identified heavy synchronous work in Application.onCreate() — moved database initialisation to a background thread and used App Startup library for sequential initialisation; reduced cold start from 3.2s to 1.4s; (2) ANR (Application Not Responding) reduction: analysed ANR traces via Android Vitals in Play Console; found main thread blocking on SharedPreferences read; migrated to DataStore (async API) and eliminated the ANR category; (3) Memory leaks: used LeakCanary to identify Activity reference held by a static singleton; fixed with WeakReference and scope correction. Key: always tie performance work to measurable Play Store metrics (ANR rate, crash-free rate, Play Store rating) — these are the business outcomes that matter to product companies.

Model answer

Jetpack Compose is Android's declarative UI framework, replacing XML-based View inflation. Key differences: (1) Declarative vs imperative: Compose describes what the UI should look like given current state; View system requires explicit update calls (setText(), setVisibility()); (2) Composition vs inheritance: Compose uses function composition (smaller, composable UI functions); View system uses class inheritance hierarchies; (3) State-driven: Compose re-renders when state changes (using remember, mutableStateOf, StateFlow); View system requires manual view updates; (4) No XML: all UI in Kotlin code, enabling type safety, code reuse, and IDE refactoring support; (5) Performance: Compose skips re-composing unchanged parts (smart recomposition); View system redraws entire subtrees. When migrating from Views: use ComposeView to embed Compose in existing Activities/Fragments (interoperability API). In India 2026: Compose is the default for new Android development at product companies; XML is still dominant in legacy IT services codebases.

Model answer

Immediate response within the first hour: (1) Check Play Console: identify the crash by package name, exception type, and top affected devices/OS versions; (2) Check if it is a crash or ANR — different root causes; (3) Look at the crash stack trace in Crashlytics or Play Console; (4) Identify the release that caused it: which commit, which feature? (5) Decision: if crash rate is above 1.5% on a core flow, initiate an emergency rollback via Play Console's rollout management (halt the rollout percentage at current level or roll back to previous version); (6) Fix in development: reproduce locally, write a regression test, fix the root cause; (7) Re-release with the fix after testing. Communication: notify product and QA teams immediately; update status page if the app is a critical service. Prevention: add crash rate monitoring to the CI/CD pipeline — block release if Crashlytics reports above a threshold in staged rollout.