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...
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...
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...
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...
You build a clean UI, test it on your emulator, and everything looks solid. But once QA or users get their hands on it, layout bugs pop up — text overflowing, views misaligned, odd paddings. It happens more often than we like to admit. That’s where the Paparazzi Testing Library proves its worth. It’s a powerful snapshot...
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.
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.
Let’s take a closer look at the key tools that power Android development under the hood:
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 logsThis is one of the most valuable tools in your toolbox, especially for real-time debugging.
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:
While not every developer uses fastboot regularly, it’s indispensable for anyone working near the hardware layer or with custom builds.
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:
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.
Even though Android Studio and Gradle handle most of the heavy lifting today, knowing how SDK tools work gives you:
When something breaks outside the Studio UI, these tools are often your first (and best) line of defense.
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.