Android Room Database
CommunitykrutikJain
Model Room entities, DAOs, transactions, migrations, schema exports, and test-safe local persistence.
Overview
- Repository
- krutikJain/android-agent-skills
- Publisher
- krutikJain
- Stars
- 14
- Forks
- 5
- Bundled files
- 5
- License
- MIT
- Updated
- Mar 25, 2026
Installation
tmp=$(mktemp -d)
git clone --depth 1 https://github.com/krutikJain/android-agent-skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/android-room-database" ~/.claude/skills/android-room-database
rm -rf "$tmp"tmp=$(mktemp -d)
git clone --depth 1 https://github.com/krutikJain/android-agent-skills.git "$tmp"
mkdir -p ~/.codex/skills
cp -R "$tmp/skills/android-room-database" ~/.codex/skills/android-room-database
rm -rf "$tmp"Install the Android Room Database agent skill from https://github.com/krutikJain/android-agent-skills/tree/main/skills/android-room-database into this project's skills folder.Instructions
Android Room Database
When To Use
- Use this skill when the request is about: room database android, dao query migration android, room schema export.
- Primary outcome: Model Room entities, DAOs, transactions, migrations, schema exports, and test-safe local persistence.
- Reach for this skill when the hard part is schema design, DAO queries, transactions, migrations, or Room testing. Hand off to
android-rxjava-to-coroutines-migrationonly if the main work is reactive API migration rather than the database contract itself. - Handoff skills when the scope expands:
android-local-persistence-datastoreandroid-testing-unit
Workflow
- Start with the persistence contract: entities, keys, indexes, relations, and whether the data is source-of-truth, cache, or offline-first state.
- Model DAO access patterns explicitly, including transaction boundaries, query shape, paging, and invalidation behavior.
- Plan schema evolution before changing entities: exported schemas, migration steps, auto-migration eligibility, and destructive-fallback policy.
- Validate migration and query behavior with deterministic tests rather than assuming Room annotations are enough.
- Hand off DataStore, sync, or reactive API questions only after the Room boundary is correct.
Guardrails
- Export schemas and treat them as part of the contract, not optional tooling noise.
- Keep entities persistence-focused; map to domain/UI models instead of leaking table shape upward.
- Use explicit transactions for multi-step writes that must remain consistent.
- Test migrations against real old schemas before trusting them in release builds.
Anti-Patterns
- Treating Room entities as the app's domain model everywhere.
- Editing schemas without exporting or validating migration paths.
- Writing broad
SELECT *queries when the screen only needs a narrow projection. - Collapsing database, sync, and reactive-stream migration problems into one undifferentiated task.
Review Focus
- Entity keys, indexes, relations, and schema ownership.
- DAO query shape, transactions, and invalidation behavior.
- Migration safety, schema exports, and test coverage.
- Clear boundaries between Room models and higher-level app models.
Examples
Happy path
- Scenario: Persist task items and reminder flags with schema-aware entities.
- Command:
cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest
Edge case
- Scenario: Recover from a failed schema change with an explicit migration path.
- Command:
python3 scripts/eval_triggers.py --skill android-room-database
Failure recovery
- Scenario: Keep Room requests separate from DataStore, networking, and modernization prompts.
- Command:
cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest
Done Checklist
- Entities, DAOs, and transactions match the real persistence contract.
- Schema export and migration strategy are explicit.
- Query and migration tests cover the risky paths.
- Non-Room concerns are handed off instead of mixed into the database task.
Official References
- https://developer.android.com/training/data-storage/room
- https://developer.android.com/training/data-storage/room/migrating-db-versions
- https://developer.android.com/training/data-storage/room/accessing-data
- https://developer.android.com/training/data-storage/room/prepopulate
- https://developer.android.com/topic/performance/sqlite-performance-best-practices
Bundled files
FAQ
What does Android Room Database do?
Model Room entities, DAOs, transactions, migrations, schema exports, and test-safe local persistence.
Who made Android Room Database?
krutikJain (a community member) publishes it in the krutikJain/android-agent-skills repository on GitHub.
Is Android Room Database free?
Yes. Android Room Database is open source, published by krutikJain under the MIT license.
What comes with Android Room Database?
Its instructions and 5 files the agent reads only when a task needs them, such as references, examples or scripts.
Which agents can use Android Room Database?
Any coding agent that reads SKILL.md files, including Claude Code, Codex, Cursor, GitHub Copilot and Gemini CLI. The agent loads the skill when a task matches its description.
What are agent skills?
An agent skill is a folder with a SKILL.md file: instructions that teach a coding agent how to do one kind of task, and optionally files it can read while it works. The agent keeps only the skill's name and description in mind and reads the rest when a task calls for it.
How are agent skills different from MCP servers?
An MCP server gives an agent new tools to call, code that runs somewhere and returns results. A skill gives it knowledge: how to approach a task with the tools it already has. Many agents use both.
How can my agent test my Android app?
Robomori lets coding agents create, start and control Android emulators and devices from one command, so they can install your app, take screenshots and check dark mode, font sizes and languages.
Room/SQLite, DataStore and repository traps: migrations, NOT IN with NULLs, LIKE escaping, delete order, local-time bucketing, imports, caching, paging. Use before writing a query or migration, or when data comes back wrong.
Required before any reply that touches KSafe (`by ksafe(...)`, `ksafe.get/put`, :ksafe-compose, :ksafe-biometrics), even a 'can KSafe do X?' question or a one-line change that looks like plain Kotlin. KSafe's signatures, defaults and overloads changed in recent releases, so answers from memory give wrong code. Typical: making one value unencrypted, passing a KSerializer for a generic T, faking KSafe in commonTest, compile errors, crashes, Desktop packaging. Also use when KSafe is unnamed but Kotlin/Compose Multiplatform code must keep secrets or settings on device: tokens, PINs, passwords, DB passphrases, encrypted prefs, a testable local data source, choosing or replacing a KMP secure-storage library (EncryptedSharedPreferences, DataStore, KVault, Multiplatform Settings), Face ID/fingerprint/Windows Hello gating, key rotation, proving keys sit in StrongBox/Secure Enclave/Keychain. Skip storage work with no KMP target and no KSafe (pure Swift, Android-only, browser).
Write Kotlin (JVM, Android or Kotlin Multiplatform) database code with sqlx4k, the coroutine-first SQL toolkit for PostgreSQL, MySQL/MariaDB, SQLite and SQLCipher: Gradle setup, @Table entities, @Repository interfaces with compile-time validated @Query methods, transactions, migrations and error handling. Use when a project depends on sqlx4k (io.github.smyrgeorge:sqlx4k-*, the io.github.smyrgeorge.sqlx4k Gradle plugin, or imports from io.github.smyrgeorge.sqlx4k), or when the user asks to use it.
Use when implementing the data layer in Android or KMP — the Repository pattern's layered error-propagation model (repository as the error boundary, sealed DataError, Result placement with and without a domain layer) and Room in commonMain (@ConstructedBy, BundledSQLiteDriver, per-target KSP).
