Question Bank

The Activity lifecycle has 7 callbacks. Understanding what triggers each is critical for managing resources correctly.

// Activity Lifecycle flow:
// onCreate → onStart → onResume → [RUNNING]
// [RUNNING] → onPause → onStop → onDestroy

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Initialize UI, ViewModels, one-time setup
    }

    override fun onResume() {
        super.onResume()
        // Activity is visible & interactive — start sensors, animations
    }

    override fun onPause() {
        super.onPause()
        // Partially hidden — pause sensors, save quick state
    }

    override fun onStop() {
        super.onStop()
        // Fully hidden — release heavy resources
    }

    override fun onDestroy() {
        super.onDestroy()
        // Final cleanup
    }
}

• Home button: onPause → onStop (Activity stays in memory, NOT destroyed)
• Back button: onPause → onStop → onDestroy (Activity is destroyed)
• Screen rotation: onPause → onStop → onDestroy → onCreate → onStart → onResume
• Another Activity opens: current Activity gets onPause → onStop
• Use onSaveInstanceState() to save UI state before destruction

Fragments have their own lifecycle that is tightly coupled to the host Activity. In 2024+, the recommended approach is to observe lifecycle in onViewCreated(), never onCreate().

class HomeFragment : Fragment(R.layout.fragment_home) {

    // viewLifecycleOwner vs this (fragment) — KEY difference
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        // ✅ Use viewLifecycleOwner for UI observations
        viewModel.data.observe(viewLifecycleOwner) { data ->
            updateUi(data)
        }

        // ❌ Never use 'this' — causes memory leaks!
        // viewModel.data.observe(this) { ... }
    }

    override fun onDestroyView() {
        super.onDestroyView()
        // View is destroyed but Fragment instance lives on
        // Clean up view binding here!
        _binding = null
    }
}

• Fragment has extra callbacks: onCreateView, onViewCreated, onDestroyView
• viewLifecycleOwner tracks the view's lifecycle, not the Fragment's — use it for UI observations
• Fragment can survive its view being destroyed (back stack) — always null binding in onDestroyView
• When Activity stops → Fragment also gets onStop; when Activity destroys → Fragment destroys too

Intents are messaging objects used to request an action. Explicit intents target a specific component; implicit intents declare an action and let the system find the right component.

// EXPLICIT INTENT — you know exactly which component to start
val explicitIntent = Intent(this, DetailActivity::class.java).apply {
    putExtra("userId", "123")
    putExtra("userName", "Rahul")
}
startActivity(explicitIntent)

// IMPLICIT INTENT — declare action, system decides handler
val shareIntent = Intent(Intent.ACTION_SEND).apply {
    type = "text/plain"
    putExtra(Intent.EXTRA_TEXT, "Check out Droidly!")
}
startActivity(Intent.createChooser(shareIntent, "Share via"))

// PENDING INTENT — for future execution (notifications, widgets)
val pendingIntent = PendingIntent.getActivity(
    context, 0, explicitIntent,
    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
)

// INTENT FLAGS — control back stack behavior
Intent(this, HomeActivity::class.java).apply {
    flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK
}

• Explicit: startActivity, start Service — within your own app
• Implicit: share, dial, open URL — uses intent filters to match
• PendingIntent: wraps an Intent for future use — used in notifications, AlarmManager, widgets
• FLAG_IMMUTABLE: required from Android 12+ for PendingIntents — always add it
• From Android 13+: explicit intents required to start services from other apps

Background work has evolved significantly in Android. WorkManager is now the recommended solution for most background tasks.

// WorkManager — RECOMMENDED for guaranteed background work
class SyncWorker(ctx: Context, params: WorkerParameters) : CoroutineWorker(ctx, params) {

    override suspend fun doWork(): Result {
        return try {
            syncDataWithServer()
            Result.success()
        } catch (e: Exception) {
            Result.retry() // automatic retry with backoff
        }
    }
}

// Schedule with constraints
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresBatteryNotLow(true)
    .build()

val workRequest = PeriodicWorkRequestBuilder<SyncWorker>(15, TimeUnit.MINUTES)
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context).enqueueUniquePeriodicWork(
    "sync", ExistingPeriodicWorkPolicy.KEEP, workRequest
)

// Foreground Service — for ongoing user-visible work
class MusicService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        startForeground(NOTIFICATION_ID, buildNotification())
        return START_STICKY
    }
}

• Service: runs on main thread — needs manual threading, use for ongoing tasks
• IntentService: deprecated in API 30 — use WorkManager or CoroutineWorker instead
• WorkManager: guaranteed execution, survives app kills and reboots, constraint-aware
• Foreground Service: for user-visible long-running work (music, navigation) — requires notification
• From Android 14: must declare foreground service type in manifest

Context is the gateway to Android system resources. Using the wrong Context type is a common cause of memory leaks.

// Activity Context — tied to Activity lifecycle
// ✅ Use for: UI operations, dialogs, layouts, startActivity
val dialog = AlertDialog.Builder(this) // 'this' = Activity context
startActivity(Intent(this, DetailActivity::class.java))

// Application Context — lives for the entire app lifetime
// ✅ Use for: singletons, databases, repos, long-lived objects
class AppDatabase {
    companion object {
        fun create(context: Context) =
            Room.databaseBuilder(
                context.applicationContext, // ✅ not context directly!
                AppDatabase::class.java, "app.db"
            ).build()
    }
}

// ❌ MEMORY LEAK — storing Activity context in singleton
object BadSingleton {
    lateinit var context: Context // Never do this with Activity context!
}

// ✅ CORRECT — use applicationContext in singletons
object GoodSingleton {
    lateinit var appContext: Context
    fun init(context: Context) { appContext = context.applicationContext }
}

• Activity Context: use for UI — dialogs, layouts, themes, startActivity
• Application Context: use in singletons, repositories, Room, Retrofit, WorkManager
• Storing Activity context in a long-lived object = memory leak (Activity can't be GC'd)
• applicationContext has no access to UI theming — dialogs will crash if created with it

Android's permission model has evolved significantly. Runtime permissions (API 23+), one-time permissions, and partial access permissions are the current landscape.

// Request runtime permission — modern approach with ActivityResult API
val requestPermission = registerForActivityResult(
    ActivityResultContracts.RequestPermission()
) { isGranted ->
    if (isGranted) {
        accessCamera()
    } else {
        // Check if user said "Don't ask again"
        if (!shouldShowRequestPermissionRationale(Manifest.permission.CAMERA)) {
            showSettingsDialog() // Direct user to app settings
        } else {
            showRationale() // Explain why you need it
        }
    }
}

// Android 13+ — granular media permissions
// READ_EXTERNAL_STORAGE replaced by:
// READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO

// Android 14 — Photo picker partial access
// READ_MEDIA_VISUAL_USER_SELECTED — user selects specific photos

// Android 13 — POST_NOTIFICATIONS permission required
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
    requestPermission.launch(Manifest.permission.POST_NOTIFICATIONS)
}

• Android 13: Granular media permissions — READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO instead of READ_EXTERNAL_STORAGE
• Android 13: POST_NOTIFICATIONS is now a runtime permission — must request it
• Android 14: Photo Picker partial access — READ_MEDIA_VISUAL_USER_SELECTED
• Android 14: SCHEDULE_EXACT_ALARM moved to SCHEDULE_EXACT_ALARM permission group
• Never request permissions at app start — always request at the point of use

BroadcastReceiver listens for system-wide or app-specific events. How you register it determines its lifecycle and when it receives broadcasts.

// Dynamic registration — registered in code, tied to component lifecycle
class NetworkActivity : AppCompatActivity() {

    private val networkReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context, intent: Intent) {
            val isConnected = intent.getBooleanExtra("isConnected", false)
            updateNetworkUI(isConnected)
        }
    }

    override fun onResume() {
        super.onResume()
        val filter = IntentFilter("com.app.NETWORK_CHANGED")
        registerReceiver(networkReceiver, filter, RECEIVER_NOT_EXPORTED) // Android 14+
    }

    override fun onPause() {
        super.onPause()
        unregisterReceiver(networkReceiver) // ALWAYS unregister!
    }
}

// Static registration — in AndroidManifest.xml
// <receiver android:name=".BootReceiver" android:exported="false">
//   <intent-filter>
//     <action android:name="android.intent.action.BOOT_COMPLETED"/>
//   </intent-filter>
// </receiver>

• Dynamic: register in code — only active while component is alive; must unregister
• Static (manifest): receives broadcasts even when app is not running — but limited by Android 8+ background restrictions
• Most implicit broadcasts blocked for static receivers since Android 8.0 — use dynamic registration
• Android 14: must pass RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED flag when registering
• BroadcastReceiver runs on the main thread — do no heavy work inside onReceive()

Android can kill your app's process at any time when it's in the background. There are 3 layers of state survival, each with different scope and capacity.

// Layer 1: ViewModel — survives config changes ONLY
@HiltViewModel
class SearchViewModel @Inject constructor(
    private val savedState: SavedStateHandle // Layer 2
) : ViewModel() {

    // Layer 2: SavedStateHandle — survives process death
    // Small data only — backed by Bundle
    val searchQuery = savedState.getStateFlow("query", "")

    fun updateQuery(q: String) {
        savedState["query"] = q // automatically persisted
    }
}

// Layer 3: onSaveInstanceState — last resort for Activity/Fragment UI state
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("key", value) // small primitives only
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    val restored = savedInstanceState?.getString("key")
}

• ViewModel: survives rotation only — lost on process death; good for large data
• SavedStateHandle: survives process death — backed by Bundle; small primitives only (<50KB)
• onSaveInstanceState: Activity/Fragment-level, called before kill; emergency backup for tiny state
• Room/DataStore: for data that must always survive — disk persistence
• Test process death: Developer Options → "Don't keep activities" or adb shell am kill

Predictive Back (Android 13+) gives users a preview of where the back gesture will take them before they complete the gesture. It requires opting in and updating your back handling code.

// Step 1: Opt-in in AndroidManifest.xml
// <application android:enableOnBackInvokedCallback="true">

