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-migration only if the main work is reactive API migration rather than the database contract itself.
Handoff skills when the scope expands:
android-local-persistence-datastore
android-testing-unit

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.

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.

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.

Scenario: Keep Room requests separate from DataStore, networking, and modernization prompts.
Command: cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest