Android

Managing dependencies in Android development can feel like juggling flaming torches—one wrong move, and your build breaks. If you’re tired of mismatched library versions, build errors, and long Gradle files, Android BOM might be the solution you didn’t know you needed.

In this guide, we’ll break down what Android BOM is, why it matters in 2025, and how you can start using it to clean up your project and avoid versioning headaches.

What Is Android BOM?

BOM stands for Bill of Materials. It’s a feature in Gradle (and supported by Maven too) that lets you manage versions of multiple libraries from a single source.

In the Android world, an Android BOM is typically published by a library maintainer (like Google for Jetpack Compose or Firebase) and defines the versioning for all related artifacts under the hood.

Instead of specifying a version number for each dependency manually, you just import the BOM, and it ensures all components stay in sync.

Why Use Android BOM in 2025?

In 2025, modern Android apps rely on a stack of complex, interconnected libraries. Manually managing versions is error-prone and inefficient.

Here’s why Android BOM is a must-have:

Simplifies Dependency Management

No more version conflicts or mismatched components.

Reduces Boilerplate

You can skip version numbers for each Firebase or Jetpack Compose module.

Keeps Everything in Sync

The BOM ensures all included libraries are compatible with each other.

Easier Upgrades

Want to update Firebase? Just bump the BOM version.

How Does It Work?

Here’s what a typical implementation looks like in your build.gradle.kts or build.gradle file:

Without Android BOM (manual versioning):

dependencies {
    implementation("androidx.compose.ui:ui:1.6.1")
    implementation("androidx.compose.material:material:1.6.1")
    implementation("androidx.compose.ui:ui-tooling-preview:1.6.1")
}

Every library needs a version. If you upgrade, you need to change them all manually.

With Android BOM (simplified and synced):

dependencies {
    implementation(platform("androidx.compose:compose-bom:2025.01.00"))
    
    implementation("androidx.compose.ui:ui")
    implementation("androidx.compose.material:material")
    implementation("androidx.compose.ui:ui-tooling-preview")
}

Only the BOM needs a version. The other libraries inherit it automatically. Clean and safe.

Where Can You Use Android BOM?

Android BOM is commonly used with:

• Jetpack Compose
• Firebase (via com.google.firebase:firebase-bom)
• Ktor (JetBrains’ Kotlin server-client library)
• Any library group that publishes a BOM

It works in both Gradle Kotlin DSL and Groovy.

Each is maintained by the respective teams and updated regularly.

BOM and Version Catalogs

Gradle’s Version Catalogs work perfectly with BOMs. Define the BOM in your libs.versions.toml file:

[versions]
compose-bom = "2025.05.00"

[libraries]
androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "compose-bom" }
ui = { group = "androidx.compose.ui", name = "ui" }

And in your build.gradle.kts:

implementation (platform(libs.androidx.compose.bom))
implementation (libs.ui)

This keeps your dependency management even more organized.

Best Practices When Using Android BOM

• Stick to one BOM per group — Don’t mix Firebase and Compose BOMs in a single platform declaration. You can have multiple BOMs, but declare them separately.
• Keep BOM versions updated — Stay on top of version updates for stability and security.
• Avoid adding versions to individual artifacts if the BOM already manages them.

What If a Library Doesn’t Support BOM?

Some third-party libraries might not publish a BOM. In that case, you’ll still have to manage versions manually. But you can combine both approaches — use BOM for libraries that support it and pin versions for others.

Overriding BOM Versions

Sometimes, you might need a specific library version that’s newer (or older) than what the BOM provides. You can override it by specifying the version directly:

implementation (platform("androidx.compose:compose-bom:2025.05.00"))
implementation ("androidx.compose.material3:material3:1.2.0-alpha09") // Overrides BOM

Be cautious: overriding can break compatibility guarantees, so only do this if necessary.

Common Questions About Android BOM

Does the BOM automatically add all libraries to my app?

No. You still need to declare each library you want to use. The BOM just manages their versions.

Can I use BOM for alpha or beta releases?

Yes! There are alpha, beta, and stable BOMs available. Just add -alpha or -beta to the BOM artifact name:

implementation (platform("androidx.compose:compose-bom-alpha:2025.05.00"))

Am I forced to use BOM?

No, but it’s highly recommended for easier and safer dependency management.

Does BOM increase build time?

Actually, the opposite. Because it simplifies dependency resolution, it can help Gradle builds run more efficiently.

Conclusion

If you’re building Android apps in 2025, using Android BOM isn’t just a nice-to-have — it’s essential. It streamlines dependency management, prevents version mismatches, and keeps your codebase cleaner and safer.

Whether you’re working on a small app or a complex multi-module project, adopting Android BOM early will save you time and frustration.

In modern Android and Kotlin Multiplatform development, managing dependencies across multiple modules can quickly become messy. Manually updating versions in each build.gradle.kts file is not only error-prone—it’s a headache when scaling projects.

That’s where libs.versions.toml steps in—the primary and recommended configuration file for Gradle Version Catalogs, a game-changing feature introduced in Gradle 7.0 and stabilized in 7.4.

In this in-depth guide, you’ll learn how to master libs.versions.toml—from setting it up, organizing your dependencies and plugins, to managing versions like a seasoned pro.

What is libs.versions.toml?

libs.versions.toml is a centralized configuration file introduced in Gradle 7+ that lets you declare and manage dependencies, plugin versions, and bundles in one place.

This improves:

• Readability of dependency definitions
• Consistency across modules
• Maintainability by updating versions in a single file

Enabling Version Catalogs

Before you can use libs.versions.toml, make sure you’re on Gradle 7.0+ and Kotlin DSL (.kts).

In your project’s settings.gradle.kts, enable the version catalog:

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            from(files("gradle/libs.versions.toml"))
        }
    }
}

This tells Gradle to look for a libs.versions.toml file inside the gradle/ directory.

Creating libs.versions.toml

Create the file at:

project-root/
├── gradle/
│   └── libs.versions.toml

Let’s break down its structure.

Structure of the File

The file is divided into three main sections:

[versions]
[libraries]
[plugins]

• [versions]: Define all your version numbers here.
• [libraries]: List your dependencies, referencing versions from above.
• [plugins]: List your plugins, referencing versions as well

Defining Versions

Under [versions], you define the reusable version strings.

[versions]
kotlin = "1.9.22"
agp = "8.4.0"
coroutines = "1.7.3"

This creates version aliases. You can later reference these in your dependency and plugin definitions.

Adding Libraries

Under [libraries], you define the actual dependencies:

[libraries]
compose-ui = { group = "androidx.compose.ui", name = "ui", version.ref = "compose" }
compose-material3 = { group = "androidx.compose.material3", name = "material3", version.ref = "material3" }

Or, use the module shorthand:

[libraries]
compose-ui = { module = "androidx.compose.ui:ui", version.ref = "compose" }
kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }
coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }
retrofit = { module = "com.squareup.retrofit2:retrofit", version = "2.9.0" }

Here, you define your dependencies using aliases. Reference the version from the [versions] block to keep things DRY (Don’t Repeat Yourself).

Explanation:

• module = full Maven coordinate
• version = direct version
• version.ref = refers to a shared version from [versions]

This improves consistency and avoids duplication.

Adding Plugins

Under [plugins], plugins are managed just like libraries. Reference the version from [versions] for consistency.

[plugins]
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
android-application = { id = "com.android.application", version.ref = "agp" }

Using the Version Catalog in Your Build Files

Once your libs.versions.toml is set up, you can use its entries in your module-level build.gradle.kts files.

Applying Plugins

Replace hardcoded plugin IDs and versions with aliases:

plugins {
    alias(libs.plugins.kotlin.android)
}

Adding Dependencies

Use the aliases you defined for dependencies:

dependencies {
    implementation(libs.compose.ui)
    implementation(libs.compose.material3)
}

Using Bundles (optional, but highly recommended for grouping related dependencies)

You can group related dependencies into bundles for convenience:

[bundles]
compose = [
    "compose-ui",
    "compose-material3"
]

And use them in your build file:

dependencies {
    implementation(libs.bundles.compose)
}

It reduces boilerplate and enforces consistency.

Pro Tips for libs.versions.toml

1. Use Comments Wisely

Unlike JSON or YAML, .toml supports inline comments:

kotlin = "1.9.22" # Kotlin version used for both plugin and stdlib

Helpful when collaborating or reviewing changes.

2. Semantic Grouping

Group dependencies logically: UI, Networking, Testing, etc.

[libraries]
# UI
compose-ui = { module = "androidx.compose.ui:ui", version = "1.6.2" }
compose-material = { module = "androidx.compose.material:material", version = "1.6.2" }

# Testing
junit = { module = "junit:junit", version = "4.13.2" }

Improves navigation and scalability.

3. Version Locking & Conflict Resolution

If you use a dependency with a transitive mismatch, use constraints in build.gradle.kts:

dependencies {
    implementation(libs.some.lib)
    constraints {
        implementation("some:transitive-lib:1.2.3")
    }
}

This ensures predictable builds.

Real-world Usage Example

libs.versions.toml:

[versions]
kotlin = "1.9.22"
agp = "8.4.0"
coroutines = "1.7.3"
compose = "1.6.2"

[libraries]
kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }
coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }
compose-ui = { module = "androidx.compose.ui:ui", version.ref = "compose" }

[plugins]
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
android-application = { id = "com.android.application", version.ref = "agp" }

[bundles]
core = ["kotlin-stdlib", "coroutines-core"]

app/build.gradle.kts:

plugins {
    alias(libs.plugins.kotlin.android)
    alias(libs.plugins.android.application)
}

dependencies {
    implementation(libs.bundles.core)
    implementation(libs.compose.ui)
}

Simple, elegant, and maintainable.

Why libs.versions.toml Matters

As projects grow, consistency becomes critical. libs.versions.toml:

• Reduces version mismatches
• Makes updates seamless
• Keeps modules DRY (Don’t Repeat Yourself)
• Is IDE-friendly and fully supported by Android Studio

It’s the kind of practice that scales well in enterprise codebases and simplifies maintenance.

Conclusion

If you’re not using libs.versions.toml, now’s the time to start.

Whether you’re building a small Android app or managing dozens of modules across a large monorepo, version catalogs offer clarity, consistency, and control.

Keep your libs.versions.toml organized, document versions, and treat it like your project’s single source of truth.

If you’re still using SharedPreferences in your Android app, it’s time to level up. Google introduced Jetpack DataStore as the modern solution for storing key-value and typed objects in a more efficient, safe, and asynchronous way.

In this guide, we’ll walk you through how to migrate from SharedPreferences to Jetpack DataStore, step by step, with easy-to-follow code examples and clear explanations.

Let’s future-proof your app’s data storage..!

Why Migrate from SharedPreferences to Jetpack DataStore?

Before we jump into the code, here’s why the switch matters:

• Asynchronous: DataStore is built on Kotlin Coroutines, meaning no more blocking the main thread.
• Type safety: With Proto DataStore, you can define your own schema.
• More robust: Handles data consistency and corruption better.
• Google-backed: DataStore is the future; SharedPreferences is legacy.

So let’s get into it.

Step 1: Add DataStore Dependencies

First, update your build.gradle (app-level) file:

dependencies {
    implementation "androidx.datastore:datastore-preferences:1.0.0"
}

Sync your project to download the necessary libraries.

Step 2: Create Your DataStore Instance

Unlike SharedPreferences, you don’t instantiate DataStore directly. Instead, use an extension on Context.

val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "user_prefs")

Place this in a Kotlin file (e.g., DataStoreModule.kt) at the top-level (outside any class).

Step 3: Reading Data from DataStore

Let’s say you used to read the user’s theme like this:

val isDarkMode = sharedPreferences.getBoolean("dark_mode", false)

Here’s how to do it with DataStore:

val DARK_MODE_KEY = booleanPreferencesKey("dark_mode")

val isDarkModeFlow: Flow<Boolean> = context.dataStore.data
    .map { preferences ->
        preferences[DARK_MODE_KEY] ?: false
    }

Btw, what’s happening here?

• DARK_MODE_KEY is a typed key (you can have string, int, float, etc.).
• dataStore.data returns a Flow of Preferences.
• map transforms it to the value you care about.

To observe the value:

lifecycleScope.launch {
    isDarkModeFlow.collect { isDark ->
        // Update UI or store in variable
    }
}

Step 4: Writing Data to DataStore

Here’s how you’d save data using SharedPreferences:

sharedPreferences.edit().putBoolean("dark_mode", true).apply()

With DataStore:

suspend fun saveDarkModeSetting(context: Context, isDarkMode: Boolean) {
    context.dataStore.edit { preferences ->
        preferences[DARK_MODE_KEY] = isDarkMode
    }
}

This function must be called from a coroutine or lifecycleScope.launch {}.

Step 5: Migrate Existing Data from SharedPreferences

Let’s say you have existing users and don’t want to lose their preferences.

Jetpack provides a migration tool built in:

val Context.dataStore: DataStore<Preferences> by preferencesDataStore(
    name = "user_prefs",
    produceMigrations = { context ->
        listOf(SharedPreferencesMigration(context, "user_prefs"))
    }
)

This tells DataStore to automatically read and move values from SharedPreferences the first time it’s accessed.

Important:

• The name in preferencesDataStore must match the SharedPreferences file name.
• After migration, DataStore handles everything.

Step 6: Remove SharedPreferences Usage

Once you’re confident DataStore is working, clean up your codebase:

• Delete old SharedPreferences references
• Remove the old preference XML file if applicable

This makes your app lighter and future-proof.

Bonus: Best Practices for DataStore

• Use a singleton or Context extension to access DataStore.
• Keep key declarations in one place (object or constants file).
• Prefer Flow + collect with lifecycle awareness to avoid leaks.
• Validate and sanitize user input before writing to DataStore.

Conclusion

Migrating from SharedPreferences to Jetpack DataStore is a smart move. It modernizes your data layer, embraces async programming, and makes your app more robust.

With the step-by-step guide above, you should now feel confident making the switch. It’s not just about keeping up with Android trends — it’s about building better apps.

So go ahead, migrate from SharedPreferences to Jetpack DataStore, and give your app the stability and performance it deserv

If you’ve ever wondered why your Android phone suddenly becomes stingy with background tasks when left idle, the answer likely lies in Doze Mode. Introduced in Android 6.0 (Marshmallow), this feature promised to significantly improve battery life. But does it actually deliver? 

Let’s break it down.

What Is Doze Mode?

Doze Mode is a battery-saving feature that kicks in when your device is idle for an extended period. Think of it as your phone going into “power nap” mode. During Doze, the system restricts background activities such as syncing, GPS, and network access to conserve energy.

Android doesn’t completely shut off these services but defers them to periodic maintenance windows. So your device can still check for important updates — just not every second.

When Does Doze Mode Activate?

Doze Mode isn’t triggered the moment you stop using your phone. Android checks several conditions:

• The device is unplugged.
• The screen is off.
• The phone hasn’t moved for a while.
• No active wake locks are held by apps.

