Android Interview Questions: Live Practice Quiz

In the Groovy DSL, ext defines a project-level extra property. coroutinesVersion is set to the string 1.7.3. The println uses Groovy string interpolation (${coroutinesVersion}), which substitutes the property value into the string, producing Resolved dependency: org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.3. The dependencies block does not affect the output of the println statement.

WorkManager is the recommended Android Jetpack library for persistent, deferrable background work. It guarantees execution across app death and device reboots, which distinguishes it from in-memory coroutine-based work that is lost when the process dies.

A configuration change like a rotation, by default, is treated as if the current Activity can no longer handle its current configuration: the system tears it down and creates a fresh instance against the new configuration (new resources, layout, etc.). Before that teardown, onSaveInstanceState(Bundle) is called so small amounts of UI state (scroll position, text field contents) can be written into a Bundle that the new instance receives in onCreate()/onRestoreInstanceState(). Only declaring android:configChanges for the specific configuration types (e.g. orientation|screenSize) opts an Activity out of this and routes the change to onConfigurationChanged() instead — the exception, not the default. This is precisely why non-trivial state belongs in a ViewModel (which survives the recreation) rather than in Activity fields, which is a very common interview probe.

Since Android 6.0, permissions in the "dangerous" protection level (location, camera, contacts, and similar) are runtime permissions: listing them in the manifest is necessary but not sufficient — it only tells the system the app may ask for them. The app must separately prompt the user at the point of use (or ahead of it, with a rationale via shouldShowRequestPermissionRationale()) and branch on whether the grant actually happened, because the user can deny it, or later revoke it in Settings even after granting it once. This is different from "normal"-level permissions (like INTERNET), which are granted automatically at install time with no runtime prompt at all — a distinction interviewers commonly probe because conflating the two is a frequent source of crashes (SecurityException) in production. <queries> is an unrelated manifest element for declaring package visibility, not a way to request a dangerous permission.

False. An ANR is specifically about the main (UI) thread failing to respond — the system watchdog fires when the main thread can't process an input event (roughly a 5-second budget) or a component like a BroadcastReceiver doesn't finish within its own timeout. Work correctly moved off the main thread onto a background thread, by definition, cannot block the main thread's ability to process input, so it cannot by itself trigger an ANR — that's precisely the point of moving expensive work off the main thread in the first place. What background work can still cause is a different failure: if it eventually blocks on a lock the main thread is also waiting on, that indirect contention can produce an ANR, but that's a distinct mechanism from "a background thread being slow" on its own.

Implicit intents are what let apps interoperate without knowing each other's package names in advance — a share sheet, a "open this URL," a "pick a photo" all work because the requesting app only describes what it wants done, and the intent-filter mechanism is the system-wide registry that lets any installed app opt into handling that kind of request. Understanding this resolution flow is what lets an engineer correctly reason about deep links, share targets, and why resolveActivity() (or checking for null before startActivity) is defensive best practice — the set of apps able to handle a given implicit intent varies by device and by what else the user has installed.

