DEV Community: YADNYESH RANA

iOS Keeps Observing a Dead Kotlin Flow — the CommonFlow Leak Hiding in Your KMP Bridge

YADNYESH RANA — Mon, 12 Oct 2026 03:52:27 +0000

iOS Keeps Observing a Dead Kotlin Flow — the CommonFlow Leak Hiding in Your KMP Bridge

So you've wrapped your shared Flow<T> for Swift consumption. Something like this on the Kotlin side:

class CommonFlow<T : Any>(private val wrapped: Flow<T>) {
    fun watch(block: (T) -> Unit): CommonFlowCancellation {
        val job = Job()
        wrapped.onEach {
            block(it)
        }.launchIn(CoroutineScope(Dispatchers.Main + job))
        return CommonFlowCancellation(job)
    }
}

class CommonFlowCancellation(private val job: Job) {
    fun cancel() {
        job.cancel()
    }
}

And on the Swift side, something like:

class ProfileViewModel: ObservableObject {
    @Published var state: ProfileState = .loading
    private var cancellation: CommonFlowCancellation?

    func observe(_ repo: ProfileRepository) {
        cancellation = repo.observeProfile().watch { [weak self] state in
            self?.state = state
        }
    }
}

This works perfectly in the demo. It works in QA. Then three sprints later someone
files a bug: "the profile screen stops updating after you navigate away and back a few
times" — or worse, a slow memory climb that only shows up after twenty minutes of real
usage, nowhere near your five-minute manual test pass.

The actual bug

observe() gets called again every time the view reappears — in onAppear, in
viewDidLoad on a reused view controller, in a SwiftUI view's init if you're not
careful. Each call overwrites cancellation with a new CommonFlowCancellation,
dropping the reference to the previous one.

The previous Job is still running. Nobody ever called cancel() on it, because the
only object that held a reference to it just got replaced. The old collector keeps
emitting into a block closure that captured self — except now you have two live
collectors fighting to set self.state, and the view model itself can't deallocate
because the dangling Job's coroutine scope still holds a strong path back to it
through the closure.

This is not a Kotlin bug and not a SKIE bug. It is the exact same "forgot to dispose
the subscription" class of bug that RxJava/RxSwift developers have been shipping since
2015 — KMP's Flow bridge just gives it a new home.

Why `[weak self]` doesn't save you here

The [weak self] in the closure stops the view model from leaking. It does nothing
for the orphaned Job. That job has its own CoroutineScope, its own dispatcher
queue, and its own onEach collector — all of that keeps running, consuming CPU and
holding onto whatever it: T values flow through it, completely independent of
whether self is nil. A leaked Job with a dead weak self just means your observer
now silently no-ops forever instead of crashing — which is worse, because nothing
tells you it's broken.

The fix: cancel before you resubscribe, every time

func observe(_ repo: ProfileRepository) {
    cancellation?.cancel()
    cancellation = repo.observeProfile().watch { [weak self] state in
        self?.state = state
    }
}

One line. The entire bug is that nothing ever called cancel() on the way out. If your
view can call observe() more than once in its lifetime — which almost every
real-world view can, via re-navigation, tab switching, or SwiftUI re-initialization —
this line is not optional.

Making the mistake impossible instead of just fixed

A one-line fix is easy to re-break the next time someone adds a new observer call site.
Better to make the lifecycle explicit on the Kotlin side too, so cancellation isn't
something Swift callers have to remember:

class CommonFlow<T : Any>(private val wrapped: Flow<T>) {
    private var activeJob: Job? = null

    fun watch(block: (T) -> Unit): CommonFlowCancellation {
        activeJob?.cancel() // kill any previous collector on THIS flow instance first
        val job = Job()
        activeJob = job
        wrapped.onEach { block(it) }
            .launchIn(CoroutineScope(Dispatchers.Main + job))
        return CommonFlowCancellation(job)
    }
}

This doesn't replace disciplined cancellation on the Swift side — a view model that
outlives its view still needs cancellation?.cancel() in deinit — but it means a
double-watch() call on the same wrapper (the actual bug above) can't silently stack
two live collectors anymore. Defense in depth matters more here than in pure-Kotlin
code, because Swift has no compiler warning for "you dropped a reference to something
that was holding a background job open."