// Step 2: Use OnBackPressedDispatcher — NOT deprecated onBackPressed()
class FormActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Modern back handling with lifecycle awareness
        onBackPressedDispatcher.addCallback(this) {
            if (hasUnsavedChanges) {
                showDiscardDialog()
            } else {
                isEnabled = false
                onBackPressedDispatcher.onBackPressed() // let system handle
            }
        }
    }
}

// In Compose — BackHandler composable
@Composable
fun FormScreen(hasUnsavedChanges: Boolean) {
    BackHandler(enabled = hasUnsavedChanges) {
        showDiscardDialog()
    }
}

• Predictive Back shows a live preview animation before the back gesture completes
• Must opt in via android:enableOnBackInvokedCallback="true" in manifest
• onBackPressed() is deprecated — use OnBackPressedDispatcher or Compose BackHandler
• Android 14 enforces predictive back on all apps targeting API 34+
• Custom animations possible with OnBackAnimationCallback

Android 12 introduced the official SplashScreen API that replaces the old SplashActivity/WindowBackground hack. It's mandatory for apps targeting API 31+ and shows instantly even before your app code runs.

// Step 1: Add dependency
// implementation("androidx.core:core-splashscreen:1.0.1")

// Step 2: Define theme in res/values/themes.xml
// <style name="Theme.App.Starting" parent="Theme.SplashScreen">
//   <item name="windowSplashScreenBackground">@color/green</item>
//   <item name="windowSplashScreenAnimatedIcon">@drawable/ic_logo</item>
//   <item name="postSplashScreenTheme">@style/Theme.App</item>
// </style>

// Step 3: Set as activity theme in manifest
// android:theme="@style/Theme.App.Starting"

// Step 4: Install in Activity.onCreate() BEFORE setContentView
class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        val splashScreen = installSplashScreen() // MUST be before super.onCreate()
        super.onCreate(savedInstanceState)

        // Keep splash visible until data is ready
        splashScreen.setKeepOnScreenCondition {
            !viewModel.isDataReady.value
        }

        // Add custom exit animation
        splashScreen.setOnExitAnimationListener { splashView ->
            splashView.iconView.animate()
                .scaleX(0f).scaleY(0f)
                .setDuration(300)
                .withEndAction { splashView.remove() }
                .start()
        }

        setContentView(R.layout.activity_main)
    }
}

• SplashScreen API shows before any app code runs — no more white flash on cold start
• installSplashScreen() must be called before super.onCreate()
• setKeepOnScreenCondition — keep splash visible while loading initial data
• setOnExitAnimationListener — custom exit animations when splash dismisses
• Old SplashActivity pattern adds extra Activity hop — slower and deprecated

Both are used to pass data between Android components, but they differ significantly in performance and implementation. In 2025, the recommended approach is to use the Kotlin Parcelize plugin.

// ❌ Serializable — uses Java reflection, slow, lots of temp objects
data class User(val id: String, val name: String) : Serializable

// ✅ Parcelable — fast, no reflection, Android-optimized
// Manual implementation (verbose)
class User(val id: String, val name: String) : Parcelable {
    constructor(parcel: Parcel) : this(parcel.readString()!!, parcel.readString()!!)
    override fun writeToParcel(parcel: Parcel, flags: Int) {
        parcel.writeString(id); parcel.writeString(name)
    }
    override fun describeContents() = 0
    companion object CREATOR : Parcelable.Creator<User> {
        override fun createFromParcel(p: Parcel) = User(p)
        override fun newArray(size: Int) = arrayOfNulls<User>(size)
    }
}

// ✅✅ @Parcelize — best of both worlds, zero boilerplate (RECOMMENDED)
@Parcelize
data class User(val id: String, val name: String) : Parcelable

// Pass via Intent
putExtra("user", user)      // sending
getParcelableExtra("user", User::class.java) // receiving (API 33+)

• Serializable: Java interface, uses reflection — ~10x slower than Parcelable
• Parcelable: Android-specific, no reflection, written to shared memory — very fast
• @Parcelize: Kotlin annotation that auto-generates Parcelable code — use this always
• Enable with id("kotlin-parcelize") plugin in build.gradle
• From API 33: use getParcelableExtra(key, Class) — old version is deprecated

Launch modes control how Activities are instantiated and placed in the back stack. Getting this wrong leads to unexpected navigation behavior.

// Defined in AndroidManifest.xml
// <activity android:launchMode="singleTop" />

// STANDARD (default) — new instance always created
// Stack: A → B → B → B  (pressing B 3 times = 3 instances)

// SINGLE TOP — reuses top instance if already at top
// Stack: A → B  (pressing B again calls onNewIntent(), not new instance)
// Stack: A → B → A → B  (B not at top → new instance created)

// SINGLE TASK — one instance per task, clears above it
// Stack: A → B → C → (launch A) → A  (B and C are destroyed!)
// Use for: MainActivity, deep link entry points

// SINGLE INSTANCE — own task, no other activities
// Isolated in its own back stack
// Use for: Launcher activities, maps, camera

// Handle reuse in onNewIntent()
override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)
    setIntent(intent) // update getIntent() to return new one
    val data = intent.getStringExtra("key")
    handleNewData(data)
}

• standard: default — every launch creates a new instance, every time
• singleTop: reuses if already on top of stack — great for notifications
• singleTask: one instance per task, brings to front and clears above it
• singleInstance: completely isolated in its own task stack
• Always override onNewIntent() when using singleTop or singleTask

Deep linking allows external sources to navigate directly into your app. Android 2025 best practice is App Links (HTTP/HTTPS) over custom schemes.

// 1. Custom URI scheme — unreliable, any app can intercept
// myapp://product/123  ← bad, can be hijacked

// 2. App Links (Verified HTTP) — RECOMMENDED
// https://myapp.com/product/123  ← verified, only your app opens it

// AndroidManifest.xml — declare intent filter
// <intent-filter android:autoVerify="true">
//   <action android:name="android.intent.action.VIEW"/>
//   <category android:name="android.intent.category.DEFAULT"/>
//   <category android:name="android.intent.category.BROWSABLE"/>
//   <data android:scheme="https" android:host="myapp.com"/>
// </intent-filter>

// Host assetlinks.json at:
// https://myapp.com/.well-known/assetlinks.json

// Handle in Activity
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    val action = intent?.action
    val data: Uri? = intent?.data
    if (Intent.ACTION_VIEW == action && data != null) {
        val productId = data.lastPathSegment // "123" from /product/123
        navigateToProduct(productId)
    }
}

// Navigation Compose — deep link support built in
composable(
    route = "product/{id}",
    deepLinks = listOf(navDeepLink {
        uriPattern = "https://myapp.com/product/{id}"
    })
) { backStackEntry ->
    ProductScreen(id = backStackEntry.arguments?.getString("id"))
}

