DEV Community: YADNYESH RANA

Your Root Detection Is Theater: Move Integrity Checks to the Server

YADNYESH RANA — Fri, 28 Aug 2026 18:05:39 +0000

Most "root detection" I see in real Android codebases is a isDeviceRooted() function that checks for su binaries, Superuser.apk, or suspicious build tags, then sets a boolean. It ships, it "works" in the demo, and it stops exactly one kind of attacker: the one who didn't bother opening a disassembler.

The uncomfortable truth: any check that runs on the device is a check the device's owner can lie to.

Why local root detection is theater

A root/tamper check written in Kotlin, running inside your own APK, is just more code for an attacker to read. Tools like Frida or Xposed can hook isDeviceRooted() directly and force it to always return false — the attacker doesn't need to actually hide root from your check, they just patch the check itself. The function's result is trusted by your app, and the function lives on hardware you don't control.

// The pattern that doesn't actually stop anyone determined
fun isDeviceRooted(): Boolean {
    val paths = listOf("/system/bin/su", "/system/xbin/su", "/sbin/su")
    return paths.any { File(it).exists() }
}

if (isDeviceRooted()) {
    // an attacker with Frida just hooks this function and returns false
    blockSensitiveAction()
}

This isn't a reason to skip integrity checks — it's a reason to stop trusting the device to grade its own homework.

The fix: let Google attest, let your server decide

Google Play Integrity API produces a token that's generated and signed by Google Play Services, not by your app's own code, and verified on a server the attacker doesn't control. The client's only job is to request the token and forward it — it never gets to declare itself trustworthy.

class IntegrityGate(private val context: Context) {

    private val cloudProjectNumber = 897654321098L // your Play Console cloud project

    fun requestToken(
        requestNonce: String,
        onToken: (String) -> Unit,
        onError: (Exception) -> Unit,
    ) {
        val manager = IntegrityManagerFactory.create(context.applicationContext)
        val request = IntegrityTokenRequest.builder()
            .setCloudProjectNumber(cloudProjectNumber)
            .setNonce(requestNonce)
            .build()

        manager.requestIntegrityToken(request)
            .addOnSuccessListener { onToken(it.token()) }
            .addOnFailureListener(onError)
    }
}

That token then goes to your backend, never gets decrypted or trusted on-device, and your server checks the verdicts inside it before doing anything sensitive (unlocking a paid feature, approving a transaction, issuing a session).

Three things that separate a real integration from a checkbox one

The nonce has to be bound to the specific request, not just "present." If you call setNonce() with a static string or a plain random UUID, an attacker who captures one valid token can replay it against a different request. Hash the actual transaction data — user id, amount, timestamp — into the nonce, so a token minted for one action is cryptographically useless for any other:

fun nonceFor(userId: String, amountCents: Long, ts: Long): String {
    val payload = "$userId:$amountCents:$ts"
    val digest = MessageDigest.getInstance("SHA-256").digest(payload.toByteArray())
    return Base64.encodeToString(digest, Base64.NO_WRAP or Base64.URL_SAFE)
}

Your server then recomputes that same hash from the request it actually received and rejects the call if it doesn't match the nonce inside the verified token.

MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY are different bars, and conflating them is a common mistake. The weaker one confirms the OS is Play-Protect-certified and passes CTS; the stronger one additionally confirms a hardware-backed keystore (TEE) is active. Gating "unlock premium content" behind the weak verdict and "approve a payment" behind the strong one is a reasonable split — using the same bar for both usually means either annoying legitimate users on older-but-fine hardware, or under-protecting the transaction that actually matters.

Tokens expire in minutes, and that's a feature you have to design around, not fight. A Play Integrity token is only valid for a few minutes after minting, deliberately, so you can't cache one and reuse it as a standing credential. That means requesting a fresh token per sensitive action (login, purchase, privileged setting change) — not once at app startup — which also keeps the ~1-2KB token off the wire for the 95% of API calls that don't need it at all.

Where this stops being enough

