Scenario-Based Android App Development Interview Questions

Kotlin and Java interoperate, so migrate gradually rather than all at once. Start with new features in Kotlin, then convert leaf classes like models and utilities, writing tests before converting. Add nullability annotations to Java code so Kotlin sees correct types. Review auto-converted code because it often overuses !!. Track progress per module and agree on style rules with ktlint or detekt so the codebase stays consistent.

Common causes are the !! operator, platform types from Java code without nullability annotations, accessing a lateinit property before assignment, calling a function from a constructor before properties are initialised, and reflection-based libraries like Gson setting non-null fields to null. Fix it by removing !!, adding annotations or explicit nullable types at the Java boundary, and using a Kotlin-aware serializer such as kotlinx.serialization or Moshi with Kotlin codegen.

Explain calmly that !! converts a compile-time check into a possible runtime crash. Suggest alternatives per case: safe calls with ?.let, Elvis with a default or early return, requireNotNull with a clear message, or fixing the type at the source so it is non-null. Add a detekt rule to flag !! in new code. Pair with them on one file so the change feels like help, not criticism.

A suspend function does not automatically run off the main thread. If it calls blocking code, like a synchronous file write, a SharedPreferences commit, a blocking SDK or heavy JSON parsing, it still blocks the main thread. Check with a profiler or StrictMode. Fix by wrapping the blocking part in withContext(Dispatchers.IO) or Default, or by using main-safe APIs such as Room suspend DAOs or DataStore.

The event is probably stored as state in a StateFlow or LiveData, so it is re-delivered when the new Activity collects again. Options: model it as part of UI state and have the UI call a function like onMessageShown() to clear it after display, which is the approach the official guidance recommends; or send it through a Channel exposed with receiveAsFlow so each event is consumed once. Collect with lifecycle awareness to avoid losing events.

The work is likely launched in GlobalScope, a custom scope never cancelled, or an Application-level scope. Move it to viewModelScope so it is cancelled when the ViewModel is cleared, and make sure the calls are cancellable, which Retrofit suspend functions are. If work must outlive the screen, like uploading a file, move it to WorkManager or an application scope deliberately, and do not update UI from it.

Limit concurrency. Use a Semaphore with withPermit around each upload, or flatMapMerge(concurrency = 4) over a flow of files, or Dispatchers.IO.limitedParallelism(4). Use supervisorScope so one failed upload does not cancel the rest, collect failures for retry with backoff, and report progress through a StateFlow. If the sync must survive app exit, run it inside a CoroutineWorker with WorkManager constraints such as network connected.

The system killed the process to reclaim memory while the app was in the background. When the user returns, Android recreates the Activity but ViewModel data is gone because the process died. Fix it by storing small UI state in SavedStateHandle or rememberSaveable, which survive process death, and persisting drafts to Room or DataStore. Test with Don't keep activities or adb shell am kill.

A fragment transaction or dialog show was committed after the Activity saved its state, usually because a network callback finished while the app was in background. Committing then would lose state. Fix by triggering navigation only when the lifecycle is at least STARTED, collecting events with repeatOnLifecycle, or deferring the action. commitAllowingStateLoss hides the crash but can lose the transaction, so use it only when that is acceptable.

Use a foreground service with foregroundServiceType location, a visible notification, and the FusedLocationProviderClient with a sensible interval. Request ACCESS_FINE_LOCATION first, then ACCESS_BACKGROUND_LOCATION separately where truly needed, explaining why. Declare foreground service permissions for Android 14. Batch and upload locations efficiently, handle battery optimisation, and complete the Play Console location permissions declaration, since background location is reviewed strictly.

Test a release build with R8, since debug builds are much slower. Use Layout Inspector recomposition counts and a system trace or Macrobenchmark to find hot spots. Common fixes: add keys and contentType, avoid heavy work or sorting inside composables, move computation to the ViewModel, use derivedStateOf for scroll-based state, defer state reads with lambda modifiers like offset { }, load images at the right size with Coil, and add a Baseline Profile.

The call is placed directly in the composable body, which runs on every recomposition. Composables must be side-effect free. Move loading to the ViewModel, triggered in init or by a user event, and expose the result as StateFlow. If something must start from composition, wrap it in LaunchedEffect with a stable key like the item ID, so it runs once per key rather than on every recomposition.

Start by setting up a shared Compose theme matching the existing design system, then build new screens in Compose. Migrate leaf components and simple screens next, using ComposeView inside fragments, and leave complex custom views wrapped in AndroidView for later. Measure performance with Macrobenchmark and add Baseline Profiles. Add Compose UI and screenshot tests, train the team, and set a rule that new UI is Compose-only.

The value is probably held with remember, which is lost when the Activity is recreated. Either use rememberSaveable for local UI state, or keep the text in the ViewModel and pass it down with onValueChange. For data that must survive process death too, store it in SavedStateHandle in the ViewModel. Avoid storing text field state asynchronously, because delayed updates can cause cursor jumps.

