Android Development Fundamentals (Kotlin/Java) Questions

Core Android concepts including Activities, Fragments, Services, lifecycle management, Intent system, memory management in Android, threading and coroutines, and common libraries (AndroidX, Jetpack). Understanding of Kotlin language features and how they're applied in Android development.

MediumTechnical

22 practiced

Describe practical strategies to ensure Android app compatibility across multiple API levels. Discuss how to use minSdkVersion, targetSdkVersion, AndroidX compatibility libraries, runtime permission handling differences, and conditional APIs or fallback implementations.

Sample Answer

**Approach summary**Explain decisions for minSdkVersion and targetSdkVersion, rely on AndroidX for backward-compatible features, handle runtime-permissions differences, and use conditional APIs with fallbacks.

**minSdkVersion vs targetSdkVersion**- Set minSdkVersion to the lowest OS you support (pragmatic balance of users vs maintenance).- Keep targetSdkVersion current to get modern platform behavior and security fixes; test regression from behavior changes when raising it.- Use Play Console metric + crash/ANR data to choose minSdk.

**AndroidX & compatibility libraries**- Use AndroidX (Jetpack) components (AppCompat, Core KTX, Lifecycle, WorkManager) for consistent APIs across levels.- Depend on AndroidX Core and AppCompat to get convenience shims (e.g., vector drawables, theming).

**Runtime permission differences**- Pre-Android 6.0 (API 23): permissions are granted at install. Post-23: request at runtime.- Always check ContextCompat.checkSelfPermission and use ActivityCompat.requestPermissions; handle onRequestPermissionsResult and provide rationales via shouldShowRequestPermissionRationale.

**Conditional APIs and fallbacks**- Check API level before calling newer APIs and provide graceful fallback:

kotlin

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
  // use new API
} else {
  // fallback implementation
}

- Prefer compatibility helper methods (e.g., NotificationCompat, WorkManager) to avoid many conditionals.- For behavior polyfills, create abstraction interfaces with implementations per-API and choose via factory.

**Testing & CI**- Use Robolectric for unit tests targeting multiple API behaviors, Firebase Test Lab / device farms for real-device testing, and lint with Android Lint and strict JVM checks.

**Trade-offs**- Raising minSdk simplifies code but drops users; heavy use of conditionals increases maintenance—balance with analytics and infra (use AndroidX where possible).

EasyTechnical

19 practiced

Explain Android memory management at a high level: the role of ART/Dalvik GC, heap vs native memory, what causes OutOfMemoryError, and common sources of memory leaks in Android apps (bitmaps, static references, long-lived callbacks).

HardTechnical

22 practiced

Propose a testing strategy for an Android application that includes unit tests, instrumentation tests, and UI tests. Specify tool choices (JUnit, Robolectric, Espresso, UIAutomator), how to structure tests to minimize flakiness, test data setup, device/emulator matrix for CI, and how to integrate tests into a CI/CD pipeline to maintain fast feedback while ensuring reliability.

Sample Answer

**Overview / Goals**Deliver fast, reliable feedback across unit, instrumentation, and UI layers while minimizing flakiness and CI cost. Use appropriate tools per layer and gate releases with stable pipelines.

**Test pyramid & tool choices**- Unit tests (fast, JVM): JUnit5 + Mockito/Kotlinx-coroutines-test + Robolectric for Android-framework behavior.- Instrumentation tests (app + framework, on-device/emulator): AndroidX Test + Espresso for in-app UI interactions; UIAutomator for cross-app/system flows.- End-to-end / smoke: real-device cloud (Firebase Test Lab or BrowserStack) running a small stable suite.

**Structure to minimize flakiness**- Keep Espresso tests deterministic: avoid Thread.sleep; use IdlingResources / CountingIdlingResource and Espresso’s built-in sync.- Mock network and time for deterministic behavior (use MockWebServer, dependency injection).- One assertion per test where practical; small, focused tests.- Clear test isolation: reset shared state in @Before/@After, use a clean app state (clear preferences/databases).

**Test data & setup**- Use fixtures and builders for objects; seed DB with test-only factories.- Use MockWebServer to serve canned JSON; support dynamic responses for edge cases.- For auth/external services use stubs or short-lived test accounts; never rely on production endpoints.

**Device/emulator matrix for CI**- Emulators (fast) for PRs: Android 11 & 13, API 29 & 33, x86 images, default locales.- Real-device cloud nightly / pre-release: representative manufacturers, API 26–33, portrait/landscape, low-memory device.- Split suites: run unit + Robolectric in parallel on PRs; run Espresso smoke tests on PRs; run full instrumentation matrix nightly.