Play Integrity assumes Google Mobile Services exist on the device, which isn't universal — HarmonyOS devices, some custom ROMs, and GMS-less tablets can't request a token at all. A production integration needs a fallback path (typically hardware-backed Android Keystore key attestation) for that slice of users, or they get silently locked out of anything gated behind the check.

I ended up writing the full attestation architecture — server-side verdict parsing, the GMS-less fallback chain, replay-attack protection, and where this fits alongside root detection, static analysis resistance, and network hardening in a real threat model — as part of a longer security handbook, since none of it fits cleanly into one post. If you want the deeper version: Android Security, Hardening & Reverse Engineering Handbook.

Either way — if your integrity check runs entirely on-device and reports its own verdict, that's the signal to move it server-side. The attacker you're defending against already has a debugger; the only check that survives contact with one is a check they can't patch.

Stop Hardcoding Breakpoints: A Practical Guide to WindowSizeClass in Jetpack Compose

YADNYESH RANA — Fri, 28 Aug 2026 08:34:18 +0000

Most "tablet support" I see in real Android codebases is the same anti-pattern: take the phone layout, let it stretch wider, ship it. It compiles. It doesn't crash. It also doesn't survive five minutes with a real tablet or a foldable, because the actual problem was never "not enough width" — it was "the UI never decided what to do with extra width."

The fix is smaller than people expect, and it starts with throwing out if (screenWidthDp > 600).

The problem with raw dp checks

Hardcoded breakpoints are everywhere because they're the first thing that occurs to you:

@Composable
fun SettingsScreen(screenWidthDp: Int) {
    if (screenWidthDp > 600) {
        SettingsTwoPane()
    } else {
        SettingsSinglePane()
    }
}

This works, right up until it doesn't. 600 isn't a real device boundary — it's a guess. It doesn't account for height. It doesn't move when Google refines what actually counts as "enough room for two panes." And because it's just an Int, nothing stops five different screens in the same app from picking five slightly different thresholds over time.

WindowSizeClass: the boundary that isn't yours to invent

WindowSizeClass replaces the guess with a shared, device-independent classification — COMPACT, MEDIUM, EXPANDED — computed once and passed down like any other piece of app state:

@Composable
fun AppRoot() {
    val windowSizeClass = currentWindowAdaptiveInfo().windowSizeClass

    SettingsScreen(widthSizeClass = windowSizeClass.windowWidthSizeClass)
}

@Composable
fun SettingsScreen(widthSizeClass: WindowWidthSizeClass) {
    when (widthSizeClass) {
        WindowWidthSizeClass.COMPACT -> SettingsSinglePane()
        WindowWidthSizeClass.MEDIUM -> SettingsSinglePaneWide()
        WindowWidthSizeClass.EXPANDED -> SettingsTwoPane()
        else -> SettingsSinglePane()
    }
}

Three things about this that matter more than the syntax:

Compute it once, near the root, not per-screen. currentWindowAdaptiveInfo() is cheap, but that's not really the point — the point is that if five different composables each call it independently, you've reintroduced the "five slightly different thresholds" problem, just with an API instead of a magic number. Treat it like NavController: resolved once, handed down explicitly.

The bucket is the contract, not the pixel value. Today EXPANDED is roughly "more than 840dp." That number has already been refined once, and it'll likely be refined again as the definition of "large enough for a persistent second pane" gets tuned. Code that branches on EXPANDED keeps working through that. Code that branches on 840 doesn't.

Height has a size class too, and it's the one people forget. WindowHeightSizeClass follows the identical three-bucket shape and matters the moment anything reflows vertically — a bottom sheet, a two-row app bar, a video player with controls beneath it. A tablet in landscape split-screen can be EXPANDED width and COMPACT height at the same time, and a layout that only checks width will get that configuration wrong.

One screen, not one screen per form factor

The other habit worth breaking: writing SettingsScreenPhone, SettingsScreenTablet, SettingsScreenDesktop as three separate composables. That's the exact same drift problem sw600dp resource qualifiers had in the View system, just moved into Kotlin.