Once all conditions are met, the phone enters Idle mode, and Doze begins throttling background processes.

Does Doze Mode Really Save Battery?

In one word: Yes — but with context.

Real-World Impact

If you’re someone who leaves their phone idle for long periods (e.g., overnight or during work hours), Doze Mode can significantly extend battery life. Users have reported up to 30% more standby time.

However, if your phone is constantly in use, or you’re moving around with it in your pocket, Doze may not activate often enough to make a noticeable difference.

How Developers Handle Doze Mode

If you’re a developer, ignoring Doze Mode can lead to broken background functionality. Here’s a simple example of how to test if your app works with Doze:

Requesting Exemption from Doze Mode

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
    String packageName = context.getPackageName();
    if (!pm.isIgnoringBatteryOptimizations(packageName)) {
        Intent intent = new Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
        intent.setData(Uri.parse("package:" + packageName));
        context.startActivity(intent);
    }
}

• This code checks if your app is excluded from Doze Mode.
• If it isn’t, it launches a system dialog requesting the user to whitelist your app.
• Be cautious: this should only be used for essential apps like alarms or health monitors.

Please note, you must have this permission in your AndroidManifest.xml:

<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>

How to Check If Doze Mode Is Hurting App Performance

Some apps rely heavily on real-time background updates (think messaging or location tracking). If users report delays or missed notifications, Doze could be the culprit.

Quick Fix for Users

1. Go to Settings > Battery > Battery Optimization.
2. Select “All apps.”
3. Tap your app and choose “Don’t optimize.”

This removes Doze restrictions for that app, but use sparingly to avoid draining your battery.

How Android Developers Can Handle It

If you’re an app developer, you’ll want to make sure your app behaves properly while Doze Mode is active. Android offers special APIs so your alarms and background jobs don’t get lost in the shuffle.

Example: Scheduling Alarms in Doze Mode

By default, normal alarms are postponed. If your app needs to set a time-sensitive alarm (think: medication reminders or calendar events), you must use setAndAllowWhileIdle():

AlarmManager alarmMgr = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
PendingIntent alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

alarmMgr.setAndAllowWhileIdle(
    AlarmManager.RTC_WAKEUP,
    triggerAtMillis, // desired trigger time in milliseconds
    alarmIntent
);

How This Works

• setAndAllowWhileIdle() lets your alarm fire even if Doze Mode is triggered—but only for critical events.
• Use this carefully, as Android limits how often you can schedule these alarms during Doze to prevent battery drain.

Best Practices for Developers

1. Use WorkManager: It’s built to handle Doze correctly.
2. Schedule jobs wisely: Use JobScheduler or AlarmManager with setAndAllowWhileIdle().
3. Test aggressively: Use adb shell dumpsys deviceidle to simulate Doze in development.

Final Verdict: Is Doze Mode Worth It?

Absolutely. For most users, Doze Mode runs silently in the background, extending battery life without sacrificing usability. It’s one of those features that just works — when you let it.

However, for power users and developers, understanding how Doze interacts with apps is essential. Used properly, Doze Mode strikes a smart balance between saving power and staying connected.

So yes, Doze Mode really does save battery. It’s not a gimmick — just smart engineering.

TL;DR (Too Long; Didn’t Read)

• Doze Mode saves battery by pausing background tasks when your phone is idle.
• It’s most effective when the device is stationary and unused.
• Developers must adapt their apps to work within Doze constraints.
• It works quietly, efficiently, and yes — it makes a real difference.

Frequently Asked Questions

Will I Miss Important Calls or Messages Because of Doze Mode?

No, Doze Mode is designed to allow high-priority push notifications and alarm clock events even while active, so you don’t miss critical alerts.

Can I Turn Off Doze Mode?

By default, Doze Mode is automatic and always-on from Android 6.0 onward. You can exclude specific apps via Android settings if you need certain apps to bypass it, but this can hurt your battery life.

Does Doze Mode Replace Battery Saver?

No, it’s a different feature. Battery Saver is a manual or automatic mode you can toggle, restricting performance and features for more aggressive savings. Doze Mode works behind the scenes automatically, focusing on background tasks while idle

When it comes to balancing app performance, user experience, and battery life, Android uses a sophisticated system of resource management that adapts dynamically based on the device’s current state. Understanding how these resource limits work is crucial for developers aiming to build efficient, battery-friendly, and responsive apps. 

In this blog, we’ll dive deep into how Android enforces or exempts resource limits depending on whether the device is charging, the screen is on, or the device is in a low-power mode like Doze.

Why Device State Matters for Resource Limits

Modern smartphones juggle dozens of apps and background processes at once. Without some form of resource control, one rogue app could drain your battery, clog the network, or degrade user experience for everything else running on your phone. To combat this, Android classifies device state into several modes — charging, screen on, and screen off with Doze active — and applies or lifts resource limits accordingly.

Resource Controls by Device State: The Big Picture

Let’s break down how resource limits change based on the device state, focusing on four key areas every developer and advanced user should know: Jobs, Alarms, Network Access, and Firebase Cloud Messaging (FCM).

1. Device Charging

Charging is the most permissive state.

