Android

Android 12 introduced one of the biggest visual upgrades in Android history: Material You.
At the heart of this design shift is a small but powerful feature called Monochrome Icons.

If you’ve ever noticed your app icons changing color to match your wallpaper, that’s Monochrome Icons doing their job.

In this guide, we’ll break down:

• What Monochrome Icons are
• How they power Android themed icons
• Why Android 12+ relies on them
• How to implement them correctly

What Are Monochrome Icons in Android?

Monochrome Icons are simplified versions of app icons that use a single color only.

They remove:

• Gradients
• Shadows
• Multiple colors
• Decorative details

Instead, they focus on shape and clarity.

Android uses these icons as a base to dynamically apply system colors based on the user’s wallpaper and theme.

In short:
Monochrome Icons are the foundation of Android themed icons.

Why Android 12+ Needs Monochrome Icons

Before Android 12, app icons were static. Every icon looked the same regardless of theme.

Android 12 changed this with dynamic theming, where the system extracts colors from the user’s wallpaper and applies them across:

• Quick settings
• Widgets
• System UI
• App icons

For this to work cleanly, Android needs icons that are easy to recolor. That’s where Monochrome Icons come in.

Without a proper monochrome layer, Android cannot theme your app icon correctly.

How Themed Icons Work Behind the Scenes

Here’s what happens when a user enables themed icons:

1. Android checks if your app supports Monochrome Icons
2. If supported, the system loads the monochrome drawable
3. Android applies dynamic colors from the Material You palette
4. The icon adapts instantly when wallpaper or theme changes

If your app does not include a monochrome icon:

• The icon stays unchanged
• It breaks visual consistency
• It looks outdated next to themed apps

Where Monochrome Icons Live in Your App

Monochrome Icons are defined inside your adaptive icon XML.

This file is usually located at:

res/mipmap-anydpi-v26/ic_launcher.xml

This is where Android expects your monochrome icon to be declared.

Sample Adaptive Icon with Monochrome Support

Here’s a valid adaptive icon configuration:

<?xml version="1.0" encoding="utf-8"?>
<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
    <background android:drawable="@color/ic_launcher_background" />
    <foreground android:drawable="@drawable/ic_launcher_foreground" />
    <monochrome android:drawable="@drawable/ic_launcher_monochrome" />
</adaptive-icon>

What Each Part Means

• background
  Used for legacy launchers and non-themed states
• foreground
  The full-color icon shown when themed icons are disabled
• monochrome
  This is the key part
  Android uses this drawable for themed icons

If the <monochrome> tag is missing, themed icons won’t work for your app.

Designing a Proper Monochrome Icon

A good Monochrome Icon should:

• Use solid white or black only
• Avoid thin lines
• Avoid transparency gradients
• Focus on a recognizable shape

Recommended Format

• Vector Drawable (.xml)
• Single path
• android:fillColor set to white or black

<vector xmlns:android="http://schemas.android.com/apk/res/android"
    android:width="108dp"
    android:height="108dp"
    android:viewportWidth="108"
    android:viewportHeight="108">
    
<path
    android:fillColor="#FFFFFFFF"
    android:pathData="M20,20h68v68h-68z" />
</vector>

This simplicity is what allows Android to recolor it cleanly.

App Icon Configuration

Your launcher icon is referenced in AndroidManifest.xml:

<application
    android:icon="@mipmap/ic_launcher"
    android:roundIcon="@mipmap/ic_launcher_round">

If your resources are misconfigured, Android won’t find the monochrome drawable.

Checking Android Version (Optional Use Case)

While Android handles themed icons automatically, you may want to check Android version in Kotlin for UI consistency elsewhere.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
    // Android 12 or higher
    // Themed icons and Material You are supported
}

• Build.VERSION.SDK_INT gives the device’s Android version
• VERSION_CODES.S represents Android 12
• This helps you align other UI elements with themed icons

Again, Monochrome Icons themselves do not need Kotlin logic.

Common Mistakes Developers Make

1. Using Colored Monochrome Icons

Monochrome means one solid color only.
Shades or gradients will break theming.

2. Overly Detailed Icons

Thin lines disappear when recolored.
Bold shapes work best.

3. Forgetting the <monochrome> Tag

Without it, Android ignores themed icons entirely.

4. Relying on PNGs

Vector drawables scale better and theme more reliably.

Why Monochrome Icons Improve User Experience

From a user perspective, Monochrome Icons:

• Make the home screen feel cohesive
• Reduce visual noise
• Adapt naturally to dark and light themes
• Feel modern and intentional

From a developer perspective:

• Your app looks native on Android 12+
• Better alignment with Material You
• Improved visual trust and polish

Conclusion

Monochrome Icons may look simple, but they power one of Android’s most advanced design features.

If your app targets Android 12 or higher, supporting Monochrome Icons is no longer optional. It’s part of building a modern, user-first Android experience.

Keep your icons simple.
Let the system do the coloring.
And embrace Material You the way it was designed.