The lifecycle is a strict progression outward and then back in reverse: an Activity can't become visible before it's created, can't gain focus before it's visible, and on the way out it loses focus before it loses visibility, and loses visibility before it's torn down — each step hands off to the next in exactly one direction for a simple finish. onPause() fires as soon as the Back press starts the transition (the Activity is still technically on screen mid-transition), onStop() fires once it's fully off screen, and onDestroy() is the final cleanup once the system has decided the Activity instance itself is being discarded (as opposed to just being stopped and possibly resumed again if the user hadn't pressed Back). Getting this order backwards — e.g. assuming onStop() happens before onPause() — is a common early mistake that leads to releasing resources at the wrong time.

WorkManager stores every WorkRequest in an internal database. When the app process is killed or the device reboots, WorkManager's BootReceiver fires on BOOT_COMPLETED and reschedules all non-terminal work. One-time work that already reached SUCCEEDED is terminal and will not re-run; only work that is ENQUEUED, RUNNING (at time of death), or periodic gets rescheduled.

For each dependency, resolve checks the forceVersion map first, then the catalog, then defaults to "unspecified". okhttp has no forced override so it resolves to the catalog version 4.12.0. retrofit is forced to 2.11.0, overriding the catalog's 2.9.0. moshi resolves to 1.14.0 from the catalog. coil is in neither map, so it becomes coil:unspecified.

The flavorDimensions list declares two dimensions: "mode" and "api". Each product flavor must be assigned to exactly one declared dimension via the dimension property. The flavors free and paid belong to the "mode" dimension, while minApi21 and minApi24 belong to the "api" dimension. Assigning a flavor to a dimension that is not declared in flavorDimensions would cause a Gradle build error. With this setup, the plugin generates variants such as freeMinApi21Debug, freeMinApi21Release, paidMinApi24Debug, etc.

onCreateView is the Fragment lifecycle method the system calls to ask the fragment to inflate and return its UI view hierarchy. The returned View is then passed to onViewCreated, making onCreateView the correct callback for layout inflation. onCreate is used for non-UI initialization, onViewCreated for view-reference setup, and onAttach runs before any view work happens.

WorkManager is purpose-built for exactly this shape of requirement — deferrable, guaranteed background work with constraints — which is why it's Google's recommended API for it. A PeriodicWorkRequest persists its schedule and constraints to WorkManager's own database, so the work survives process death and device reboots and resumes once its network constraint is satisfied again, without the app needing to still be running. A coroutine loop in Application.onCreate() dies the moment the process is killed by the system, which is routine on Android; a permanently-running foreground Service burns battery and is the wrong tool for infrequent, deferrable work; and firing network I/O directly inside a BroadcastReceiver on the main thread will both block the UI thread and likely exceed the receiver's short execution time limit, causing an ANR-adjacent crash. Note WorkManager's periodic work also has a platform-enforced 15-minute minimum interval, which a 6-hour cadence comfortably clears.

Room's whole pitch is catching persistence bugs at compile time and keeping the database off the main thread by default: its annotation processor validates @Query strings against the real schema so a bad query fails the build (a), and a suspend DAO method is automatically run on a background dispatcher Room manages internally, no manual withContext needed (b). A missing Migration for a bumped version is treated as a real error — Room throws rather than silently trusting stale schema assumptions, specifically to prevent the far worse failure mode of reading/writing data with a schema that no longer matches (c). Room has nothing to do with Firestore or any cloud sync layer (d is invented) — it's purely a local SQLite abstraction — and by default Room actively throws IllegalStateException ("Cannot access database on the main thread") for a synchronous query, unless the dangerous allowMainThreadQueries() escape hatch is explicitly opted into, so (e)'s "allowed by default with no warning" is false.

The explicit-vs-implicit distinction is exactly (a): an explicit intent targets a specific component by class name, bypassing resolution entirely, while an implicit intent is resolved by the system against every app's declared intent filters (b describes why PendingIntent exists — a notification is drawn and shown by the system server, not the originating app, so it needs a token it can later fire with the originating app's identity and permissions, which is what a PendingIntent is). Intent filters in the manifest are precisely the mechanism that makes implicit-intent resolution possible, matched against action/category/data (d). On the other two: since Android 12, apps targeting API 31+ must explicitly specify PendingIntent.FLAG_MUTABLE or FLAG_IMMUTABLE when constructing one, and FLAG_IMMUTABLE is the one the platform pushes as the safer default — mutability is not silently allowed with no flag, so (c) is false. And calling startActivity() with an implicit intent that resolves to nothing throws ActivityNotFoundException rather than silently no-op'ing, which is exactly why the docs recommend calling resolveActivity() first to check — so (e) is false.

True. A Fragment's view is destroyed in onDestroyView() well before the Fragment instance itself is destroyed in onDestroy() — this happens routinely when a Fragment is pushed onto the back stack (its view is torn down to free memory) while the Fragment object stays alive, ready to have its view re-created in onCreateView() if the user navigates back. That's exactly why observing LiveData/Flow with the Fragment's own lifecycle (this / viewLifecycleOwner = fragment) instead of viewLifecycleOwner is a well-known source of bugs: the observer keeps running (and can crash trying to touch a destroyed view, or silently accumulate duplicate observers across view recreations) because it's scoped to the longer-lived Fragment lifecycle rather than the shorter-lived view lifecycle the UI code actually depends on.

The distinction hinges on what actually gets destroyed: a configuration change destroys and recreates the Activity, but the process — and therefore anything held purely in memory, like a running ViewModel — keeps living, so the framework simply reattaches the existing ViewModelStore to the new Activity instance with zero serialization involved. Process death is a strictly harder failure mode: the whole process, including every in-memory object, is gone, so nothing can be 'handed off' at all — the only thing that survives is whatever was written to durable storage before death, which for Android is the Bundle written in onSaveInstanceState(). SavedStateHandle is the ViewModel-facing API onto that same Bundle mechanism, which is why it, and not a plain ViewModel field, is the one that also survives process death, not just rotation.

On line 6, version = "retrofit" sets the version to the literal string "retrofit", so Gradle looks for com.squareup.retrofit2:retrofit:retrofit, which does not exist. To reference the version declared in the [versions] table ("2.9.0"), the key must be version.ref = "retrofit", as correctly done on line 7 for retrofit-converter-gson and line 8 for okhttp-logging. In a Gradle version catalog TOML, version = "…" sets a hardcoded literal, while version.ref = "…" dereferences an entry from [versions].

Service lifecycle callbacks (onCreate, onStartCommand, onDestroy) do execute on the main thread, which is why long-running work in a Service must be offloaded to a background thread. However, a CoroutineWorker's doWork() runs on a background thread by default (Dispatchers.Default), not the main thread. This is a key difference: WorkManager handles threading for you, whereas a Service does not.