The better shape is one screen that takes its pieces as slots, and rearranges them internally:

@Composable
fun SettingsScreen(
    widthSizeClass: WindowWidthSizeClass,
    accountSection: @Composable () -> Unit,
    preferencesSection: @Composable () -> Unit,
) {
    when (widthSizeClass) {
        WindowWidthSizeClass.EXPANDED -> Row(Modifier.fillMaxSize()) {
            Box(Modifier.weight(1f)) { accountSection() }
            Box(Modifier.weight(1f)) { preferencesSection() }
        }
        else -> Column(Modifier.verticalScroll(rememberScrollState())) {
            accountSection()
            preferencesSection()
        }
    }
}

accountSection and preferencesSection don't know or care which arrangement they end up in. The arrangement is the only thing that varies by size class — which is exactly the part that should vary, and the only part you now have to touch when a designer asks for a different large-screen layout.

Where this stops being enough

WindowSizeClass gets you correct phone-vs-tablet behavior, and it's genuinely most of the win for most screens. It does not, on its own, cover:

A folding device's hinge — which isn't a width, it's a physical region with its own state (flat, half-opened) and orientation, and content sitting directly under it is either occluded or awkward to tap
Canonical list-detail / supporting-pane layouts with correct predictive-back behavior baked in, instead of hand-rolled navigation state
The newer Compose adaptive surface — NavigationSuiteScaffold, environment-signal queries, CSS-Grid-style layout primitives — that's landed in just the last few months

I ended up writing all of that up properly — foldable posture handling, canonical layouts, the new adaptive APIs, and the production concerns (multi-window, predictive back, testing across size classes, and the actual Play Console checklist for the large-screen badge) — as a 12-topic playbook, since none of it fit cleanly into a single post. If you want the deeper version: Jetpack Compose Adaptive UI & Foldables Playbook.

Either way — if you take one thing from this post, let it be: the next time you're tempted to write if (width > 600), that's the signal to reach for WindowSizeClass instead. The bug you're avoiding isn't a crash, it's the slow drift of five screens each guessing a slightly different number.

Bypassing Circular Dependencies in Android: The API/Implementation Module Pattern

YADNYESH RANA — Mon, 24 Aug 2026 17:41:21 +0000

As Android codebases scale, modularization is inevitable. We break down monolithic apps to achieve faster build times, separate team ownership, and isolate features.

However, many teams fall into a common trap: direct feature-to-feature dependencies.

If :feature:onboarding needs to trigger :feature:auth, developers often add a direct dependency. But what happens when :feature:auth needs to redirect back to onboarding, or share a common session state? You hit the dreading Circular Dependency compiler error.

To fix this, teams often resort to merging modules or writing messy reflection wrappers.

Here is the clean, enterprise-grade solution: The API vs. Implementation Module Separation.

The Core Concept: Dependency Inversion at Module Level

Instead of creating a single feature module, we split the feature into two separate Gradle modules:

:feature:auth:api (Lightweight interface module): Contains only public interfaces, DTOs, navigation entry points, and event states. It has no dependency on UI, Compose, or database layers.
:feature:auth:impl (Concrete implementation module): Contains the actual UI screens, Compose layouts, view models, database helper engines, and internal Hilt modules. It implements the interfaces defined in the :api module.

:feature:onboarding (Feature UI)
       │
       ▼ (Depends on API only)
:feature:auth:api (Public Interface) ◄─── (Implemented by) ─── :feature:auth:impl (Private UI)

Now, :feature:onboarding only needs to depend on the lightweight :feature:auth:api module. It calls the public interface, while the actual implementation (:feature:auth:impl) is injected dynamically at runtime.

Step-by-Step Implementation

1. Define the API Interface (`:feature:auth:api`)

The API module contains only standard Kotlin code and basic model dependencies. Here, we define the contract for other modules:

// Location: :feature:auth:api
interface AuthApi {
    fun getAuthFlow(): Flow<UserSession?>
    suspend fun logout()
}

2. Implement the Business Logic (`:feature:auth:impl`)