If you’ve ever worked with Android’s BroadcastReceiver, you know there’s a golden rule: keep your work quick. The system expects your receiver to finish in about 10 seconds, or it’ll label your app as unresponsive (ANR). But what happens when you need just a bit more time?

That’s exactly where goAsync() comes to the rescue.

In this guide, I’ll walk you through everything you need to know about goAsync() in BroadcastReceiver. We’ll explore how it works, when to use it, common mistakes developers make, and the best practices that’ll keep your Android apps running smoothly.

What Exactly Is goAsync()?

Let’s start with the basics. The goAsync() method is a special tool provided by the BroadcastReceiver class that gives you extra time to complete your work without blocking the main thread.

Normally, when a broadcast arrives, Android expects you to handle it immediately on the main thread. This works great for simple tasks like updating a variable or showing a notification. But what if you need to write to a database, make a quick network call, or perform some computation?

That’s the problem goAsync() solves.

When you call goAsync(), it returns a PendingResult object. This object essentially tells Android: “Hey, I’m not done yet, but I promise I’ll finish soon.” It extends your execution window beyond the typical onReceive() lifecycle.

The Lifecycle: How goAsync() Actually Works

Understanding the lifecycle is crucial to using goAsync() correctly. Let me break it down step by step.

Normal BroadcastReceiver Lifecycle

Here’s what happens in a regular broadcast receiver:

class SimpleBroadcastReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // Your code runs here on the main thread
        Log.d("Receiver", "Broadcast received!")
        // When this method exits, the receiver is considered "done"
    }
}

The moment your onReceive() method finishes, Android assumes you’re done. The receiver becomes inactive, and the system may even kill your process if there’s no other component keeping it alive.

With goAsync() in the Picture

Now let’s see how goAsync() changes things:

class AsyncBroadcastReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // Call goAsync() immediately to get a PendingResult
        val pendingResult: PendingResult = goAsync()
        
        // Now you can do work off the main thread
        CoroutineScope(Dispatchers.IO).launch {
            try {
                // Perform your background work here
                performLongRunningTask(context)
            } finally {
                // CRITICAL: Always call finish() when done
                pendingResult.finish()
            }
        }
    }
    
    private suspend fun performLongRunningTask(context: Context) {
        // Simulate some work
        delay(3000)
        Log.d("Receiver", "Task completed!")
    }
}

Here’s what’s happening behind the scenes:

1. goAsync() is called: This immediately returns a PendingResult object and tells Android the receiver is still working
2. Work happens off-thread: You move your heavy lifting to a background thread using coroutines or another threading mechanism
3. finish() is called: When you’re done, calling pendingResult.finish() signals to Android that the receiver has completed its work

The key difference? Your process stays alive even after onReceive() returns, as long as you haven’t called finish() yet.

When Should You Use goAsync()?

The goAsync() method isn’t meant for every situation. Here’s when it makes sense to reach for it:

Perfect Use Cases

Database Operations: Writing user preferences or logging data that takes 2–3 seconds.

class DataSavingReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                val database = AppDatabase.getInstance(context)
                val data = intent.getStringExtra("data") ?: return@launch
                
                // This database write might take a few seconds
                database.userDao().insertData(data)
                Log.d("Receiver", "Data saved successfully")
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Quick Network Calls: Sending analytics events or pinging a server (though WorkManager is often better for this).

File I/O: Reading or writing small amounts of data to storage.

When NOT to Use goAsync()

Long-running tasks: Anything taking more than 10 seconds should use WorkManager, JobScheduler, or a foreground service instead.

Complex operations: If your task requires multiple steps that could fail, consider a more robust solution.

Simple tasks: If your work takes less than a millisecond, you don’t need goAsync() at all. Just do it directly in onReceive().

Common Pitfalls and How to Avoid Them

I’ve seen developers stumble over the same issues when using goAsync(). Let me save you from these headaches.

Pitfall 1: Forgetting to Call finish()

This is the number one mistake. If you never call finish(), Android keeps your receiver alive indefinitely, wasting system resources.

// BAD: Missing finish() call
class BadReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            performTask()
            // Oops..! Forgot to call pendingResult.finish()
        }
    }
}

Always use a try-finally block or Kotlin’s use pattern to ensure finish() gets called:

// GOOD: Guaranteed finish() call
class GoodReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                performTask()
            } catch (e: Exception) {
                Log.e("Receiver", "Error: ${e.message}")
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Pitfall 2: Running on the Main Thread

Calling goAsync() doesn’t automatically move your work off the main thread. You still need to handle that yourself.

// BAD: Still blocking the main thread
class BlockingReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        // This still runs on the main thread!
        Thread.sleep(5000) // Don't do this!
        
        pendingResult.finish()
    }
}

Always explicitly move to a background thread:

// GOOD: Work happens on background thread
class NonBlockingReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        // Using Dispatchers.IO for background work
        CoroutineScope(Dispatchers.IO).launch {
            try {
                delay(5000) // This is okay on IO thread
                processData()
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Pitfall 3: Exceeding the Time Limit

Even with goAsync(), you still have time constraints. Android gives you approximately 10 seconds total. Going beyond that results in an ANR.

class TimeConsciousReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                withTimeout(8000) { // Set a timeout slightly under 10 seconds
                    performTaskWithTimeout()
                }
            } catch (e: TimeoutCancellationException) {
                Log.e("Receiver", "Task took too long")
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Pitfall 4: Memory Leaks with Context

Be careful about holding onto the Context object in your background work. The context passed to onReceive() is short-lived.

// SAFER: Use application context for long-running work
class SafeContextReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        val appContext = context.applicationContext // Use app context
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                // Use appContext instead of context
                doWorkWith(appContext)
            } finally {
                pendingResult.finish()
            }
        }
    }
}

Best Practices for Using goAsync()

After working with goAsync() across multiple projects, here are my recommended best practices.

1. Always Use Structured Concurrency

Kotlin coroutines with proper scope management make your life easier:

class StructuredReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        // Create a supervised scope
        val scope = CoroutineScope(SupervisorJob() + Dispatchers.IO)
        
        scope.launch {
            try {
                // All your async work here
                val result = performNetworkCall()
                saveToDatabase(context, result)
            } catch (e: Exception) {
                handleError(e)
            } finally {
                pendingResult.finish()
                scope.cancel() // Clean up the scope
            }
        }
    }
}

2. Implement Proper Error Handling

Things will go wrong. Handle exceptions gracefully:

class RobustReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                val data = intent.getStringExtra("key") 
                    ?: throw IllegalArgumentException("Missing data")
                
                processData(data)
                
            } catch (e: IllegalArgumentException) {
                Log.e("Receiver", "Invalid input: ${e.message}")
            } catch (e: IOException) {
                Log.e("Receiver", "Network error: ${e.message}")
            } catch (e: Exception) {
                Log.e("Receiver", "Unexpected error: ${e.message}")
            } finally {
                pendingResult.finish()
            }
        }
    }
}

3. Add Logging for Debugging

When things go wrong, good logs are your best friend:

class LoggingReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        Log.d(TAG, "Broadcast received: ${intent.action}")
        val startTime = System.currentTimeMillis()
        val pendingResult = goAsync()
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                Log.d(TAG, "Starting background work")
                performWork()
                Log.d(TAG, "Work completed successfully")
            } catch (e: Exception) {
                Log.e(TAG, "Work failed", e)
            } finally {
                val duration = System.currentTimeMillis() - startTime
                Log.d(TAG, "Total execution time: ${duration}ms")
                pendingResult.finish()
            }
        }
    }
    
    companion object {
        private const val TAG = "LoggingReceiver"
    }
}

4. Consider WorkManager for Complex Tasks

If your task is getting complicated, it might be time to switch to WorkManager:

class SmartReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val taskComplexity = estimateComplexity(intent)
        
        when {
            taskComplexity < 3 -> {
                // Simple task: use goAsync()
                val pendingResult = goAsync()
                CoroutineScope(Dispatchers.IO).launch {
                    try {
                        quickTask()
                    } finally {
                        pendingResult.finish()
                    }
                }
            }
            else -> {
                // Complex task: delegate to WorkManager
                val workRequest = OneTimeWorkRequestBuilder<DataSyncWorker>()
                    .setInputData(workDataOf("data" to intent.getStringExtra("data")))
                    .build()
                WorkManager.getInstance(context).enqueue(workRequest)
            }
        }
    }
}

Real-World Example: Network Sync on Connectivity Change

Let’s put everything together with a practical example. This receiver syncs data when the device connects to WiFi:

class ConnectivitySyncReceiver : BroadcastReceiver() {
    
    override fun onReceive(context: Context, intent: Intent) {
        // Check if this is a connectivity change
        if (intent.action != ConnectivityManager.CONNECTIVITY_ACTION) {
            return
        }
        
        Log.d(TAG, "Connectivity changed")

        val pendingResult = goAsync()
        val appContext = context.applicationContext
        
        CoroutineScope(Dispatchers.IO).launch {
            try {
                // Check if we're on WiFi
                if (!isWiFiConnected(appContext)) {
                    Log.d(TAG, "Not on WiFi, skipping sync")
                    return@launch
                }
                
                Log.d(TAG, "WiFi connected, starting sync")
                
                // Perform sync with timeout
                withTimeout(8000) {
                    syncDataWithServer(appContext)
                }
                
                Log.d(TAG, "Sync completed successfully")
                
            } catch (e: TimeoutCancellationException) {
                Log.e(TAG, "Sync timed out")
                scheduleRetryWithWorkManager(appContext)
            } catch (e: IOException) {
                Log.e(TAG, "Network error during sync", e)
            } catch (e: Exception) {
                Log.e(TAG, "Unexpected error during sync", e)
            } finally {
                pendingResult.finish()
            }
        }
    }
    