A Kotlin object is a singleton that lives for the process's lifetime — it's exactly the kind of long-lived GC root Android developers are warned about, and storing a mutable reference to an Activity inside one is a textbook leak: nothing ever clears currentActivity when that Activity is destroyed (on rotation, on back-press, on navigating away), so the singleton keeps pinning the old Activity — and everything it transitively references (its whole View hierarchy, any Contexts derived from it) — in memory indefinitely, while the system believes it destroyed that Activity. Every subsequent attach() call makes it worse by leaking the previous Activity permanently (nothing frees it, attach() only overwrites the reference for future lookups) and the one that's live now stays pinned too. The fix is to never hold a long-lived reference to an Activity/View/Context tied to a UI lifecycle; if a singleton genuinely needs a Context, it should hold applicationContext, which is safe because it's already tied to the process lifetime. ?.let (b) and a parameter's name (c) have no bearing on garbage collection, and Kotlin singletons are not specially collected alongside any particular Activity (d) — GC only reclaims what has no remaining reachable reference, which is exactly what line 2 prevents.

Room treats a version bump as a promise that the developer has told it how to get from the old schema to the new one. When it opens an existing database file whose stored version (1) doesn't match the code's declared version (2), it looks for a registered Migration(1, 2) to run the necessary ALTER TABLE/CREATE/COPY SQL; finding none, and with no fallbackToDestructiveMigration() opted into either, its only safe option is to refuse to open the mismatched database and throw — silently guessing at a schema reconciliation would risk corrupting or misreading user data. That's exactly what happens to every existing installed user here: a fresh install never hits this (there's no old file to reconcile), which is why it's easy to miss in dev testing on a clean emulator and only surfaces against real upgraded users, exactly as QA reported. The fix is either a real Migration(1, 2) object that adds the new column, or, if data loss is acceptable, an explicit fallbackToDestructiveMigration() call. exportSchema (b) is a schema-history feature with no crash implication, abstract fun in a RoomDatabase subclass is the required, correct pattern (Room generates the implementation) so (c) is backwards, and Room never migrates automatically with no instructions regardless of default values (d).

This is a genuinely common senior-level design question because all three tools can technically run the same code, so the right answer is about the guarantee each one gives, not the code inside it. A coroutine in viewModelScope gives no guarantee beyond the current UI session — it's cancelled automatically when the ViewModel is cleared, which is correct for work that should stop with the screen. A foreground Service is for work the OS and user both need active, real-time visibility into (hence the mandatory notification), and it still dies with the process, so it's not a durability guarantee either. WorkManager is the only one of the three that persists its own scheduling state to disk and survives process death and reboots, which is exactly the guarantee deferrable, must-eventually-happen work needs — picking the wrong one of these three is a frequent source of real production bugs (uploads silently dropped when the user backgrounds the app, for instance).

When a OneTimeWorkRequest is enqueued it enters ENQUEUED. Once constraints are satisfied the Worker is dispatched and the state becomes RUNNING. When doWork() returns Result.retry(), WorkManager reschedules the work (applying the configured backoff delay) and the state returns to ENQUEUED. On the second attempt the state becomes RUNNING again, and when doWork() returns Result.success() the work transitions to SUCCEEDED. The full sequence is: ENQUEUED → RUNNING → ENQUEUED → RUNNING → SUCCEEDED.

ExistingWorkPolicy.REPLACE specifies that existing pending (uncompleted) work with the same unique name is cancelled first, then the new work is enqueued. The old RUNNING work transitions to CANCELLED. Only after cancellation does the new work enter ENQUEUED. The new work then proceeds through its normal lifecycle: ENQUEUED → RUNNING → SUCCEEDED (since doWork() returns success). The old work's CANCELLED transition strictly precedes the new work's ENQUEUED transition.

Intent resolution for an implicit intent tests action, category, and data in sequence.

The intent's action is ACTION_VIEW; its data URI scheme is content. The framework auto-adds CATEGORY_DEFAULT, so the intent's category set is exactly {DEFAULT}.

Filter A — Action VIEW matches. The filter declares CATEGORY_DEFAULT, satisfying the category test (the filter must contain every category present in the intent). The data scheme content matches the intent's content:// URI. Match.

Filter B — The filter omits CATEGORY_DEFAULT. Because startActivity() injects CATEGORY_DEFAULT into the implicit intent, the category test fails: every category in the intent must be listed in the filter. No match.

Filter C — Action and category pass, but the filter's data scheme is https, which does not match the intent's content scheme. No match.

Filter D — The filter's action is EDIT, not VIEW. The action test requires at least one filter action to match the intent's action. No match.

Filter E — Action VIEW matches. The filter declares both DEFAULT and BROWSABLE; the category test only requires that every category in the intent appear in the filter—extra categories in the filter are irrelevant. DEFAULT is present, so the test passes. The scheme content matches. Match.

Therefore Filters A and E match; B, C, and D do not.

WorkManager's two distinguishing guarantees are crash-safe persistence (via a Room-backed WorkSpec table) and guaranteed eventual execution with backoff. A started Service provides neither: its in-memory state is lost on process death, and START_STICKY only restarts with a null intent. This is the fundamental architectural difference between the two APIs.