Question 1

A form screen loses user input on rotation — walk through why, and the ways to preserve it.

Accepted Answer

When the screen rotates, Android tears down the current Activity and creates a brand-new instance to apply resources for the new configuration (a different layout, drawables, etc.) — this is the default behavior of Activity/Fragment recreation on a config change. Any state held in local fields (a String in the Activity, or text sitting only in the View hierarchy without being wired into a retained state holder) disappears with the old instance, and the new one starts from onCreate with defaults, so a TextField that was populated goes blank.

The idiomatic fix is to lift the input out of the View and Activity entirely into a ViewModel. A ViewModel is kept alive across configuration changes because the framework keeps the ViewModelStore associated with the same logical Activity/Fragment across the recreation — only true process death (low memory, "don't keep activities") destroys it. So text typed into the field should update a StateFlow/LiveData in the ViewModel, and the UI just re-renders from that state after recreation.

```kotlin
class FormViewModel : ViewModel() {
    private val _name = MutableStateFlow("")
    val name: StateFlow<String> = _name
    fun onNameChanged(v: String) { _name.value = v }
}
```

For the case where the process itself is killed by the OS (not just a config change — e.g. backgrounded and reclaimed), a plain ViewModel isn't enough since the whole process, including its ViewModelStore, is gone. For that you additionally save the value into SavedStateHandle (or onSaveInstanceState for older View-based code), which is backed by a Bundle the system persists and restores even across process death.

Question 2

Design where a long-running upload should live so it survives configuration changes but cancels when the user leaves the flow.

Accepted Answer

The right home for the upload is a coroutine launched in the screen's ViewModel, using viewModelScope. viewModelScope is a CoroutineScope tied to the ViewModel's lifecycle: it survives Activity/Fragment recreation on rotation (because the ViewModel instance itself survives), but it's automatically cancelled when onCleared() runs — which happens when the user actually navigates away from that screen for good (the ViewModel is removed from the store), not on a mere rotation. Concretely: launch the upload with viewModelScope.launch(Dispatchers.IO) { repository.upload(file) }, and expose progress through a StateFlow the UI collects. Rotation destroys/recreates the Activity but not the ViewModel, so the upload job just keeps running underneath, and the new UI instance re-attaches to the same StateFlow and sees the current progress. When the user backs out of the flow entirely, the ViewModel is cleared, viewModelScope is cancelled, and any cooperative suspension point in the upload code throws CancellationException, stopping the network call. ```kotlin class UploadViewModel(private val repo: UploadRepository) : ViewModel() { private val _state = MutableStateFlow(UploadState.Idle) val state: StateFlow = _state fun start(file: File) = viewModelScope.launch { _state.value = UploadState.InProgress(0) repo.upload(file) { pct -> _state.value = UploadState.InProgress(pct) } _state.value = UploadState.Done } } ``` Anchoring it lower (Activity scope) would cancel on every rotation; anchoring it higher (Application scope, or a foreground Service) would make it survive leaving the screen entirely, which is wrong here since the requirement is explicitly cancel-on-leave. If the upload instead needed to survive the whole app being backgrounded/killed, that's the signal to move it to WorkManager or a foreground Service instead — a ViewModel is right only while it's still tied to a live screen.

Question 3

Fetch three independent APIs in parallel and combine results, cancelling all if any fails.

Accepted Answer

Use coroutineScope { } combined with async for each call. coroutineScope is a structured-concurrency builder: it only returns once all its child coroutines complete, and critically, if any child throws, the scope cancels every other child automatically and rethrows — exactly the "cancel all if any fails" behavior, with no manual bookkeeping needed.

```kotlin
suspend fun loadDashboard(): Dashboard = coroutineScope {
    val userDeferred = async { api.getUser() }
    val postsDeferred = async { api.getPosts() }
    val statsDeferred = async { api.getStats() }
    Dashboard(userDeferred.await(), postsDeferred.await(), statsDeferred.await())
}
```

All three async calls start concurrently. Calling .await() on each suspends until that particular result is ready, but if getPosts() throws, coroutineScope propagates that failure by cancelling the sibling userDeferred and statsDeferred jobs before the exception surfaces to the caller of loadDashboard(). This is different from just launching three independent coroutines with viewModelScope.launch each — those aren't linked, so one failing wouldn't cancel the others. The key thing to get right: don't use supervisorScope here, because a SupervisorJob/supervisorScope deliberately isolates failures instead of propagating them — that's the tool for "let each fail independently," not "cancel everything together."

Question 4

A list screen janks while parsing a large JSON — restructure the work with proper dispatchers.

Accepted Answer

If JSON parsing runs on the main thread (e.g., inside a coroutine on Dispatchers.Main, or synchronously in a callback), it blocks the UI thread doing CPU work, so the frame renderer can't hit its budget and the list stutters. The fix is "main safety": keep coroutines that touch Views on Dispatchers.Main, but push the actual parsing to Dispatchers.Default (CPU-bound work) or Dispatchers.IO if it's blocking I/O, and only hop back to Main to update the UI with the result.

```kotlin
viewModelScope.launch {
    val items = withContext(Dispatchers.Default) {
        // CPU-heavy JSON parsing off the main thread
        jsonParser.parseLargeList(rawJson)
    }
    _uiState.value = UiState.Loaded(items) // back on Main automatically
}
```

withContext suspends the calling coroutine, runs the block on the given dispatcher's thread pool, and resumes back on the original dispatcher (Main here) once done — no manual runOnUiThread/handler-posting needed. A well-designed repository function should ideally already be "main-safe" internally (wrap its own blocking work in withContext(Dispatchers.IO)), so any caller, regardless of which dispatcher it's on, never accidentally blocks that caller's thread — this is standard Android guidance for repository/data-layer functions.

Question 5

A Composable list recomposes every item on each scroll — identify likely causes and fixes.

Accepted Answer

The usual culprits are: passing unstable parameter types into item composables (a plain List<T> or a mutable class without @Stable/@Immutable is treated as "unstable" by the Compose compiler, so it can't skip recomposition even if the value didn't actually change); not providing stable keys to LazyColumn's items(), so Compose can't tell which item is which across recomposition and re-binds everything; reading a frequently-changing state (like scroll position) inside the item content itself, forcing every item reading it to recompose on every scroll tick; and creating new lambda/object instances on every parent recomposition passed down as parameters, defeating skipping.

Fixes: mark data classes used as item state @Immutable or make them genuinely immutable, always pass a stable key to items(), and don't read hot state like listState.firstVisibleItemIndex inside each item's composable — hoist that read to the parent.

```kotlin
LazyColumn {
    items(items = messages, key = { it.id }) { message ->
        MessageRow(message) // MessageRow's params should be stable
    }
}
```

Enabling the Compose compiler's recomposition report (or the layout inspector's recomposition counts) is the fastest way to confirm which composable is recomposing unnecessarily rather than guessing.

Question 6

Update a large list efficiently when only a few items change.

Accepted Answer

Instead of calling notifyDataSetChanged() — which throws away all existing ViewHolders' knowledge of what changed and forces RecyclerView to rebind and re-render every visible row — you compute the difference between the old and new list with DiffUtil and dispatch only the specific inserts/removals/moves/changes. DiffUtil.Callback (or the simpler ListAdapter base class, which wraps this for you) compares two lists using areItemsTheSame() (identity, usually by ID) and areContentsTheSame() (equality of the displayed content). It computes the minimal set of operations, and RecyclerView only rebinds/animates the rows that actually changed. ```kotlin class MessageDiffCallback( private val old: List, private val new: List ) : DiffUtil.Callback() { override fun getOldListSize() = old.size override fun getNewListSize() = new.size override fun areItemsTheSame(oldPos: Int, newPos: Int) = old[oldPos].id == new[newPos].id override fun areContentsTheSame(oldPos: Int, newPos: Int) = old[oldPos] == new[newPos] } // adapter.submitList(newList) if using ListAdapter — diffing happens on a background thread automatically ``` Using ListAdapter is preferred over hand-rolling DiffUtil because it already runs the diff on a background executor and dispatches results back to the main thread, so a very large list doesn't jank the UI while diffing.