    private fun isWiFiConnected(context: Context): Boolean {
        val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
        val network = cm.activeNetwork ?: return false
        val capabilities = cm.getNetworkCapabilities(network) ?: return false
        return capabilities.hasTransport(NetworkCapabilities.TRANSPORT_WIFI)
    }
    
    private suspend fun syncDataWithServer(context: Context) {
        // Simulate API call
        delay(2000)
        
        // In reality, you'd make an actual network call here
        val repository = DataRepository.getInstance(context)
        repository.syncWithServer()
    }
    
    private fun scheduleRetryWithWorkManager(context: Context) {
        val retryWork = OneTimeWorkRequestBuilder<SyncWorker>()
            .setInitialDelay(15, TimeUnit.MINUTES)
            .build()
        WorkManager.getInstance(context).enqueue(retryWork)
    }
    
    companion object {
        private const val TAG = "ConnectivitySync"
    }
}

This example demonstrates several best practices:

• Immediate goAsync() call to extend execution time
• Application context usage to prevent memory leaks
• Proper exception handling for different error scenarios
• Timeout protection to avoid ANRs
• Fallback to WorkManager for retry logic
• Comprehensive logging for debugging

Testing Your goAsync() Implementation

Testing broadcast receivers with goAsync() requires special attention. Here’s a simple approach:

@Test
fun testAsyncBroadcastReceiver() = runBlocking {
    val context = ApplicationProvider.getApplicationContext<Context>()
    val intent = Intent("com.softaai.TEST_ACTION")
    val receiver = AsyncBroadcastReceiver()
    
    // Set up a CountDownLatch to wait for async completion
    val latch = CountDownLatch(1)
    
    // Mock the receiver to signal when done
    receiver.onReceive(context, intent)
    
    // Wait for async work to complete (with timeout)
    val completed = latch.await(5, TimeUnit.SECONDS)
    assertTrue("Receiver should complete within timeout", completed)
}

Conclusion

The goAsync() method is a powerful tool in your Android development toolkit, but it requires careful handling. 

Let me recap the key points:

What goAsync() does: Extends the execution window for your BroadcastReceiver beyond the typical onReceive() lifecycle

When to use it: For tasks taking 1–8 seconds, like database writes, quick network calls, or file I/O

Critical rules: Always call finish(), move work off the main thread, respect the 10-second limit, and handle errors gracefully

Better alternatives: For longer tasks or complex workflows, consider WorkManager, JobScheduler, or foreground services

Remember, goAsync() is meant for those in-between moments when your work is too heavy for the main thread but too quick to justify a full background service. Use it wisely, follow the best practices we’ve covered, and your broadcast receivers will run smoothly without causing ANRs or draining battery life.

Have you ever opened an app on your Android phone, switched to another app for a while, and then returned only to find everything reset? Your form data gone, your scroll position lost, or the app back at the home screen?

That’s Process Death in Android.

Understanding Process Death in Android is crucial for building apps that feel reliable and professional. In this guide, we’ll explore what it is, why it happens, and most importantly, how to handle it properly in your Android apps.

What Exactly Is Process Death in Android?

Process Death in Android occurs when the Android operating system kills your app’s process to free up memory for other apps. Think of it like your phone doing some housekeeping — when memory gets tight, Android decides which apps to close to keep everything running smoothly.

Here’s the tricky part: when your app’s process dies, your activities might still appear to be in the back stack. When the user returns, Android recreates the activity, but all your runtime data is gone unless you’ve saved it properly.

This is different from the normal activity lifecycle. Your app doesn’t just pause or stop — it’s completely terminated and then brought back to life.

Why Does Process Death Happen?

Android needs to manage limited device resources efficiently. Here are the main reasons Process Death in Android occurs:

Low Memory Situations

When your device runs low on RAM, Android starts killing background processes. Apps you haven’t used recently are the first to go.

Developer Options Testing

During development, you can enable “Don’t keep activities” in Developer Options. This immediately destroys activities when they leave the foreground, making it easier to test Process Death scenarios.

Long Background Duration

If your app stays in the background for an extended period while the user uses other memory-intensive apps, there’s a higher chance your process will be killed.

System Updates or Crashes

Sometimes system events or crashes can trigger process termination across multiple apps.

Real-World Example: The Shopping Cart Problem

Let me share a common scenario that illustrates Process Death in Android perfectly.

Imagine you’re building a shopping app. A user adds five items to their cart, then switches to their messaging app to check a friend’s recommendation. They spend 10 minutes chatting, during which Android kills your shopping app’s process to free memory.

When they return to your app, if you haven’t handled Process Death properly, their cart is empty. 

Frustrating, right?

This is exactly why understanding and handling Process Death in Android matters for user experience.

How to Detect Process Death in Android

Before we fix it, let’s learn how to detect it. Add this code to your activity:

class MainActivity : AppCompatActivity() {
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        if (savedInstanceState != null) {
            // Activity was recreated after process death
            Log.d("ProcessDeath", "Activity restored after process death")
        } else {
            // Normal first-time creation
            Log.d("ProcessDeath", "Activity created normally")
        }
    }
}