First add tests around current behaviour so refactoring is safe. Then extract business logic into use cases or domain classes, move data mapping into repositories or mappers, and split UI state into smaller, focused data classes. If the screen truly has separate areas, consider separate state holders or child ViewModels per section. Refactor in small pull requests so reviewers can follow and regressions are easy to locate.

Each screen probably fetches and caches its own copy. Create a single CartRepository, scoped as a singleton, that owns cart data in Room or an in-memory StateFlow, and have both ViewModels observe its Flow instead of keeping private copies. Mutations go through the repository so every observer updates automatically. This enforces the single source of truth and removes the need for manual refresh calls between screens.

I would use Kotlin, Jetpack Compose with Material 3, MVVM with unidirectional data flow, Hilt for DI, Coroutines and Flow, Retrofit with OkHttp and kotlinx.serialization, Room for offline data, DataStore for preferences, WorkManager for background sync, and Navigation Compose. For fintech, add certificate pinning considerations, encrypted storage via Keystore, Play Integrity checks, and strong test coverage. Start modular from day one with core and feature modules.

Constructor-inject the repository as an interface, so tests can pass a fake implementation. With Hilt, add @Inject to the constructor and bind the real implementation in a module. Also inject dispatchers rather than using Dispatchers.IO directly. Then tests create ViewModel(FakeRepository()) and control results precisely. This change improves design too, because the ViewModel no longer knows how data is created.

Options in order of preference: pass small IDs as navigation arguments and load the rest from a repository; store flow data in a repository scoped to the session; or use a ViewModel scoped to a nested navigation graph so all checkout screens share it and it is cleared when the flow ends. Avoid activity-scoped ViewModels holding everything, and avoid passing large objects through arguments.

Interfaces let us swap implementations, mainly fakes in tests and alternate data sources, and they define clear contracts between modules so feature modules depend on abstractions instead of concrete network code. But the rule is not absolute: if a class has one implementation and is easy to test directly, an interface adds noise. I would explain the reason with an example test and our team convention.

Use a remote config service with defaults bundled in the app, wrapped in a FeatureFlags interface injected via Hilt. Fetch and cache values at startup with a sensible timeout, and read the flag at navigation decision points rather than deep inside UI code. Keep both checkout paths tested, log which variant users see for analytics, and plan to remove the old path and the flag after rollout.

Room is the single source of truth: the UI observes DAO flows and writes go to Room immediately with a sync status column like pending. A WorkManager job uploads pending changes when the network is available and pulls server changes, updating Room. Handle conflicts with timestamps or server versions, use unique work to avoid duplicate syncs, and show a small sync indicator. The app works fully without network.

Immediately halt the staged rollout in Play Console. Reproduce by installing the previous version, adding data, and upgrading. The schema version was probably increased without a matching migration, or a migration SQL does not match the new entity. Write the correct Migration, test it with MigrationTestHelper from every supported old version, and release a hotfix. Avoid destructive fallback because it deletes user data.

Some manufacturers apply aggressive battery optimisations that delay or kill background work. Check the job state with WorkManager's getWorkInfosForUniqueWorkFlow and the background task inspector in Android Studio. Verify constraints are not too strict. Guide users to allow unrestricted battery for the app only where the feature truly needs it, use expedited work for urgent tasks, and use FCM to trigger sync when timely delivery matters.

Make sure the query runs off the main thread using suspend or Flow. Use EXPLAIN QUERY PLAN to check for full table scans, and add an @Index on columns used in WHERE, JOIN or ORDER BY. Select only needed columns into a smaller data class instead of SELECT *, page results with Paging 3, and avoid loading large blobs into lists. Wrap bulk inserts in a single transaction.

Store the response in Room, or a file for a single blob, and have the screen observe the cached data immediately while a refresh runs in the background, known as stale-while-revalidate. Store a timestamp to decide when cache is too old. HTTP caching with OkHttp Cache can also help for GET requests with proper cache headers. Show cached content first, then update smoothly when fresh data arrives.

Android Auto Backup automatically backs up app data to the user's cloud backup account for apps targeting API 23 and above, unless disabled. Configure dataExtractionRules for Android 12 and above to include settings files and exclude tokens or caches. For important data like notes, sync to your own server tied to the user's account, since backup is not guaranteed. Test with adb shell bmgr commands.

Check Settings storage breakdown and inspect filesDir, cacheDir and databases with Device Explorer. Common culprits are unbounded image caches, old downloaded files, logs, and databases that never delete old rows. Set size limits on Coil and OkHttp caches, use cacheDir for temporary files so the system can clear them, delete old records with a periodic WorkManager job, and compress or downscale stored images.

Set reasonable connect and read timeouts, retry idempotent requests with exponential backoff, and cache responses so screens show something offline. Reduce payload size with gzip, pagination and fields filtering, and load images in smaller sizes with placeholders. Show clear offline and retry states instead of generic errors. Test with the emulator network throttling and real devices on poor connections, and track failure rates by network type.