The broader pattern

Anywhere a KMP shared module hands Swift something that needs explicit teardown —
Flow collectors, platform expect/actual resource handles (file handles, native
camera sessions), long-lived Koin-scoped singletons — the failure mode is the same:
Kotlin's structured concurrency assumes a CoroutineScope owner that cancels it, but
Swift's ARC has no equivalent "scope" concept, so the handoff point is exactly where
leaks are born. Treat every cross-boundary Flow/callback bridge as a resource that
needs an explicit, defensive cancel-on-resubscribe path, not just a cancel-on-deinit
path — re-navigation will exercise the first case long before deinit ever exercises the
second.

If you're setting up a KMP shared module from scratch and want the Ktor client, Room,
Koin DI, and navigation wiring done right the first time (with the trap callouts for
this kind of lifecycle mismatch built in), I put together a Kotlin Multiplatform &
Compose Multiplatform Developer Cookbook with 10
production-grade recipes and a ready-to-clone starter project.

Your @Stable Data Class Isn't the Recomposition Leak — the Lambda Next to It Is

YADNYESH RANA — Mon, 05 Oct 2026 03:54:06 +0000

The setup

You've got a @Stable data class, you're passing it into a composable, and Layout Inspector's recomposition counter is still climbing every time the parent redraws. The usual advice — "mark your classes @Stable or @Immutable" — doesn't fix it, because the leak isn't in the data class. It's in the lambda next to it.

@Stable
data class CartSummary(val itemCount: Int, val totalCents: Long)

@Composable
fun CartHeader(summary: CartSummary, onCheckout: () -> Unit) {
    Row {
        Text("${summary.itemCount} items — ${summary.totalCents.toFormattedPrice()}")
        Button(onClick = onCheckout) { Text("Checkout") }
    }
}

CartHeader looks stable on paper: a @Stable data class and a function-typed parameter, which Compose treats as stable if the lambda itself is stable across recompositions. The bug lives in how the caller constructs that lambda.

The actual leak

@Composable
fun CartScreen(viewModel: CartViewModel) {
    val summary by viewModel.summary.collectAsStateWithLifecycle()
    var promoCode by remember { mutableStateOf("") }

    CartHeader(
        summary = summary,
        onCheckout = { viewModel.checkout(promoCode) } // new instance every recomposition
    )
}

Every time CartScreen recomposes — and promoCode changing on every keystroke guarantees that — the trailing lambda passed to onCheckout is a new object. Compose's stability check for CartHeader compares the lambda instance, not its captured values' equality, so a structurally identical-looking lambda still reads as "changed," and CartHeader recomposes along with it, even though summary itself didn't change and the composable only cares about onCheckout being callable, not which promoCode snapshot it happens to close over.

This is the part Layout Inspector won't tell you directly: it'll show CartHeader recomposing on every keystroke in an unrelated text field, and the instinct is to go check CartSummary's stability, which is a dead end — it was never the problem.

The fix: stop capturing, start reading

The lambda doesn't need to capture promoCode by value at the point it's created — it needs to read promoCode's current value at the point it's called. rememberUpdatedState is built for exactly this split:

@Composable
fun CartScreen(viewModel: CartViewModel) {
    val summary by viewModel.summary.collectAsStateWithLifecycle()
    var promoCode by remember { mutableStateOf("") }
    val currentPromoCode by rememberUpdatedState(promoCode)

    val onCheckout = remember(viewModel) {
        { viewModel.checkout(currentPromoCode) }
    }

    CartHeader(summary = summary, onCheckout = onCheckout)
}

remember(viewModel) now holds the same lambda instance across recompositions (it only rebuilds if viewModel itself changes), while currentPromoCode — read inside the lambda body, not captured at creation — always resolves to whatever the latest promo code is when checkout actually fires. CartHeader now only recomposes when summary changes, which is the only thing it was ever supposed to care about.

Why this matters more as screens get bigger

