Background Work: Threads, Coroutines & WorkManager

When an Android application process launches, the Android Runtime (ART) forks from the Zygote template and instantiates a primary thread of execution called the Main Thread (colloquially termed the UI Thread). This thread runs a continuous message dispatch loop powered by three fundamental Android OS primitives:

• MessageQueue: A low-level, priority-ordered FIFO buffer containing work items (Runnables and Messages) submitted for execution.
• Looper: An infinite loop mechanism (Looper.loop()) executing on the Main Thread that extracts the next ready message from the MessageQueue and dispatches it to its corresponding Handler.
• Handler: The IPC and intra-process messaging bridge used to enqueue messages and runnables onto a specific thread's Looper.

The Choreographer 16.6ms Frame Budget: Android's display subsystem refreshes at 60Hz (standard displays) or 120Hz (ProMotion/High Refresh Rate panels). To render smooth 60 FPS graphics, the UI thread must measure, lay out, draw, and commit every frame within a strict 16.6 milliseconds (8.3ms for 120Hz). If any blocking operation (disk I/O, heavy JSON parsing, database query, network socket fetch) stalls the Main Looper past this deadline, the device drops frames (causing visible UI jank and stutter).

A Coroutine is a lightweight, cooperative concurrency primitive that can suspend its execution without blocking the underlying operating system thread. While creating a standard Java thread incurs substantial overhead (~1MB of dedicated stack memory allocation and expensive kernel context switching), thousands of coroutines can execute concurrently across a small pool of shared threads with minimal memory footprint (~few kilobytes).

The suspend Modifier & Continuation Passing Style (CPS):
When a function is marked with the suspend keyword, the Kotlin compiler transforms its bytecode under the hood using Continuation Passing Style (CPS). The compiler appends a hidden parameter, continuation: Continuation<T>, to the function signature and converts the function body into a finite state machine:

// Developer writes:
suspend fun fetchCourse(id: String): Course

// Kotlin Compiler generates bytecode equivalent to:
fun fetchCourse(id: String, continuation: Continuation<Course>): Any? {
    // Returns Course data, or COROUTINE_SUSPENDED if asynchronous I/O is ongoing
}

When a coroutine hits a suspension point (e.g. waiting for a network socket or database query), it saves its local variable state in the Continuation object and yields the underlying thread back to the OS. The thread is immediately free to draw UI frames or process other tasks. Once the data arrives, the continuation's resumeWith() is invoked, restoring the state and continuing execution seamlessly.

Modern Android development prohibits global asynchronous tasks (e.g. GlobalScope.launch) because they outlive their parent screens and cause severe memory leaks. Kotlin enforces Structured Concurrency:

• Every coroutine must be launched inside a bounded CoroutineScope (such as viewModelScope or lifecycleScope).
• Parent scopes track all child jobs. If a parent scope is cancelled (e.g. when the user presses Back and the ViewModel triggers onCleared()), all active child coroutines are cancelled automatically.
• A parent scope does not complete until all its child coroutines have completed.
• Cancellation is Cooperative: A coroutine cannot be killed forcefully from the outside. The running code must cooperate with cancellation by either calling built-in suspending functions (which check cancellation automatically) or manually verifying isActive or ensureActive() during tight CPU loops.

In modern enterprise Android architecture, every suspend function must be main-safe. This means a caller should be able to invoke any repository or data-source suspend function directly from Dispatchers.Main without fearing an ANR or thread crash. The suspend function itself is responsible for switching dispatchers using withContext():

class CourseRepository(
    private val api: DevAscentApiService,
    private val dao: CourseDao
) {
    // MAIN-SAFE: Safe to call directly from viewModelScope on Dispatchers.Main
    suspend fun syncAndSaveCourses(): List<Course> = withContext(Dispatchers.IO) {
        // 1. Network fetch on Dispatchers.IO
        val remoteCourses = api.getCourses()
        
        // 2. Disk persistence on Dispatchers.IO
        dao.insertAll(remoteCourses)
        
        return@withContext remoteCourses
    }
}

Prior to Android 8.0 (API 26), developers used raw background Services and AlarmManager to run background tasks. However, rogue apps constantly drained device battery and consumed RAM when idle. Android introduced aggressive power management:

• Background Execution Limits: Apps cannot execute long-running background services when the app is in the background or killed.
• Doze Mode & App Standby: When a device is unplugged, stationary, and screen-off, the OS restricts CPU access, network connectivity, and sync adapters into maintenance windows.

Enter Jetpack WorkManager: WorkManager is Google's recommended library for persistent, deferrable, guaranteed background work. A task is persistent if it must execute even if the app process is killed or the physical device reboots.

Notifications display messages outside an application's normal UI to inform users of background events, incoming sync updates, or ongoing downloads.

Android 13 (API 33) Runtime Permission: Historically, notification posting was granted automatically upon installation. Starting with Android 13 (Tiramisu), applications must declare and request the runtime permission android.permission.POST_NOTIFICATIONS. If denied, all notifications posted by the app are silently suppressed by the OS.

<!-- Mandatory for Android 13+ (API 33) -->
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

Legacy Android applications registered global CONNECTIVITY_ACTION broadcast receivers, which Google deprecated because thousands of idle apps woke up simultaneously whenever a device toggled Wi-Fi. The modern standard is to register a ConnectivityManager.NetworkCallback:

class NetworkConnectivityObserver(context: Context) {
    private val connectivityManager = 
        context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

    val isConnectedFlow: Flow<Boolean> = callbackFlow {
        val callback = object : ConnectivityManager.NetworkCallback() {
            override fun onAvailable(network: Network) {
                trySend(true)
            }

            override fun onLost(network: Network) {
                trySend(false)
            }
        }

        val request = NetworkRequest.Builder()
            .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
            .build()

        connectivityManager.registerNetworkCallback(request, callback)

        // Cleanup callback when Flow collection stops
        awaitClose { connectivityManager.unregisterNetworkCallback(callback) }
    }
}