The implementation module depends on its corresponding API module and implements the interface:

// Location: :feature:auth:impl/build.gradle.kts
dependencies {
    implementation(projects.feature.auth.api)
    implementation(libs.hilt.android)
}

// Location: :feature:auth:impl/src/.../AuthApiImpl.kt
class AuthApiImpl @Inject constructor(
    private val tokenStorage: TokenStorage,
    private val database: AppDatabase
) : AuthApi {
    override fun getAuthFlow(): Flow<UserSession?> = tokenStorage.observeSession()
    override suspend fun logout() {
        tokenStorage.clear()
        database.clearAllTables()
    }
}

3. Bind the Interface dynamically using Hilt

Inside the implementation module, define a Hilt module to bind the implementation to the interface. Because other modules request the AuthApi interface, Hilt will resolve it to the AuthApiImpl class at runtime:

// Location: :feature:auth:impl/src/.../AuthModule.kt
@Module
@InstallIn(SingletonComponent::class)
abstract class AuthModule {
    @Binds
    @Singleton
    abstract fun bindAuthApi(impl: AuthApiImpl): AuthApi
}

Why this improves your Gradle builds

Zero Circular Dependencies: Sibling feature modules can call each other's APIs without circular compiler cycles.
Faster Incremental Builds: If you modify a Compose layout inside :feature:auth:impl, only that module compiles. Sibling modules (like onboarding) are completely bypassed because the API module (:feature:auth:api) hasn't changed.
Parallel Workflows: Teams can develop features in parallel. You can write your feature code using mock API implementations before the other team even begins writing their concrete implementation code.

📘 Master Android System Design & Architecture

If you want to master clean architecture, offline-first syncing, performance profiling, and dependency injection patterns, grab The Ultimate Android System Design & Tech Lead Bundle:

➡️ Get the Ultimate Tech Lead Bundle on Gumroad

The bundle includes the flagship System Design Playbook (26 pages) along with three premium bonuses: the 2026 Interview Question Bank, the Jetpack Compose Custom UI Cookbook, and the Android Gradle Optimization Cheat Sheet.

How to cut Android build times in half: Gradle JVM tuning & precompiled Kotlin DSL conventions

YADNYESH RANA — Wed, 15 Jul 2026 19:50:15 +0000

Slow build times are the single biggest bottleneck in daily Android development cycles. Waiting 3 minutes for a task configuration or incremental compilation kills developer momentum.

In this guide, we will implement the two highest-impact optimizations for modern multi-module Android projects: JVM compiler daemon tuning and centralizing build logic via precompiled Kotlin DSL convention plugins.

⚡ Step 1: High-Impact JVM Properties

Gradle runs tasks in background compiler processes called daemons. By default, these processes are memory-constrained. Add these switches to your root-level gradle.properties file to configure parallel execution, task caching, and garbage collector parameters:

# Enable parallel module compilation
org.gradle.parallel=true

# Cache task inputs and reuse previous outputs
org.gradle.caching=true

# Skip configuration phase by reusing task graphs
org.gradle.configuration-cache=true

# Allocate heap space and G1 Garbage Collector
org.gradle.jvmargs=-Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError

# Non-transitive R classes to isolate resource changes
android.nonTransitiveRClass=true

Why G1GC?
The G1 Garbage Collector (G1GC) divides the JVM heap into regions and performs incremental collections. This prevents long, freezes during compilation, preserving compiler speed for incremental builds.

🛠️ Step 2: Composite Builds & Precompiled Kotlin DSL Plugins

In multi-module configurations, copying configuration scripts across modules leads to configuration drift and slows down compilation. In 2026, standard architectures use composite builds inside a build-logic folder.

1. Include build-logic in settings.gradle.kts

// settings.gradle.kts
pluginManagement {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}
includeBuild("build-logic")

2. Define the Android Library Convention
Create a precompiled script in build-logic/convention/src/main/kotlin/android.library.gradle.kts:

// android.library.gradle.kts
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

