Android Developer Interview Questions India 2026: Kotlin, Jetpack Compose, and Architecture Patterns

Android lifecycle questions:

1. Activity lifecycle: - onCreate(): called when the activity is first created; initialise UI, bind views, restore saved state - onStart(): activity becomes visible to the user - onResume(): activity enters the foreground and is interactive; the best place to start animations or acquire exclusive resources (camera) - onPause(): activity loses focus (another activity in the foreground, or a dialog appears); release exclusive resources; save lightweight UI state; should execute quickly (the next activity is paused until this returns) - onStop(): activity is no longer visible; release more resources, save data to persistent storage - onDestroy(): activity is about to be destroyed; final cleanup - onSaveInstanceState(bundle): called before onStop(); save transient UI state (scroll position, text entered) to survive rotation or process death

2. Configuration changes (rotation): By default, rotating the device destroys and recreates the Activity. To survive rotation without data loss: use ViewModel (survives configuration changes because it is not destroyed with the Activity), and onSaveInstanceState for small transient values. Declare android:configChanges in the manifest to handle rotation yourself (avoid this for most cases).

3. Fragment lifecycle: Fragment lifecycle mirrors Activity but with additional phases: onCreateView() (inflate the fragment's layout), onViewCreated() (safe place to bind views and start observers), onDestroyView() (clean up view binding references to avoid memory leaks). Fragment back stack: fragments can be added to a back stack so the user can navigate back through them using the system back button.

4. Jetpack Navigation Component: Replaces manual Fragment transactions. Define a navigation graph (XML or Compose NavHost) with destinations and actions. Navigate with NavController.navigate(). Handles back stack, deep links, and argument passing between destinations in a type-safe way.

Kotlin concurrency interview questions:

1. What are Kotlin coroutines? Coroutines are Kotlin's solution for asynchronous programming. They allow you to write asynchronous code that looks and reads like synchronous code, using suspend functions and the suspend/resume mechanism under the hood. No callback hell, no RxJava complexity.

2. Key concepts: - CoroutineScope: defines the lifetime of coroutines; when the scope is cancelled, all coroutines in it are cancelled (ViewModelScope, LifecycleScope, GlobalScope) - Dispatcher: determines which thread the coroutine runs on (Dispatchers.Main: Android UI thread; Dispatchers.IO: I/O operations (network, disk); Dispatchers.Default: CPU-intensive work) - launch: starts a coroutine and returns a Job (fire and forget); does not return a result - async: starts a coroutine and returns a Deferred (like a promise); call .await() to get the result - suspend fun: a function that can be paused and resumed; can call other suspend functions

3. Kotlin Flow: Flow is a cold, asynchronous data stream built on coroutines. Unlike a single suspend function that returns one value, Flow can emit multiple values over time (like RxJava Observable but simpler). StateFlow: hot, always has a current state; used in ViewModel to expose UI state. SharedFlow: hot, can have multiple collectors; used for one-time events.

4. coroutineScope vs viewModelScope vs lifecycleScope: - viewModelScope: coroutines are cancelled when the ViewModel is cleared (activity/fragment destroyed); safe for network/database operations - lifecycleScope: coroutines are cancelled when the lifecycle owner (activity/fragment) is destroyed; for UI operations that should stop when the screen is gone - GlobalScope: not recommended; not cancelled automatically; use only for application-wide operations that should survive configuration changes

Android architecture interview questions:

1. MVVM (Model-View-ViewModel): - Model: data layer (repository, database, network API) - View: UI layer (Activity, Fragment, Composable); observes ViewModel state; sends user events to the ViewModel - ViewModel: mediator between View and Model; holds UI state; survives configuration changes; exposes data to the View via StateFlow or LiveData

2. Repository pattern: The Repository abstracts the data sources (local database, remote API) behind a single interface. The ViewModel calls the Repository; the Repository decides whether to return cached data from Room or fetch fresh data from the network. This makes the ViewModel testable (mock the repository) and decouples the data fetching strategy from the business logic.

3. Room Database: Room is Android's official ORM built on SQLite. Three components: @Entity (Kotlin data class annotating each database table), @Dao (data access object: interface with SQL queries annotated with @Query, @Insert, @Update, @Delete), and @Database (the Room database class that creates the Dao instances). Room supports: returning Flow from queries (automatically emits updates when the table changes), database migrations (for schema changes between app versions), and type converters (for storing custom types like Date or List).

4. Jetpack Compose: Compose is Android's modern declarative UI toolkit. It replaces XML layouts with Kotlin functions (@Composable). Key concepts: recomposition (Compose automatically re-executes composable functions when their state changes), remember { } (preserves state across recompositions), rememberSaveable { } (persists across configuration changes), LaunchedEffect (runs a coroutine when a composable enters composition). Compose vs XML layouts: Compose is more concise, more testable (no XML fragmentation), and enables easier animation; XML layouts have better tooling maturity and are still used in existing codebases.

Android performance and testing questions:

1. RecyclerView and performance: RecyclerView reuses (recycles) view holders instead of creating a new view for every item in a list. The ViewHolder pattern: create the ViewHolder in onCreateViewHolder(), bind data to the existing ViewHolder in onBindViewHolder(). DiffUtil: compares old and new lists and only updates changed items (instead of notifyDataSetChanged() which redraws everything). ConcatAdapter: combine multiple adapters (e.g., header + list + footer) without merging their datasets.

2. Memory leaks: Common causes in Android: holding a reference to an Activity or Fragment from a longer-lived object (static field, background thread, anonymous inner class); not removing listeners (RecyclerView adapter references, BroadcastReceiver not unregistered). Tools: LeakCanary (automatically detects and reports leaks during development). Prevention: use WeakReference for Activity/Context in background threads; use ViewModel (which outlives the Activity) for state that needs to survive configuration changes; use viewLifecycleOwner (not this) when observing LiveData/Flow in a Fragment.

3. Profiling and performance tools: Android Profiler (in Android Studio): CPU profiler (find slow methods and method traces), Memory profiler (identify memory leaks and excessive allocations), Network profiler (inspect API requests and response times). StrictMode: developer tool that detects accidental disk or network access on the UI thread and crashes the app (during development) to force you to fix it.

4. Testing: Unit tests (fast, no device required): test ViewModel, Repository, and business logic with JUnit 5 and Mockito/MockK. Instrumented tests (require a device or emulator): test UI behaviour with Espresso (XML views) or Compose UI test (Compose); test database queries with Room in-memory databases. TestCoroutineDispatcher: replace real dispatchers with test dispatchers to control coroutine execution in unit tests.