Question 7

Add a non-null column to a shipped Room table without losing user data.

Accepted Answer

You can't just add a NOT NULL column with no default to a table that already has rows — SQLite (and Room's schema validation) will reject that for existing installs, since existing rows have no value to put there. The correct approach is a Room Migration that runs raw SQL to add the column with a DEFAULT value, so existing rows are backfilled automatically at migration time.

```kotlin
val MIGRATION_1_2 = object : Migration(1, 2) {
    override fun migrate(db: SupportSQLiteDatabase) {
        db.execSQL("ALTER TABLE users ADD COLUMN isVerified INTEGER NOT NULL DEFAULT 0")
    }
}

Room.databaseBuilder(context, AppDatabase::class.java, "app.db")
    .addMigrations(MIGRATION_1_2)
    .build()
```

You also bump @Database(version = 2) and update the entity's Kotlin data class to include the new field with a default value matching the migration's default, so fresh installs and migrated ones end up with the same schema. Room validates the actual schema against entity definitions at runtime and throws if they don't match, so it's worth exporting the schema and writing a MigrationTestHelper test that migrates a real pre-populated v1 database to v2 and asserts the data survived. fallbackToDestructiveMigration() is the "delete and recreate" escape hatch, which is the wrong answer here since the whole point is not losing data.

Question 8

Design offline-first note editing where the same note may be edited on two devices.

Accepted Answer

The core idea: the local Room database is the single source of truth the UI always reads from, writes go to Room immediately (so editing feels instant and works offline), and a sync layer (WorkManager-driven) reconciles local changes with the server in the background, including when the server's copy changed too. Each note needs a version marker to detect conflicts — a monotonically increasing version integer, an updatedAt timestamp, or a server-issued ETag/token returned on the last successful sync.

When syncing, the client sends its local version alongside the edit. If the server's current version doesn't match what the client last saw, that's a genuine conflict, and the server should reject the naive overwrite rather than silently accepting whichever write arrives last (last-write-wins is simplest but silently discards a user's edits). A more respectful approach is a three-way merge for structured fields, or, when content is free-text, surfacing both versions to the user to pick/merge — the "conflict copy" pattern apps like Dropbox use, keeping both as separate items rather than losing one.

Practically: mark each local edit with a dirty/pendingSync flag and a local lastModified timestamp, enqueue a WorkManager OneTimeWorkRequest with a network constraint to push dirty rows, and on conflict either apply a merge strategy or write a local note_conflicts row the UI surfaces next time the user opens that note. This keeps the app fully usable offline, and treats "two devices edited it" as an expected case to handle explicitly, not an edge case to paper over.

Question 9

Explain the Activity lifecycle methods and when each is called.

Accepted Answer

The core callbacks are onCreate() → onStart() → onResume() → [running/visible/interactive] → onPause() → onStop() → onDestroy(), with onRestart() called when coming back from a stopped state before onStart() runs again. onCreate() runs once per instance and is where you inflate the layout and do one-time setup (view binding, ViewModel creation). onStart() means the Activity is becoming visible but not yet interactive; onResume() means it's now in the foreground receiving input — a good place to start a camera preview or resume animations. onPause() fires when the Activity is losing focus but might still be partially visible (a dialog appears, or multi-window split), so it should be quick — release resources like the camera that shouldn't be held while not fully in the foreground. onStop() runs when no longer visible at all, good for unregistering expensive listeners. onDestroy() is final cleanup, either because the Activity finished or the system is reclaiming the process.

Example: for a screen with a camera preview, start the camera in onResume() and stop it in onPause() (not onStop()), because on some devices multiple apps can be partially visible (split-screen), and holding the camera while not interactive can crash or block another app. Getting this pairing right (onCreate/onDestroy, onStart/onStop, onResume/onPause as symmetric bookends) is the most common lifecycle interview follow-up.

Question 10

What is the difference between a Fragment and an Activity?

Accepted Answer

An Activity is a top-level Android app component registered in the manifest, representing one screen with its own window and task-stack entry — the OS starts/stops Activities via Intents. A Fragment is not a standalone component — it has no manifest entry and can't exist without being hosted inside an Activity (or another Fragment) via a FragmentManager; it represents a reusable portion of UI and behavior that can be swapped in and out of a host's layout.

Fragments exist mainly for two problems: building flexible/adaptive layouts (showing a list Fragment and a detail Fragment side-by-side on tablets but as two full-screen swaps on phones, reusing the same Fragment classes), and modular, reusable pieces of UI+logic (a "comment section" Fragment reused across screens) without duplicating an Activity per usage.

Fragments have their own extended lifecycle nested inside the host Activity's (onAttach, onCreateView, onViewCreated, onDestroyView, onDetach), since a Fragment's view can be destroyed and recreated independently of the Fragment instance (e.g. when placed on the back stack). In modern single-Activity architecture with Jetpack Navigation, most screens are Fragments (or Compose destinations) hosted inside one Activity, with the Activity mainly providing the window/container.

Question 11

What are Intents, and what's the difference between explicit and implicit Intents?

Accepted Answer

An Intent is a messaging object used to request an action from another component — starting an Activity, starting a Service, or delivering a broadcast. An explicit Intent names the exact target component by class (Intent(this, DetailActivity::class.java)), used when you know exactly which component in your own app should handle it. An implicit Intent declares an action and data/category without naming a component, and the system resolves it at runtime to whichever installed app(s) declared a matching intent-filter, launching the sole match or showing a chooser if multiple qualify.

```kotlin
// Explicit: launch a known Activity in your own app
startActivity(Intent(this, DetailActivity::class.java).putExtra("id", itemId))

// Implicit: ask the system to open a URL, letting any browser handle it
startActivity(Intent(Intent.ACTION_VIEW, Uri.parse("https://example.com")))
```

Implicit intents are how apps interoperate without knowing about each other in advance — e.g. a "Share" button uses Intent.ACTION_SEND and the system shows every app registered as a share target. Always guard implicit intents with resolveActivity() or a try/catch for ActivityNotFoundException, since with package visibility restrictions there might be no app installed to handle it.

Question 12

What is a Service in Android, and what's the difference between a started service and a bound service?

Accepted Answer

A Service is a component for running work without a UI, independent of any particular Activity. A started service is launched with startService()/startForegroundService() and runs until it stops itself (stopSelf()) or is stopped externally — fire-and-forget from the caller's perspective, good for a one-off download or music playback that outlives the launching screen. A bound service is obtained via bindService(), which returns an IBinder the client uses to call methods directly on the service (client-server relationship) — the service lives as long as at least one client is bound, and is torn down when the last client unbinds. A service can be both at once.

```kotlin
class MusicService : Service() {
    private val binder = LocalBinder()
    inner class LocalBinder : Binder() { fun getService() = this@MusicService }
    override fun onBind(intent: Intent) = binder
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        player.play()
        return START_STICKY
    }
}
```

Since Android 8 (Oreo), a service doing real background work while the app isn't foreground generally needs to be a foreground service with a persistent notification (or use WorkManager instead) — plain background services get stopped after a short window to save battery.