• Custom scheme (myapp://): no verification, any app can handle it — avoid
• App Links (https://): verified via assetlinks.json — only your app handles it
• android:autoVerify="true": triggers verification at install time
• Navigation Compose has built-in deep link support with navDeepLink { }
• Test with: adb shell am start -W -a android.intent.action.VIEW -d "https://myapp.com/product/123"

ANR (Application Not Responding) occurs when the main thread is blocked for too long. Android shows a dialog giving users the option to wait or force-close the app.

// ANR triggers:
// Input dispatch timeout  → 5 seconds (key/touch events)
// BroadcastReceiver       → 10 seconds (foreground), 60s (background)
// Service start/bind      → 20 seconds

// ❌ Common ANR causes on main thread
fun onCreate(...) {
    val data = readFile()           // disk IO on main thread
    val user = api.getUser().execute() // network on main thread
    Thread.sleep(6000)              // sleeping main thread
    db.query("SELECT * FROM users")   // DB query on main thread
}

// ✅ Fix — move to coroutines
fun onCreate(...) {
    lifecycleScope.launch {
        val data = withContext(Dispatchers.IO) { readFile() }
        updateUi(data) // back on Main automatically
    }
}

// Enable StrictMode to catch violations in development
if (BuildConfig.DEBUG) {
    StrictMode.setThreadPolicy(
        StrictMode.ThreadPolicy.Builder()
            .detectDiskReads()
            .detectNetwork()
            .penaltyLog()
            .build()
    )
}

• Input timeout: 5s — most common; touch/key events blocked on main thread
• Use StrictMode in debug builds to catch accidental main-thread IO
• Diagnose via: Play Console → Android Vitals → ANRs, or pull traces.txt from device
• Use adb shell dumpsys activity to check what the main thread is doing
• Deadlocks between coroutines and main thread are a sneaky ANR cause

These three SDK settings control compatibility and which APIs you can use. Getting them wrong causes crashes, broken features, or Play Store rejections.

// build.gradle.kts
android {
    compileSdk = 35   // API level used to COMPILE your code
                       // Must be ≥ targetSdk
                       // Use latest stable always

    defaultConfig {
        minSdk = 24    // Minimum Android version your app supports
                       // API 24 = Android 7.0 = ~97% of devices

        targetSdk = 35 // API level your app is TESTED against
                       // Android applies compatibility behaviors based on this
                       // Google Play requires ≥ 34 for new apps (2024)
                       // Google Play requires ≥ 35 for new apps (Aug 2025)
    }
}

// What targetSdk affects:
// targetSdk 31+ → PendingIntent.FLAG_IMMUTABLE required
// targetSdk 33+ → POST_NOTIFICATIONS runtime permission
// targetSdk 34+ → Foreground service type required in manifest
// targetSdk 35+ → Edge-to-edge enforced by default

// Runtime check for API level
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
    // API 33+ only code
}

• compileSdk: which APIs you can reference in code — use latest always
• minSdk: lowest Android version your app installs on — affects device reach
• targetSdk: what Android version you've tested against — enables new OS behaviors
• Google Play requires targetSdk ≥ 34 for existing apps and ≥ 35 for new apps from Aug 2025
• Raising targetSdk without testing can break your app with new OS behavior changes

Edge-to-edge means your app draws behind the status bar and navigation bar. From Android 15 (targetSdk 35), this is enforced by default — apps must handle insets or UI will be overlapped.

// MainActivity — enable edge-to-edge
override fun onCreate(savedInstanceState: Bundle?) {
    enableEdgeToEdge() // androidx.activity 1.8.0+
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
}

// Handle insets in XML views
// ViewCompat.setOnApplyWindowInsetsListener(view) { v, insets ->
//   val bars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
//   v.updatePadding(bottom = bars.bottom)
//   insets
// }

// In Jetpack Compose — use WindowInsets directly
@Composable
fun MainScreen() {
    Scaffold(
        // Scaffold handles insets automatically
        contentWindowInsets = WindowInsets.safeDrawing
    ) { paddingValues ->
        LazyColumn(
            contentPadding = paddingValues // avoids system bars
        ) { /* items */ }
    }
}

// For specific insets in Compose
val statusBarHeight = WindowInsets.statusBars.asPaddingValues().calculateTopPadding()
val navBarHeight = WindowInsets.navigationBars.asPaddingValues().calculateBottomPadding()

• From targetSdk 35: edge-to-edge is enforced — you can no longer opt out
• Use enableEdgeToEdge() from androidx.activity — replaces manual window flag setting
• In Compose: Scaffold handles most insets automatically if used correctly
• Watch out for: bottom sheets, FABs, and BottomNavigation overlapping nav bar
• Use WindowInsets.safeDrawing for content that needs to avoid all system UI

Push notifications in 2025 use FCM (Firebase Cloud Messaging). The flow covers token management, foreground/background handling, and Android 13+ permission requirements.

// Step 1: Request POST_NOTIFICATIONS permission (Android 13+)
val requestPermission = registerForActivityResult(
    ActivityResultContracts.RequestPermission()
) { granted -> if (!granted) showPermissionRationale() }

if (Build.VERSION.SDK_INT >= 33) {
    requestPermission.launch(Manifest.permission.POST_NOTIFICATIONS)
}

// Step 2: FCM Service — handle messages
class MyFCMService : FirebaseMessagingService() {

    // Called when new token generated (first launch, token refresh)
    override fun onNewToken(token: String) {
        // Send to your backend immediately
        CoroutineScope(Dispatchers.IO).launch {
            api.updateFcmToken(token)
        }
    }

    // Called for FOREGROUND messages (data or notification)
    override fun onMessageReceived(message: RemoteMessage) {
        val title = message.notification?.title ?: message.data["title"]
        val body  = message.notification?.body  ?: message.data["body"]
        showNotification(title, body, message.data)
    }
}

// Step 3: Build notification with channel
fun showNotification(title: String?, body: String?, data: Map<String, String>) {
    val channelId = "orders"
    // Create channel (required API 26+)
    val channel = NotificationChannel(channelId, "Order Updates", NotificationManager.IMPORTANCE_HIGH)
    getSystemService(NotificationManager::class.java).createNotificationChannel(channel)

    val notification = NotificationCompat.Builder(this, channelId)
        .setSmallIcon(R.drawable.ic_notification)
        .setContentTitle(title)
        .setContentText(body)
        .setAutoCancel(true)
        .setContentIntent(buildPendingIntent(data))
        .build()

    NotificationManagerCompat.from(this).notify(1, notification)
}

• Android 13+: POST_NOTIFICATIONS is a runtime permission — must request it
• FCM data messages: always delivered to onMessageReceived() — full control
• FCM notification messages: shown automatically by system when app is in background
• Use data messages for full control; notification messages for simplicity
• NotificationChannels are required from API 26 — without them, notifications are silently dropped

App Startup is a Jetpack library that provides a straightforward way to initialize components at app startup, replacing multiple ContentProviders with a single one and allowing parallel initialization.

// Problem: each library's ContentProvider adds ~2ms to startup
// Firebase, WorkManager, Timber each register ContentProviders
// 10 libraries = ~20ms extra cold start time

// Solution: App Startup merges all into ONE ContentProvider

// 1. Implement Initializer for each library
class TimberInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        if (BuildConfig.DEBUG) Timber.plant(Timber.DebugTree())
    }
    override fun dependencies(): List<Class<out Initializer<*>>> =
        emptyList() // no dependencies
}

class AnalyticsInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Analytics.init(context)
    }
    // Declare dependencies — Analytics needs Timber first
    override fun dependencies() = listOf(TimberInitializer::class.java)
}

// 2. Lazy initialization — don't init until needed
val heavyComponent by lazy {
    HeavyComponent() // only created on first access
}

// 3. Measure startup with Macrobenchmark
// adb shell am start -W -n com.app/.MainActivity
// Look for: TotalTime in output

• Each ContentProvider adds ~2ms to app startup — App Startup consolidates them into one
• Dependency ordering: declare what each initializer depends on
• Lazy init: only initialize when first needed, not at app start
• Use lazy { } for ViewModels, repositories, and non-critical singletons
• Measure with Macrobenchmark library or adb shell am start -W

These three visibility states affect both rendering and layout measurement differently — a common source of layout bugs when not understood correctly.

// VISIBLE — drawn and takes up space (default)
view.visibility = View.VISIBLE

// INVISIBLE — NOT drawn but STILL takes up space
// Other views position themselves as if it's there
view.visibility = View.INVISIBLE

// GONE — NOT drawn AND does NOT take up space
// Layout recalculates as if view doesn't exist
view.visibility = View.GONE

// Compose equivalent
@Composable
fun MyComponent(isVisible: Boolean) {
    // VISIBLE / GONE equivalent
    if (isVisible) {
        Text("Hello") // not rendered when false (like GONE)
    }

    // INVISIBLE equivalent in Compose
    Box(modifier = Modifier.alpha(if (isVisible) 1f else 0f)) {
        Text("Hello") // invisible but still takes space
    }

    // AnimatedVisibility — smooth transition
    AnimatedVisibility(visible = isVisible) {
        Text("Hello")
    }
}

// Performance tip: prefer GONE over INVISIBLE
// INVISIBLE still triggers measure/layout passes
// GONE skips them entirely → better performance

• VISIBLE: drawn + takes space — normal state
• INVISIBLE: not drawn but still occupies space — use for placeholder animations
• GONE: not drawn and no space — sibling views reposition — use for show/hide
• INVISIBLE still runs measure/layout — GONE is more performant in lists
• Compose equivalent: if(condition) = GONE behavior; alpha(0f) = INVISIBLE behavior

Baseline Profiles allow you to pre-compile critical code paths ahead of time, dramatically reducing startup time and improving runtime performance. In 2025, Google strongly recommends them for all production apps.

// Baseline Profiles — pre-compile critical code paths
// Reduces: startup time by up to 40%, jank, and JIT compilation overhead

// 1. Add dependencies
// implementation("androidx.profileinstaller:profileinstaller:1.3.1")
// androidTestImplementation("androidx.benchmark:benchmark-macro-junit4:1.2.3")

// 2. Create BaselineProfileGenerator test
@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {

    @get:Rule val rule = BaselineProfileRule()

    @Test
    fun generate() = rule.collect(packageName = "com.myapp") {
        // Simulate critical user journey
        pressHome()
        startActivityAndWait()          // cold start
        device.waitForIdle()
        // Navigate through main flows
        findObject(By.text("Browse")).click()
        device.waitForIdle()
    }
}

// 3. Generate profile
// ./gradlew generateBaselineProfile
// Profile saved to: src/main/baseline-prof.txt

// 4. Profile is bundled with AAB and installed by Play Store
// ART pre-compiles critical methods before first launch

// Startup Profiles — even faster startup (subset of Baseline)
// Mark critical classes with StartupProfileRule

• ART normally JIT-compiles code at runtime — first launch is slow
• Baseline Profiles pre-compile critical paths — up to 40% faster startup
• Delivered via Play Store with your AAB — users get pre-compiled code from first install
• Generate by running real user journeys in a Macrobenchmark test
• Google Play also generates Cloud Profiles from real user data automatically

ContentProvider is one of Android's four core components. It manages access to a structured set of data and allows sharing data between apps securely using a URI-based interface.

// ContentProvider — expose your data to other apps
class UserContentProvider : ContentProvider() {

    override fun onCreate(): Boolean {
        // Initialize database
        return true
    }

    override fun query(
        uri: Uri, projection: Array<String>?, selection: String?,
        selectionArgs: Array<String>?, sortOrder: String?
    ): Cursor? {
        return db.query("users", projection, selection, selectionArgs, null, null, sortOrder)
    }

    override fun getType(uri: Uri) = "vnd.android.cursor.dir/users"
    override fun insert(uri: Uri, values: ContentValues?) = null
    override fun delete(uri: Uri, s: String?, a: Array<String>?) = 0
    override fun update(uri: Uri, v: ContentValues?, s: String?, a: Array<String>?) = 0
}

// Access another app's ContentProvider via ContentResolver
val cursor = contentResolver.query(
    ContactsContract.Contacts.CONTENT_URI,
    null, null, null, null
)
cursor?.use {
    while (it.moveToNext()) {
        val name = it.getString(it.getColumnIndex(ContactsContract.Contacts.DISPLAY_NAME))
    }
}

// Declare in manifest
// <provider android:name=".UserContentProvider"
//   android:authorities="com.myapp.provider"
//   android:exported="false" />

• ContentProvider exposes data to other apps via a standardized URI interface
• System providers: Contacts, MediaStore, Calendar, SMS — all use ContentProvider
• For internal app data sharing — use Room directly, not ContentProvider
• android:exported="false" — keep private unless intentionally sharing with other apps
• FileProvider is a special ContentProvider for securely sharing files between apps (camera, downloads)

LiveData is lifecycle-aware but Android-platform dependent. StateFlow is a Kotlin-first, coroutine-based alternative that works everywhere and has better performance. In 2025, StateFlow is the recommended choice.

// LiveData — lifecycle-aware, Android-only
class UserViewModel : ViewModel() {
    private val _user = MutableLiveData<User>()
    val user: LiveData<User> = _user