Short term, make parsing lenient for that field, for example with a custom serializer, and handle parse failures without crashing. Long term, agree on API contracts with versioning, use contract tests or a shared OpenAPI schema checked in CI, add ignoreUnknownKeys and default values in kotlinx.serialization, and use remote config or a minimum supported app version mechanism. Monitor parse errors as non-fatal events.

Disable the button and show progress once tapped, but do not rely only on the UI. Generate an idempotency key on the client for each checkout attempt and send it with the request so the server returns the same result for retries. Ensure the payment call is not retried automatically by OkHttp for non-idempotent POSTs, and let the user check order status if the response is lost.

Options are polling, WebSockets, Server-Sent Events, or push notifications. For a live tracking screen, a WebSocket via OkHttp exposed as a callbackFlow works well, started when the screen is visible and closed when it leaves. Add reconnection with backoff, heartbeat pings, and fall back to polling on failure. When the app is in background, rely on FCM pushes for status changes instead of keeping the socket open.

You would use a client like Apollo Kotlin, which generates type-safe models from the schema and queries at build time, and supports normalised caching and coroutines. Benefits are fetching exactly the fields a screen needs and fewer round trips. Costs include learning the tooling, more complex caching and error handling since errors can come with partial data. I would pilot it on one feature before migrating everything.

Use an image library like Coil, which handles memory and disk caching, request downsampling to the view size, and cancellation when items scroll away. Ask the backend or CDN for resized, compressed images such as WebP instead of full-size originals. Use placeholders and crossfade, avoid holding Bitmaps in ViewModels, and set memory cache limits. Profile with Memory Profiler to confirm the large allocations are gone.

First check R8 or ProGuard: release builds shrink and obfuscate code, and the SDK may need keep rules for classes used by reflection or JSON parsing. Check the SDK documentation for required rules and add them to proguard-rules.pro. Also verify the release signing key SHA is registered with the provider, the correct production keys and base URLs are used, and network security config allows the domains.

Measure first with Macrobenchmark StartupTimingMetric on a release build. Then reduce work in Application.onCreate by deferring SDK initialisation, using App Startup or lazy injection, and moving disk I/O off the main thread. Simplify the first screen, avoid blocking on network before showing UI, use the SplashScreen API properly, and add a Baseline Profile, which often improves startup by about 20 to 30 percent.

Halt the staged rollout immediately. Filter Crashlytics or Play vitals by OS version to find the top crash, then check Android 15 behaviour changes such as edge-to-edge enforcement, foreground service rules or new restrictions affecting your target SDK. Reproduce on an Android 15 emulator, fix, add a test, and resume rollout with the hotfix. Afterward, add Android 15 devices to the regular test matrix.

Read the rejection email and policy centre message carefully to see which permission or declaration failed, often SMS, call log, background location, all-files access or exact alarms. Remove the permission if a less sensitive alternative exists, such as the SMS Retriever API or photo picker. Otherwise update the permission declaration form with a clear use case and video. Check the merged manifest for permissions added by libraries.

Analyse the build with APK Analyzer. Publish as an App Bundle so users get only their density, language and ABI. Enable R8 and resource shrinking, convert images to WebP or vectors, remove unused libraries and duplicate dependencies, and move large optional features or assets to Play Feature Delivery or Play Asset Delivery. Avoid bundling all native libraries for every ABI. Track size in CI.

Get exact device model, OS and skin versions, and steps. Use a remote device lab or Firebase Test Lab to reproduce if you lack the device. Collect logcat and bug reports, and compare behaviour around known differences like battery optimisation, autostart restrictions, custom permission dialogs or WebView versions. Add targeted logging or a non-fatal Crashlytics event, then apply a fix guarded by checks only if necessary.

Check secure storage with Keystore and no secrets in code, TLS only with pinning where justified, no sensitive data in logs, FLAG_SECURE on sensitive screens, root and tamper checks using Play Integrity, exported components reviewed, WebView with JavaScript bridges restricted, R8 obfuscation, session timeout, and biometric authentication with BiometricPrompt and CryptoObject. Use the OWASP MASVS as the checklist and fix findings by severity.

Ship it behind a remote feature flag defaulted off, release the build with a staged rollout and monitor crash-free and ANR rates. Then enable the flag for internal users, then 1, 5, 25 and 100 percent, watching business metrics and errors at each step. Keep a kill switch ready, define rollback criteria beforehand, and keep the old path until the new one is stable.

Check Android vitals for excessive wake locks and wakeups, then use Battery Historian or the Energy Profiler to look at wake locks, alarms, location requests, jobs and network activity. Common causes are frequent location updates, a foreground service left running, polling instead of push, and WorkManager jobs scheduled too often. Fix by batching work, using lower location priority, stopping services promptly and adding proper constraints.

Profile with Gradle build scans to find slow tasks. Enable the configuration cache and build cache, including a remote cache in CI. Use KSP instead of kapt, avoid unnecessary api dependencies so changes do not recompile many modules, use convention plugins, and keep non-transitive R classes. Check heavy annotation processors and give Gradle enough memory. Developers can build only the module they work on with a sample app.