android {
    compileSdk = 35

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_21
        targetCompatibility = JavaVersion.VERSION_21
    }

    kotlinOptions {
        jvmTarget = "21"
    }
}

3. Apply the custom plugin in modules
Now, feature modules only need a single line of plugin declaration, eliminating hundreds of lines of boilerplate across the project:

// app/feature-auth/build.gradle.kts
plugins {
    id("android.library") // Applies our custom convention plugin
}

📂 Download the Full 15-Page Playbook (Free PDF)
These configuration files and composite build blueprints are part of the AndroidDev Suite resources. If you want the complete, print-ready 15-page vector playbook—which includes KAPT to KSP migrations, build scan audits, and CI/CD compiler caching rules—download the PDF reference card below:

➡️ Download the Free Playbook on Gumroad

The open-source code and sample configurations are free to browse on GitHub: android-digital-products.

Encrypting Room SQLite Databases with SQLCipher and Biometric Keys

YADNYESH RANA — Fri, 26 Jun 2026 07:52:21 +0000

Storing raw user credentials, OAuth tokens, or sensitive transactions in a standard local SQLite database is a major security vulnerability. Anyone with a rooted device or access to a backup can extract the database file and read the tables in plain text.

To secure your local storage, you need to encrypt the database using SQLCipher and generate the encryption keys inside the device's hardware-backed Keystore.

Here is the exact implementation details.

1. Setup SQLCipher Dependency
First, add the SQLCipher library to your module's dependency configuration:

// build.gradle.kts
dependencies {
    implementation("net.zetetic:android-database-sqlcipher:4.5.4")
    implementation("androidx.sqlite:sqlite-ktx:2.4.0")
}

2. Generating the Encryption Key in the TEE (Keystore)
Never hardcode your database passphrase in the Kotlin source. Instead, generate an AES key inside the device's secure hardware enclave—the Trusted Execution Environment (TEE)—and require biometric verification before the key can be accessed.

fun generateSecretKey() {
    val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }

    if (!keyStore.containsAlias("DatabaseKeyAlias")) {
        val keyGenerator = KeyGenerator.getInstance(
            KeyProperties.KEY_ALGORITHM_AES, 
            "AndroidKeyStore"
        )

        val spec = KeyGenParameterSpec.Builder(
            "DatabaseKeyAlias",
            KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
        )
            .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
            .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
            .setUserAuthenticationRequired(true) // Requires biometrics (fingerprint/face)
            .setUserAuthenticationValidityDurationSeconds(-1) // Authenticate per session/call
            .setInvalidatedByBiometricEnrollment(true) // Key invalidates if new fingers enrolled
            .build()

        keyGenerator.init(spec)
        keyGenerator.generateKey()
    }
}

3. Initializing Room with the SQLCipher Open Helper
Once the key is generated in the hardware, construct a helper factory that feeds the passphrase to SQLCipher's open helper during database initialization:

fun getEncryptedDatabase(context: Context, passphraseString: String): AppDatabase {
    // Convert passphrase string to byte array
    val passphrase = SQLiteDatabase.getBytes(passphraseString.toCharArray())

    // Create the SQLCipher OpenHelper Factory
    val factory = SupportOpenHelperFactory(passphrase)

    return Room.databaseBuilder(
        context,
        AppDatabase::class.java,
        "secure_app.db"
    )
        .openHelperFactory(factory) // Wraps standard Room with SQLCipher
        .build()
}

4. Handling Biometric Key Access
To open the database, trigger the system biometric prompt and pass the resulting cipher object to decrypt your passphrase:

fun decryptPassphrase(cipher: Cipher, encryptedData: ByteArray): String {
    val decryptedBytes = cipher.doFinal(encryptedData)
    return String(decryptedBytes, Charsets.UTF_8)
}

If the device is rooted or someone tries to clone the app, the SQLite database file remains completely unreadable (displays as corrupted binary noise).

Open-Source Reference
This security implementation is part of the open-source Android System Design & Architecture Checklist. You can clone the full repository of cryptographic configurations, SSL pinning helpers, and offline sync transaction queues here:

👉 GitHub: Android System Design & Architecture Checklist (A print-ready, A4 PDF version is also pinned in the repository description).

Encrypting Room SQLite Databases with SQLCipher and Biometric Keys

YADNYESH RANA — Thu, 25 Jun 2026 14:22:40 +0000

To secure your local storage, you need to encrypt the database using SQLCipher and generate the encryption keys inside the device's hardware-backed Keystore.

Here is the exact implementation details.

1. Setup SQLCipher Dependency
First, add the SQLCipher library to your module's dependency configuration:

// build.gradle.kts
dependencies {
    implementation("net.zetetic:android-database-sqlcipher:4.5.4")
    implementation("androidx.sqlite:sqlite-ktx:2.4.0")
}

fun generateSecretKey() {
    val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }

    if (!keyStore.containsAlias("DatabaseKeyAlias")) {
        val keyGenerator = KeyGenerator.getInstance(
            KeyProperties.KEY_ALGORITHM_AES, 
            "AndroidKeyStore"
        )

        val spec = KeyGenParameterSpec.Builder(
            "DatabaseKeyAlias",
            KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
        )
            .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
            .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
            .setUserAuthenticationRequired(true) // Requires biometrics (fingerprint/face)
            .setUserAuthenticationValidityDurationSeconds(-1) // Authenticate per session/call
            .setInvalidatedByBiometricEnrollment(true) // Key invalidates if new fingers enrolled
            .build()

        keyGenerator.init(spec)
        keyGenerator.generateKey()
    }
}

fun getEncryptedDatabase(context: Context, passphraseString: String): AppDatabase {
    // Convert passphrase string to byte array
    val passphrase = SQLiteDatabase.getBytes(passphraseString.toCharArray())

    // Create the SQLCipher OpenHelper Factory
    val factory = SupportOpenHelperFactory(passphrase)

    return Room.databaseBuilder(
        context,
        AppDatabase::class.java,
        "secure_app.db"
    )
        .openHelperFactory(factory) // Wraps standard Room with SQLCipher
        .build()
}

4. Handling Biometric Key Access
To open the database, trigger the system biometric prompt and pass the resulting cipher object to decrypt your passphrase:

fun decryptPassphrase(cipher: Cipher, encryptedData: ByteArray): String {
    val decryptedBytes = cipher.doFinal(encryptedData)
    return String(decryptedBytes, Charsets.UTF_8)
}

If the device is rooted or someone tries to clone the app, the SQLite database file remains completely unreadable (displays as corrupted binary noise).

👉 GitHub: Android System Design & Architecture Checklist (A print-ready, A4 PDF version is also pinned in the repository description).

Stop Losing Offline User Updates: Build a Room Mutation Queue

YADNYESH RANA — Wed, 24 Jun 2026 07:07:19 +0000

Most Android apps handle offline reads using Room as a cache. But when it comes to offline writes (mutations like updates, inserts, or deletes), standard implementations either fail immediately or block the UI until the network returns.

To build a true offline-first app, you need a local transaction write-queue.

Here is a lightweight, production-grade blueprint using Room, Ktor, and WorkManager to buffer and sync offline updates reliably.

1. The Offline Mutation Schema
First, create a SQLite table in Room to store pending mutations. This table captures the type of operation, the target table, and the serialized payload.

@Entity(tableName = "mutation_queue")
data class PendingMutation(
    @PrimaryKey(autoGenerate = true) val id: Long = 0,
    val type: String,          // "INSERT", "UPDATE", "DELETE"
    val targetTable: String,   // e.g., "tasks", "users"
    val payloadJson: String,   // Serialized request body
    val timestamp: Long = System.currentTimeMillis()
)

Create the corresponding Data Access Object (DAO) to write, fetch, and clear queued operations:

@Dao
interface MutationDao {
    @Query("SELECT * FROM mutation_queue ORDER BY timestamp ASC")
    suspend fun getAllPending(): List<PendingMutation>

    @Delete
    suspend fun delete(mutation: PendingMutation)

