Android Developer Interview Questions

"I started in my second year of college when I wanted a simple app to split bills with friends. I built it in Kotlin with a single activity and a Room database, and about forty friends ended up using it, which taught me more than any course. After graduating I joined a small team building a delivery tracking app. I owned the order history and notifications screens, moved them from XML to Compose, and set up the WorkManager job that syncs orders when the network comes back. Now I want to work on an app with a bigger user base, where performance, crash rates and careful releases matter more, because that's the part of the job I've enjoyed most."

"I like native Android because I get new platform features the day they ship, I can integrate deeply with things like background work, widgets and notifications, and when something is slow I can profile it all the way down. That said, I don't think native is always right. If a small team has to ship the same mostly standard screens on two platforms, a cross-platform framework can be the smarter business choice. A middle path I find interesting is sharing the business logic in Kotlin Multiplatform while keeping native UI on each side. So for me it's about the product. I want to go deep on Android because that's where I think I add the most value, not because the other options are bad."

"On a shopping app, the backend team planned an endpoint that returned the whole product catalogue in one response, so the app could filter locally. On mid-range phones that meant a large download and a parse that froze the screen. Instead of just saying no, I built a quick test with a real sample file and showed the load time and memory use on a cheap test phone during our sync. That made the problem concrete. We agreed on a paged endpoint with server-side filtering and a small summary call for the first screen. It meant a bit more backend work, but the first screen loaded much faster and we stopped seeing memory crashes on low-end devices. I learned to bring numbers from a real device, not arguments."

"I split it into what we must do and what's nice to try. The must-do list is the behaviour changes page for each new Android version and the store's target SDK requirements, because those can break us or block updates if we ignore them. I read those every year and turn them into tickets early. For new libraries, I follow the official Android developer blog and release notes and a handful of engineers whose judgement I trust. When something looks useful, I try it in a side project first, then on one small, low-risk screen at work. If it earns its place, I write a short note or give a quick demo so the team can decide together. I'm happy to be a few months behind the newest thing if it means the app stays stable."

"When the app opens, the activity gets onCreate, where I set up the UI and ViewModel, then onStart when it becomes visible, then onResume when it's in the foreground and taking input. When the user presses Home, it gets onPause and then onStop, and the system also calls onSaveInstanceState so it can restore small UI state later. When they come back, it's onRestart, onStart and onResume. The catch is that while the app sat in the background, the system may have killed the process to free memory. In that case, coming back runs a fresh onCreate with the saved bundle. That's why I tie things like location updates or camera use to start and stop, and never assume the activity simply resumes."

"By default, a rotation is a configuration change, so the system destroys the activity and creates a new one with the new resources. Anything held only in the activity is gone. I handle it in layers. Screen data like a loaded list lives in a ViewModel, which survives rotation because it's kept outside the activity instance. But a ViewModel dies if the system kills the process in the background, so small things the user typed or selected, like a search query or a tab, go into SavedStateHandle, or rememberSaveable in Compose. Those are written into the saved instance state bundle. Anything that must last, like a draft message, I write to Room or DataStore. I avoid opting out of recreation in the manifest, because it just hides the problem."

"A fragment and its view don't live for the same length of time. When I replace a fragment and add that transaction to the back stack, the old fragment gets onDestroyView but not onDestroy, so the fragment object stays in memory with no view. When the user presses Back, onCreateView runs again and builds a brand new view. If I observe LiveData in onViewCreated with the fragment as the owner, the old observer is never removed, because the fragment never died. So after coming back I have two observers, and the old one may touch views that are gone. Using viewLifecycleOwner ties the observer to the current view, so it's removed in onDestroyView. Flows work the same way: I collect them with the view's lifecycle and repeatOnLifecycle. And I set the binding to null in onDestroyView so the old view tree can be freed."

"LiveData is an Android class that knows about the lifecycle, so it only pushes updates to observers that are started or resumed, and it cleans up when the owner is destroyed. StateFlow comes from Kotlin coroutines. It always has a value, so you must give it an initial one, and it skips an update if the new value equals the current one. It isn't lifecycle-aware by itself, so in views I collect it inside repeatOnLifecycle with the started state, and in Compose I use collectAsStateWithLifecycle. For a new ViewModel I'd expose StateFlow, because it works with the rest of the flow operators, it's easy to test without Android, and it can live in modules that don't depend on Android. I'd keep LiveData where an older screen already uses it."