A two-line composable eating an extra recomposition is noise. The same pattern inside a LazyColumn item scope — a row-level onClick capturing a loop variable or a per-item ViewModel field — means every keystroke in an unrelated search box or filter chip can ripple into rebuilding every visible row, because each row's lambda was freshly allocated on the parent's last pass. The fix is identical: hoist the lambda out of the loop body with remember(key), and let it read current values through rememberUpdatedState or a stable callback object instead of closing over them directly.

The check to run before blaming `@Stable`

If Layout Inspector shows a composable recomposing on a state change that has nothing to do with the data it renders, don't start by re-annotating your model classes. Check what's being passed as a trailing lambda or callback first, and whether that lambda is remember-ed or rebuilt fresh on every pass. Stability of the data you already got right; it's the stability of the behavior you hand down alongside it that's usually the actual leak.

This is one slice of a much bigger surface — Compose's stability inference rules, how the slot table actually decides what counts as "changed," and the handful of other non-obvious recomposition triggers that show up constantly in senior Android interviews — covered in full in Jetpack Compose & UI Architecture: Ultimate Interview Prep Blueprint if you want the deeper dive, including the Google-interviewer-specific framing for how this gets asked in a whiteboard setting.

Your catch(Exception) Block Is Quietly Breaking Coroutine Cancellation

YADNYESH RANA — Mon, 28 Sep 2026 03:52:38 +0000

Your `catch (e: Exception)` Block Is Quietly Breaking Coroutine Cancellation

You've probably written this exact pattern to make a network call "resilient":

suspend fun loadProfile(userId: String): Profile {
    var attempt = 0
    while (true) {
        try {
            return api.fetchProfile(userId)
        } catch (e: Exception) {
            attempt++
            if (attempt >= 3) throw e
            delay(1000L * attempt)
        }
    }
}

Looks reasonable. Retries on failure, backs off, gives up after three tries. It'll pass
every unit test you throw at it. It will also silently break structured concurrency the
moment the coroutine calling it gets cancelled — and nothing in this function will ever
tell you that happened.

Why `catch (e: Exception)` catches cancellation too

CancellationException is a subclass of Exception in Kotlin. When a coroutine's Job
gets cancelled — the screen is destroyed and viewModelScope cancels, a parent
coroutineScope fails and cancels its siblings, a timeout fires — the suspension point
the coroutine is sitting at (here, delay() or the actual api.fetchProfile suspend
call) throws a CancellationException to unwind it.

A catch (e: Exception) block doesn't know the difference between "the server returned
a 500" and "this coroutine was told to stop existing." It catches both. In the code
above, a cancellation during delay(1000L * attempt) gets treated as attempt-failed,
and the loop just... retries again. The coroutine keeps running network calls on a
Job that's already cancelled, for as long as the retry budget allows — a small,
easy-to-miss cancellation leak that shows up in production as "why is this screen still
making requests after the user navigated away" and almost never as a crash you can
grep for.

Structured concurrency assumes cancellation actually propagates

The entire value proposition of structured concurrency — a parent Job cancelling all
its children, a coroutineScope waiting for every child before returning, cancellation
composing cleanly through suspend function calls — depends on CancellationException
reaching the top of the coroutine and actually finishing the job. Swallow it partway up
the call stack and you've quietly opted this one coroutine out of the entire cancellation
model, without changing a single type signature. Nothing about the function's shape
tells a caller this happened.

It gets worse in a coroutineScope { } with multiple children: if one child's exception
is supposed to cancel its siblings, and a sibling's catch block is eating the resulting
CancellationException instead of rethrowing it, that sibling keeps running past the
point where the whole scope should have unwound — defeating the "fail one, cancel all"
guarantee that's the actual reason to use coroutineScope instead of supervisorScope
in the first place.

The fix

Check for cancellation explicitly, and rethrow it before your generic handling runs:

suspend fun loadProfile(userId: String): Profile {
    var attempt = 0
    while (true) {
        try {
            return api.fetchProfile(userId)
        } catch (e: CancellationException) {
            throw e // never swallow this — let cancellation propagate
        } catch (e: Exception) {
            attempt++
            if (attempt >= 3) throw e
            delay(1000L * attempt)
        }
    }
}