    // ❌ LiveData issues:
    // - Android-only, not testable without Android framework
    // - No initial value required
    // - setValue() must be called on main thread
    // - No built-in operators (map, filter, combine)
}

// StateFlow — Kotlin-first, coroutine-native (RECOMMENDED 2025)
class UserViewModel : ViewModel() {
    private val _user = MutableStateFlow<User?>(null)
    val user: StateFlow<User?> = _user.asStateFlow()

    // ✅ StateFlow benefits:
    // - Works in pure Kotlin/KMM — no Android dependency
    // - Always has a current value (.value)
    // - Rich operators: map, filter, combine, flatMapLatest
    // - Thread-safe — can update from any thread
}

// Collect in Fragment (both are lifecycle-safe)
// LiveData
viewModel.user.observe(viewLifecycleOwner) { user -> updateUi(user) }

// StateFlow — use repeatOnLifecycle to avoid collecting in background
viewLifecycleOwner.lifecycleScope.launch {
    viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.user.collect { user -> updateUi(user) }
    }
}

// Convert LiveData → Flow if migrating
val userFlow = viewModel.user.asFlow()

• LiveData: Android-only, simpler, good for quick prototypes — being phased out
• StateFlow: Kotlin-first, works in KMM, better operators, testable without Android — recommended
• Always use repeatOnLifecycle(STARTED) to stop collecting when app is backgrounded
• Never use lifecycleScope.launch { flow.collect { } } without repeatOnLifecycle — leaks in background
• Google's official guidance since 2022: prefer StateFlow over LiveData for new code

RecyclerView is the View-system list component. LazyColumn is its Compose equivalent. They solve the same problem — efficiently rendering large lists — but with different APIs and paradigms.

// RecyclerView — View system (XML)
class UserAdapter : ListAdapter<User, UserAdapter.ViewHolder>(DiffCallback()) {

    class ViewHolder(view: View) : RecyclerView.ViewHolder(view) {
        fun bind(user: User) { itemView.findViewById<TextView>(R.id.name).text = user.name }
    }

    override fun onCreateViewHolder(parent: ViewGroup, type: Int) =
        ViewHolder(LayoutInflater.from(parent.context).inflate(R.layout.item_user, parent, false))

    override fun onBindViewHolder(holder: ViewHolder, position: Int) =
        holder.bind(getItem(position))

    class DiffCallback : DiffUtil.ItemCallback<User>() {
        override fun areItemsTheSame(old: User, new: User) = old.id == new.id
        override fun areContentsTheSame(old: User, new: User) = old == new
    }
}

// LazyColumn — Jetpack Compose equivalent
@Composable
fun UserList(users: List<User>) {
    LazyColumn(
        contentPadding = PaddingValues(16.dp),
        verticalArrangement = Arrangement.spacedBy(8.dp)
    ) {
        items(users, key = { it.id }) { user ->  // key = stable identity
            UserCard(user)
        }
        item { LoadMoreButton() } // easily add headers/footers
    }
}

// LazyColumn with Paging 3
val users: LazyPagingItems<User> = viewModel.usersPaged.collectAsLazyPagingItems()
LazyColumn {
    items(users, key = { it.id }) { user -> UserCard(user) }
}

• RecyclerView: View system — needs Adapter, ViewHolder, DiffUtil — more boilerplate
• LazyColumn: Compose — declarative, much less code, key parameter handles diffing
• Both only compose/render visible items — efficient for large lists
• Always provide a key in LazyColumn items — prevents recomposition and animation glitches
• Use ListAdapter (not basic RecyclerView.Adapter) — built-in DiffUtil on background thread

Doze mode kicks in when the device is stationary, screen off, and unplugged — it restricts network, wakelocks, GPS, alarms, and syncs to periodic maintenance windows. App Standby buckets (Android 9+) restrict background work based on how recently the user interacted with your app. WorkManager is the correct API because it schedules around both restrictions transparently.

val work = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)
        .setRequiresBatteryNotLow(true)
        .build())
    .build()
WorkManager.getInstance(context).enqueue(work)

// AlarmManager.setExactAndAllowWhileIdle() — fires in Doze, use sparingly
alarmManager.setExactAndAllowWhileIdle(
    AlarmManager.RTC_WAKEUP, triggerMs, pendingIntent
)

// FCM high-priority messages bypass Doze and wake the device
// Foreground services are exempt from Doze network restrictions

• Doze blocks: network, wakelocks, alarms, JobScheduler — until the next maintenance window
• App Standby buckets: ACTIVE → WORKING → FREQUENT → RARE → RESTRICTED — more restrictions as usage drops
• WorkManager is Doze-aware — it reschedules work for the next maintenance window automatically
• FCM high-priority messages pierce Doze — the only reliable way to wake a Dozed device
• setExactAndAllowWhileIdle(): fires during Doze but Android limits call frequency — use for urgent alarms only

These three classes form Android's thread messaging system. While modern code uses coroutines, understanding Handler/Looper is still tested heavily in interviews because the Android framework itself uses them internally.

// Looper — message loop attached to a thread
// Main thread has a Looper by default
// Background threads need Looper.prepare() manually

// MessageQueue — FIFO queue of Messages/Runnables
// Each Looper has exactly one MessageQueue

// Handler — posts/processes messages to a Looper's queue
class MyWorkerThread : Thread() {
    lateinit var handler: Handler

    override fun run() {
        Looper.prepare()               // create Looper for this thread
        handler = Handler(Looper.myLooper()!!)
        Looper.loop()                  // start processing messages
    }
}

// Post to main thread from background
val mainHandler = Handler(Looper.getMainLooper())
mainHandler.post {
    updateUi() // runs on main thread
}

// Post delayed (use sparingly — prefer coroutines + delay())
mainHandler.postDelayed({ hideToast() }, 2000)

// Modern equivalent with coroutines
lifecycleScope.launch {
    delay(2000)
    hideToast() // runs on Main dispatcher
}

// How Android uses Handler internally:
// ViewRootImpl posts draw calls via Handler
// Activity callbacks are delivered via Handler
// AsyncTask used Handler internally (now deprecated)

• Looper: runs an infinite message loop on a thread — main thread has one by default
• MessageQueue: the FIFO queue attached to each Looper
• Handler: posts Messages or Runnables to a Looper's queue for execution on that thread
• Use Handler for: posting to main thread, delayed execution, inter-thread communication
• Modern preference: coroutines + Dispatchers — cleaner and cancellable

ViewBinding is the modern, type-safe way to access views in XML layouts. It replaces both the error-prone findViewById and the heavier DataBinding for most use cases.

// Enable in build.gradle.kts
android { buildFeatures { viewBinding = true } }

// ViewBinding — generates a binding class per layout file
class HomeFragment : Fragment(R.layout.fragment_home) {

    private var _binding: FragmentHomeBinding? = null
    private val binding get() = _binding!!

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        _binding = FragmentHomeBinding.bind(view)
        binding.tvTitle.text = "Hello"   // type-safe, no cast needed
        binding.btnSubmit.setOnClickListener { submit() }
    }

    override fun onDestroyView() {
        super.onDestroyView()
        _binding = null  // IMPORTANT: prevent memory leak
    }
}

// vs DataBinding — more powerful but heavier
// Supports: two-way binding, binding expressions in XML, ObservableFields
// <layout><data><variable name="vm" type="UserViewModel"/></data></layout>
// android:text="@{vm.userName}" — expression evaluated in XML

// vs findViewById — error prone
val title = findViewById<TextView>(R.id.tvTitle) // ClassCastException risk
// No null safety — NullPointerException if ID doesn't exist in layout

• findViewById: no type safety, no null safety, no performance benefit
• ViewBinding: type-safe, null-safe, fast (compile-time generation) — recommended
• DataBinding: superset of ViewBinding — adds XML expressions and two-way binding — use when needed
• ViewBinding compiles faster than DataBinding (no annotation processing)
• Always null the binding in onDestroyView() to avoid Fragment memory leaks

Foldable and large screen support became a major focus for Google in 2023-25. Apps must handle dynamic window size classes, multi-pane layouts, and configuration changes from folding/unfolding.

// WindowSizeClass — categorizes screen size
// implementation("androidx.window:window:1.2.0")

@Composable
fun AdaptiveLayout() {
    val windowSizeClass = calculateWindowSizeClass(LocalContext.current as Activity)

    when (windowSizeClass.widthSizeClass) {
        WindowWidthSizeClass.COMPACT  -> SinglePaneLayout()   // phone portrait
        WindowWidthSizeClass.MEDIUM   -> TabletLayout()       // foldable unfolded
        WindowWidthSizeClass.EXPANDED -> TwoPaneLayout()      // tablet/desktop
    }
}

// Jetpack Adaptive — list-detail layout
// implementation("androidx.compose.material3.adaptive:adaptive:1.0.0")
@Composable
fun EmailApp() {
    ListDetailPaneScaffold(
        directive = calculatePaneScaffoldDirective(currentWindowAdaptiveInfo()),
        value = rememberListDetailPaneScaffoldNavigator<Email>(),
        listPane = { EmailList() },
        detailPane = { EmailDetail() }
    )
}

// Handle fold state changes
val foldingFeature = WindowInfoTracker
    .getOrCreate(this)
    .windowLayoutInfo(this)
    .map { it.displayFeatures.filterIsInstance<FoldingFeature>().firstOrNull() }

// Manifest — support resizable activity
// android:resizeableActivity="true"
// android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation"

• WindowSizeClass: COMPACT (phone), MEDIUM (foldable/small tablet), EXPANDED (large tablet)
• Use adaptive layouts that respond to size class changes, not fixed screen size checks
• Jetpack's ListDetailPaneScaffold: handles list-detail pattern automatically across sizes
• FoldingFeature: detect hinge position — use for "table-top" mode in camera apps
• android:resizeableActivity="true" required for multi-window and foldable support

Jetpack Navigation Component provides a framework for navigating between screens, managing the back stack, and handling deep links consistently — in both Fragment-based and Compose apps.