• Jobs: When your device is plugged in, most job execution limits are lifted, with the exception of apps in the restricted standby bucket (these are apps the user or system has placed under heavy restriction for background activity).
• Alarms: There are essentially no limits to alarm scheduling, unless you have manually restricted an app’s battery usage.
• Network Access: Apps can access the network freely. No special throttling or restrictions are applied.
• FCM: Firebase Cloud Messaging enjoys unrestricted delivery of both high and normal priority messages while charging.

If your app needs to perform heavy background work, leveraging the charging state is best practice for both user satisfaction and energy efficiency.

2. Screen On

Active usage, but with smart checks in place.

• Jobs: Execution of background jobs is allowed, but still subject to limits based on the app’s standby bucket. Apps the system deems “frequent” get more leeway than those rarely used.
• Alarms: Alarm limits are enforced based on both process (foreground or background) and standby bucket.
• Network Access: Access to network resources is permitted, but could be throttled depending on standby bucket or app process state.
• FCM: No restrictions. Both high and normal priority FCM messages are delivered without delay.

Even with the screen on, background execution is managed to prevent resource hogging but without compromising the user’s foreground tasks.

3. Screen Off & Doze Mode

Aggressive conservation to preserve battery.

• Jobs: Execution is heavily restricted. Jobs are only permitted to run during periodic “maintenance windows” triggered by Doze. The standby bucket further dictates how much background work an app can do — a rarely used app may only get a 10-minute quota every 24 hours.
• Alarms: Most alarms, especially regular alarms, are deferred until these maintenance windows. “While-idle” alarms are strictly limited (e.g., 7 per hour). This ensures that the device is not frequently awakened from deep sleep, maximizing battery savings.
• Network Access: Network requests are typically deferred, especially for background apps. Only the most essential tasks will get through during Doze.
• FCM: High priority messages are delivered immediately, bypassing Doze. Normal priority messages are deferred until the next maintenance window, so non-urgent notifications may experience some delay.

Doze mode is designed to maximize standby time without missing critical notifications or updates. Writing efficient background code means understanding and respecting these constraints.

Device State vs. Resource Limits

Developer Takeaways and Best Practices

• Schedule background-intensive work during charging: Use job scheduling APIs to detect charging state and defer heavy tasks until then.
• Respect Doze and App Standby Buckets: Design your background operations to be efficient and infrequent, using WorkManager or JobScheduler for compatibility.
• Use High Priority FCM judiciously: Only essential and time-sensitive notifications should be sent with high priority to respect users’ battery life.
• User control matters: Remember, users can manually restrict battery usage for specific apps, which overrides nearly all exemptions.

Conclusion

Android’s adaptive resource limits are a cornerstone of its battery and performance management strategy. By understanding how device state influences background jobs, alarms, network access, and cloud messaging, developers can craft apps that play nicely with the system, keeping users happy and devices running longer

Android power management has evolved significantly over the years. As developers, we need to design apps that are not only functional but also battery-friendly. Google introduced Doze Mode, App Standby, and various resource restrictions to extend battery life. While these features improve user experience, they can cause unexpected issues if apps aren’t built with resilience in mind.

In this guide, we’ll break down Android power management features, why they matter, and how you can build resilient Android apps that survive and thrive under these restrictions.

Why You Should Care About Android Power Management

Modern Android devices aggressively manage background processes to save battery. If your app misbehaves — draining battery or waking up the device too often — it can be throttled, delayed, or even killed. Worse case, when you might see user complaints about missed notifications or slow updates.

By understanding how Doze Mode, App Standby, and background restrictions work, you can ensure your app remains responsive while respecting battery life.

Doze Mode

Doze Mode activates when a device is idle for a while — screen off, unplugged, and stationary. Android periodically defers background CPU and network activity to preserve battery.

Key Points:

• Your app’s background tasks get paused.
• Network access is restricted.
• Alarms (except AlarmManager.setExactAndAllowWhileIdle()) are deferred.

How to Handle Doze Mode Correctly:

PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
if (pm.isIgnoringBatteryOptimizations(getPackageName())) {
    // Your app is exempted from Doze (rarely recommended)
} else {
    // Use WorkManager or Firebase JobDispatcher for background tasks
}

Instead of fighting Doze, work with it. Use WorkManager for deferrable background tasks. It automatically handles Doze and other restrictions.

App Standby: What Developers Must Know

App Standby identifies apps that aren’t used frequently and restricts their background activity.

Behavior:

• Background network access is blocked.
• Jobs and alarms are deferred.
• High-priority notifications still work.

Detecting App Standby Bucket:

UsageStatsManager usageStatsManager = (UsageStatsManager) getSystemService(Context.USAGE_STATS_SERVICE);
int appStandbyBucket = usageStatsManager.getAppStandbyBucket();

switch (appStandbyBucket) {
    case UsageStatsManager.STANDBY_BUCKET_ACTIVE:
        // App is active
        break;
    case UsageStatsManager.STANDBY_BUCKET_RARE:
        // App is rarely used
        break;
}

Encourage user engagement with meaningful notifications to avoid landing in the “rare” bucket.