"A scope decides how long a coroutine lives. viewModelScope is my default for loading screen data, because it's cancelled when the ViewModel is cleared, so a user leaving the screen stops the work. lifecycleScope belongs to an activity or fragment, and I use it for UI things like collecting state. GlobalScope isn't tied to anything, so nothing cancels it and it can leak or run after it's useful. If work really must outlive a screen, I inject an application-level scope, and if it must survive the process dying, it goes to WorkManager. For dispatchers, Main is for touching the UI, IO is for blocking work like file access, and Default is for CPU-heavy work like parsing a big list. Suspend functions from Room and Retrofit already switch threads, so I don't wrap them again."

"Cancellation is cooperative. Library suspend functions like delay or withContext check for it, but a loop doing CPU work won't stop unless I call ensureActive or check isActive. Cancelling throws a CancellationException inside the coroutine, so if I write a catch-all for Exception, I have to rethrow that one or I break cancellation. For failures, under a normal Job, a child that throws cancels its parent, and the parent cancels all the other children. That's usually right for related work: if one of two parallel calls for a screen fails, the other is pointless. When the children are independent, I use a SupervisorJob or supervisorScope, so one failing doesn't cancel the rest. viewModelScope already uses a SupervisorJob, which is why one failed launch doesn't kill the others there."

"I keep the query in a MutableStateFlow that the text field updates. From that I build the results flow. debounce waits until typing pauses for a short time, then I trim the text and use distinctUntilChanged so the same query doesn't search twice. The key operator is mapLatest: when a new query comes in while the previous search is still running, it cancels the old one, so a slow response can't overwrite newer results. I catch network errors inside the mapLatest block, not after it, because a catch at the end of the chain would complete the whole flow after the first failure and search would stop working. Finally stateIn turns it into a StateFlow tied to viewModelScope, and WhileSubscribed stops the work shortly after the screen stops collecting."

"Compose tracks which state each composable reads. When that state changes, Compose re-runs the composables that read it, and it can skip children whose inputs are stable and haven't changed. Problems come from reading fast-changing state too high up. For example, if the whole screen reads a scroll offset, every scroll frame recomposes the screen. My fixes are to read state as low and as late as possible, like passing a lambda instead of a value, or using the lambda version of a modifier such as offset so the read happens in layout, not composition. I use derivedStateOf when the UI only cares about a threshold, like whether to show a scroll-to-top button. I remember expensive calculations, give lazy list items stable keys, and keep UI models immutable. Then I check the counts in Layout Inspector."

"Composables can run again at any time, so a normal local variable resets on every recomposition. remember keeps a value across recompositions, and mutableStateOf makes it observable, so changing it recomposes whatever reads it. remember alone doesn't survive rotation, which is what rememberSaveable is for. State hoisting means taking that state out of a composable and moving it up to the caller. The composable receives the current value and a lambda like onQueryChange, and it just displays and reports. So my search field is stateless: it shows the text it's given and calls back when the user types. The caller, often backed by the screen's ViewModel, owns the real state. That gives me one source of truth, and the same component works in previews, tests and other screens. I hoist state to the lowest common parent that needs to read or change it."

"RecyclerView only creates enough view holders to fill the screen plus a few extra. When a row scrolls off, its view holder goes into a cache or a shared pool, and when a new row scrolls in, RecyclerView reuses one and calls onBindViewHolder to fill it with new data. So binding has to be fast, and it has to set every view, or you see old data flicker in from a recycled row. notifyDataSetChanged tells the adapter that everything might have changed, so it rebinds all visible rows and you lose item animations. DiffUtil compares the old and new lists, using areItemsTheSame on the id and areContentsTheSame on the data, and sends only the real changes. I use ListAdapter, which runs that diff on a background thread and just needs submitList."

"An explicit intent names the exact class to start, like my own DetailsActivity, so I use it inside my app. An implicit intent describes what I want done, like viewing a web page or sharing text, and the system finds an app whose intent filter matches. With implicit intents I have to handle the case where no app can do it, otherwise startActivity throws. A PendingIntent wraps an intent and hands it to someone else, like the notification system or AlarmManager, so they can fire it later with my app's identity and permissions. That's how tapping a notification opens my screen even if my app isn't running. On recent Android versions I have to say whether it's mutable or immutable, and I choose immutable unless something like an inline reply needs to fill it in."

"I'd use WorkManager. The work is persisted, so it survives the app being closed and even a reboot, and I can add a network constraint, retry with backoff, and use unique work so the same batch isn't queued twice. A plain background service isn't reliable here, because since Android 8 the system stops background services soon after the app leaves the foreground. A foreground service is meant for ongoing work the user is actively aware of, like navigation or music, and it needs a notification and, on newer versions, a declared service type. For a large upload the user started and is waiting on, I'd still use WorkManager but make the worker long-running with setForeground, which shows a progress notification. I'd also save upload progress so a retry doesn't start from zero."