// Navigation Compose (2025 recommendation)
@Composable
fun AppNavGraph() {
    val navController = rememberNavController()

    NavHost(navController, startDestination = "home") {
        composable("home") { HomeScreen(navController) }
        composable(
            route = "detail/{userId}",
            arguments = listOf(navArgument("userId") { type = NavType.StringType }),
            deepLinks = listOf(navDeepLink { uriPattern = "app://detail/{userId}" })
        ) { entry ->
            DetailScreen(userId = entry.arguments?.getString("userId"))
        }
        composable("settings") { SettingsScreen() }
    }
}

// Navigate with popUpTo to control back stack
navController.navigate("home") {
    popUpTo("login") { inclusive = true }  // remove login from back stack
    launchSingleTop = true                   // avoid duplicate destinations
}

// Type-safe navigation (Navigation 2.8+ with Kotlin Serialization)
@Serializable object HomeRoute
@Serializable data class DetailRoute(val userId: String)

navController.navigate(DetailRoute(userId = "123")) // type-safe!

• Single Activity pattern — Navigation manages Fragment/Compose destination back stack
• popUpTo + inclusive: controls which destinations are removed from back stack on navigate
• launchSingleTop: prevents duplicate destinations (like pressing home tab twice)
• Navigation 2.8+ introduced type-safe routes using @Serializable — recommended for new code
• NavController automatically handles deep links declared in composable() destinations

Android security is multi-layered. A production app must protect data at rest, in transit, and at the code level. This is a common senior-level interview topic in 2025-26.

// 1. Network Security — Certificate Pinning
// res/xml/network_security_config.xml
// <network-security-config>
//   <domain-config>
//     <domain includeSubdomains="true">api.myapp.com</domain>
//     <pin-set>
//       <pin digest="SHA-256">base64EncodedPin</pin>
//     </pin-set>
//   </domain-config>
// </network-security-config>