The onCreate() method receives a savedInstanceState parameter. When this parameter is not null, it means Android is restoring your activity after Process Death. If it’s null, your activity is being created for the first time or normally resumed.

This simple check helps you understand when restoration is happening.

Saving State with onSaveInstanceState

The primary way to handle Process Death in Android is by overriding onSaveInstanceState(). This method is called before your activity might be destroyed, giving you a chance to save important data.

class ShoppingCartActivity : AppCompatActivity() {
    
    private var cartItems = mutableListOf<String>()
    private var totalPrice = 0.0
    private var userName = ""
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_shopping_cart)
        
        // Restore saved state if available
        savedInstanceState?.let {
            cartItems = it.getStringArrayList("CART_ITEMS")?.toMutableList() ?: mutableListOf()
            totalPrice = it.getDouble("TOTAL_PRICE", 0.0)
            userName = it.getString("USER_NAME", "")
            
            Log.d("ProcessDeath", "Restored ${cartItems.size} items")
        }
        
        updateUI()
    }
    
    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        
        // Save critical data before potential process death
        outState.putStringArrayList("CART_ITEMS", ArrayList(cartItems))
        outState.putDouble("TOTAL_PRICE", totalPrice)
        outState.putString("USER_NAME", userName)
        
        Log.d("ProcessDeath", "Saved ${cartItems.size} items to bundle")
    }
    
    private fun updateUI() {
        // Update your UI with restored data
        findViewById<TextView>(R.id.itemCount).text = "Items: ${cartItems.size}"
        findViewById<TextView>(R.id.totalPrice).text = "Total: $$totalPrice"
    }
}

Here, we override two key methods:

1. onSaveInstanceState(): This is where we save our data to a Bundle. Think of a Bundle as a container that Android keeps safe even during Process Death. We use methods like putStringArrayList(), putDouble(), and putString() to store different data types.
2. onCreate(): We check if savedInstanceState exists. If it does, we restore our data using corresponding get methods like getStringArrayList() and getDouble().

The ?.let syntax is Kotlin’s safe call operator, ensuring we only access the bundle if it’s not null.

What Data Can You Save in a Bundle?

Bundles support many common data types, but there are limitations. Here’s what you can save:

Supported Types:

• Primitive types (Int, Long, Float, Double, Boolean)
• Strings and CharSequences
• Parcelable objects
• Serializable objects
• Arrays and ArrayLists of supported types

Important Limitation: Bundles have a size limit (typically around 500KB to 1MB). Don’t try to save large images, videos, or extensive datasets. For large data, use other persistence methods like databases or files.

Using ViewModel to Survive Configuration Changes

While onSaveInstanceState() handles Process Death in Android, ViewModels help with configuration changes like screen rotation. However, ViewModels alone don’t survive process death.

Here’s how to combine both approaches:

class UserProfileViewModel : ViewModel() {
    
    // This survives configuration changes but NOT process death
    var userName = MutableLiveData<String>()
    var userAge = MutableLiveData<Int>()
    var profileImageUrl = MutableLiveData<String>()
    
    fun updateUserData(name: String, age: Int, imageUrl: String) {
        userName.value = name
        userAge.value = age
        profileImageUrl.value = imageUrl
    }
}

class UserProfileActivity : AppCompatActivity() {
    
    private lateinit var viewModel: UserProfileViewModel
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_user_profile)
        
        viewModel = ViewModelProvider(this).get(UserProfileViewModel::class.java)
        
        // If recovering from process death, restore to ViewModel
        savedInstanceState?.let {
            val name = it.getString("USER_NAME", "")
            val age = it.getInt("USER_AGE", 0)
            val imageUrl = it.getString("PROFILE_IMAGE_URL", "")
            
            viewModel.updateUserData(name, age, imageUrl)
        }
        
        observeViewModel()
    }
    
    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        
        // Save ViewModel data to survive process death
        outState.putString("USER_NAME", viewModel.userName.value ?: "")
        outState.putInt("USER_AGE", viewModel.userAge.value ?: 0)
        outState.putString("PROFILE_IMAGE_URL", viewModel.profileImageUrl.value ?: "")
    }
    
    private fun observeViewModel() {
        viewModel.userName.observe(this) { name ->
            findViewById<TextView>(R.id.nameText).text = name
        }
        
        viewModel.userAge.observe(this) { age ->
            findViewById<TextView>(R.id.ageText).text = "Age: $age"
        }
    }
}

The ViewModel holds our UI data and survives configuration changes automatically. However, to survive Process Death in Android, we still need to:

1. Save ViewModel data in onSaveInstanceState()
2. Restore that data back to the ViewModel in onCreate()

This gives us the best of both worlds: automatic configuration change handling from ViewModel, plus process death recovery from saved instance state.

SavedStateHandle: The Modern Approach

Android Jetpack provides SavedStateHandle, which combines ViewModel benefits with automatic state saving. This is the recommended approach for handling Process Death in Android:

class ShoppingViewModel(private val savedStateHandle: SavedStateHandle) : ViewModel() {
    
    // Automatically saved and restored across process death
    var cartItems: MutableLiveData<List<String>> = savedStateHandle.getLiveData("cart_items", emptyList())
    var totalPrice: MutableLiveData<Double> = savedStateHandle.getLiveData("total_price", 0.0)
    
    fun addItem(item: String, price: Double) {
        val currentItems = cartItems.value?.toMutableList() ?: mutableListOf()
        currentItems.add(item)
        cartItems.value = currentItems
        
        val currentTotal = totalPrice.value ?: 0.0
        totalPrice.value = currentTotal + price
        
        // Automatically saved to SavedStateHandle
    }
    
    fun clearCart() {
        cartItems.value = emptyList()
        totalPrice.value = 0.0
    }
}


class ShoppingActivity : AppCompatActivity() {
    
    private val viewModel: ShoppingViewModel by viewModels()
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_shopping)
        
        // No manual state restoration needed!
        // SavedStateHandle does it automatically
        
        viewModel.cartItems.observe(this) { items ->
            updateCartUI(items)
        }
        
        viewModel.totalPrice.observe(this) { total ->
            findViewById<TextView>(R.id.totalText).text = "Total: $$total"
        }
        
        findViewById<Button>(R.id.addButton).setOnClickListener {
            viewModel.addItem("Product ${System.currentTimeMillis()}", 29.99)
        }
    }
    
    private fun updateCartUI(items: List<String>) {
        // Update RecyclerView or ListView with items
    }
}

SavedStateHandle is magical for handling Process Death in Android. Here’s why:

1. getLiveData(): This method creates LiveData that’s automatically backed by saved state. When process death occurs, the data is saved. When the process restarts, the data is restored automatically.
2. No manual saving: Unlike the previous examples, we don’t need to override onSaveInstanceState(). The SavedStateHandle does it for us.
3. Type-safe: We can store various types, and they’re automatically serialized and deserialized.

The by viewModels() delegate is a Kotlin property delegate that creates or retrieves the ViewModel with SavedStateHandle automatically injected.

Testing Process Death in Android

Testing is crucial to ensure your app handles Process Death in Android correctly. Here are practical ways to test:

Method 1: Developer Options

1. Go to Settings → Developer Options
2. Enable “Don’t keep activities”
3. Navigate through your app, switching between activities
4. Every time an activity goes to the background, it’s destroyed

Method 2: Using ADB Command

Force your app’s process to be killed using Android Debug Bridge:

adb shell am kill com.yourapp.package

Then return to your app from the recent apps menu.

Method 3: Memory Pressure Testing

Use Android Studio’s Profiler to simulate low memory conditions:

1. Open Android Profiler
2. Select Memory
3. Click “Force garbage collection” multiple times
4. Android may kill your app’s process naturally

Common Mistakes to Avoid

When dealing with Process Death in Android, developers often make these mistakes:

Mistake 1: Saving Large Objects

// DON'T DO THIS
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putSerializable("LARGE_IMAGE", largeImageBitmap) // Too big!
}

Why it’s wrong: Bundles have size limits. Saving large objects causes TransactionTooLargeException.

Better approach: Save only a reference or ID, then reload the data from a persistent source.

// DO THIS INSTEAD
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("IMAGE_URL", imageUrl) // Save URL, not bitmap
}

Mistake 2: Assuming ViewModel Survives Process Death

// INCORRECT ASSUMPTION
class MyActivity : AppCompatActivity() {
    private lateinit var viewModel: MyViewModel
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        viewModel = ViewModelProvider(this).get(MyViewModel::class.java)
        
        // Assuming viewModel.userData is always available after process death
        // This is WRONG - ViewModel doesn't survive process death without SavedStateHandle
    }
}

Fix: Use SavedStateHandle or manually save/restore ViewModel data.

Mistake 3: Not Testing Thoroughly

Many developers never test Process Death scenarios until users report bugs. Always enable “Don’t keep activities” during development.

Best Practices for Handling Process Death in Android

1. Use SavedStateHandle for Simple Data

For primitive types and small objects, SavedStateHandle is your best friend:

class MyViewModel(private val state: SavedStateHandle) : ViewModel() {
    val username: LiveData<String> = state.getLiveData("username", "")
    val score: LiveData<Int> = state.getLiveData("score", 0)
}

2. Persist Important Data to Database

For critical data that users can’t afford to lose, use Room database or other persistent storage:

class FormActivity : AppCompatActivity() {
    private lateinit var database: AppDatabase
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        database = Room.databaseBuilder(
            applicationContext,
            AppDatabase::class.java,
            "form-database"
        ).build()
        
        // Restore form from database if exists
        lifecycleScope.launch {
            val savedForm = database.formDao().getUnsubmittedForm()
            savedForm?.let { restoreForm(it) }
        }
    }
    
    override fun onPause() {
        super.onPause()
        // Save form to database when leaving activity
        lifecycleScope.launch {
            val formData = collectFormData()
            database.formDao().saveForm(formData)
        }
    }
}