Question 13

What is a BroadcastReceiver and what are its use cases?

Accepted Answer

A BroadcastReceiver lets a component respond to system-wide or app-wide broadcast messages — events like device boot completed, battery level changing, connectivity changing, or a custom broadcast one part of an app sends to another. It's registered either statically in the manifest (for the handful of system broadcasts still allowed to wake a stopped app) or dynamically at runtime via registerReceiver(), tied to a Context's lifecycle.

```kotlin
val receiver = object : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == ConnectivityManager.CONNECTIVITY_ACTION) {
            viewModel.onConnectivityChanged(isOnline())
        }
    }
}
registerReceiver(receiver, IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION))
```

Since Android 8, most implicit broadcasts can no longer be declared in the manifest to auto-launch an app in the background (to prevent every app waking on every system event) — apps register dynamically while running, or use JobScheduler/WorkManager with the equivalent constraint instead of listening for a raw broadcast. LocalBroadcastManager for in-app-only messages is now deprecated in favor of a Flow/LiveData-based observer, since it added indirection an in-process pattern doesn't need.

Question 14

What is a ContentProvider used for?

Accepted Answer

A ContentProvider is Android's mechanism for sharing structured data between apps behind a stable, permission-controlled interface — it exposes a CRUD API (query, insert, update, delete) addressed by content:// URIs rather than exposing your database file directly. The classic example is the system Contacts provider: any app with the right permission can query it without knowing or caring it's backed by SQLite internally, and Android enforces permission checks per-provider so apps can't just read each other's private files.

```kotlin
val cursor = contentResolver.query(
    ContactsContract.CommonDataKinds.Phone.CONTENT_URI,
    arrayOf(ContactsContract.CommonDataKinds.Phone.NUMBER),
    null, null, null
)
```

Within a single app that doesn't need to share data with other apps, you generally don't need a ContentProvider — Room/SQLite via a repository is simpler and is the modern default. ContentProviders are still required for specific system integration points: exposing files to other apps safely via FileProvider, implementing a custom sync adapter, or when your app itself needs to expose structured data to other apps.

Question 15

Explain WorkManager and when you'd use it over other background APIs.

Accepted Answer

WorkManager is the recommended API for deferrable, guaranteed background work — tasks that should run even if the app is closed or the device restarts, like uploading analytics or syncing data periodically. It sits on top of JobScheduler, AlarmManager, and a Room-backed database depending on API level and constraints, and persists the work request so it survives process death and reboot.

```kotlin
val uploadWork = OneTimeWorkRequestBuilder<UploadWorker>()
    .setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build())
    .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 10, TimeUnit.SECONDS)
    .build()
WorkManager.getInstance(context).enqueue(uploadWork)
```

Reach for WorkManager instead of a plain ViewModel job when the task must survive the app being fully closed and needs constraints (network available, charging, storage not low) plus automatic retry/backoff. Reach for it instead of a foreground Service when the work doesn't need to be immediate/user-visible right now — WorkManager can legitimately defer execution for battery efficiency, whereas a foreground service runs immediately with a visible notification. For work that must start instantly and stay running with the user aware of it (an active call), a foreground service is still right, not WorkManager.

Question 16

What is Dependency Injection and how does Hilt simplify it in Android?

Accepted Answer

Dependency Injection means a class receives its dependencies (a repository, a network client) from the outside rather than constructing them itself — this makes classes easier to test (swap in a fake) and decouples them from concrete implementations. Doing this by hand in Android is painful because dependencies need Android-lifecycle-aware scoping (one Retrofit client for the whole app, one repository per screen) and Activities/Fragments are instantiated by the OS, so you can't just pass constructor args into them.

Hilt (built on Dagger) solves this by generating the wiring code at compile time and providing scoped containers tied to Android lifecycles out of the box (@Singleton app-wide, @ActivityRetainedScoped for ViewModel-lifetime, etc.), plus first-class ViewModel injection via @HiltViewModel.

```kotlin
@Module @InstallIn(SingletonComponent::class)
object NetworkModule {
    @Provides @Singleton
    fun provideApi(): ApiService = Retrofit.Builder()
        .baseUrl(BASE_URL).build().create(ApiService::class.java)
}

@HiltViewModel
class HomeViewModel @Inject constructor(private val api: ApiService) : ViewModel()
```

Compared to hand-rolled Dagger, Hilt trades a little flexibility for far less boilerplate — for a small app, manual constructor injection (just passing dependencies through constructors yourself) is often enough, and reaching for Hilt is justified once there are enough screens/scopes that wiring becomes repetitive.

Question 17

What's the difference between LiveData and StateFlow?

Accepted Answer

Both are observable holders of a current value, but they come from different worlds: LiveData is an Android-specific, lifecycle-aware type (automatically stops delivering updates to a destroyed Activity/Fragment), while StateFlow is a plain Kotlin coroutines Flow type with no Android dependency — usable in any Kotlin codebase, not lifecycle-aware by itself, needing repeatOnLifecycle/collectAsStateWithLifecycle in the UI to get the same "stop collecting when not visible" behavior LiveData gives for free. StateFlow always has a current value (like LiveData) and only emits distinct consecutive values, whereas a Flow/SharedFlow can represent a stream of events with no inherent "current value." Because StateFlow is part of the Flow ecosystem, it composes naturally with operators like map, combine, debounce — LiveData's transformation API (Transformations.map/switchMap) is much thinner. ```kotlin class SearchViewModel : ViewModel() { private val _query = MutableStateFlow("") val results: StateFlow> = _query .debounce(300) .flatMapLatest { repo.search(it) } .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), emptyList()) } ``` Current guidance is to prefer StateFlow for new Kotlin-first (especially Compose/multiplatform-leaning) code and keep LiveData mainly for legacy View-based code or Java interop.

Question 18

What causes memory leaks in Android, and how do you detect and fix them?

Accepted Answer

The most common pattern is a long-lived object holding a reference to something that should be short-lived — a static field or singleton holding an Activity/View reference, or an inner (non-static) class/anonymous listener implicitly holding an outer Activity reference, registered with something that outlives the Activity and never unregistered. Because the Activity can't be garbage collected while referenced, every rotation leaks a whole Activity + View tree, eventually causing an OutOfMemoryError.

```kotlin
// Leak: anonymous listener implicitly holds `this` (the Activity)
class MyActivity : AppCompatActivity() {
    override fun onCreate(b: Bundle?) {
        EventBus.getDefault().register(this)
    }
    // if onDestroy() forgets unregister(this), Activity leaks forever
}
```

Detection: LeakCanary is the standard tool — it hooks into object destruction (e.g. Fragment.onDestroy) and, if the object isn't garbage collected shortly after, dumps the heap and walks the reference graph to show the exact chain keeping it alive. Android Studio's Memory Profiler is the manual alternative — force a GC, take a heap dump, and search for instances that shouldn't still exist.

Fixes generally mean not holding the long-lived reference at all, or always symmetrically unregistering in the matching lifecycle callback (register in onStart / unregister in onStop, not just registering with nothing undoing it).

Question 19

What is an ANR and how do you prevent it?

Accepted Answer

An ANR ("Application Not Responding") triggers when the main thread is blocked long enough that the system considers the app unresponsive — roughly 5 seconds for input dispatch, or a shorter window for a BroadcastReceiver's onReceive. The user sees a dialog offering to wait or force-close, and it's a tracked quality metric (Android Vitals surfaces ANR rate in the Play Console).