// Or via OkHttp CertificatePinner
val pinner = CertificatePinner.Builder()
    .add("api.myapp.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
    .build()
val client = OkHttpClient.Builder().certificatePinner(pinner).build()

// 2. Secure Storage — Android Keystore
val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()
val securePrefs = EncryptedSharedPreferences.create(
    context, "secure", masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

// 3. Code obfuscation — R8/ProGuard
// build.gradle.kts
// isMinifyEnabled = true  → shrinks + obfuscates

// 4. Root/Emulator detection (for banking apps)
// Use SafetyNet Attestation API or Play Integrity API
// Play Integrity API (replaces SafetyNet from 2024)

// 5. Prevent screenshots on sensitive screens
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    window.addFlags(WindowManager.LayoutParams.FLAG_SECURE)
}

• SSL/Certificate Pinning: prevents MITM attacks — verify server cert against known pin
• Android Keystore: hardware-backed key storage — keys never leave the device
• R8/ProGuard: obfuscates class/method names — makes reverse engineering harder
• Play Integrity API: replaces SafetyNet — verifies app/device integrity (banking apps)
• FLAG_SECURE: prevents screenshots and screen recording on sensitive screens

ConstraintLayout allows building complex UIs with a flat view hierarchy — no nesting needed. This dramatically improves rendering performance compared to nested LinearLayouts or RelativeLayouts.

<!-- ConstraintLayout — flat hierarchy, no nesting needed -->
<androidx.constraintlayout.widget.ConstraintLayout>

    <!-- Chain — distribute views horizontally/vertically -->
    <TextView android:id="@+id/tvTitle"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintEnd_toEndOf="parent" />

    <!-- Guideline — invisible positioning reference -->
    <androidx.constraintlayout.widget.Guideline
        android:orientation="vertical"
        app:layout_constraintGuide_percent="0.5" />

    <!-- Barrier — dynamic constraint based on multiple views -->
    <androidx.constraintlayout.widget.Barrier
        app:barrierDirection="end"
        app:constraint_referenced_ids="tvLabel1,tvLabel2" />

</androidx.constraintlayout.widget.ConstraintLayout>

// MotionLayout — subclass for animations
// Animate between two ConstraintSets
// Define in MotionScene XML file
motionLayout.transitionToEnd() // trigger animation

// In Compose: ConstraintLayout also available
// implementation("androidx.constraintlayout:constraintlayout-compose:1.0.1")
@Composable
fun ProfileCard() {
    ConstraintLayout {
        val (image, name, bio) = createRefs()
        Image(modifier = Modifier.constrainAs(image) { top.linkTo(parent.top) })
        Text(modifier = Modifier.constrainAs(name) { top.linkTo(image.bottom) })
    }
}

• Flat hierarchy: one ConstraintLayout replaces many nested LinearLayouts — fewer measure passes
• Guideline: invisible helper for percentage-based positioning
• Barrier: dynamic constraint that adjusts based on the largest of multiple views
• Chain: distribute multiple views evenly (spread, packed, weighted)
• MotionLayout: subclass for declarative animations between two constraint states

AndroidManifest.xml is the app's blueprint — it tells the Android system everything about your app before any code runs. Every component, permission, and configuration must be declared here.

<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Permissions -->
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.CAMERA" />

    <!-- Hardware features -->
    <uses-feature android:name="android.hardware.camera" android:required="false" />

    <application
        android:name=".MyApp"            <!-- Custom Application class -->
        android:theme="@style/AppTheme"
        android:networkSecurityConfig="@xml/network_security_config"
        android:enableOnBackInvokedCallback="true"  <!-- Predictive Back -->
        android:largeHeap="false">          <!-- avoid unless necessary -->

        <!-- Entry point activity -->
        <activity android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTop">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <!-- android:exported required for all components targeting API 31+ -->
        <service android:name=".MyFCMService" android:exported="false" />
        <receiver android:name=".BootReceiver" android:exported="false">
        <provider android:name=".MyProvider" android:authorities="com.app.provider" />

    </application>
</manifest>

• Declares all 4 components: Activity, Service, BroadcastReceiver, ContentProvider
• android:exported required for all components targeting API 31+ — crash if missing
• uses-feature android:required="false" — makes feature optional (don't block installs)
• Merge manifests: libraries inject their own manifest entries — check merged manifest in AS
• tools:remove and tools:replace for overriding library manifest entries

Paging 3 is the Jetpack library for loading large datasets in pages. It handles loading states, error handling, retry, and integrates with Room and Retrofit out of the box.

// 1. PagingSource — defines how to load data
class UserPagingSource(
    private val api: UserApi
) : PagingSource<Int, User>() {

    override suspend fun load(params: LoadParams<Int>): LoadResult<Int, User> {
        val page = params.key ?: 1
        return try {
            val response = api.getUsers(page = page, size = params.loadSize)
            LoadResult.Page(
                data = response.users,
                prevKey = if (page == 1) null else page - 1,
                nextKey = if (response.users.isEmpty()) null else page + 1
            )
        } catch (e: Exception) { LoadResult.Error(e) }
    }

    override fun getRefreshKey(state: PagingState<Int, User>) =
        state.anchorPosition?.let { state.closestPageToPosition(it)?.prevKey?.plus(1) }
}

// 2. ViewModel — create Pager
val users = Pager(PagingConfig(pageSize = 20)) {
    UserPagingSource(api)
}.flow.cachedIn(viewModelScope)

// 3. Compose UI
val lazyPagingItems = viewModel.users.collectAsLazyPagingItems()
LazyColumn {
    items(lazyPagingItems, key = { it.id }) { user ->
        if (user != null) UserCard(user)
    }
    if (lazyPagingItems.loadState.append is LoadState.Loading) {
        item { CircularProgressIndicator() }
    }
}

• PagingSource: defines data loading logic — handles pages and keys
• Pager: creates a Flow of PagingData from PagingSource
• cachedIn(viewModelScope): caches pages so they survive recomposition/rotation
• RemoteMediator: combines network + Room for offline-first paging
• Built-in loading states: refresh, prepend, append — handle in UI easily

Accessibility ensures your app is usable by people with disabilities. Google Play now audits accessibility and it's asked in interviews at companies like Google and Flipkart.

// Views — content descriptions for screen readers
imageView.contentDescription = "Profile photo of Rahul"
iconButton.contentDescription = "Share this post"

// Decorative images — hide from accessibility
decorativeImage.importantForAccessibility = View.IMPORTANT_FOR_ACCESSIBILITY_NO

// Group related views for TalkBack
// android:focusable="true" on parent
// android:importantForAccessibility="yes"

// Compose — semantics
@Composable
fun LikeButton(isLiked: Boolean, onClick: () -> Unit) {
    IconButton(
        onClick = onClick,
        modifier = Modifier.semantics {
            contentDescription = if (isLiked) "Unlike post" else "Like post"
            role = Role.Button
            stateDescription = if (isLiked) "Liked" else "Not liked"
        }
    ) { Icon(imageVector = if (isLiked) Icons.Filled.Favorite else Icons.Outlined.FavoriteBorder) }
}

// Merge semantics — treat group as one accessible element
Row(modifier = Modifier.semantics(mergeDescendants = true) {}) {
    Image(/*...*/)
    Text("Rahul — Android Developer")
}

// Test accessibility
// Enable TalkBack in Accessibility Settings
// Use Accessibility Scanner app from Google
// Run: ./gradlew connectedAndroidTest with AccessibilityChecks

• Always add contentDescription to images, icons, and non-text interactive elements
• Minimum touch target size: 48x48dp — required by Material Design guidelines
• In Compose: use semantics { } modifier to describe UI to accessibility services
• mergeDescendants = true: groups child semantics into one accessible unit
• Test with TalkBack enabled — navigate your app without looking at the screen

Android 15 and 16 continue tightening security, privacy, and predictive-back. The biggest developer-facing changes are edge-to-edge enforcement, health-connect updates, and stricter broadcast receiver rules.

// Edge-to-edge enforcement (Android 15) -- window insets required
ViewCompat.setOnApplyWindowInsetsListener(rootView) { v, insets ->
    val bars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
    v.setPadding(bars.left, bars.top, bars.right, bars.bottom)
    insets
}

// Predictive Back -- must opt-in via manifest
// android:enableOnBackInvokedCallback="true"
onBackPressedDispatcher.addCallback(this) {
    // custom back logic -- runs with predictive back animation
}

// Foreground service types now mandatory for specific use cases
// android:foregroundServiceType="dataSync|mediaPlayback|location"

• Edge-to-edge is enforced in Android 15 -- apps that don't handle window insets will have UI clipped behind system bars
• Predictive back gesture: opt-in via android:enableOnBackInvokedCallback=true in manifest, then use OnBackPressedDispatcher
• Foreground service types: must declare the type in manifest and pass it to startForeground() -- missing type = crash on Android 14+
• Health Connect 2.0: new data types, background read permissions tightened
• Stricter broadcast receivers: dynamically registered receivers must explicitly declare RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED

KMM (now called Kotlin Multiplatform) allows sharing business logic between Android, iOS, and other platforms while keeping native UI for each. It became stable in 2023 and is increasingly asked in 2025-26 interviews.

// KMP Project Structure
// ├── shared/
// │   ├── commonMain/     ← shared Kotlin code (business logic)
// │   ├── androidMain/    ← Android-specific implementations
// │   └── iosMain/        ← iOS-specific implementations
// ├── androidApp/         ← Android UI (Jetpack Compose)
// └── iosApp/             ← iOS UI (SwiftUI)

// shared/commonMain — pure Kotlin, no platform APIs
class UserRepository(
    private val api: UserApi,
    private val db: UserDatabase
) {
    suspend fun getUsers(): List<User> {
        return try {
            val users = api.fetchUsers()
            db.insertAll(users)
            users
        } catch (e: Exception) { db.getAllUsers() }
    }
}

// expect/actual — platform-specific implementations
// commonMain
expect fun getPlatformName(): String

// androidMain
actual fun getPlatformName() = "Android ${Build.VERSION.SDK_INT}"

// iosMain
actual fun getPlatformName() = UIDevice.currentDevice.systemName()

// KMP libraries (multiplatform-ready)
// Ktor         → networking
// SQLDelight   → database
// kotlinx.serialization → JSON
// kotlinx.coroutines    → async
// Koin         → dependency injection

• Share: business logic, data models, repositories, use cases, networking
• Keep native: UI (Compose for Android, SwiftUI for iOS)
• expect/actual: declare an interface in common, implement per platform
• KMP is stable since 1.9.20 (Nov 2023) — production-ready
• Companies using KMM: Netflix, Philips, VMware, McDonald's, Cash App

IPC (Inter-Process Communication) allows different processes to communicate. Android provides several IPC mechanisms — AIDL is the most powerful but also the most complex.

// IPC mechanisms in Android (simplest → most complex):
// 1. Intent/Bundle    → between components, same/different apps
// 2. ContentProvider  → structured data sharing
// 3. Messenger        → simple message passing between processes
// 4. AIDL             → full bidirectional, multi-threaded IPC

// AIDL — Android Interface Definition Language
// Step 1: Define interface in .aidl file
// IUserService.aidl
// interface IUserService {
//     User getUser(String id);
//     List<User> getAllUsers();
// }

// Step 2: Implement in Service
class UserService : Service() {
    private val binder = object : IUserService.Stub() {
        override fun getUser(id: String): User {
            // runs on Binder thread pool — NOT main thread
            return db.findUser(id)
        }
        override fun getAllUsers(): List<User> = db.getAll()
    }
    override fun onBind(intent: Intent) = binder
}

// Step 3: Bind from client
private var userService: IUserService? = null
val connection = object : ServiceConnection {
    override fun onServiceConnected(name: ComponentName, binder: IBinder) {
        userService = IUserService.Stub.asInterface(binder)
    }
    override fun onServiceDisconnected(name: ComponentName) { userService = null }
}
bindService(Intent(this, UserService::class.java), connection, BIND_AUTO_CREATE)

• AIDL generates boilerplate for Binder IPC — methods run on Binder thread pool, not main thread
• Use AIDL when: multiple clients call service concurrently, complex data types needed
• Use Messenger when: simple sequential messages, no concurrent calls needed
• AIDL supported types: primitives, String, CharSequence, List, Map, Parcelable
• Always handle RemoteException when calling AIDL methods from client

Scoped Storage (Android 10+) restricts apps to their own files and specific media collections. The old READ_EXTERNAL_STORAGE approach no longer works for most use cases in Android 13+.

// Android 13+ — granular media permissions
// READ_MEDIA_IMAGES  → access photos
// READ_MEDIA_VIDEO   → access videos
// READ_MEDIA_AUDIO   → access audio
// READ_MEDIA_VISUAL_USER_SELECTED → partial access (Android 14+)

// Query images with MediaStore
suspend fun getAllImages(context: Context): List<Uri> =
    withContext(Dispatchers.IO) {
        val images = mutableListOf<Uri>()
        val collection = MediaStore.Images.Media.getContentUri(MediaStore.VOLUME_EXTERNAL)
        val projection = arrayOf(MediaStore.Images.Media._ID, MediaStore.Images.Media.DISPLAY_NAME)
        context.contentResolver.query(collection, projection, null, null, "date_added DESC")
            ?.use { cursor ->
                val idCol = cursor.getColumnIndex(MediaStore.Images.Media._ID)
                while (cursor.moveToNext()) {
                    val id = cursor.getLong(idCol)
                    images.add(ContentUris.withAppendedId(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, id))
                }
            }
        images
    }

// Write a file to app-specific storage (no permissions needed)
val file = File(context.getExternalFilesDir(Environment.DIRECTORY_PICTURES), "photo.jpg")

// Save to shared MediaStore (needs WRITE permission on API < 29)
val values = ContentValues().apply {
    put(MediaStore.Images.Media.DISPLAY_NAME, "photo.jpg")
    put(MediaStore.Images.Media.MIME_TYPE, "image/jpeg")
    put(MediaStore.Images.Media.RELATIVE_PATH, "Pictures/MyApp")
}
val uri = context.contentResolver.insert(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, values)

• Scoped Storage: apps can only access their own files + media via MediaStore
• App-specific dirs (getFilesDir(), getExternalFilesDir()): no permissions needed
• Android 13+: READ_EXTERNAL_STORAGE replaced by granular media permissions
• Photo Picker API: best UX — no permissions needed, user selects photos directly
• MANAGE_EXTERNAL_STORAGE: only for file managers — Google Play heavily restricts it

BiometricPrompt is the modern, unified API for fingerprint, face, and iris authentication. It replaces the deprecated FingerprintManager and handles all biometric types automatically.

// Add dependency
// implementation("androidx.biometric:biometric:1.1.0")

// Step 1: Check biometric availability
val biometricManager = BiometricManager.from(context)
when (biometricManager.canAuthenticate(BiometricManager.Authenticators.BIOMETRIC_STRONG)) {
    BiometricManager.BIOMETRIC_SUCCESS          -> showBiometricPrompt()
    BiometricManager.BIOMETRIC_ERROR_NO_HARDWARE -> showPasswordFallback()
    BiometricManager.BIOMETRIC_ERROR_NONE_ENROLLED -> promptUserToEnroll()
}

// Step 2: Build and show prompt
fun showBiometricPrompt(activity: FragmentActivity) {
    val promptInfo = BiometricPrompt.PromptInfo.Builder()
        .setTitle("Unlock App")
        .setSubtitle("Use your fingerprint or face to authenticate")
        .setAllowedAuthenticators(
            BiometricManager.Authenticators.BIOMETRIC_STRONG or
            BiometricManager.Authenticators.DEVICE_CREDENTIAL // PIN fallback
        )
        .build()

    val biometricPrompt = BiometricPrompt(activity,
        object : BiometricPrompt.AuthenticationCallback() {
            override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
                // result.cryptoObject — use for crypto operations if needed
                unlockApp()
            }
            override fun onAuthenticationError(errorCode: Int, errString: CharSequence) {
                showError(errString.toString())
            }
            override fun onAuthenticationFailed() {
                // Called on failed attempt — don't show error yet (system handles retries)
            }
        }
    )
    biometricPrompt.authenticate(promptInfo)
}

• BiometricPrompt handles fingerprint, face, and iris — no need to differentiate
• BIOMETRIC_STRONG: hardware-backed biometrics (Class 3) — for banking apps
• DEVICE_CREDENTIAL: PIN/pattern/password fallback — always include this
• CryptoObject: combine with Keystore for cryptographically-bound authentication
• FingerprintManager is deprecated since API 28 — never use it in new code

Custom Views let you draw anything on the canvas. Understanding the three phases — measure, layout, draw — is essential for building reusable UI components and is a common senior interview question.

class CircularProgressView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : View(context, attrs, defStyleAttr) {

    private val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply {
        style = Paint.Style.STROKE
        strokeWidth = 12f
        color = 0xFF4CAF50.toInt()
    }
    private val oval = RectF()
    var progress: Float = 0f
        set(value) { field = value.coerceIn(0f, 100f); invalidate() } // trigger redraw

    // Phase 1: MEASURE — determine size
    override fun onMeasure(widthSpec: Int, heightSpec: Int) {
        val desiredSize = 200
        val width = MeasureSpec.getSize(widthSpec).coerceAtLeast(desiredSize)
        setMeasuredDimension(width, width) // must call this!
    }

    // Phase 2: LAYOUT — called after measure, gives final size
    override fun onSizeChanged(w: Int, h: Int, oldW: Int, oldH: Int) {
        val padding = paint.strokeWidth / 2
        oval.set(padding, padding, w - padding, h - padding)
    }

    // Phase 3: DRAW — paint on canvas
    override fun onDraw(canvas: Canvas) {
        // Draw background track
        paint.color = 0xFFE0E0E0.toInt()
        canvas.drawArc(oval, 0f, 360f, false, paint)
        // Draw progress arc
        paint.color = 0xFF4CAF50.toInt()
        canvas.drawArc(oval, -90f, progress * 3.6f, false, paint)
    }
}

// Never do heavy work in onDraw — called 60fps
// Never allocate objects in onDraw — causes GC pressure
// Use invalidate() to trigger redraw
// Use postInvalidateOnAnimation() for smooth animations

• onMeasure: determine view dimensions — must call setMeasuredDimension()
• onSizeChanged/onLayout: final size known — pre-calculate positions here
• onDraw: paint on canvas — called every frame, must be fast
• Never allocate objects in onDraw (no Paint(), RectF()) — declare as fields
• Use invalidate() to request a redraw; requestLayout() to re-measure

The JVM is Oracle's Java Virtual Machine running on desktop and server -- it executes Java bytecode. DVM (Dalvik) was Android's original runtime, optimised for constrained devices using register-based architecture and DEX files. ART (Android Runtime) replaced Dalvik in Android 5.0 and compiles code ahead-of-time at install, dramatically improving performance. Today all Android devices use ART.

// Build pipeline: Kotlin source → bytecode (.class) → DEX (.dex) → APK/AAB
// kotlinc compiles .kt → .class, then D8/R8 converts .class → .dex

// ART AOT compilation at install time:
// dex2oat converts DEX → native machine code (.oat) for the device CPU
// Subsequent launches execute pre-compiled native code -- no JIT warmup

// Profile-guided compilation (Android 7+):
// First run: interpreted + JIT profiling
// Background: dex2oat compiles hot methods from profile
// Later runs: hot paths execute as native code

// Baseline Profiles force AOT for your declared critical paths at install

• JVM: runs on servers/desktop, class files, large heap -- not designed for mobile constraints
• DVM: register-based (faster than JVM's stack-based), DEX format (smaller than class files), one process per app
• ART: replaced DVM in Android 5.0 -- AOT compiles DEX to native at install, faster startup and execution
• D8: the dex compiler -- converts Java bytecode to DEX. R8 extends D8 with shrinking and obfuscation
• Profile-guided JIT (Android 7+): hot methods profiled at runtime then compiled to native in the background

AlarmManager triggers actions at specific times, even when your app isn't running. WorkManager handles deferrable background work. They serve different purposes and are often confused.

// AlarmManager — time-specific execution
// Use when: exact time matters, user-scheduled reminders, calendar events
val alarmManager = getSystemService(AlarmManager::class.java)
val intent = PendingIntent.getBroadcast(
    context, 0,
    Intent(context, ReminderReceiver::class.java),
    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
)

// Exact alarm — requires SCHEDULE_EXACT_ALARM permission (API 31+)
if (alarmManager?.canScheduleExactAlarms() == true) {
    alarmManager.setExactAndAllowWhileIdle(
        AlarmManager.RTC_WAKEUP,
        triggerTimeMs,
        intent
    )
}

// WorkManager — constraint-based, guaranteed execution
// Use when: network sync, file upload, data backup
val workRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setInitialDelay(15, TimeUnit.MINUTES) // NOT exact timing
    .setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build())
    .build()

// Decision table:
// Exact time reminder (alarm clock) → AlarmManager.setExact()
// Periodic sync (15+ min intervals)  → WorkManager PeriodicWorkRequest
// Upload on WiFi when charging        → WorkManager with Constraints
// Timer/countdown in app              → Handler.postDelayed() or delay()

• AlarmManager: exact time — alarm clocks, calendar reminders, time-sensitive notifications
• WorkManager: constraint-based, deferrable — syncs, uploads, background tasks
• SCHEDULE_EXACT_ALARM: runtime permission required from Android 12+
• AlarmManager resets on device reboot — must re-schedule in BOOT_COMPLETED receiver
• WorkManager survives reboots automatically — preferred for most background tasks

SparseArray is an Android-specific data structure that maps integer keys to Object values, avoiding the autoboxing overhead of HashMap<Int, Any> when keys are integers.

// HashMap<Int, User> — autoboxes int to Integer every access
// Creates Integer objects → GC pressure → avoid in performance-critical code
val hashMap = HashMap<Int, User>()
hashMap[1] = user // int 1 gets autoboxed to Integer(1)

// SparseArray — no autoboxing, uses binary search
// Efficient for small-to-medium maps (< ~1000 items)
val sparseArray = SparseArray<User>()
sparseArray.put(1, user)          // no boxing
val user = sparseArray.get(1)     // no unboxing
sparseArray.delete(1)

// Kotlin variants
val sparseIntArray  = SparseIntArray()    // Int → Int
val sparseBoolArray = SparseBooleanArray() // Int → Boolean
val sparseLongArray = SparseLongArray()   // Int → Long

// Use SparseArray when:
// ✅ Keys are integers (view IDs, item positions, user IDs)
// ✅ Small-to-medium data sets (<1000 items)
// ✅ Performance critical code (RecyclerView, custom views)

// Use HashMap when:
// ✅ Keys are non-integer types (String, Enum, complex objects)
// ✅ Large datasets (>1000 items) — HashMap O(1) vs SparseArray O(log n)
// ✅ Need map iteration with entrySet()

• SparseArray avoids Integer autoboxing — key performance benefit for integer keys
• Uses binary search (O(log n)) — HashMap is O(1) for large sets
• Android Lint warns when you use HashMap<Int, *> — suggests SparseArray instead
• For Map<Int, Int> use SparseIntArray; for Map<Int, Boolean> use SparseBooleanArray
• Not thread-safe — same as HashMap, needs external synchronization

Bitmaps are the largest source of OOM (OutOfMemory) errors in Android. Understanding bitmap memory allocation and reuse is critical for building smooth image-heavy apps.

// Bitmap memory size = width × height × bytes per pixel
// ARGB_8888 (default): 4 bytes/pixel
// RGB_565: 2 bytes/pixel (no alpha, half memory)
// 1080×1920 ARGB_8888 = ~8MB per image!

// ❌ Never load full bitmap — sample it down first
fun decodeSampledBitmap(path: String, reqWidth: Int, reqHeight: Int): Bitmap {
    return BitmapFactory.Options().run {
        inJustDecodeBounds = true            // decode size only
        BitmapFactory.decodeFile(path, this)
        inSampleSize = calculateInSampleSize(this, reqWidth, reqHeight)
        inJustDecodeBounds = false           // now decode actual pixels
        BitmapFactory.decodeFile(path, this)
    }
}

// ✅ BitmapPool — reuse existing bitmap memory
// Instead of allocating new bitmap: reuse one of same dimensions
// Coil/Glide maintain a LruCache of unused bitmaps
val options = BitmapFactory.Options().apply {
    inBitmap = pooledBitmap   // reuse existing memory!
    inMutable = true
}

// ✅ Use Coil (recommended 2025) for auto bitmap management
@Composable
fun UserAvatar(url: String) {
    AsyncImage(
        model = ImageRequest.Builder(LocalContext.current)
            .data(url)
            .crossfade(true)
            .size(200, 200) // downsample to display size
            .build(),
        contentDescription = null
    )
}

// Bitmap configs
// ARGB_8888 → full quality (default)
// RGB_565   → no alpha, 2x memory saving (icons, backgrounds)
// HARDWARE  → stored in GPU memory, fastest rendering (API 26+)

• Always decode with inSampleSize — never load full-res into memory unnecessarily
• BitmapPool: reuse bitmap memory allocations — prevents GC thrashing in lists
• Coil/Glide handle pooling, sampling, caching automatically — prefer them over manual loading
• HARDWARE bitmaps (API 26+): stored in GPU memory — fastest rendering but immutable
• Use Bitmap.recycle() only if you manually manage bitmaps — not needed with Coil/Glide

App Widgets are mini views that live on the home screen. Android 12 introduced Glance (Jetpack Compose-style) and new widget APIs that make widgets more dynamic and interactive.

// Modern App Widget with Glance (Compose-style) — RECOMMENDED 2025
// implementation("androidx.glance:glance-appwidget:1.0.0")

class WeatherWidget : GlanceAppWidget() {
    override suspend fun provideGlance(context: Context, id: GlanceId) {
        val prefs = currentState<Preferences>()
        val temp = prefs[intPreferencesKey("temperature")] ?: 0

        provideContent {
            Column(modifier = GlanceModifier.fillMaxSize().background(Color.White)) {
                Text(text = "${temp}°C", style = TextStyle(fontSize = 24.sp))
                Button(text = "Refresh", onClick = actionRunCallback<RefreshAction>())
            }
        }
    }
}

// Update widget data
class RefreshAction : ActionCallback {
    override suspend fun onAction(context: Context, glanceId: GlanceId, parameters: ActionParameters) {
        val temp = api.getTemperature()
        updateAppWidgetState(context, glanceId) { prefs ->
            prefs[intPreferencesKey("temperature")] = temp
        }
        WeatherWidget().update(context, glanceId)
    }
}

// Declare in manifest
// <receiver android:name=".WeatherWidgetReceiver">
//   <intent-filter>
//     <action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
//   </intent-filter>
//   <meta-data android:name="android.appwidget.provider" android:resource="@xml/widget_info" />
// </receiver>

• Glance: Jetpack Compose-style API for widgets — recommended over RemoteViews for new code
• Android 12: responsive layouts, dynamic colors, rounded corners in widgets
• Widget updates limited by system — use WorkManager to fetch data, then update widget
• RemoteViews: old API — still needed for non-Glance cases and lock screen widgets
• Widget size: specify targetCellWidth/Height in AppWidgetProviderInfo for Android 12+

With Android fragmentation (minSdk vs latest API), backward compatibility requires runtime checks, AndroidX libraries, and proper API guarding to avoid crashes on older devices.

// Runtime API level check
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) { // API 31+
    // Use API 31+ feature safely
    window.setDecorFitsSystemWindows(false)
} else {
    // Fallback for older devices
}