    @Insert
    suspend fun insert(mutation: PendingMutation)
}

2. Writing to the Queue Natively
When a user performs an update while offline, write the data to the local feature table (so the UI updates immediately) and queue the transaction inside a single database transaction:

suspend fun updateTaskOffline(task: TaskEntity) {
    database.withTransaction {
        // 1. Update the local UI cache table
        taskDao.update(task)

        // 2. Queue the mutation for server sync
        val mutation = PendingMutation(
            type = "UPDATE",
            targetTable = "tasks",
            payloadJson = json.encodeToString(task)
        )
        mutationDao.insert(mutation)
    }
    // 3. Trigger WorkManager to run sync task
    scheduleSyncWorker()
}

3. The WorkManager Synchronization Loop
Now, write a CoroutineWorker that reads the queue and flushes the mutations to your API sequentially.

class SyncWorker(
    context: Context,
    params: WorkerParameters,
    private val db: AppDatabase,
    private val api: KtorClient
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        val pendingMutations = db.mutationDao().getAllPending()
        if (pendingMutations.isEmpty()) return Result.success()

        for (mutation in pendingMutations) {
            try {
                // Post payload to Ktor server
                val response = api.post("api/sync") {
                    setBody(mutation.payloadJson)
                }

                // If success, delete from queue
                if (response.status.value in 200..299) {
                    db.mutationDao().delete(mutation)
                }
            } catch (e: Exception) {
                // If API fails or times out, reschedule with exponential backoff
                return Result.retry()
            }
        }
        return Result.success()
    }
}

4. Scheduling the Sync
Set up constraints to ensure the worker only runs when the device has an active network connection, and apply an exponential backoff policy:

fun Context.scheduleSyncWorker() {
    val constraints = Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)
        .build()

    val syncWorkRequest = OneTimeWorkRequestBuilder<SyncWorker>()
        .setConstraints(constraints)
        .setBackoffCriteria(
            BackoffPolicy.EXPONENTIAL,
            10,
            TimeUnit.SECONDS
        )
        .build()

    WorkManager.getInstance(this).enqueueUniqueWork(
        "OfflineSyncWork",
        ExistingWorkPolicy.KEEP, // Keep existing sync task in queue, don't interrupt
        syncWorkRequest
    )
}

The Result

The user updates data offline.
The UI changes immediately (caching).
The mutation is saved in Room.
WorkManager triggers the moment connection returns, uploading the queue chronologically without user intervention.

Open-Source Reference
This implementation is part of the open-source Android System Design & Architecture Checklist. You can clone the full repository of offline-first configurations, convention plugins, and secure Keystore setups here:

👉 GitHub: Android System Design & Architecture Checklist (A print-ready, high-resolution 12-page PDF version is also pinned in the repository description).

Stop Animating Modifiers Like This in Jetpack Compose

YADNYESH RANA — Tue, 23 Jun 2026 17:19:50 +0000

Animating offset or alpha properties using standard compose states can easily tank your UI frame rates. If you read animation states directly in composition, your composable runs all three phases—composition, layout, and drawing—at 120 FPS.

You can bypass this overhead by deferring state reads to the layout or draw phases.

The Three Phases of Compose
Jetpack Compose renders frames in three distinct steps:

Composition: What to show (runs the composable functions and builds the UI tree).
Layout: Where to show (measures children and places them in coordinates).
Draw: How to render (draws pixels on the canvas).

When a state changes, Compose starts from the phase where that state was read. If you read state during composition, you force the entire pipeline to rerun. If you defer the state read to the layout or draw phase, you skip composition entirely.

Animating Positions (Layout Phase) Here is a common animation implementation that degrades layout performance:

// BAD: Recomposes the Box and its parents on every single frame
@Composable
fun SlidingCard(targetOffset: Dp) {
    val translationX by animateDpAsState(targetValue = targetOffset)

    Box(
        modifier = Modifier
            .size(100.dp)
            .offset(x = translationX, y = 0.dp) // State read occurs in composition
            .background(Color.Blue)
    )
}