The main thread also drives UI rendering, so any blocking call there — a synchronous network request, a heavy database query, a large synchronous JSON parse, or contended synchronization — can trigger it. Prevention is: never do I/O or heavy CPU work on the main thread; move it to a coroutine on Dispatchers.IO/Dispatchers.Default.

```kotlin
// Wrong: runs a network call on the main thread
button.setOnClickListener { val data = api.fetchSync() }  // can ANR

// Right
button.setOnClickListener {
    lifecycleScope.launch { val data = withContext(Dispatchers.IO) { api.fetchSync() } }
}
```

StrictMode (enabled in debug builds) helps catch this during development by flagging disk/network access on the main thread with a log warning or crash, before it reaches a real user as an ANR.

Question 20

Explain the Handler and Looper mechanism in Android.

Accepted Answer

Every thread that wants to process a queue of tasks needs a Looper — an object that runs a loop pulling Messages off a MessageQueue and dispatching them. The main thread already has one set up automatically (Looper.getMainLooper()); other threads don't have one unless you call Looper.prepare()/Looper.loop() yourself (HandlerThread wraps that boilerplate). A Handler is bound to a specific Looper and is how you enqueue work onto that Looper's queue — handler.post { ... } or sendMessage(...).

The classic use is posting work back to the main thread from a background thread: a worker finishes, then calls mainHandler.post { textView.text = result } to safely update a View, since Views can only be touched on the thread that created them.

```kotlin
val mainHandler = Handler(Looper.getMainLooper())
Thread {
    val result = doHeavyWork()
    mainHandler.post { textView.text = result }
}.start()
```

In modern code, coroutines with Dispatchers.Main/withContext have largely replaced hand-written Handler/Looper code for this pattern, but the underlying mechanism is the same — Dispatchers.Main is itself implemented using a Handler bound to the main Looper.

Question 21

How does Retrofit work under the hood?

Accepted Answer

Retrofit turns a Kotlin/Java interface with annotated methods into a working HTTP client at runtime using dynamic proxies (or generated call adapters for suspend functions) — you declare the shape of the API, and Retrofit generates the implementation that builds the actual HTTP request, executes it via the underlying OkHttp client, and converts the response body into your model objects via a Converter.Factory (Gson or Moshi for JSON).

```kotlin
interface ApiService {
    @GET("users/{id}")
    suspend fun getUser(@Path("id") id: String): User
}

val api = Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .client(okHttpClient)
    .addConverterFactory(MoshiConverterFactory.create())
    .build()
    .create(ApiService::class.java)
```

Calling api.getUser("42") builds a request to the right URL, hands it to OkHttp (which handles connection pooling, interceptors for logging/auth, caching, retries), and on response, the converter factory deserializes the JSON body into a User object. Retrofit's suspend fun support wraps the OkHttp callback in a coroutine continuation so the call suspends without blocking a thread while waiting for the network — this is why Retrofit + coroutines is the standard combo over the older callback-based Call<T> API.

Question 22

Explain the MVVM architecture pattern in Android.

Accepted Answer

MVVM splits a screen into three layers: the View (Activity/Fragment/Composable), which only renders state and forwards user actions; the ViewModel, which holds UI state and business logic for that screen and exposes it as observable state (LiveData/StateFlow) with no reference back to the View; and the Model (repository/data layer) the ViewModel talks to for data. The View observes the ViewModel's state and re-renders on change; it never synchronously asks the ViewModel to do something and get a return value — it triggers an action, and the ViewModel updates its exposed state. ```kotlin class ProfileViewModel(private val repo: UserRepository) : ViewModel() { private val _uiState = MutableStateFlow(ProfileUiState.Loading) val uiState: StateFlow = _uiState fun load(userId: String) = viewModelScope.launch { _uiState.value = ProfileUiState.Loading _uiState.value = ProfileUiState.Loaded(repo.getUser(userId)) } } ``` The key benefit is testability and lifecycle safety: the ViewModel has no Android View references, so it can be unit-tested with plain JVM tests (no emulator needed for the logic), and because it doesn't hold a View reference, it naturally avoids the View-leak problems a more tightly coupled pattern (like a raw MVP presenter holding an Activity reference) can fall into.

Question 23

What's the difference between MVVM and MVI?

Accepted Answer

MVVM typically exposes multiple independent observable properties from the ViewModel (a separate StateFlow for loading, one for data, one for an error), and the View reacts to each independently — flexible, but can let the UI end up in an "impossible" combination of states if you're not careful (e.g. loading=true and data already shown and an error, all at once).

MVI ("Model-View-Intent") models the entire screen as one single, immutable state object (a sealed class with distinct cases like Loading, Success(data), Error(message)), so the View can only ever be in exactly one defined state — impossible combinations become unrepresentable at the type level. User actions are modeled as explicit "intents" (sealed events) the ViewModel reduces into a new state, giving unidirectional data flow: Intent → reducer → new State → View.

```kotlin
sealed interface ProfileState {
    object Loading : ProfileState
    data class Loaded(val user: User) : ProfileState
    data class Error(val message: String) : ProfileState
}
sealed interface ProfileIntent {
    data class Load(val userId: String) : ProfileIntent
}
```

MVI is more rigid and adds more boilerplate but scales better on complex screens, since the compiler forces exhaustive handling of every case (a when without else fails to compile if a case is missing). Plain MVVM with several independent flows is usually the more pragmatic choice for simpler screens.

Question 24

How do you write a unit test for a ViewModel using a mocking library like Mockito?

Accepted Answer

Testing a ViewModel in isolation means faking its dependencies so the test only exercises the class under test's own logic, not real network/database code. Mockito creates a fake implementation of an interface at runtime that you can program to return specific values and later verify was called with expected arguments.

```kotlin
@Test
fun `loading user updates state to Loaded`() = runTest {
    val repo = mock<UserRepository>()
    whenever(repo.getUser("42")).thenReturn(User("42", "Alice"))
    val viewModel = ProfileViewModel(repo)

viewModel.load("42")

assertEquals(ProfileUiState.Loaded(User("42", "Alice")), viewModel.uiState.value)
    verify(repo).getUser("42")
}
```

runTest (from kotlinx-coroutines-test) runs the coroutine body on a controlled test dispatcher that auto-advances virtual time, so viewModelScope.launch coroutines complete synchronously within the test instead of needing real delays. For Android-framework-dependent classes (things touching a real Context or View), plain Mockito + JVM unit tests aren't enough — that's where Robolectric or an instrumented Espresso test on a device/emulator comes in instead.

Question 25

What is ProGuard/R8 and why is it used?

Accepted Answer