Background Execution Limits

Starting from Android 8.0 (Oreo), background execution limits make Android power management stricter:

• Background services can’t run freely.
• Implicit broadcasts are restricted.

Solution: WorkManager to the Rescue

WorkManager workManager = WorkManager.getInstance(context);
OneTimeWorkRequest workRequest = new OneTimeWorkRequest.Builder(MyWorker.class).build();
workManager.enqueue(workRequest);

Replace IntentService with JobIntentService or WorkManager to ensure reliability.

Optimizing Notifications Under Power Management

Notifications are crucial for engagement, but Android power management policies may delay them if improperly handled.

Best Practices:

• Use Firebase Cloud Messaging (FCM) with high-priority messages sparingly.
• Avoid unnecessary wake-ups; reserve high-priority FCM for time-critical updates.
• Use NotificationManager correctly to deliver timely, non-intrusive notifications.

NotificationCompat.Builder builder = new NotificationCompat.Builder(this, CHANNEL_ID)
    .setSmallIcon(R.drawable.notification_icon)
    .setContentTitle("Update Available")
    .setContentText("New data ready to view!")
    .setPriority(NotificationCompat.PRIORITY_HIGH);

High-priority FCM bypasses Doze but excessive usage can get your app flagged.

Avoid Common Pitfalls

Don’t abuse foreground services. They drain battery and annoy users if misused.

Don’t request battery optimization exemptions unless absolutely necessary. Google Play has strict policies and most requests get denied.

Do leverage JobScheduler, WorkManager, and FCM effectively.

Do test under real conditions. Use adb shell dumpsys deviceidle to simulate Doze Mode and check your app’s behavior.

Conclusion

Building resilient Android apps means respecting Android power management rather than working around it. Focus on:

• Using WorkManager for background tasks.
• Optimizing notifications.
• Monitoring app standby behavior.

By designing apps that adapt to Android’s power-saving mechanisms, you’ll deliver reliable experiences without draining users’ batteries. 

If you’ve noticed your Android app getting delayed push notifications, or background tasks not running as expected, the culprit could be Android Standby Bucket.

This isn’t some hidden developer setting — it’s a key part of Android’s power management system. And if you want your app to work smoothly in the background without draining battery, you need to understand how the Standby Bucket works, how it categorizes apps, and what you can do to stay on Android’s good side.

Let’s break it all down in simple way.

What Is Android Standby Bucket?

The Android Standby Bucket is a power management feature introduced in Android 9 (Pie). It groups apps into “buckets” based on how frequently the user interacts with them.

Why..? 

Because Android wants to optimize battery life. And background activity — like location updates, network calls, or jobs running silently — can suck up power fast.

So Android created a smart system that limits background access for apps the user rarely uses.

The Five Standby Buckets Explained

Here are the five standby buckets an app can fall into:

Active

• The user is actively using the app.
• No background restrictions.

Working Set

• Used recently but not in the foreground now.
• Minor restrictions apply.

Frequent

• Used regularly but not daily.
• Background access is more limited.

Rare

• Used occasionally.
• Significant background restrictions.

Restricted

• Manually restricted or flagged by the system for battery drain.
• Heavily limited in all background access.

Your app moves between these buckets dynamically based on user behavior — and that impacts what you can do in the background.

Why Should Developers Care?

If your app needs to do anything in the background — sync data, send reminders, update location — you must understand where your app stands in the Standby Bucket hierarchy.

Failing to adapt could mean:

• Missed push notifications.
• Jobs not running on time.
• Background tasks being throttled or killed.

And ultimately, frustrated users.

How to Check Your App’s Bucket With Code

You can check which bucket your app is currently in using UsageStatsManager. 

val usageStatsManager = getSystemService(Context.USAGE_STATS_SERVICE) as UsageStatsManager
val standbyBucket = usageStatsManager.appStandbyBucket

when (standbyBucket) {
    UsageStatsManager.STANDBY_BUCKET_ACTIVE -> Log.d("Bucket", "App is Active")
    UsageStatsManager.STANDBY_BUCKET_WORKING_SET -> Log.d("Bucket", "App is in Working Set")
    UsageStatsManager.STANDBY_BUCKET_FREQUENT -> Log.d("Bucket", "App is Frequent")
    UsageStatsManager.STANDBY_BUCKET_RARE -> Log.d("Bucket", "App is Rare")
    UsageStatsManager.STANDBY_BUCKET_RESTRICTED -> Log.d("Bucket", "App is Restricted")
    else -> Log.d("Bucket", "Unknown Bucket")
}

This snippet uses UsageStatsManager to get the current standby bucket. Based on that, you can log or trigger actions to adjust your app’s behavior accordingly.

How the Standby Bucket Impacts Background Activity

Here’s what each bucket means for your app’s background capabilities:

This directly impacts APIs like:

• WorkManager
• AlarmManager
• JobScheduler
• Firebase Cloud Messaging (FCM)

If you’re wondering why your background sync isn’t firing, check your bucket first.

How to Keep Your App in a Good Bucket

You can’t directly set the bucket, but you can influence it by keeping users engaged:

1. Encourage Regular Use

Design for stickiness. The more users interact with your app, the better your bucket position.

2. Send Relevant Notifications

Make sure your notifications lead to real engagement. Avoid spamming or your app could get demoted.

3. Use Foreground Services Wisely

For important tasks (like location tracking or media playback), run them in a foreground service with a visible notification.

4. Follow Background Execution Limits

Stick to Android’s guidelines. Use WorkManager for deferred tasks and ForegroundService for immediate ones.

Best Practices for Dealing With Standby Buckets

• Test under all bucket conditions: Simulate lower buckets using ADB (see below).
• Use JobScheduler.setRequiresDeviceIdle() carefully: It might never trigger if your app is in a low bucket.
• Monitor your background task success rate: Adjust logic depending on current restrictions.

Simulating Buckets with ADB

You can force your app into a specific bucket for testing:

adb shell am set-standby-bucket com.yourapp.package rare

To reset:

adb shell am reset-standby-bucket com.yourapp.package

This is incredibly useful for QA and debugging.

Real-World Examples

• Social Media Apps: Stay in Active/Working Set buckets due to frequent use, keeping messages and updates timely.
• Fitness App Used Weekly: Dropped to Frequent or Rare, background syncs may be delayed, so design your UI to handle missing updates gracefully.
• Single-Purpose Utility: Used once after installation, then falls to Rare or even Restricted. Background operations almost always deferred.

Conclusion

The Android Standby Bucket system is here to stay. It’s designed to protect user battery life while still allowing well-behaved apps to run efficiently.

By understanding how it works and adapting your app’s background behavior accordingly, you’ll build a better, more battery-friendly experience for your users.

Remember: apps that respect user attention and system resources will always win in the long run.

FAQs

What is Android Standby Bucket?
 It’s a power-saving feature that groups apps based on usage to limit background activity. Apps are bucketed as Active, Working Set, Frequent, Rare, or Restricted.

How does it impact apps?
 The lower the bucket, the more Android restricts background tasks, job scheduling, and network access.

How to check your app’s bucket?
 Use UsageStatsManager.appStandbyBucket to programmatically find the current bucket.

How to stay in a good bucket?
 Encourage engagement, follow background limits, and use foreground services wisely.

Let’s talk about something that trips up a lot of Android developers — especially when building apps with complex navigation: the Android Back Stack.

You know that moment when you hit the back button and your app behaves like it has a mind of its own? Yeah, we’ve all been there. The Android Back Stack can be tricky, but once you get a handle on it, your app’s navigation feels intuitive, snappy, and exactly how users expect it to behave.

This guide breaks it down step by step, with real-world code examples, clear explanations, and some personal tips from my own development experience.

What Is the Android Back Stack, Really?

The Android Back Stack is just a managed stack (think: a vertical pile) of activities or fragments that tracks the user’s navigation history. When the user presses the back button, Android pops the top of the stack and returns to the previous screen.

Simple in theory. In practice? It gets more interesting.

Let’s start with an example.

Activities and the Back Stack

When you start a new activity using:

val intent = Intent(this, SecondActivity::class.java)
startActivity(intent)

Android pushes SecondActivity onto the back stack. Now, pressing the back button pops it off and returns you to MainActivity.

So far, so good.

By default, each call to startActivity() adds the new activity to the task’s back stack, unless you explicitly modify this behavior using intent flags or manifest attributes.

Customizing Back Stack Behavior with Intent Flags

You can tweak the back stack behavior with intent flags. Here are a few you’ll use often:

1. FLAG_ACTIVITY_CLEAR_TOP

Let’s say your stack looks like this: A → B → C → D

If you call startActivity() from D to go back to B with FLAG_ACTIVITY_CLEAR_TOP, Android will pop off C and D and bring B to the top.

val intent = Intent(this, B::class.java)
intent.flags = Intent.FLAG_ACTIVITY_CLEAR_TOP
startActivity(intent)

It’s like saying: “Hey Android, I want B on top again — clear anything above it.”

2. FLAG_ACTIVITY_NEW_TASK

This one creates a new task entirely. It’s mostly used in system-level or launcher-related contexts.

val intent = Intent(this, MainActivity::class.java)
intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK
startActivity(intent)

3. FLAG_ACTIVITY_SINGLE_TOP

If the activity you’re trying to start is already at the top of the stack, don’t create a new instance — just reuse the existing one.

val intent = Intent(this, ProfileActivity::class.java)
intent.flags = Intent.FLAG_ACTIVITY_SINGLE_TOP
startActivity(intent)

You’ll also need to handle this in onNewIntent() in the target activity.

Fragments and the Back Stack: The Modern Way

These days, many apps use fragments instead of spinning up new activities. That’s where things get more nuanced.

When using fragments, you manage the back stack yourself with FragmentManager. Here’s how you can add a fragment to the back stack:

supportFragmentManager.beginTransaction()
    .replace(R.id.fragment_container, SecondFragment())
    .addToBackStack(null)
    .commit()

Calling addToBackStack() (with either null or a string tag) adds the fragment transaction to the back stack, which means the system will remember it and can reverse the transaction—i.e., remove the newly added fragment and restore the previous one—when the back button is pressed.