3. Combine Multiple Approaches

Use the right tool for each type of data:

• SavedStateHandle: UI state (scroll position, selected tab, form inputs)
• ViewModel: Temporary runtime data that survives configuration changes
• Database/SharedPreferences: Persistent user data
• Memory cache: Easily re-fetchable data

4. Keep Bundles Small

Only save essential state information. Calculate or reload other data:

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    
    // Save only IDs, not entire objects
    outState.putInt("SELECTED_ITEM_ID", selectedItem.id)
    outState.putString("SEARCH_QUERY", searchQuery)
    
    // Don't save the entire search results list
    // Reload it using the search query instead
}

Advanced: Handling Process Death with Compose

If you’re using Jetpack Compose, handling Process Death in Android looks a bit different:

@Composable
fun ShoppingCartScreen(viewModel: ShoppingViewModel = viewModel()) {
    
    val cartItems by viewModel.cartItems.observeAsState(emptyList())
    val totalPrice by viewModel.totalPrice.observeAsState(0.0)
    
    Column(modifier = Modifier.fillMaxSize().padding(16.dp)) {
        Text(
            text = "Shopping Cart",
            style = MaterialTheme.typography.h5
        )
        
        Spacer(modifier = Modifier.height(16.dp))
        
        LazyColumn(modifier = Modifier.weight(1f)) {
            items(cartItems) { item ->
                CartItemRow(item = item)
            }
        }
        
        Divider()
        
        Text(
            text = "Total: $${"%.2f".format(totalPrice)}",
            style = MaterialTheme.typography.h6,
            modifier = Modifier.padding(vertical = 16.dp)
        )
        
        Button(
            onClick = { viewModel.addItem("New Product", 29.99) },
            modifier = Modifier.fillMaxWidth()
        ) {
            Text("Add Item")
        }
    }
}

@Composable
fun CartItemRow(item: String) {
    Row(
        modifier = Modifier
            .fillMaxWidth()
            .padding(vertical = 8.dp),
        horizontalArrangement = Arrangement.SpaceBetween
    ) {
        Text(text = item)
        Text(text = "$29.99")
    }
}

With Compose, you still use ViewModel with SavedStateHandle. The difference is:

1. observeAsState(): Converts LiveData from ViewModel into Compose State
2. Automatic recomposition: When the ViewModel data changes (including after process death restoration), Compose automatically updates the UI
3. No manual lifecycle management: Compose handles the observation lifecycle for you

The underlying Process Death handling still uses SavedStateHandle in the ViewModel, but the UI layer becomes much simpler.

Monitoring Process Death in Production

To understand how often Process Death in Android affects your users, implement analytics:

class AnalyticsHelper(private val context: Context) {
    
    fun trackProcessDeath(activityName: String) {
        // Log to your analytics service
        FirebaseAnalytics.getInstance(context).logEvent("process_death_recovery") {
            param("activity_name", activityName)
            param("timestamp", System.currentTimeMillis())
        }
    }
}

class MainActivity : AppCompatActivity() {
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        if (savedInstanceState != null) {
            AnalyticsHelper(this).trackProcessDeath("MainActivity")
        }
    }
}

This helps you understand:

• How frequently users experience process death
• Which activities are most affected
• Whether users successfully recover their state

Conclusion

Process Death in Android is an essential concept every Android developer must master. It’s not just about preventing crashes — it’s about creating a seamless user experience that feels reliable and polished.

Remember these key takeaways:

For simple UI state: Use SavedStateHandle with ViewModel. It automatically handles Process Death in Android with minimal code.

For important user data: Persist to a database. Don’t rely solely on saved instance state for data users can’t afford to lose.

Always test: Enable “Don’t keep activities” during development. Test your app thoroughly by simulating process death scenarios.

Keep bundles small: Only save essential state information. Reload complex data when the activity restores.

By properly handling Process Death in Android, you’ll build apps that feel professional, reliable, and respectful of your users’ time and data. Your users might never know about the complexity you’ve handled behind the scenes — and that’s exactly the point.

Start implementing these patterns in your next project, and you’ll be amazed at how much more robust your apps become. 

If you’ve ever used Hilt in a Jetpack Compose app, you’ve probably written code like this:

class MyRepository @Inject constructor(
    @ApplicationContext private val context: Context
)

And then paused for a second and thought:

“Okay… but where is this @ApplicationContext coming from?”
 “Who creates it?”
 “And how does Hilt magically inject it at runtime?”

This article answers those questions deeply and practically — without buzzwords, without hand-waving, and without unsafe patterns.

We’ll cover:

• Why ViewModels should not receive Context
• How Hilt resolves @ApplicationContext at runtime
• The exact dependency flow from Compose → ViewModel → Repository
• Why this approach is clean, safe, and testable
• What code Hilt generates behind the scenes (conceptually)
• Common mistakes and how to avoid them