R8 (which replaced ProGuard as Android's default code shrinker/obfuscator/optimizer, though it still uses ProGuard-style rule files) runs at build time on a release build to shrink the APK by removing unused classes/methods/fields, obfuscate remaining code by renaming classes/methods to short meaningless names (harder to reverse-engineer, smaller string table), and optimize bytecode (inlining, dead-branch removal).

The danger is that R8's reachability analysis is static — it can't see code accessed only via reflection (some JSON libraries deserializing into a POJO by field name, or classes referenced only from XML) and will strip it, causing a runtime exception that only shows up in release builds, not debug. The fix is -keep rules.

```
# proguard-rules.pro
-keep class com.example.app.model.** { *; }
-keepattributes Signature, *Annotation*
```

Most popular libraries ship their own consumer ProGuard rules bundled in their AAR, so you don't need to hand-write rules for them — but any custom data class deserialized reflectively without codegen, or accessed via reflection in your own code, needs an explicit keep rule. This is exactly the kind of bug that only reproduces in a release/R8-minified build, which is why testing an actual release build before shipping matters.

Question 26

What is the Jetpack Navigation component and how does it simplify navigation?

Accepted Answer

The Navigation component replaces manually managing a FragmentTransaction back stack (or a stack of Composable screens) with a declarative navigation graph — a resource describing every destination and possible actions between them, plus a NavController that executes navigation, manages the back stack, and handles the system back button automatically.

```kotlin
NavHost(navController, startDestination = "home") {
    composable("home") { HomeScreen(onItemClick = { id -> navController.navigate("detail/$id") }) }
    composable("detail/{id}", arguments = listOf(navArgument("id") { type = NavType.StringType })) { entry ->
        DetailScreen(id = entry.arguments?.getString("id")!!)
    }
}
```

Its main benefits over hand-rolled fragment transactions: type-safe argument passing, automatic and consistent back-stack/up-button behavior, built-in deep-link support (a URI can map directly to a graph destination), and a visual graph editor in Android Studio for the XML flavor. It also integrates with ViewModel scoping so a ViewModel can be scoped to a navigation graph/flow rather than just one Fragment.

Question 27

How do you request runtime permissions in Android?

Accepted Answer

Since Android 6.0 (API 23), "dangerous" permissions (camera, location, contacts) must be requested at runtime, not just declared in the manifest, since a user can grant or revoke them at any time even after granting once. The flow: check if already granted with ContextCompat.checkSelfPermission(), and if not, launch a request and handle the callback.

```kotlin
val requestPermission = registerForActivityResult(
    ActivityResultContracts.RequestPermission()
) { granted ->
    if (granted) startCamera() else showRationale()
}

if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
        != PackageManager.PERMISSION_GRANTED) {
    requestPermission.launch(Manifest.permission.CAMERA)
} else {
    startCamera()
}
```

registerForActivityResult with RequestPermission() is the modern API, replacing the older onRequestPermissionsResult override, since it avoids a manually-managed request code and ties the callback cleanly to the Activity/Fragment's lifecycle. If the user denied before, shouldShowRequestPermissionRationale() tells you whether to explain before re-asking versus the user having permanently denied it, in which case you should direct them to app settings instead of re-prompting.

Question 28

What's the difference between an APK and an AAB (Android App Bundle)?

Accepted Answer

An APK is the actual installable package format — a single file containing compiled code, resources for every supported device configuration (every density, CPU architecture, language), and the manifest, signed and ready to install. An AAB is not directly installable; it's a publishing format uploaded to the Play Console, which uses "dynamic delivery" to generate and serve a much smaller, device-specific APK to each user — someone with an arm64 phone at xxhdpi gets only the resources/native libraries relevant to their device.

The practical benefit is app size: bundling every density and every native ABI into one universal APK used to bloat downloads significantly; AAB + Play's dynamic delivery routinely cuts real download size for end users substantially. AABs also enable Play Feature Delivery — splitting optional features (e.g. an AR mode used by few users) into on-demand modules downloaded only when the user opens that feature, rather than shipping it to everyone upfront.

Since 2021, Google Play has required new apps to publish as AAB rather than a universal APK.

Question 29

How do image loading libraries like Glide or Coil handle loading and caching?

Accepted Answer

Both Glide and Coil (Coil being the more modern, coroutines-first choice, natural in Compose via AsyncImage) solve the same problem: loading an image from a URL/resource, resizing/transforming it to fit the target without wasting memory on a full-resolution decode, and caching the result at two layers — an in-memory LRU cache (fast redisplay of a recently-shown image, e.g. scrolling back up) and a disk cache (avoids re-download on next launch).

```kotlin
// Coil in Compose
AsyncImage(
    model = ImageRequest.Builder(context)
        .data(user.avatarUrl)
        .crossfade(true)
        .build(),
    contentDescription = "Avatar"
)
```

Both libraries tie the load to the lifecycle of the target so an in-flight load is cancelled if the View/Composable is detached before it finishes — this matters a lot in a RecyclerView, where without this a fast-scrolling list could load images into ViewHolders that have already been recycled and reassigned to a different item, briefly showing the wrong picture (a classic bug if you roll naive image loading yourself instead of using a library that handles this).

Question 30

How do custom Views participate in onMeasure and onDraw?

Accepted Answer

A custom View subclass participates in the standard measure/layout/draw pipeline by overriding onMeasure() to tell its parent how big it wants to be, and onDraw() to render its content with a Canvas. onMeasure() receives widthMeasureSpec/heightMeasureSpec — each encoding a size and a mode (EXACTLY, AT_MOST, UNSPECIFIED) set by the parent based on the View's layout params — and must call setMeasuredDimension() with the final chosen size.

```kotlin
class RingProgressView(context: Context) : View(context) {
    private val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply { style = Paint.Style.STROKE; strokeWidth = 12f }
    var progress = 0f
        set(v) { field = v; invalidate() }

override fun onMeasure(widthSpec: Int, heightSpec: Int) {
        val size = resolveSize(200, widthSpec)
        setMeasuredDimension(size, size)
    }
    override fun onDraw(canvas: Canvas) {
        canvas.drawArc(RectF(10f, 10f, width - 10f, height - 10f), -90f, 360 * progress, false, paint)
    }
}
```

Calling invalidate() schedules a redraw when visual state changes, while requestLayout() is needed instead when the View's size itself needs recalculating. A common mistake is calling requestLayout() unnecessarily (a full measure+layout pass) when only invalidate() was needed, wasting CPU on every update of a fast-changing value like an animated progress indicator.

Question 31

What's the difference between the Property Animator system and the older View Animation system?

Accepted Answer

The old View Animation system (Animation/AnimationSet, XML under res/anim/) only animates how a View is drawn — it changes the visual position/scale/rotation on screen during the animation but doesn't update the View's real properties, so fading out a Button with View Animation still leaves it fully clickable in its original spot underneath the faded pixels unless separately disabled. It's also limited to a fixed set of transformations and can't animate custom properties.

The Property Animator system (ObjectAnimator, ValueAnimator) instead animates the actual property value on the object via its getter/setter (View.setAlpha(), View.setTranslationX(), or any custom property with matching accessors), so the object's real state genuinely changes over time.

```kotlin
ObjectAnimator.ofFloat(view, View.ALPHA, 1f, 0f).apply {
    duration = 300
    start()
}
```

Property Animator is the modern, recommended approach for anything beyond trivial view-only transitions, and it's also conceptually what underlies Jetpack Compose's own animate*AsState/Animatable APIs — interpolating a real value over time rather than faking a visual.

Question 32

What's the difference between Jetpack DataStore and SharedPreferences?

Accepted Answer

SharedPreferences reads/writes a single XML file, has no type safety for structured data (only primitives/String sets), and its getX() calls can silently block on I/O the first time the file loads — a real ANR risk if called from the main thread. Its API also gives minimal error handling, with no clean signal if a write failed. Jetpack DataStore fixes this: Preferences DataStore gives the same key-value model but backed by coroutines/Flow (dataStore.data: Flow), so reads are observed reactively and writes are suspend functions guaranteed to complete or throw, with no synchronous main-thread blocking. Proto DataStore goes further, storing fully typed, schema-defined objects (via protobuf), catching type mistakes at compile time instead of a runtime ClassCastException. ```kotlin val Context.dataStore by preferencesDataStore(name = "settings") val DARK_MODE = booleanPreferencesKey("dark_mode") suspend fun setDarkMode(context: Context, enabled: Boolean) { context.dataStore.edit { it[DARK_MODE] = enabled } } val darkModeFlow: Flow = context.dataStore.data.map { it[DARK_MODE] ?: false } ``` Google's current guidance is to migrate away from SharedPreferences to DataStore for new code, with a provided migration helper to move existing data automatically.

Question 33

What is the Paging3 library and why would you use it for a large list?

Accepted Answer

Loading a very large list (thousands of DB rows, or an endless server-paginated feed) entirely into memory at once wastes memory and slows the initial load; Paging3 loads and displays data incrementally, a page at a time, fetching the next page automatically as the user scrolls near the end of what's loaded, keeping memory bounded to a window of pages around the currently visible position. ```kotlin class ArticlePagingSource(private val api: ApiService) : PagingSource() { override suspend fun load(params: LoadParams): LoadResult { val page = params.key ?: 1 return try { val response = api.getArticles(page, params.loadSize) LoadResult.Page(response.items, prevKey = if (page == 1) null else page - 1, nextKey = if (response.items.isEmpty()) null else page + 1) } catch (e: Exception) { LoadResult.Error(e) } } override fun getRefreshKey(state: PagingState) = state.anchorPosition } val pager = Pager(PagingConfig(pageSize = 20)) { ArticlePagingSource(api) } val flow: Flow> = pager.flow.cachedIn(viewModelScope) ``` On the UI side, PagingDataAdapter (RecyclerView) or LazyPagingItems (Compose) consumes the Flow>, triggering load() calls as needed and exposing LoadState for loading/error footers. Paging3 also composes with Room directly, and RemoteMediator layers on top to combine a local Room cache with remote paging for a true offline-first paginated feed.

Question 34

Explain state hoisting in Jetpack Compose.

Accepted Answer

State hoisting means a Composable doesn't own/mutate its own state internally; instead it receives the current value as a parameter and reports change requests upward via a callback (typically onValueChange), and the actual mutableStateOf lives higher up — in a parent Composable or a ViewModel. This makes the Composable stateless and reusable in different contexts, and it's what allows a single source of truth instead of the same value being duplicated and drifting out of sync in multiple places.

```kotlin
@Composable
fun SearchField(query: String, onQueryChange: (String) -> Unit) {
    TextField(value = query, onValueChange = onQueryChange)
}

@Composable
fun SearchScreen(viewModel: SearchViewModel) {
    val query by viewModel.query.collectAsStateWithLifecycle()
    SearchField(query = query, onQueryChange = viewModel::onQueryChanged)
}
```

The alternative — a Composable holding its own local var text by remember internally — works fine for genuinely local, throwaway UI state that no other part of the screen needs, but breaks down the moment something else (a ViewModel validating input, a sibling Composable, a "clear all fields" button) needs to read or drive that value. The general rule taught in Compose docs is: hoist state to the lowest common ancestor that needs to read or write it, no higher.

Question 35

What is SavedStateHandle and how is it used with a ViewModel?

Accepted Answer

SavedStateHandle is a key-value object automatically injected into a ViewModel (via its constructor, when created through the standard ViewModelProvider/Hilt's @HiltViewModel) backed by the same saved-instance-state Bundle mechanism Views use, meaning values stored in it survive not just configuration changes but also process death — the OS killing your app's process while backgrounded and later recreating it when the user returns.

```kotlin
class SearchViewModel(private val savedStateHandle: SavedStateHandle) : ViewModel() {
    val query: StateFlow<String> = savedStateHandle.getStateFlow("query", "")
    fun onQueryChanged(newQuery: String) {
        savedStateHandle["query"] = newQuery
    }
}
```

A plain ViewModel field would be lost entirely on process death (the whole process, ViewModelStore included, is gone), so the user would return to find their search box empty even though the system "restored" the screen. SavedStateHandle is specifically for values important enough that this would be a bad experience (search query, scroll position, form input, current tab) but small enough to fit in a Bundle — it has the same size limits as onSaveInstanceState, so it's not for large objects/lists, which is what a proper repository/cache is for.

Question 36

Why use sealed classes to represent UI state in Android?

Accepted Answer

A sealed class/interface restricts which types can extend it to a known, fixed set, which lets the compiler exhaustively check a when expression over it — if you add a new subtype later and forget to handle it somewhere, the build fails instead of silently falling through, exactly the safety property you want for representing "what can this screen currently look like." ```kotlin sealed interface UiState { object Loading : UiState data class Success(val data: T) : UiState data class Error(val message: String) : UiState } @Composable fun ScreenContent(state: UiState>) { when (state) { is UiState.Loading -> LoadingSpinner() is UiState.Success -> ItemList(state.data) is UiState.Error -> ErrorMessage(state.message) } } ``` Compare this to representing the same thing with three loose nullable fields (isLoading, data, error) — nothing stops all three being set simultaneously, states that shouldn't be reachable but compile fine and need runtime checks to defend against. Sealed classes push that invariant into the type system, which is why they're the standard building block for UI state in modern MVVM/MVI Android architectures.

Question 37

How do you handle exceptions properly in Kotlin coroutines?

Accepted Answer

An uncaught exception in a coroutine propagates up and cancels the whole parent Job/scope by default (structured concurrency) — often exactly what you want (one failed child cancels its siblings) but it can also crash the app if it reaches the top of viewModelScope/GlobalScope uncaught, since Kotlin coroutines treat an unhandled exception as fatal by default.

Three layers control this: wrap a specific suspend call in try/catch when you want to handle a failure locally without affecting siblings; use supervisorScope/SupervisorJob when child failures should be isolated by design (independent background refreshes where one failing shouldn't cancel the others); attach a CoroutineExceptionHandler as a last-resort top-level catch for logging/crash reporting — it does NOT stop propagation/cancellation, it just observes the final uncaught exception.

```kotlin
val handler = CoroutineExceptionHandler { _, e -> Log.e("VM", "Uncaught", e) }
viewModelScope.launch(handler) {
    supervisorScope {
        launch { try { repo.refreshA() } catch (e: IOException) { /* handled locally */ } }
        launch { repo.refreshB() } // if this throws, only this child fails
    }
}
```

A common mistake is wrapping try/catch around the async { } builder call itself instead of around .await() — the exception from a failed async isn't thrown until you call .await() on the resulting Deferred, so catching around the builder catches nothing.

Question 38

What is process death in Android and how should an app handle it?

Accepted Answer

Process death is the OS killing your app's entire process while it's in the background to reclaim memory — different from the user swiping the app from recents (also kills the process, but discarding the back stack is intentional by design) and different from a configuration change (Activity is destroyed/recreated but the process and ViewModels survive). After a background-death kill, if the user navigates back to the app, Android recreates the Activity with the previously saved Bundle (if onSaveInstanceState was called before dying) as if nothing happened — but every in-memory object (ViewModels, singletons) is gone silently, with no warning callback.

This matters because code assuming "if my Activity is still around, my ViewModel/singleton state is still valid" breaks silently — it doesn't crash, it quietly loses state, e.g. a filled-in form reverting to step 1. The defense is SavedStateHandle for essential small UI state, and, for anything larger, persisting to Room/DataStore instead of relying on in-memory state alone.

You can simulate this without waiting for a real low-memory kill: enable "Don't keep activities" in Developer Options, or use adb shell am kill <package> while the app is backgrounded, then bring it back — the standard way to catch process-death bugs before they ship, since they're easy to miss in normal foreground testing where the process never actually dies.

Question 39

What's the difference between using raw SQLite directly and using Room?

Accepted Answer

Using SQLiteOpenHelper/raw SQLite directly means hand-writing CREATE TABLE SQL, manually opening/closing a SQLiteDatabase, constructing ContentValues for inserts, writing raw query strings (no compile-time checking — a typo in a column name only surfaces at runtime), and manually mapping Cursor rows back into model objects field by field.

Room is an abstraction layer over the same SQLite engine that removes most of that boilerplate and adds compile-time safety: @Entity classes define the schema, @Dao interfaces define queries as annotated methods, and the annotation processor validates the actual SQL against the entity schema at compile time.

```kotlin
@Entity data class User(@PrimaryKey val id: String, val name: String)

@Dao interface UserDao {
    @Query("SELECT * FROM User WHERE id = :id")
    suspend fun getUser(id: String): User?
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insert(user: User)
}
```

Room also natively returns Flow/LiveData from a @Dao query for reactive updates, and integrates directly with coroutines/Paging3 — none of which raw SQLiteOpenHelper gives you without hand-writing equivalent observer plumbing. There's essentially no reason to reach for raw SQLite in new code today; Room is the default unless there's an unusual need for hand-tuned raw SQL Room's API can't express.

Question 40

What background execution limits did Android 8 (Oreo) introduce, and how do you work within them?

Accepted Answer

Starting with Android 8.0, the OS imposes stricter limits on background work to improve battery life: apps not in the foreground can no longer freely start background Services (calling startService() from the background throws in many cases — you must use startForegroundService(), which requires posting a persistent notification within a few seconds), and most implicit broadcasts registered in the manifest are no longer delivered to stopped apps.

The intended replacements are WorkManager for deferrable background work (with constraints and guaranteed eventual execution), a genuine foreground service for work the user needs to know is actively happening (music playback, live location tracking), and JobScheduler directly for lower-level cases WorkManager doesn't cover (though WorkManager uses JobScheduler under the hood on newer API levels, so it's rarely needed directly).

```kotlin
// Old, broken on Android 8+ if app isn't foreground
context.startService(Intent(context, SyncService::class.java))

// Correct: either
ContextCompat.startForegroundService(context, Intent(context, SyncService::class.java))
// or, for deferrable work:
WorkManager.getInstance(context).enqueue(OneTimeWorkRequestBuilder<SyncWorker>().build())
```

Later Android versions added further restrictions (background location requiring a separate permission, background Activity launch restrictions, exact alarm permission gating), all following the same direction: the OS, not the app, decides when background work runs unless it's visibly foreground or explicitly deferred through a system-managed scheduler.

Question 41

What is a baseline profile and how does it improve app startup performance?

Accepted Answer

On a fresh install, most of an app's code hasn't been compiled to native machine code yet — ART initially interprets bytecode or JIT-compiles it on the fly as methods are called, which is slower, especially on the very first cold start and the first time through commonly-hit code paths, a big contributor to a sluggish first-launch experience.

A baseline profile is a list of the classes/methods an app actually exercises during its critical user journeys (startup, scrolling the main feed), captured by instrumenting the app with Macrobenchmark's profile-generation API and recording what ART would otherwise have to JIT-compile on the device. That profile ships inside the APK/AAB, and the Play Store uses it to pre-compile (AOT) exactly those methods to native code on the user's device at install time, before the user ever opens the app.

```kotlin
@Test
fun startup() = baselineProfileRule.collect(packageName = "com.example.app") {
    pressHome()
    startActivityAndWait()
}
```

The measured effect for real apps is typically a meaningfully faster cold start, commonly cited in double-digit percentage improvements, with no runtime code change required — a purely build/distribution-level optimization, making it a relatively high-leverage, low-risk change for an already-shipped app.

Question 42

What's the difference between ART and Dalvik, and how do AOT and JIT compilation affect app performance?

Accepted Answer

Dalvik, the original Android runtime, primarily used JIT compilation — bytecode was interpreted/compiled to native code on the fly as the app ran, keeping install fast but paying interpretation/compilation overhead on every run, plus a comparatively simple mark-and-sweep garbage collector that could cause visible UI jank during a GC pause.

ART (default since Android 5.0) originally did full AOT compilation of the entire app at install time — trading a slower install for faster execution — but compiling code paths that might never run wasted storage and slowed installs/OTA updates. Since Android 7.0, ART switched to a hybrid model: JIT interpretation initially, combined with background AOT compilation of "hot" methods used frequently (informed by runtime profiling, optionally seeded by a baseline profile), balancing install speed, storage, and runtime performance.

The garbage collector also improved substantially with ART — a concurrent, mostly-non-blocking collector that dramatically reduced GC-pause jank versus Dalvik. As a developer you don't choose between them (ART has been the only option for years), but understanding this history explains why baseline profiles and reducing allocations still matter — they directly leverage this hybrid, profile-guided compilation model.

Question 43

What is Choreographer and how does it relate to frame drops (jank)?

Accepted Answer

Choreographer is the system component that coordinates animation, input, and drawing with the display's vsync signal — it receives a callback roughly every 16.6ms (on a 60Hz display) and, on each tick, drives input processing, animation updates, and traversal/drawing of the View hierarchy (or Compose's recomposition+layout+draw) for that frame. If all work needed to produce a frame doesn't finish before the next vsync tick, the frame is "missed" — the previous frame shows again for an extra vsync interval, perceived as jank.

Every View.postFrameCallback, invalidate()-triggered redraw, and Compose recomposition ultimately schedules through Choreographer, so a heavy onDraw(), an expensive layout pass, or a slow recomposition are all really "work Choreographer needed done before the next vsync didn't finish in time." Android Studio's Profiler (Janky Frames view, or adb shell dumpsys gfxinfo) reports frame timings precisely in these terms.

```
adb shell dumpsys gfxinfo com.example.app
```

Fixing jank almost always means finding what work happens synchronously inside a frame's measure/layout/draw path (or a heavy recomposition) and moving it off — the earlier DiffUtil and Compose recomposition-control questions are both, at bottom, about keeping per-frame work small enough that Choreographer's deadline is consistently met.

Question 44

What causes TransactionTooLargeException, and how do you avoid it?

Accepted Answer

Cross-process communication on Android (calling into a bound Service in another process, ContentProvider calls) goes through the Binder kernel driver, which uses a fixed-size shared memory buffer per process (historically around 1MB, shared across all concurrent Binder transactions for that process, not per-call) to pass transaction data between processes. If a transaction's data exceeds what's left in that buffer, the call fails with TransactionTooLargeException.

The classic trigger is passing a large Bundle through startActivity()'s Intent extras (e.g., a full Bitmap as a Parcelable extra) — Intents delivered across processes go through Binder, so a multi-megabyte Bitmap can throw this, sometimes only on certain devices/OS versions depending on how much of the shared buffer other in-flight transactions were already using, which is exactly why this exception has a reputation for being intermittent and hard to reproduce in a small test.

```kotlin
// Risky: passing a large Bitmap directly through an Intent
intent.putExtra("photo", largeBitmap)   // can throw TransactionTooLargeException

// Fix: pass a reference instead — a file Uri via FileProvider, or a cache key
intent.putExtra("photoUri", savedPhotoUri)
```

The fix is always to avoid sending large payloads through Binder-mediated APIs — save the data to a file/cache and pass a URI or lightweight identifier instead, which is why FileProvider-style "share a reference, not the data" patterns exist as a standard idiom, not just a style preference.

Question 45

What is CompositionLocal in Jetpack Compose and when should you use it?

Accepted Answer

CompositionLocal provides an implicit way to pass a value down through the Compose tree without threading it explicitly through every Composable's parameter list — a Composable anywhere below a CompositionLocalProvider can read the current value with .current, regardless of how many layers of unrelated Composables sit in between. It's how Compose itself propagates cross-cutting, ambient concerns like the current MaterialTheme colors/typography, LocalContext, or LocalLayoutDirection.

```kotlin
val LocalAppTheme = compositionLocalOf { AppTheme.Default }

@Composable
fun App() {
    CompositionLocalProvider(LocalAppTheme provides AppTheme.Dark) {
        ScreenContent() // anything ScreenContent calls, arbitrarily deep, can read LocalAppTheme.current
    }
}
```

It should be used sparingly, not as a general-purpose way to avoid state hoisting — overusing it makes a Composable's actual dependencies implicit and harder to trace/test, working against the explicit, testable data flow hoisting is meant to provide. The Compose team's guidance treats it as appropriate for genuinely tree-wide ambient configuration (theme, locale, content alpha) — not as a shortcut for passing a screen's regular business data down.

Question 46

What's the difference between remember and rememberSaveable in Compose?

Accepted Answer

remember caches a value across recompositions of the same composition — it survives a Composable being recomposed but is lost the moment the Composable leaves the composition entirely, which includes a configuration change like rotation, since that recreates the whole composition from scratch by default.

rememberSaveable additionally saves the value into the same Bundle-based saved-instance-state mechanism SavedStateHandle/onSaveInstanceState use, so it survives both recomposition and Activity recreation (rotation) and, like SavedStateHandle, process death — at the cost of only supporting types that fit into a Bundle (primitives, Parcelable, or a type with a registered custom Saver).

```kotlin
@Composable
fun ExpandableCard() {
    var expanded by remember { mutableStateOf(false) }       // lost on rotation
    var noteText by rememberSaveable { mutableStateOf("") }   // survives rotation
}
```

The rule of thumb: use rememberSaveable for anything the user would be annoyed to lose on rotation or backgrounding (typed text, a toggle they just set), and plain remember for cheap, easily-recomputed, or genuinely disposable UI state (like whether a tooltip is currently showing) where losing it on rotation is unnoticeable or even expected.

Question 47

What is derivedStateOf used for in Jetpack Compose?

Accepted Answer

derivedStateOf creates a piece of state computed from other state, but Compose only triggers recomposition of readers of the derived value when the computed result itself actually changes — not every time one of its inputs changes. This matters when the input changes far more often than the derived output does: without it, every input change forces recomposition of everything reading the derived value even when the value didn't actually end up different.

```kotlin
val listState = rememberLazyListState()
val showScrollToTopButton by remember {
    derivedStateOf { listState.firstVisibleItemIndex > 0 }
}
```

Here firstVisibleItemIndex changes on every scroll pixel/item during a fling, but showScrollToTopButton only actually flips value twice (false→true crossing the threshold, and back). Wrapping it in derivedStateOf explicitly declares "this is a computed value, only invalidate readers when the computed result changes" — the meaningful optimization here, avoiding a Composable reading the derived boolean from recomposing on every scroll tick instead of only at the two real transition points.

It's specifically for values recomputed from other Compose State reads — for a value not depending on frequently-changing Compose state, it's unnecessary overhead, and remember(keys) { compute() } or a plain calculation is simpler.

Question 48

Explain Doze mode and App Standby buckets, and their effect on background work.

Accepted Answer

Doze (Android 6.0+) kicks in when a device has been stationary, unplugged, and screen-off for a while — it progressively restricts background network access, defers WorkManager/JobScheduler jobs, and suspends most wakelocks and alarms (except during periodic maintenance windows), saving battery when the device is idle in a pocket overnight. App Standby Buckets (Android 9+) is a complementary, per-app system classifying each app into a bucket (active, working_set, frequent, rare, restricted) based on actual usage patterns, throttling how often that app's jobs/alarms/high-priority FCM messages run — an app not opened in weeks gets pushed into rare/restricted and its background work deferred far more aggressively, independent of whether the device is in Doze at all.

The practical implication: you cannot assume a WorkManager job or scheduled alarm fires at a predictable time — the design defers non-urgent background work to batch it efficiently, and an app that isn't actively used gets deferred more. For truly time-critical alerts, setExactAndAllowWhileIdle() (or, since Android 12, the more restricted exact-alarm permission) exists specifically to bypass Doze's deferral for rare legitimate cases (an alarm clock, a calendar reminder) — but Google discourages defaulting to exact alarms, since overusing them defeats Doze's purpose, and Play Store policy now requires justifying the permission on submission.

```
adb shell dumpsys deviceidle force-idle   # simulate Doze for testing
adb shell am set-inactive com.example.app true  # push into standby
```

Testing this deliberately via adb (rather than waiting hours for real Doze) is the standard way to verify a background sync feature degrades gracefully instead of silently failing to run and being blamed on "flaky network."

Question 49

What is scoped storage and how did it change file access starting Android 10?

Accepted Answer

Before Android 10, an app with WRITE_EXTERNAL_STORAGE/READ_EXTERNAL_STORAGE could read and write essentially any file on shared external storage, meaning one poorly-behaved app could see and modify every other app's files freely — a real privacy problem. Scoped storage, phased in from Android 10 and enforced more strictly from Android 11 onward, confines each app by default to its own app-specific directory (no permission needed, deleted on uninstall) plus mediated access to shared collections (Photos, Videos, Audio, Downloads) only through the MediaStore API, where the app can manage files it created itself without a broad permission, but must go through a system-mediated request to touch files other apps created.

```kotlin
// Scoped storage: save to app-specific storage, no permission needed
val file = File(context.getExternalFilesDir(null), "notes.txt")

// Or insert into the shared MediaStore collection (visible to other apps/gallery)
val values = ContentValues().apply {
    put(MediaStore.Images.Media.DISPLAY_NAME, "photo.jpg")
    put(MediaStore.Images.Media.RELATIVE_PATH, Environment.DIRECTORY_PICTURES)
}
resolver.insert(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, values)
```

Apps genuinely needing broad file-manager-style access (a file manager or backup app) can request MANAGE_EXTERNAL_STORAGE, but Google Play now requires a specific policy justification for approval, precisely because it re-opens the broad-access hole scoped storage was designed to close — most apps don't need it and should use MediaStore/the Storage Access Framework document picker instead.

Question 50

What's the difference between a microbenchmark and a macrobenchmark in Android performance testing?

Accepted Answer

A microbenchmark (Jetpack Benchmark library) measures a small, isolated piece of code in-process — a single function's CPU time, run thousands of iterations in a tight loop with JIT warm-up accounted for — good for answering "is this specific parsing function fast," but it can't measure anything depending on the full app/process lifecycle, like actual cold-start time or real rendering jank.

Macrobenchmark instead measures realistic, whole-app scenarios out-of-process — launching the real APK via instrumentation and measuring end-to-end metrics like cold/warm/hot start time, frame timing during a real scroll, or the effect of a baseline profile — because those things only manifest across a full process launch and can't be isolated into an in-process loop.

```kotlin
@Test
fun startupCompilationNone() = benchmarkRule.measureRepeated(
    packageName = "com.example.app",
    metrics = listOf(StartupTimingMetric()),
    iterations = 5,
    startupMode = StartupMode.COLD,
    compilationMode = CompilationMode.None()
) {
    pressHome()
    startActivityAndWait()
}
```

The two are complementary: use a microbenchmark to optimize a hot function's raw execution time, and a macrobenchmark to verify that optimization (or a baseline profile, or a startup refactor) actually moved the needle on the metric a real user experiences — a microbenchmark improvement doesn't automatically prove an end-to-end improvement, since it says nothing about I/O, class loading, or other processes contending for the CPU during a real launch.

Android Interview Questions & Answers

Ready to practice these live?