Artificial intelligence on mobile devices is no longer a futuristic concept — it’s part of our daily tech life. From facial recognition to voice assistants, AI is everywhere. For Android developers, the Neural Networks API (NNAPI) is the key to unlocking efficient on-device AI. In this guide, you’ll learn everything about NNAPI, why it matters, how it...
If you’ve ever worked with AI models, you know how exciting it is to see them in action. But here’s the catch — many models are slow to run, especially in production environments. That’s where ONNX Runtime comes in. It’s a game-changer for speeding up model inference without changing the model itself.
In this guide, you’ll learn exactly what ONNX Runtime is, why it’s useful, and how you can use it to run your AI models faster. Whether you’re a beginner in AI or an experienced developer looking for performance boosts, this post will break it down simply and clearly.
ONNX Runtime is an open-source, high-performance engine for running machine learning models. Developed by Microsoft, it supports models trained in popular frameworks like PyTorch, TensorFlow, and scikit-learn by converting them to the ONNX (Open Neural Network Exchange) format.
Think of ONNX Runtime as a universal language interpreter for AI models. You train your model in any framework, convert it to ONNX, and then ONNX Runtime takes care of running it efficiently across various hardware (CPU, GPU, even specialized accelerators).
ONNX Runtime is optimized for speed. It reduces inference time dramatically compared to native frameworks.
It runs on Windows, Linux, macOS, Android, and iOS. You can use it in cloud services, edge devices, or even mobile apps.
Supports models from PyTorch, TensorFlow, scikit-learn, XGBoost, and more — once converted to ONNX.
Faster inference means fewer resources and lower cloud costs. Who doesn’t like saving money..?
Here’s the simple flow:
Let’s see a basic Python example to understand how to use ONNX Runtime.
pip install onnxruntimeThis command installs the CPU version. If you have a GPU, you can install the GPU version like this:
pip install onnxruntime-gpuLet’s say you have a model called model.onnx.
import onnxruntime as ort
# Create an inference session
session = ort.InferenceSession("model.onnx")You need to know the input names and shapes.
import numpy as np
# Get input name
input_name = session.get_inputs()[0].name
# Create dummy input
input_data = np.random.randn(1, 3, 224, 224).astype(np.float32)# Run inference
outputs = session.run(None, {input_name: input_data})
print("Model Output:", outputs[0])That’s it! You just ran an AI model using ONNX Runtime in a few lines of code.
import torch
# Example PyTorch model
model = torch.hub.load('pytorch/vision', 'resnet18', pretrained=True)
model.eval()
# Dummy input
dummy_input = torch.randn(1, 3, 224, 224)
# Export to ONNX
torch.onnx.export(model, dummy_input, "resnet18.onnx")Now you can use resnet18.onnx with ONNX Runtime for fast inference.
| Use Case | ONNX Runtime Benefit |
|---|---|
| Production deployment | Faster inference and hardware flexibility |
| Edge devices (IoT) | Smaller footprint and speed |
| Cloud services | Reduced inference costs |
| Multi-framework pipelines | Easier model standardization |
If you need consistent, fast model inference across different environments, ONNX Runtime is a solid choice.
| Feature | PyTorch/TensorFlow | ONNX Runtime |
|---|---|---|
| Inference Speed | Good | Faster, optimized kernels |
| Deployment Flexibility | Limited | Multi-platform, hardware-optimized |
| Framework Lock-in | Yes | No, cross-framework support |
| Learning Curve | Framework-specific | Simple API, easy to adopt |
onnxoptimizer help remove redundant operations.CUDAExecutionProvider for GPU, CPUExecutionProvider for CPU, or others like TensorRT.ONNX Runtime is not just a tool — it’s a performance booster for AI inference. It simplifies deployment, cuts inference time, and makes your AI projects more scalable.
If you’ve been struggling with slow model inference or complicated deployments, ONNX Runtime is your friend. Install it, give it a try, and see the speed-up for yourself.
Q: Is ONNX Runtime free?
Yes, it’s completely open-source and free to use under the MIT license.
Q: Can I use ONNX Runtime with GPU?
Absolutely. Just install onnxruntime-gpu and you’re good to go.
Q: Does ONNX Runtime support quantized models?
Yes! It supports quantization for even faster and smaller models.
Artificial Intelligence (AI) seems like magic — type a prompt and it answers, upload a picture and it identifies objects, or speak to your phone and it replies smartly. But what happens behind the scenes when an AI makes these decisions? The answer lies in a crucial process called model inference in AI.
In this guide, we’ll keep things simple and walk through a few easy coding examples. Whether you’re new to AI or just curious about how it works, you’ll come away with a clear understanding of how AI models make real-world predictions.
Think of AI as a student who spends months studying (training) and finally takes a test (inference). Model inference in AI refers to the phase where a trained model uses its knowledge to make predictions or decisions on new data it hasn’t seen before.
When you ask a chatbot a question or upload an image to an app, the model is performing inference — it’s not learning at that moment but applying what it has already learned.
It’s the AI’s way of taking what it learned and helping you in the real world.
Without inference, AI would be useless after training. The whole point of AI is to make smart decisions quickly and reliably on new data.
Here’s why model inference in AI matters:
Let’s walk through a typical inference workflow in simple terms.
This is the real-world information the AI needs to process:
Before sending the input to the model, it’s cleaned and formatted:
The preprocessed data enters the trained model:
The raw model output is converted into human-friendly results:
Finally, the AI gives you the result: a prediction, an answer, or an action.
Let’s see a practical example using Python and a pretrained model from PyTorch.
import torch
from torchvision import models, transforms
from PIL import Image
# Load a pretrained model (ResNet18)
model = models.resnet18(pretrained=True)
model.eval() # Set model to inference mode
# Preprocessing steps
preprocess = transforms.Compose([
transforms.Resize(256),
transforms.CenterCrop(224),
transforms.ToTensor(),
transforms.Normalize(mean=[0.485, 0.456, 0.406],
std=[0.229, 0.224, 0.225]),
])
# Load and preprocess the image
image = Image.open("cat.jpg")
input_tensor = preprocess(image)
input_batch = input_tensor.unsqueeze(0) # Add batch dimension
# Model Inference
with torch.no_grad():
output = model(input_batch)
# Get the predicted class
_, predicted_class = torch.max(output, 1)
print(f"Predicted class index: {predicted_class.item()}")Here,
model.eval() puts the model in inference mode.torch.no_grad() disables gradient calculations (saves memory).imagenet_classes.Let’s see one more working example using TensorFlow and a pre-trained model.
import tensorflow as tf
import numpy as np
from tensorflow.keras.applications import MobileNetV2
from tensorflow.keras.applications.mobilenet_v2 import preprocess_input, decode_predictions
from tensorflow.keras.preprocessing import image
# Load a pre-trained model
model = MobileNetV2(weights='imagenet')
# Load and preprocess image
img_path = 'dog.jpg' # path to your image
img = image.load_img(img_path, target_size=(224, 224))
img_array = image.img_to_array(img)
img_array = np.expand_dims(img_array, axis=0)
img_array = preprocess_input(img_array)
# Perform inference
predictions = model.predict(img_array)
# Decode predictions
decoded = decode_predictions(predictions, top=1)[0]
print(f"Predicted: {decoded[0][1]} with confidence {decoded[0][2]:.2f}")Here,
So, basically,
If you need speed and small model size, go for MobileNetV2.
If you need accuracy and don’t care about size/speed, ResNet-18 is a solid choice.
In real-world applications, inference needs to be fast, efficient, and accurate. Here are some common optimization techniques:
These techniques allow you to deploy AI on devices ranging from cloud servers to mobile phones.
There are three common ways to deploy model inference in AI:
Example: Google Lens uses edge inference for instant results, but may use cloud inference for more complex tasks.
Every time you use AI, you’re actually seeing model inference in action..!
To ensure trustworthy AI, especially in sensitive applications, keep these tips in mind:
Yes! Inference happens in real-time, while training can take days.
Yes. With edge inference, AI runs without internet access.
Not always. Many models run fine on CPUs, especially after optimization.
Model inference in AI is where the magic happens — when AI takes all its training and applies it to make real-world decisions. Whether it’s recommending a Netflix show, identifying diseases, or powering chatbots, inference ensures that AI doesn’t just stay in labs but actively helps people.
Quick Recap,
By understanding inference, you gain a deeper appreciation of how AI works, and you’re better equipped to build or use AI responsibly.
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.
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.
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:
No more version conflicts or mismatched components.
You can skip version numbers for each Firebase or Jetpack Compose module.
The BOM ensures all included libraries are compatible with each other.
Want to update Firebase? Just bump the BOM version.
Here’s what a typical implementation looks like in your build.gradle.kts or build.gradle file:
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.
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.
Android BOM is commonly used with:
com.google.firebase:firebase-bom)It works in both Gradle Kotlin DSL and Groovy.
Each is maintained by the respective teams and updated regularly.
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.
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.
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 BOMBe cautious: overriding can break compatibility guarantees, so only do this if necessary.
No. You still need to declare each library you want to use. The BOM just manages their versions.
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"))No, but it’s highly recommended for easier and safer dependency management.
Actually, the opposite. Because it simplifies dependency resolution, it can help Gradle builds run more efficiently.
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.
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:
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.
libs.versions.tomlCreate the file at:
project-root/
├── gradle/
│ └── libs.versions.tomlLet’s break down its structure.
The file is divided into three main sections:
[versions]
[libraries]
[plugins]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.
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 coordinateversion = direct versionversion.ref = refers to a shared version from [versions]This improves consistency and avoids duplication.
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" }Once your libs.versions.toml is set up, you can use its entries in your module-level build.gradle.kts files.
Replace hardcoded plugin IDs and versions with aliases:
plugins {
alias(libs.plugins.kotlin.android)
}Use the aliases you defined for dependencies:
dependencies {
implementation(libs.compose.ui)
implementation(libs.compose.material3)
}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.
libs.versions.tomlUnlike JSON or YAML, .toml supports inline comments:
kotlin = "1.9.22" # Kotlin version used for both plugin and stdlibHelpful when collaborating or reviewing changes.
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.
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.
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.
libs.versions.toml MattersAs projects grow, consistency becomes critical. libs.versions.toml:
It’s the kind of practice that scales well in enterprise codebases and simplifies maintenance.
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..!
Before we jump into the code, here’s why the switch matters:
SharedPreferences is legacy.So let’s get into it.
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.
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).
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
}
}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 {}.
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.
name in preferencesDataStore must match the SharedPreferences file name.Once you’re confident DataStore is working, clean up your codebase:
SharedPreferences referencesThis makes your app lighter and future-proof.
Context extension to access DataStore.Flow + collect with lifecycle awareness to avoid leaks.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.
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.
Doze Mode isn’t triggered the moment you stop using your phone. Android checks several conditions:
Once all conditions are met, the phone enters Idle mode, and Doze begins throttling background processes.
In one word: Yes — but with context.
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.
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:
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);
}
}Please note, you must have this permission in your AndroidManifest.xml:
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>
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.
This removes Doze restrictions for that app, but use sparingly to avoid draining your battery.
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.
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
);setAndAllowWhileIdle() lets your alarm fire even if Doze Mode is triggered—but only for critical events.JobScheduler or AlarmManager with setAndAllowWhileIdle().adb shell dumpsys deviceidle to simulate Doze in development.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.
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.
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.
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.
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.
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).
If your app needs to perform heavy background work, leveraging the charging state is best practice for both user satisfaction and energy efficiency.
Even with the screen on, background execution is managed to prevent resource hogging but without compromising the user’s foreground tasks.
Doze mode is designed to maximize standby time without missing critical notifications or updates. Writing efficient background code means understanding and respecting these constraints.
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.
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 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:
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 identifies apps that aren’t used frequently and restricts their background activity.
Behavior:
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.
Starting from Android 8.0 (Oreo), background execution limits make Android power management stricter:
Solution: WorkManager to the Rescue
WorkManager workManager = WorkManager.getInstance(context);
OneTimeWorkRequest workRequest = new OneTimeWorkRequest.Builder(MyWorker.class).build();
workManager.enqueue(workRequest);Replace
IntentServicewithJobIntentServiceorWorkManagerto ensure reliability.
Notifications are crucial for engagement, but Android power management policies may delay them if improperly handled.
Best Practices:
Firebase Cloud Messaging (FCM) with high-priority messages sparingly.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.
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.
Building resilient Android apps means respecting Android power management rather than working around it. Focus on:
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.
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.
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.
Here are the five standby buckets an app can fall into:
Your app moves between these buckets dynamically based on user behavior — and that impacts what you can do in the background.
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:
And ultimately, frustrated users.
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.
Here’s what each bucket means for your app’s background capabilities:
| Bucket | Background Execution | Job Scheduling | Network Access |
|---|---|---|---|
| Active | No restrictions | Immediate | Unrestricted |
| Working Set | Minor delays | Slight delay | Slight delay |
| Frequent | Moderate limits | Scheduled with delay | Delayed |
| Rare | Severe limits | Deferred heavily | Heavily delayed |
| Restricted | Blocked | Blocked | Blocked |
This directly impacts APIs like:
If you’re wondering why your background sync isn’t firing, check your bucket first.
You can’t directly set the bucket, but you can influence it by keeping users engaged:
Design for stickiness. The more users interact with your app, the better your bucket position.
Make sure your notifications lead to real engagement. Avoid spamming or your app could get demoted.
For important tasks (like location tracking or media playback), run them in a foreground service with a visible notification.
Stick to Android’s guidelines. Use WorkManager for deferred tasks and ForegroundService for immediate ones.
JobScheduler.setRequiresDeviceIdle() carefully: It might never trigger if your app is in a low bucket.You can force your app into a specific bucket for testing:
adb shell am set-standby-bucket com.yourapp.package rareTo reset:
adb shell am reset-standby-bucket com.yourapp.packageThis is incredibly useful for QA and debugging.
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.
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.