DEV Community: YADNYESH RANA

Encrypting Room SQLite Databases with SQLCipher and Biometric Keys

YADNYESH RANA — Thu, 25 Jun 2026 14:22:40 +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).

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