"I'd push back, because asking for more than we need hurts us twice. Users are much more likely to say no to a scary prompt on first launch, and background location brings a stricter store review where we'd have to justify it. Since the feature only runs while the app is open, foreground location is enough. I'd request it when the user taps the feature, using the activity result permission API, with a short explanation first if the system says a rationale should be shown. If they deny it, the feature falls back to letting them type a city. On recent Android versions, after two denials the system stops showing the prompt, so then I'd offer a button to the app's settings page instead. If we later need tracking during an active trip, a foreground service with a location type is the right route, not background access."

"First I update the entity and bump the database version number. Then I write a Migration from the old version to the new one that runs the SQL, here an ALTER TABLE that adds the column with a default value that matches the entity, and I register it with addMigrations on the database builder. If I bump the version and forget the migration, Room throws when it opens the database, so the app crashes on launch for everyone who updates. The shortcut is fallbackToDestructiveMigration, but that deletes the user's data, so I only accept it for pure caches. For simple changes like adding a column, Room can also generate an auto-migration from the exported schemas. Either way I keep exportSchema on, commit the schema files, and write a migration test that upgrades a real old database."

"I declare the API as a Retrofit interface with suspend functions. The repository is the only thing that calls it. With a suspend function that returns the body directly, a non-success status code throws an HttpException and a network problem throws an IOException, so the repository catches those two and maps them to a small sealed result, like success with data or failure with a reason the UI can explain. If I need the status code or headers, I return Response and check it myself. The ViewModel then turns that into one UI state, loading, content or error with a retry action, and exposes it as a StateFlow. Things every request needs, like the auth token and logging, go into OkHttp interceptors rather than each call."

"I'd explain it without making it personal. Anything inside the app, including BuildConfig fields and strings, can be pulled out of the APK with free tools in a few minutes, and obfuscation only slows that down. If it's a secret that can spend money or read other users' data, someone will eventually take it. The safer design is for the app to call our own backend, which holds the secret and calls the service, so we can also add rate limits and logging. If the service is meant to be called from the client, like a maps key, I'd use a key restricted to our package name and signing certificate, or have our server issue a short-lived token. I'd offer to help build the backend piece, so it doesn't feel like I'm just blocking the feature."

"Without injection, each class creates its own dependencies, so a ViewModel might build its own repository, which builds its own Retrofit client. That's hard to test and wastes objects. Hilt, which is built on Dagger, generates that wiring at compile time. I annotate the Application with HiltAndroidApp and each activity or fragment with AndroidEntryPoint. The ViewModel gets HiltViewModel and an Inject constructor that asks for the repository interface. Then I tell Hilt which implementation to use in a module installed in the singleton component. I use Binds for my own interface-to-class mappings and Provides for things I can't annotate, like the Retrofit instance. In the screen I just use by viewModels, or hiltViewModel in Compose. In tests I can swap the module for fakes."

"I split it into three layers. The UI layer is the activity, fragment or composables plus the ViewModel. The screen only renders a state object and sends user events up. The ViewModel turns events into calls and exposes one UI state as a StateFlow, and it doesn't hold views or contexts. Under that, an optional domain layer holds use cases, like applying a discount rule, when that logic is shared or complex enough to test alone. The data layer has repositories that hide where data comes from, network, Room or DataStore, and decide things like caching. State flows down and events go up. Each layer only knows about the one below it through interfaces, so I can test the ViewModel with a fake repository and swap a data source without touching the UI."

"I'd make Room the single source of truth. The feed screen observes a paged query from Room, and the network never talks to the UI directly. It only writes into the database. For paging I'd use the Paging library with a remote mediator, so when the user nears the end of the cached items it fetches the next page and inserts it, and the list updates itself. Each row stores when it was fetched, so on opening the app I refresh only if the data is stale. For background freshness, a periodic WorkManager job runs on unmetered network, and I'd use conditional requests so an unchanged feed costs almost nothing. If the user likes or saves an article offline, I update the local row right away and write the action to an outbox table that a worker sends later, with the server as the final word on conflicts."

"In my last team, most screens used callbacks and a lot of logic lived in fragments, which made bugs hard to test. A full rewrite wasn't an option, so I proposed a rule: any screen we touch for a feature moves to a ViewModel with coroutines, and new screens are written in Compose. I started with one small settings screen to set the pattern, wrote a short guide, and used ComposeView so Compose screens sat inside our existing fragments. For shared code we wrapped the old callback APIs with suspendCancellableCoroutine, so new code didn't have to wait for the old code to change. It took about nine months, and the crash rate on migrated screens dropped noticeably. What I'd change is agreeing on the UI state pattern earlier, because the first few screens did it three different ways."

