DEV Community: YADNYESH RANA

Why Your Compose UI Test Can't Find That Button (Semantics vs. Text Matching)

YADNYESH RANA — Mon, 21 Sep 2026 03:40:28 +0000

Why Your Compose UI Test Can't Find That Button (Semantics vs. Text Matching)

You write onNodeWithText("Submit").performClick(), the test fails with "no matching
semantics node," and the button is right there on screen. Nothing about the UI is
broken — the test is looking for the wrong thing, and it's one of the most common ways
Compose UI tests get flaky or brittle without anyone noticing why.

The core misunderstanding

Compose UI tests don't query the screen the way a human reads it. They query the
semantics tree — a separate tree that Compose builds alongside the visual tree,
purely for accessibility and testing. A composable only shows up in a test query if it
(or something nested in it) actually merges the semantics property you're asking about.

onNodeWithText("Submit") matches on the merged Text semantics property. That
breaks the moment:

The visible label is drawn with Canvas or drawText, not a Text composable.
The button's content is an Icon with no visible text at all.
The text is split across multiple child composables and Compose merges them into a parent node you didn't expect.
The text is correct but wrapped in a Row with clearAndSetSemantics {} somewhere in the tree, which silently erases everything below it.

None of these are bugs in the app. They're all completely normal Compose UI. The test
was just asking the wrong question.

The fix: stop matching on text, start matching on identity

Give interactive elements a stable identity that has nothing to do with their visible
copy:

@Composable
fun SubmitButton(onClick: () -> Unit) {
    Button(
        onClick = onClick,
        modifier = Modifier.testTag("submit_button")
    ) {
        Text("Submit")
    }
}

@Test
fun submitButton_click_triggersCallback() {
    composeTestRule.setContent {
        SubmitButton(onClick = { clicked = true })
    }
    composeTestRule.onNodeWithTag("submit_button").performClick()
    assertTrue(clicked)
}

testTag is a semantics property specifically for this — it never shows up on screen,
never gets localized out from under your test, and doesn't care whether the label is a
Text, an Icon with a content description, or a custom-drawn glyph. Reserve
onNodeWithText for the one thing it's actually good at: asserting that copy is
correct, not for locating the element you're about to interact with. Those are two
different jobs and conflating them is why so many Compose UI tests both fail
mysteriously and fail to catch real copy regressions.

The second trap: merged vs. unmerged trees