// @RequiresApi — lint annotation, NOT a runtime check
@RequiresApi(Build.VERSION_CODES.S)
fun useBlurEffect(view: View) {
    view.setRenderEffect(RenderEffect.createBlurEffect(10f, 10f, Shader.TileMode.CLAMP))
}
// Caller must guard with SDK_INT check — @RequiresApi just suppresses lint

// AndroidX — backported APIs with consistent behavior
// ✅ Use ActivityResultContracts instead of onActivityResult (deprecated)
// ✅ Use WindowCompat instead of Window flags directly
// ✅ Use NotificationCompat instead of Notification
// ✅ Use ContextCompat.checkSelfPermission instead of checkSelfPermission

// Example: WindowCompat handles SDK differences internally
WindowCompat.setDecorFitsSystemWindows(window, false) // works API 17+

// BuildConfig for conditional features
if (BuildConfig.DEBUG) {
    StrictMode.enableDefaults()
    Timber.plant(Timber.DebugTree())
}

// @SuppressLint for known safe usages
@SuppressLint("NewApi")
fun guardedApiCall() {
    if (Build.VERSION.SDK_INT >= 33) { /* safe */ }
}

• Always check Build.VERSION.SDK_INT before using APIs above minSdk
• @RequiresApi suppresses lint — it's NOT a runtime guard, must still check SDK_INT
• AndroidX libraries handle SDK differences internally — prefer Compat classes always
• Use ContextCompat, NotificationCompat, WindowCompat for consistent behavior
• Test on your minSdk device/emulator — the most common source of Play Store crashes