If addToBackStack() is not called, the transaction is not saved to the back stack, so pressing the back button does not reverse that specific transaction.

In that case, if there are no other entries in the back stack and no other UI elements to pop, pressing the back button will exit the activity (if you’re at the top of the stack).

Pro Tip: Naming Your Back Stack Entries

You can pass a string tag to addToBackStack("tag_name") to track what’s on the stack. This helps with debugging or popping specific entries.

.addToBackStack("SecondFragment")

Then later:

supportFragmentManager.popBackStack("SecondFragment", 0)

You now have surgical control over your navigation history.

Jetpack Navigation Component: A Modern Solution

If you’re using the Jetpack Navigation Component (and you probably should be), it abstracts much of this back stack management while still giving you hooks when needed.

findNavController().navigate(R.id.action_home_to_detail)

And to go back:

findNavController().popBackStack()

The Navigation Component maintains a back stack internally and works seamlessly with the system back button and deep links. It also integrates nicely with BottomNavigationView, DrawerLayout, and more.

Common Mistakes and How to Avoid Them

Here are a few Android Back Stack missteps I’ve seen:

Mistake #1: Forgetting addToBackStack()

If you don’t add your fragment transaction to the back stack, pressing back won’t return to the previous fragment — it might just exit the app.

Mistake #2: Overusing Activities

Switching activities too often can make your app feel clunky. Stick to fragments when screens are tightly related.

Mistake #3: Ignoring Task Affinities

Sometimes, your app can get into weird states when launched from a notification or deep link. Always check if your task and back stack behave as expected.

Handling the System Back Button

You can override the back button behavior in both activities and fragments:

In an activity:

override fun onBackPressed() {
    // Custom logic
    super.onBackPressed()
}

In a fragment (Jetpack way):

requireActivity().onBackPressedDispatcher.addCallback(viewLifecycleOwner) {
    // Your custom back logic here
}

This gives you full control while still respecting Android’s expected navigation model.

Conclusion

A smooth, predictable back navigation experience is one of the most critical parts of mobile UX. Users expect it to “just work.”

Understanding how the Android Back Stack works — and how to tame it — gives you a major edge as a developer. Whether you’re working with activities, fragments, or the Navigation Component, mastering this system ensures your app feels polished and professional.

When building Android apps, it’s easy to focus only on the code, UI, and features. But behind every successful app lies a set of powerful, low-level tools that keep the whole process moving. These are the Android SDK Tools — the unsung heroes of the Android development ecosystem.

In this post, we’ll break down what they are, how they work, and why every Android developer should understand them — even in the age of Android Studio.

What Are Android SDK Tools?

Android SDK Tools are a collection of command-line utilities that help you build, test, and debug Android apps. They used to be packaged together as “SDK Tools,” but over time, they’ve been split into modular components like:

• platform-tools — includes ADB, fastboot, and other core tools.
• build-tools — includes utilities like aapt, zipalign, etc.

Even though Android Studio handles much of this behind the scenes, these tools are still critical — especially when things go wrong, or when you want to automate development tasks.

Essential SDK Tools Every Android Developer Should Know

Let’s take a closer look at the key tools that power Android development under the hood:

1. ADB (Android Debug Bridge)

ADB is a command-line tool that lets your computer communicate with an Android device or emulator.

Think of it as a remote control for your Android environment. You can install apps, copy files, debug logs, and even run shell commands directly on the device.

Common ADB Commands:

adb devices             # Lists connected devices
adb install myapp.apk   # Installs an APK
adb logcat              # Displays real-time device logs

This is one of the most valuable tools in your toolbox, especially for real-time debugging.

2. fastboot

When your device is in bootloader mode, fastboot lets you flash images to the device, unlock the bootloader, and perform other low-level operations.

It’s typically used for:

• Flashing custom recoveries or ROMs
• Unlocking or locking bootloaders
• Recovering bricked devices

While not every developer uses fastboot regularly, it’s indispensable for anyone working near the hardware layer or with custom builds.

3. R8 and ProGuard

Originally, ProGuard was used to shrink and obfuscate Java code in Android apps. Today, R8 has replaced it as the default tool for most modern Android projects.

R8 performs:

• Code shrinking
• Dead code elimination
• Resource optimization
• Obfuscation (to make reverse engineering harder)

R8 is built into the Android Gradle plugin, so you don’t typically run it manually — but understanding what it does can help you configure it properly in proguard-rules.pro.

Why These Tools Still Matter in 2025

Even though Android Studio and Gradle handle most of the heavy lifting today, knowing how SDK tools work gives you:

• More control over your builds and deployments
• Better debugging capabilities, especially on real devices
• The ability to automate testing, CI/CD, and device management
• Deeper insights into how Android actually works

When something breaks outside the Studio UI, these tools are often your first (and best) line of defense.

Conclusion

The Android SDK Tools may not be glamorous, but they are the engine under the hood of Android development. Whether you’re pushing your first APK or debugging a complex issue, understanding ADB, fastboot, and R8 will make you a more capable — and confident — developer.