Even with testTag in place, a surprisingly common failure is a node that exists in
the semantics tree but isn't reachable by the default query — because Compose merges
descendant semantics into a single parent node for accessibility services (a screen
reader shouldn't announce five separate child nodes for one logical button). Your test
runs against the merged tree by default.

If you're asserting on something that got merged away — e.g. checking that a specific
child Text inside a Row has certain semantics, when the Row itself is the thing
exposing merged semantics to accessibility — the query needs the unmerged tree:

composeTestRule
    .onNodeWithTag("submit_button", useUnmergedTree = true)
    .onChildren()
    .filterToOne(hasText("Submit"))
    .assertIsDisplayed()

useUnmergedTree = true walks the tree as Compose actually built it, before the
accessibility-merge pass collapses it. This is the fix for the specific failure mode
where a node "should be there" by every visual inspection, printToLog() shows it
exists, but the default query still can't find it — because printToLog(), notably,
prints the unmerged tree by default too, which is exactly why it disagrees with your
failing query and makes this bug so confusing to debug the first time you hit it.

A minimal checklist before you write another Compose UI test

Add testTag to anything you'll click or assert on, not just the ones that happen not to have a Text child today — UI copy changes, and a testTag-based test survives that; a text-based one silently starts failing for the wrong reason.
Use onNodeWithText for content assertions, onNodeWithTag for element location. They're not interchangeable, even though both compile against the same SemanticsNodeInteraction API.
Reach for useUnmergedTree = true the moment printToLog() shows a node that your query still can't find — that mismatch is almost always a merge boundary, not a real absence.
Don't add Thread.sleep or retry loops to "fix" a node-not-found failure. It's never actually timing; Compose test rules already run synchronously against the composition by default. A node-not-found failure is a semantics-tree mismatch, and sleeping just delays the same failure or turns it into a flaky pass/fail coin flip.

None of this requires a testing framework beyond what compose.ui.test already ships
with — it's entirely about understanding the semantics tree Compose is actually
building, instead of assuming the test API mirrors what's visually on screen.

If you want the fuller picture — Hilt-based fake injection for ViewModel-level tests,
Turbine for asserting on StateFlow/Flow emissions without race conditions, and the
full Espresso-to-Compose migration checklist for mixed-UI apps — I wrote it all up in
the Android & Compose Testing Playbook.

Gemini Nano Isn't on Most of Your Users' Phones. Here's the Feature-Detection Pattern That Doesn't Embarrass You in Production

YADNYESH RANA — Mon, 14 Sep 2026 03:41:54 +0000

Gemini Nano Isn't on Most of Your Users' Phones. Here's the Feature-Detection Pattern That Doesn't Embarrass You in Production

On-device AI on Android sounds simple until you actually ship it: "just call Gemini Nano through AICore." Then you test on a real device fleet and discover most of your users don't have a phone that supports it — wrong chipset, OS version too old, AICore not provisioned, or the device just isn't on Google's supported list yet. If your app assumes local inference is always available, it crashes or silently does nothing for a huge chunk of your install base.

The fix isn't "wrap it in a try/catch." It's treating on-device AI capability as a first-class piece of state you check before you build any UI around it, with a real fallback path — not a loading spinner over a dead end.

The wrong way (what most first attempts look like)

// Don't do this
suspend fun generateReply(prompt: String): String {
    val session = GenerativeModel.getInstance(context) // throws on unsupported devices
    return session.generateContent(prompt).text
}

This works on your Pixel 9 Pro. It throws UnsupportedOperationException (or just hangs, depending on the failure mode) on everything else. You find out in a crash report, not in code review.

Model the capability as a sealed state, not a boolean

A plain isSupported: Boolean loses information you actually need — "not supported at all" and "supported but the model isn't downloaded yet" require completely different UI.

sealed interface OnDeviceAiState {
    data object Unavailable : OnDeviceAiState        // hardware/OS doesn't support it, ever
    data object NeedsDownload : OnDeviceAiState        // supported, but model isn't provisioned locally yet
    data object Downloading : OnDeviceAiState
    data class Ready(val session: AiSession) : OnDeviceAiState
    data class Failed(val reason: Throwable) : OnDeviceAiState
}

Feature detection: check before you commit to a UI path

class OnDeviceAiAvailability(private val context: Context) {

    suspend fun check(): OnDeviceAiState {
        val manager = context.getSystemService(AiCoreManager::class.java)
            ?: return OnDeviceAiState.Unavailable // system service doesn't exist on this OS build

        val status = try {
            manager.checkFeatureStatus(GenerativeAiFeature.TEXT_GENERATION)
        } catch (e: SecurityException) {
            // AICore present but this feature isn't whitelisted/enabled on this device
            return OnDeviceAiState.Unavailable
        }

        return when (status) {
            FeatureStatus.UNSUPPORTED -> OnDeviceAiState.Unavailable
            FeatureStatus.DOWNLOADABLE -> OnDeviceAiState.NeedsDownload
            FeatureStatus.DOWNLOADING -> OnDeviceAiState.Downloading
            FeatureStatus.AVAILABLE -> runCatching { AiSession.create(manager) }
                .fold(
                    onSuccess = { OnDeviceAiState::Ready.let { ctor -> OnDeviceAiState.Ready(it) } },
                    onFailure = { OnDeviceAiState.Failed(it) }
                )
            else -> OnDeviceAiState.Unavailable
        }
    }
}

The important part isn't the exact API shape (AICore's surface is still shifting release to release) — it's the principle: every branch of FeatureStatus becomes a distinct state your UI can render correctly, instead of one boolean that collapses "will never work" and "works in three seconds once the model downloads" into the same thing.

The fallback that actually matters: cloud, but only when it's worth it

Here's where teams get the tradeoff backwards. The instinct is "local unavailable → always call the cloud API instead." That's correct for the common case, but it silently reintroduces the exact costs on-device inference was supposed to avoid — data leaves the device, latency goes up, and now you're paying per-token for every user whose phone couldn't run it locally.

A better default: only fall back to cloud for requests where the user explicitly asked for a response now (a chat message, a summarize-this-page tap) — not for speculative/background inference (pre-fetching a suggestion, drafting a notification reply nobody asked for yet). Background inference on Unavailable/NeedsDownload should just... not happen, rather than quietly turning into a cloud bill.

class HybridGenerationRouter(
    private val local: OnDeviceAiAvailability,
    private val cloud: CloudGeminiClient,
) {
    suspend fun generate(prompt: String, userInitiated: Boolean): Result<String> {
        return when (val state = local.check()) {
            is OnDeviceAiState.Ready ->
                runCatching { state.session.generate(prompt) }
                    .recoverCatching { if (userInitiated) cloud.generate(prompt) else throw it }

            OnDeviceAiState.Unavailable, OnDeviceAiState.NeedsDownload, OnDeviceAiState.Downloading ->
                if (userInitiated) cloud.generate(prompt)
                else Result.failure(IllegalStateException("on-device unavailable, skipping background inference"))

            is OnDeviceAiState.Failed ->
                if (userInitiated) cloud.generate(prompt) else Result.failure(state.reason)
        }
    }
}