Why Passing Context to ViewModel Is a Bad Idea

Let’s start with the mistake most Android developers make at least once:

class MyViewModel(private val context: Context) : ViewModel()

This looks harmless — until it isn’t.

Jetpack ViewModels are designed to outlive UI components like Activities and Fragments. An Activity context, however, is tied to the Activity lifecycle.

If a ViewModel holds an Activity context:

• The Activity cannot be garbage collected
• Memory leaks occur
• Configuration changes become dangerous
• Testing becomes harder

This is why Android’s architecture guidelines are very clear:

ViewModels should not hold a Context.

But what if you need access to:

• SharedPreferences
• DataStore
• ConnectivityManager
• Location services
• File system APIs

You do need a Context — just not in the ViewModel. This is where repositories and Application context come in.

The Clean Architecture Rule

Here’s the mental model that solves this cleanly:

So the rule is simple:
 If something needs a Context, it belongs below the ViewModel layer.

The Correct Dependency Flow

In a modern Compose app using Hilt, the flow looks like this:

Compose Screen
   ↓
ViewModel (no Context)
   ↓
Repository (Application Context)
   ↓
Android System Services

The ViewModel never touches Context.
 The Repository owns it.
 The Application provides it.

So… Where Does @ApplicationContext Come From?

This is the part that feels like magic — but isn’t.

@HiltAndroidApp Creates the Root Component

@HiltAndroidApp
class MyApp : Application()

When you add this annotation, Hilt:

• Generates a base class for your Application
• Creates a singleton Application-level component
• Stores the Application instance inside it

At runtime, Android creates your Application before anything else.

That Application instance is a Context.

Hilt Has a Built-In Context Provider

Inside Hilt’s internal codebase (not yours), there is a binding equivalent to:

@Provides
@Singleton
@ApplicationContext
fun provideApplicationContext(app: Application): Context = app

You never write this.
 You never import it.
 But it exists and is always available once @HiltAndroidApp is present.

So when Hilt sees:

@ApplicationContext Context

It knows exactly what to inject:
 ➡ the Application instance

Repository Requests the Context

class UserRepository @Inject constructor(
    @ApplicationContext private val context: Context
)

At compile time:

• Hilt validates that a binding exists
• It generates a factory class for MyRepository

Conceptually, the generated code looks like:

class MyRepository_Factory(
    private val contextProvider: Provider<Context>
) {
    fun get(): MyRepository {
        return MyRepository(contextProvider.get())
    }
}

At runtime:

• contextProvider.get() returns the Application
• The repository receives a safe, long-lived context

ViewModel Receives the Repository

@HiltViewModel
class UserViewModel @Inject constructor(
    private val repository: UserRepository
) : ViewModel()

The ViewModel:

• Has no idea where the context comes from
• Has no Android dependency
• Is fully testable with fake repositories

Compose retrieves it like this:

val viewModel = hiltViewModel<UserViewModel>()

Hilt handles everything else.

A Real Example: SharedPreferences

Repository:

class UserPreferencesRepository @Inject constructor(
    @ApplicationContext context: Context
) {
    private val prefs =
        context.getSharedPreferences("user_prefs", Context.MODE_PRIVATE)

    fun saveUsername(name: String) {
        prefs.edit().putString("username", name).apply()
    }

    fun loadUsername(): String =
        prefs.getString("username", "Guest") ?: "Guest"
}

The ViewModel remains clean:

@HiltViewModel
class UserViewModel @Inject constructor(
    private val repository: UserPreferencesRepository
) : ViewModel() {

    val username = MutableStateFlow("")

    fun load() {
        username.value = repository.loadUsername()
    }
}

Notice what’s missing?

No Context in the ViewModel.
 That’s the whole point.

Why This Is Safe (And Recommended)

Let’s address the usual concerns.

Will this leak memory?
 No. Application context lives as long as the app process.

Will this break on rotation?
 No. ViewModels are lifecycle-aware; repositories aren’t tied to UI.

Is this officially recommended?
 Yes. This matches Google’s own Compose + Hilt samples.

Is this future-proof?
 Yes. This is the architecture Android is moving toward, not away from.

What If You Forget @HiltAndroidApp?

Your app will crash early with a clear error:

Hilt Activity must be attached to an @HiltAndroidApp Application

This happens because:

• No ApplicationComponent is created
• No Context binding exists
• Dependency graph cannot be resolved

This is Hilt protecting you — not failing silently.

The One Rule to Remember

Context belongs to the data layer, not the state layer.

If you follow this rule:

• Your architecture scales
• Your code stays testable
• Your app avoids subtle lifecycle bugs

Conclusion

@ApplicationContext isn’t magic.
 It’s a well-defined dependency provided by Hilt at the Application level, injected safely into the data layer, and kept far away from your UI state.

Once you understand this flow, Compose + Hilt stops feeling mysterious — and starts feeling predictable.

If this helped you, consider sharing it with the next developer who asks:
 “But where does the Context come from?”