**CI/CD integration & speed/reliability**- Run unit + Robolectric on every commit (fast, parallelized).- Gate PRs with a small critical instrumentation suite (fast Espresso tests) in CI; run full instrumentation matrix as async checks (merge blocked only on nightly/regression failures).- Use build cache, Gradle’s test parallelization, and test batching to reduce runtime.- Collect and act on flakiness metrics: track test failure rate, quarantine flaky tests, add retries (1) only with logging and tickets to fix root cause.- Report artifacts: Android Test Orchestrator, screenshots, and videos uploaded on failure for triage.

**Operational practices**- Enforce test ownership and SLAs to fix flakes within sprint.- Review new tests for determinism before merging.- Maintain CI budget: favor emulator PR checks + cloud device smoke on merge.

This yields fast feedback for developers while ensuring release confidence through broader nightly/device coverage and strict flakiness controls.

EasyTechnical

17 practiced

Compare Parcelable and Serializable for passing objects between Android components. Then, in Kotlin, implement a small data class User(id: Int, name: String) that is Parcelable. Show both the @Parcelize approach and outline how you'd write it manually if Parcelize is not available.

Sample Answer

**Compare Parcelable vs Serializable**

- Parcelable (Android-specific): much faster, designed for IPC; requires more boilerplate but less garbage/CPU. Preferred for passing objects via Intent/Bundle in production apps.- Serializable (Java): easy to implement (marker interface) but uses reflection, slower and creates more temporary objects — OK for small/debugging use but not ideal for high-performance or frequent passes.

**Kotlin — @Parcelize (recommended)**

kotlin

import kotlinx.parcelize.Parcelize
import android.os.Parcelable

@Parcelize
data class User(val id: Int, val name: String) : Parcelable

- Minimal, compile-time generated implementation. Ensure plugin: kotlin-parcelize enabled in build.gradle.

**Manual Parcelable implementation (if @Parcelize unavailable)**

kotlin

import android.os.Parcel
import android.os.Parcelable

data class User(val id: Int, val name: String) : Parcelable {
    private constructor(parcel: Parcel) : this(
        parcel.readInt(),
        parcel.readString() ?: ""
    )

    override fun writeToParcel(parcel: Parcel, flags: Int) {
        parcel.writeInt(id)
        parcel.writeString(name)
    }

    override fun describeContents(): Int = 0

    companion object CREATOR : Parcelable.Creator<User> {
        override fun createFromParcel(parcel: Parcel): User = User(parcel)
        override fun newArray(size: Int): Array<User?> = arrayOfNulls(size)
    }
}

Notes:- Prefer Parcelize for readability and fewer mistakes.- For complex nested objects, ensure those types are also Parcelable or use primitives/Strings.

EasyTechnical

19 practiced

Explain Kotlin's null-safety features and the typical patterns used in Android: nullable types, safe-call operator (?.), Elvis operator (?:), non-null assertion (!!). Also explain differences between lateinit var and lazy { } delegates and when you'd use each in an Android component.

Sample Answer

**Kotlin null-safety overview**

- Kotlin types are non-null by default: `val s: String = "hi"`. To allow null: `val s: String? = null`.- Compiler forces you to handle nullable types to avoid NPEs.

**Common operators & patterns**

- Safe-call `?.` — call only if not null, returns null otherwise:

kotlin

val len = user?.name?.length

- Elvis `?:` — provide a default when left side is null:

kotlin

val display = user?.name ?: "Anonymous"

- Non-null assertion `!!` — force unwrap, throws NPE if null (avoid except for quick checks):

kotlin

val must = user!!.id

- Smart casts — `if (s != null) { /* s treated as non-null */ }`

**lateinit vs lazy**

- `lateinit var` (mutable, non-null) — for vars initialized later (e.g., view references, injected deps). Useful in Android components where lifecycle supplies value:

kotlin

lateinit var binding: ActivityMainBinding
override fun onCreate(...) {
  super.onCreate(...)
  binding = ActivityMainBinding.inflate(layoutInflater)
}

- `val lazy { }` (immutable, thread-safe by default) — deferred initialization on first access, good for expensive computations or singletons:

kotlin

private val repo by lazy { RepoImpl() }

**When to use which**- Use `lateinit` for lifecycle-initialized, mutable properties (views, DI fields) where you guarantee init before use.- Use `lazy` for read-only, possibly expensive initialization that you want only when needed.

Keep `!!` rare; prefer safe-call + Elvis or explicit checks to provide robust Android code.

Unlock Full Question Bank

Get access to hundreds of Android Development Fundamentals (Kotlin/Java) interview questions and detailed answers.

Join thousands of developers preparing for their dream job.