recoverCatching on the local path matters too — local inference can fail mid-session (memory pressure, the model getting evicted under load), and you want the same "cloud only if the user is actually waiting" rule to apply there, not just at the initial capability check.

The part that's easy to get wrong: caching the check

checkFeatureStatus isn't free, and DOWNLOADABLE → DOWNLOADING → AVAILABLE is a real state transition that can happen while your app is running (the OS can provision the model in the background). Don't cache the result of check() for the lifetime of the app — cache it for the lifetime of a screen, and re-check whenever the app returns to foreground after being backgrounded for more than a few minutes. Otherwise you'll show "AI unavailable" for the rest of the session to a user whose phone finished downloading the model two minutes after they opened your app.

This capability-detection layer is the boring 20% of on-device AI work that determines whether the flashy 80% (actual prompt design, streaming responses, structured output parsing) ships to real users instead of just your test device. If you want the fuller picture — the actual AICore/Gemini Nano client setup, token-budget management for the 2K-token local context window, and the AICore beta-track device whitelisting steps this article deliberately skipped — I wrote it all up in the Android On-Device AI: Gemini Nano & AI Edge SDK Playbook.

Why Your Compose Screenshot Tests Are Flaky (And the Fix Isn't "Add Sleep")

YADNYESH RANA — Mon, 07 Sep 2026 03:42:13 +0000

Why Your Compose Screenshot Tests Are Flaky (And the Fix Isn't "Add Sleep")

Your Compose screenshot tests pass locally, then flake red on CI for no reason anyone can point at. The instinct is to add a retry, bump a timeout, or slap Thread.sleep into the test rule and move on. That just hides the actual bug: something in the test is non-deterministic, and a screenshot test with any non-determinism in it is not testing anything — it's a coin flip with extra steps.

Here are the four sources of non-determinism that account for almost every flaky Compose screenshot test I've run into, and the actual fix for each — not a retry, a fix.

1. The animation clock is running free

By default, Compose's test clock auto-advances in real time. If your composable kicks off any animation — a ripple, a Crossfade, an AnimatedVisibility, even an implicit one from a state change — the screenshot gets taken at whatever frame the clock happens to be on when the test thread catches up. Locally that's usually frame 0. On a loaded CI runner, it can be mid-transition.

Fix: take manual control of the clock and force it to the end state before capturing.

class DeterministicScreenshotRule(
    private val composeRule: ComposeContentTestRule
) : TestRule {
    override fun apply(base: Statement, description: Description) = object : Statement() {
        override fun evaluate() {
            composeRule.mainClock.autoAdvance = false
            base.evaluate()
        }
    }
}

// in the test
composeRule.setContent { ProfileScreen(state = loadedState) }
composeRule.mainClock.advanceTimeBy(10_000) // past any entry animation
composeRule.onRoot().captureToImage()

advanceTimeBy with a large value rather than stepping frame-by-frame is deliberate — you want the animation fully settled, not a mid-transition frame that happens to be reproducible. Reproducible-but-wrong is not the goal.

2. Fonts render differently on CI than on your machine

This is the one that costs the most debugging time because the diff looks like nothing changed — a few pixels off around glyph edges, sometimes just in one corner of the screen. It's font fallback: your CI runner's system image doesn't have the same font as your local emulator or physical device, so text falls back to a different glyph renderer, and every screenshot with text on it gets slightly different anti-aliasing.

Fix: pin a bundled font for screenshot tests specifically, so the test never depends on what's installed on the runner.

val ScreenshotTestFontFamily = FontFamily(
    Font(R.font.roboto_regular, FontWeight.Normal),
    Font(R.font.roboto_medium, FontWeight.Medium),
    Font(R.font.roboto_bold, FontWeight.Bold),
)

@Composable
fun ScreenshotTestTheme(content: @Composable () -> Unit) {
    MaterialTheme(
        typography = Typography().let { base ->
            base.copy(
                bodyLarge = base.bodyLarge.copy(fontFamily = ScreenshotTestFontFamily),
                titleLarge = base.titleLarge.copy(fontFamily = ScreenshotTestFontFamily),
                labelMedium = base.labelMedium.copy(fontFamily = ScreenshotTestFontFamily),
                // ...repeat for whichever styles your screens actually use
            )
        }
    ) { content() }
}

Wrap every screenshot test's content in ScreenshotTestTheme instead of your app's real theme. It's not a visual downgrade for the test — the bundled font renders identically on every machine, which is the entire point.

3. Pixel-exact diffing punishes anti-aliasing, not real regressions

Even with the clock and fonts pinned, GPU driver differences between CI and local hardware can shift anti-aliasing by a channel value or two on curved edges. A byte-exact ByteArray.contentEquals comparison will flag that as a failure even though no human would ever see a difference.

Fix: diff with a tolerance, not exact equality — count the proportion of pixels that differ beyond a threshold, and fail only past a small percentage.

fun assertImagesMatch(expected: Bitmap, actual: Bitmap, toleranceFraction: Double = 0.01) {
    require(expected.width == actual.width && expected.height == actual.height) {
        "Size mismatch: expected ${expected.width}x${expected.height}, got ${actual.width}x${actual.height}"
    }
    var mismatched = 0
    val totalPixels = expected.width * expected.height
    for (x in 0 until expected.width) {
        for (y in 0 until expected.height) {
            val e = expected.getPixel(x, y)
            val a = actual.getPixel(x, y)
            val dr = abs(Color.red(e) - Color.red(a))
            val dg = abs(Color.green(e) - Color.green(a))
            val db = abs(Color.blue(e) - Color.blue(a))
            if (dr > 8 || dg > 8 || db > 8) mismatched++
        }
    }
    val mismatchFraction = mismatched.toDouble() / totalPixels
    assertTrue(
        "Images differ in ${(mismatchFraction * 100).format(2)}% of pixels (tolerance ${toleranceFraction * 100}%)",
        mismatchFraction <= toleranceFraction
    )
}

The per-channel threshold of 8 and the 1% overall tolerance aren't universal constants — tune them against your own known-good baselines. The point is that the failure mode changes from "any pixel differs" to "a real visual change happened," which is the thing you actually want to know about.

4. Async state races the composition

The most common one: a screen collects a StateFlow from a ViewModel, the test sets content, and immediately calls captureToImage() — but the first emission from the flow hasn't landed in composition yet, so the screenshot captures the loading state, not the state the test thinks it configured.

Fix: don't screenshot immediately after setContent. Use waitForIdle() (or, better, a synchronization point tied to a testTag that only appears in the final state) before capturing.

composeRule.setContent { ProfileScreen(viewModel = fakeViewModel) }
composeRule.waitUntil(timeoutMillis = 2_000) {
    composeRule.onAllNodesWithTag("profile-loaded").fetchSemanticsNodes().isNotEmpty()
}
composeRule.onRoot().captureToImage()

waitForIdle() alone works for simple cases, but a waitUntil gated on a real semantic marker in the loaded UI is worth the extra line — it fails loudly with a clear timeout message instead of silently screenshotting the wrong state.

None of these four fixes are exotic. They're also, in my experience, never all four applied consistently across a real test suite — usually a codebase has the clock one nailed down and still gets bitten by font fallback six months later when a new CI image rolls out. Worth auditing your existing screenshot tests against this list rather than waiting for the next flake to show up.

If you want the fuller version of this — including how these four checks compose into a single reusable JUnit rule, plus the Paparazzi-specific variants of each fix (Paparazzi skips the emulator entirely, which removes GPU-driver flakiness but reintroduces its own font-loading gotchas) — I wrote all of it up in the Android & Compose Testing Playbook.

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

Why Your Compose UI Test Can't Find That Button (Semantics vs. Text Matching)

Why Your Compose UI Test Can't Find That Button (Semantics vs. Text Matching)

The core misunderstanding

The fix: stop matching on text, start matching on identity

The second trap: merged vs. unmerged trees

A minimal checklist before you write another Compose UI test

Gemini Nano Isn't on Most of Your Users' Phones. Here's the Feature-Detection Pattern That Doesn't Embarrass You in Production

Gemini Nano Isn't on Most of Your Users' Phones. Here's the Feature-Detection Pattern That Doesn't Embarrass You in Production

The wrong way (what most first attempts look like)

Model the capability as a sealed state, not a boolean

Feature detection: check before you commit to a UI path

The fallback that actually matters: cloud, but only when it's worth it

The part that's easy to get wrong: caching the check

Why Your Compose Screenshot Tests Are Flaky (And the Fix Isn't "Add Sleep")

Why Your Compose Screenshot Tests Are Flaky (And the Fix Isn't "Add Sleep")

1. The animation clock is running free

2. Fonts render differently on CI than on your machine

3. Pixel-exact diffing punishes anti-aliasing, not real regressions

4. Async state races the composition

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`)