Order matters: the CancellationException catch has to come before the broader
Exception catch, or it never gets reached. This is easy to get backwards if you add
the cancellation handling later as an afterthought rather than up front.

If you're using runCatching instead of try/catch — common in repository layers that
want a Result<T> return type — you have the same bug, less visibly:

// Buggy: runCatching wraps CancellationException into a failed Result
suspend fun loadProfileResult(userId: String): Result<Profile> =
    runCatching { api.fetchProfile(userId) }

// Fixed: rethrow cancellation, let everything else become a Result
suspend fun loadProfileResult(userId: String): Result<Profile> =
    try {
        Result.success(api.fetchProfile(userId))
    } catch (e: CancellationException) {
        throw e
    } catch (e: Exception) {
        Result.failure(e)
    }

runCatching's own implementation catches Throwable, not just Exception — so this
version of the bug is arguably worse, and it's the one that shows up constantly in
"clean architecture" repository layers that standardized on Result<T> for every
suspend function.

Writing a test that actually catches this

The scary part of this bug is that it's invisible to a test that doesn't specifically
check for it — loadProfile returning the right value on success and throwing on
repeated failure both look fine. You need a test that cancels the calling coroutine
mid-flight and asserts the function actually stops:

@Test
fun `loadProfile does not swallow cancellation`() = runTest {
    val fakeApi = FakeProfileApi(neverResolves = true)
    val job = launch {
        loadProfile(fakeApi, "user-1")
    }
    advanceTimeBy(100)
    job.cancel()
    job.join()

    assertTrue(job.isCancelled)
    assertEquals(0, fakeApi.callCountAfter(job.cancel()))
    // If the buggy version is under test, this either hangs (TestCoroutineScheduler
    // never idles because the retry loop keeps scheduling more delay()s) or the
    // call count keeps climbing after cancel() — either is the leak, caught.
}

With kotlinx-coroutines-test's runTest, a coroutine that keeps rescheduling work
after being told to cancel will either fail the test's idle-detection or keep
incrementing a call counter you can assert against — either way, this is the test that
would have actually caught the retry-loop bug above, where "does it return the right
value" tests wouldn't.

The pattern to watch for in review

Any catch (e: Exception), catch (e: Throwable), or runCatching inside a suspend
function is worth a second look — not because catching broadly is always wrong, but
because it's the one shape of bug that every other kind of testing (unit tests on
success/failure paths, manual QA, crash reporting) is structurally blind to. The
function keeps working correctly for every input except "the coroutine was cancelled
while this was running," which is exactly the case a fast reviewer skims past.

This is one specific case of a broader category — cooperative cancellation leaks,
structured concurrency guarantees, and the Job-hierarchy internals that explain why
this works the way it does — that comes up constantly in senior Android interviews and,
more importantly, in production. I went deep on this and 54 other coroutines/Kotlin
questions in Modern Kotlin & Concurrency: Ultimate Interview Prep
Blueprint if you want the fuller picture,
including Job state transitions and CoroutineExceptionHandler interactions this
post didn't have room for.

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

DEV Community: YADNYESH RANA

iOS Keeps Observing a Dead Kotlin Flow — the CommonFlow Leak Hiding in Your KMP Bridge

The actual bug

Why [weak self] doesn't save you here

The fix: cancel before you resubscribe, every time

Making the mistake impossible instead of just fixed

The broader pattern

Your @Stable Data Class Isn't the Recomposition Leak — the Lambda Next to It Is

The setup

The actual leak

The fix: stop capturing, start reading

Why this matters more as screens get bigger

The check to run before blaming @Stable

Your catch(Exception) Block Is Quietly Breaking Coroutine Cancellation

Your catch (e: Exception) Block Is Quietly Breaking Coroutine Cancellation

Why catch (e: Exception) catches cancellation too

Structured concurrency assumes cancellation actually propagates

The fix

Writing a test that actually catches this

The pattern to watch for in review

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

Why `[weak self]` doesn't save you here

The check to run before blaming `@Stable`

Your `catch (e: Exception)` Block Is Quietly Breaking Coroutine Cancellation

Why `catch (e: Exception)` catches cancellation too

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

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