StrictMode is a developer tool that detects accidental disk reads, network calls on the main thread, and leaked resources — and can crash or log your app when these occur during development.

class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()

        if (BuildConfig.DEBUG) {
            // ThreadPolicy — main thread violations
            StrictMode.setThreadPolicy(
                StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()          // SharedPreferences on main thread
                    .detectDiskWrites()
                    .detectNetwork()             // network on main thread
                    .detectCustomSlowCalls()    // StrictMode.noteSlowCall()
                    .penaltyLog()               // log to Logcat
                    .penaltyDeath()             // crash the app (strict!)
                    .build()
            )

            // VmPolicy — memory & resource violations
            StrictMode.setVmPolicy(
                StrictMode.VmPolicy.Builder()
                    .detectLeakedSqlLiteObjects()    // unclosed Cursor/DB
                    .detectLeakedClosableObjects()    // unclosed streams
                    .detectActivityLeaks()            // Activity not GC'd
                    .detectFileUriExposure()          // file:// URI exposure
                    .penaltyLog()
                    .build()
            )
        }
    }
}

// Mark a slow operation for StrictMode tracking
fun loadConfig() {
    val token = StrictMode.allowThreadDiskReads() // temporarily allow
    try { readConfigFile() }
    finally { StrictMode.setThreadPolicy(token) } // restore policy
}

• ThreadPolicy: catches disk/network on main thread — most common ANR causes
• VmPolicy: catches leaked cursors, unclosed streams, activity leaks
• Always wrap in BuildConfig.DEBUG — never ship StrictMode to production
• Use penaltyLog() first, switch to penaltyDeath() when cleaning up violations
• allowThreadDiskReads(): temporarily suppress for known-safe operations

WebView embeds a web browser in your app. It's powerful but introduces significant security risks — especially JavaScript interface bridges — that are frequently exploited and asked about in security-focused interviews.

val webView: WebView = findViewById(R.id.webView)

// ✅ Secure WebView setup
webView.settings.apply {
    javaScriptEnabled = true           // only if needed
    allowFileAccess = false             // ✅ disable file access
    allowContentAccess = false          // ✅ disable content provider access
    setSupportZoom(false)
    mixedContentMode = WebSettings.MIXED_CONTENT_NEVER_ALLOW // ✅ no HTTP in HTTPS
}

// ❌ DANGEROUS — exposes entire Java bridge to ALL JS on page
webView.addJavascriptInterface(myObject, "Android")
// Any JS on the page can call Android.sensitiveMethod()
// XSS attack can steal data or call dangerous methods

// ✅ SAFE — validate origin before executing JS bridge calls
class SafeBridge {
    @JavascriptInterface
    fun postMessage(data: String) {
        // Validate data, never trust JS input
        if (isValidData(data)) { handleMessage(data) }
    }
}

// ✅ Only load trusted URLs
webView.webViewClient = object : WebViewClient() {
    override fun shouldOverrideUrlLoading(view: WebView, req: WebResourceRequest): Boolean {
        return if (req.url.host == "trusted.myapp.com") {
            false // allow
        } else {
            true // block external URLs
        }
    }
}

// ✅ Update WebView — it's separately updatable via Play Store
// Keep it updated — most security patches come through WebView updates

• JavaScript bridge (addJavascriptInterface): exposes Java to ALL JS — XSS can exploit it
• Always validate data received from JS bridge — treat it as untrusted input
• Disable file/content access unless absolutely needed — major attack vectors
• MIXED_CONTENT_NEVER_ALLOW: prevent HTTP content loading in HTTPS pages
• WebView is updated separately via Play Store — encourage users to keep it updated

App Shortcuts appear when users long-press your app icon on the home screen. They provide quick access to common actions and can significantly improve user engagement.

// 1. STATIC shortcuts — defined in XML, never change
// res/xml/shortcuts.xml
// <shortcuts>
//   <shortcut android:shortcutId="compose"
//             android:shortcutShortLabel="@string/compose_shortcut_short_label"
//             android:icon="@drawable/ic_compose">
//     <intent android:action="android.intent.action.VIEW"
//             android:targetPackage="com.myapp"
//             android:targetClass="com.myapp.ComposeActivity" />
//   </shortcut>
// </shortcuts>

// 2. DYNAMIC shortcuts — created at runtime, user-specific
val shortcutManager = getSystemService(ShortcutManager::class.java)

val shortcut = ShortcutInfo.Builder(this, "recent_chat_rahul")
    .setShortLabel("Rahul")
    .setLongLabel("Chat with Rahul")
    .setIcon(Icon.createWithResource(this, R.drawable.ic_chat))
    .setIntent(Intent(this, ChatActivity::class.java).apply {
        action = Intent.ACTION_VIEW
        putExtra("userId", "rahul_123")
    })
    .build()

shortcutManager?.setDynamicShortcuts(listOf(shortcut))

// 3. PINNED shortcuts — user manually pins to home screen
if (shortcutManager?.isRequestPinShortcutSupported == true) {
    shortcutManager.requestPinShortcut(shortcut, null)
}

// Report usage — system learns and surfaces relevant shortcuts
shortcutManager?.reportShortcutUsed("recent_chat_rahul")

• Static: defined in XML, same for all users — max 4-5 shortcuts
• Dynamic: created in code at runtime — personalized (recent contacts, items)
• Pinned: user explicitly pins to home screen — persists even if app removes dynamic shortcut
• Max 5 shortcuts combined (static + dynamic) — system enforces this
• Call reportShortcutUsed() to help launcher learn user habits

Android apps normally run in a single process. Running components in separate processes provides isolation, independent lifecycle, and crash containment — but adds complexity and IPC overhead.

// Declare separate process in manifest
// android:process=":remote" → private process (prefixed with package name)
// android:process="com.myapp.sync" → global process (shared between apps)

// <service android:name=".SyncService"
//          android:process=":sync" />  ← runs in separate process

// Implications of multi-process:
// - Each process has its own Application instance onCreate()
// - Singletons NOT shared between processes
// - SharedPreferences NOT safe across processes (use ContentProvider or AIDL)
// - Room database: use multi-process safe database setup

class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        // Check which process we're in before initializing
        val processName = ProcessPhoenix.getProcessName(this) // or use ActivityManager
        if (processName == packageName) {
            initMainProcess() // only init heavy stuff in main process
        }
    }
}

// Use cases for multi-process:
// 1. Crash isolation — buggy library in :remote won't kill main UI
// 2. Memory isolation — push parser/renderer to separate process
// 3. Security isolation — sensitive operations in :secure process
// 4. SyncAdapter — always runs in separate process

// Modern alternative: WorkManager in separate process
// implementation("androidx.work:work-multiprocess:2.8.1")
val config = Configuration.Builder()
    .setDefaultProcessName("$packageName:worker")
    .build()

• Each process gets its own Application.onCreate() — initialize carefully per process
• Singletons are NOT shared across processes — common source of bugs
• SharedPreferences is NOT multi-process safe — use ContentProvider or AIDL
• WorkManager supports multi-process via work-multiprocess artifact
• Use sparingly — adds complexity, IPC overhead, and debugging difficulty

Android Vitals in Play Console provides real-world performance data from production users. Monitoring and improving these metrics directly impacts your app's Play Store ranking and user retention.

// Android Vitals key metrics (Play Console):
// ANR rate        → target < 0.47% (bad behavior threshold)
// Crash rate      → target < 1.09%
// Slow startup    → cold start > 5s = slow
// Slow frames     → > 50ms frames (jank)
// Frozen frames   → > 700ms frames (very bad)
// Permission denial rate, wake lock time, battery usage

// Monitor in code with Firebase Performance
val trace = Firebase.performance.newTrace("checkout_flow")
trace.start()
// ... perform operation
trace.stop()
trace.putMetric("items_count", cart.size.toLong())

// Custom metrics for ANR prevention
StrictMode.noteSlowCall("slowDatabaseQuery") // marks slow call for StrictMode

// Crash reporting — Firebase Crashlytics
try {
    riskyOperation()
} catch (e: Exception) {
    Firebase.crashlytics.recordException(e) // non-fatal
    Firebase.crashlytics.setCustomKey("userId", currentUserId)
}

// Macrobenchmark for measuring startup in CI
// @Test fun coldStart() {
//   benchmarkRule.measureRepeated(
//     packageName = "com.myapp",
//     metrics = listOf(StartupTimingMetric()),
//     startupMode = StartupMode.COLD
class="cm">//   ) { pressHome(); startActivityAndWait() }
// }

// Bad behavior thresholds (Play Store flags apps exceeding these):
// ANR rate > 0.47% of daily sessions
// Crash rate > 1.09% of daily sessions
// Excessive wakeups > 10/hour

• Android Vitals: real production data — Play Store ranking affected if thresholds exceeded
• ANR rate target: below 0.47%; Crash rate target: below 1.09%
• Firebase Crashlytics: non-fatal exception tracking with custom keys for context
• Firebase Performance: custom traces for business-critical flows
• Macrobenchmark: automated startup/scroll performance testing in CI pipeline