Introduction

Using an existing database in an Android app can mean two very different things: shipping a prepopulated SQLite database with the app, or connecting to a remote server database. Those cases should be handled differently, and confusing them leads to bad architecture quickly.

Use a Prepackaged SQLite Database for Offline Data

If the existing database is already SQLite and should live on the device, package it as an asset and copy or open it through Android's database layer. With modern Android, Room is usually the cleanest approach.

A Room setup with a prepackaged database looks like this:

1@Database(entities = [Book::class], version = 1)
2abstract class AppDatabase : RoomDatabase() {
3    abstract fun bookDao(): BookDao
4}

1val db = Room.databaseBuilder(
2    context,
3    AppDatabase::class.java,
4    "books.db"
5)
6    .createFromAsset("database/books.db")
7    .build()

This is much cleaner than manually copying files with streams unless you are maintaining older code that predates Room.

If your source database is not SQLite, convert it first. Android does not embed MySQL or PostgreSQL servers inside your app.

Use an API for Remote Databases

If the "existing database" is a server database such as MySQL or PostgreSQL, do not connect to it directly from Android. The usual design is:

1. Android app talks to an HTTPS API
2. API talks to the database
3. app receives JSON or another controlled response format

A simple Retrofit example:

1interface BookService {
2    @GET("books")
3    suspend fun listBooks(): List<BookDto>
4}

This protects credentials, centralizes validation, and avoids exposing the database directly to every mobile client.

Think About Updates and Migrations

If you ship a local database with the app, decide how it will be updated later. A prepackaged asset is great for seed data, but users may eventually need migrations when the schema changes.

With Room, schema versioning and migrations give you a safer path:

1val migration1To2 = object : Migration(1, 2) {
2    override fun migrate(database: SupportSQLiteDatabase) {
3        database.execSQL("ALTER TABLE books ADD COLUMN category TEXT NOT NULL DEFAULT ''")
4    }
5}

Then include it in the builder:

1val db = Room.databaseBuilder(context, AppDatabase::class.java, "books.db")
2    .createFromAsset("database/books.db")
3    .addMigrations(migration1To2)
4    .build()

That keeps the packaged starting state and the installed database lifecycle aligned.

Common Pitfalls

The biggest mistake is trying to connect directly from Android to a production relational database server. That exposes credentials, expands the attack surface, and usually performs poorly on mobile networks.

Another common issue is assuming any existing database file can simply be dropped into an Android project. If it is not SQLite, it needs conversion or a server-side access layer.

People also manually copy prepackaged SQLite files even in new projects where Room already supports createFromAsset. Manual copy logic works, but it adds more code paths to test and maintain.

Finally, do not forget schema migrations. A preloaded database is only the starting point. Once users install the app, updates must preserve their local state correctly.

If the database is large, also think about app size and first-launch time. Shipping a huge asset may be less practical than syncing the needed data after installation.

Summary

• First decide whether the existing database is a local SQLite file or a remote server database.
• Use a prepackaged SQLite asset for offline local data on Android.
• Use an API, not a direct database connection, for remote server databases.
• Prefer Room and createFromAsset for modern Android local-database integration.
• Plan schema migrations early so updates do not break installed apps.