"A leak on Android is almost always something long-lived holding a reference to something short-lived, usually an activity or a view. The classic cases are a singleton or companion object keeping an activity context, a listener or callback registered with a system service and never unregistered, an inner class or long-running job capturing the activity, and in fragments, keeping the view binding after onDestroyView, because the fragment outlives its view. To find one, I run LeakCanary in debug builds, which dumps the heap after a screen is destroyed and shows the chain of references keeping it alive. For harder cases I take a heap dump in the Android Studio memory profiler. Fixes are usually small: use the application context for long-lived things, unregister in the matching lifecycle callback, and null the binding in onDestroyView."

"An ANR means the main thread was blocked too long, for example an input event wasn't handled within about five seconds, or a broadcast receiver or service didn't finish in time. In production I start with the ANR clusters in the Play Console, which show the main thread's stack when it happened. The top of that stack tells me whether it was doing disk work, waiting on a lock, making a synchronous binder call or just doing too much. On newer Android versions the app can also read the exit reasons the system recorded for it, including the ANR trace. The common roots I've seen are database or SharedPreferences writes on main, a lock held by a background thread, and heavy work at startup. In debug builds I turn on StrictMode so disk and network on the main thread get caught before release."

"At my last company, after a release our crash reports showed an IllegalStateException in a fragment transaction, mostly on older, low-memory phones. My first guess was a missing null check, but the stacks showed it happened after the activity had saved its state. Grouping the reports by device and by the steps before the crash, I found the pattern: users opened a payment screen, switched to their banking app, and our network callback then tried to show a dialog fragment while we were in the background. I reproduced it by starting a slow payment call and switching apps before it finished. The fix was to move the result into ViewModel state and show the dialog only when the screen was started again. I added a test for that path, and the crash disappeared from the next release."

"First I'd reproduce it properly: on a low-end phone, with a release build, because debug builds, and Compose in particular, are much slower and can send me after the wrong problem. Then I'd measure instead of guessing. I'd record a system trace while scrolling to see which frames miss their deadline and what the main thread is doing in them. For a RecyclerView list I'd look at time in onBindViewHolder and layout. For Compose, I'd check recomposition counts in Layout Inspector. The usual culprits are loading full-size images into small thumbnails, formatting dates or parsing text during binding, deep nested layouts, and database or disk work landing on the main thread while scrolling. Once I've fixed the top cause, I'd re-measure and add a macrobenchmark for scrolling so it doesn't quietly get worse again."

"I test the ViewModel as a plain JVM unit test, with no device. The repository is an interface, so I pass in a fake whose results I control, like returning data or throwing an IOException. viewModelScope runs on the Main dispatcher, which doesn't exist on the JVM, so I use a small JUnit rule that swaps Main for a test dispatcher before each test and resets it after. The test body runs inside runTest, which uses virtual time, so a delay or debounce doesn't make the test slow. Then I call the ViewModel's function and assert on the state it exposes. For flows that emit several values in order, I collect them in the test and check the whole sequence. If a class uses IO or Default, I inject the dispatcher so the test can replace it."

"I build an Android App Bundle for the release variant with R8 turned on, which shrinks and obfuscates the code, and I test that exact build, because R8 can strip classes used through reflection, which only shows up as a crash in release. I keep the mapping file so crash stack traces can be read. The bundle is signed with our upload key, and Play holds the real app signing key, so a lost upload key can be reset. I bump the versionCode, then push to the internal testing track, then a closed group, then production as a staged rollout to a small share of users. I watch the crash and ANR rates in Android vitals for a day or two before widening it. If something's wrong I halt the rollout, but people who already updated keep it, so the fix goes out as a new version."

"In a fitness app, some users said their reminder notifications never arrived, but they always worked on my phone. The reports clustered on a couple of manufacturers, so I borrowed a device from a colleague and found its battery saver was stopping our app completely in the background, which also removed our scheduled alarms. On top of that, a few users on newer Android versions had never granted the notification permission, because we only asked for it deep inside settings. We fixed it in two parts: we asked for the notification permission at the moment users turned reminders on, and added a short help screen explaining how to exclude the app from battery saving on those phones. After that, the complaints dropped to almost none, and we added those device models to our test list."

"First I'd halt the rollout in the Play Console so no more users get the build. If the new code sits behind a remote feature flag, I'd switch it off too, since that helps people who already updated. Then I'd post a short note to the team and support: what we're seeing, that the rollout is paused, and when I'll update them next. After that I'd dig in. I'd look at the stack traces, the device models and OS versions, and compare against what changed in this build, maybe a new library version or a camera or media API that behaves differently on that manufacturer. If I can't get the device, a cloud device lab often has it. The fix goes out as a new build with a higher version code, through internal testing first, and I'd add that device to our test list."