Since the state translationX is read in the composition phase (as an argument to Modifier.offset), the composable recomposes at 120 FPS as the animation updates.

We can fix this by wrapping the offset calculation in a lambda:

// GOOD: Zero recompositions. Updates coordinates directly in the Layout phase
@Composable
fun SlidingCard(targetOffset: Dp) {
    val translationX by animateDpAsState(targetValue = targetOffset)

    Box(
        modifier = Modifier
            .size(100.dp)
            .offset { IntOffset(x = translationX.roundToPx(), y = 0) } // Lambda defers state read
            .background(Color.Blue)
    )
}

By using the lambda version of offset, the value of translationX is not read until the layout phase. The composition step is skipped entirely.

2.Animating Alpha and Rotations (Draw Phase)
Similarly, animating visual transformations like opacity or rotations can trigger layout recalculations if done incorrectly:

// BAD: Triggers composition and layout passes on every frame change
@Composable
fun FadingCard(targetAlpha: Float) {
    val alphaState by animateFloatAsState(targetValue = targetAlpha)

    Box(
        modifier = Modifier
            .size(100.dp)
            .alpha(alphaState) // State read occurs in composition
            .background(Color.Blue)
    )
}

Since changing alpha does not affect the size or positions of elements, there is no reason to rerun layout passes.

We can bypass both composition and layout by reading the state directly inside a graphics layer block:

// GOOD: Zero recompositions. Modifies drawing properties directly on the GPU
@Composable
fun FadingCard(targetAlpha: Float) {
    val alphaState by animateFloatAsState(targetValue = targetAlpha)

    Box(
        modifier = Modifier
            .size(100.dp)
            .graphicsLayer { alpha = alphaState } // Direct draw-phase read
            .background(Color.Blue)
    )
}

Inside the graphicsLayer lambda, alphaState is read during the drawing phase. Compose skips composition and layout, rendering the visual changes directly.

How to Verify in Layout Inspector
Open the Layout Inspector in Android Studio:

Run the animation.
Watch the Recomposition Counts column.
Using the standard modifiers, the recomposition count climbs rapidly.
Switch to lambda modifiers (offset {} or graphicsLayer {}) and the recomposition count stays at exactly 0.

Open-Source Reference
This optimization is part of the open-source Compose Performance Cheat Sheet. You can clone the full repository of performance starter kits, stability configurations, and lazy list recycling templates here:

👉 GitHub: Compose Performance & Recomposition Cheat Sheet (A print-ready, high-resolution A4 PDF version is also pinned in the repository description).

DEV Community: YADNYESH RANA

Your Root Detection Is Theater: Move Integrity Checks to the Server

Why local root detection is theater

The fix: let Google attest, let your server decide

Three things that separate a real integration from a checkbox one

Where this stops being enough

Stop Hardcoding Breakpoints: A Practical Guide to WindowSizeClass in Jetpack Compose

The problem with raw dp checks

WindowSizeClass: the boundary that isn't yours to invent

One screen, not one screen per form factor

Where this stops being enough

Bypassing Circular Dependencies in Android: The API/Implementation Module Pattern

The Core Concept: Dependency Inversion at Module Level

Step-by-Step Implementation

1. Define the API Interface (:feature:auth:api)

2. Implement the Business Logic (:feature:auth:impl)

3. Bind the Interface dynamically using Hilt

Why this improves your Gradle builds

📘 Master Android System Design & Architecture

How to cut Android build times in half: Gradle JVM tuning & precompiled Kotlin DSL conventions

⚡ Step 1: High-Impact JVM Properties

🛠️ Step 2: Composite Builds & Precompiled Kotlin DSL Plugins

Encrypting Room SQLite Databases with SQLCipher and Biometric Keys

Encrypting Room SQLite Databases with SQLCipher and Biometric Keys

Stop Losing Offline User Updates: Build a Room Mutation Queue

Stop Animating Modifiers Like This in Jetpack Compose

1. Define the API Interface (`:feature:auth:api`)

2. Implement the Business Logic (`:feature:auth:impl`)