Android Data Basics

SQLite is a lightweight, file-based relational database engine embedded in Android. Every Android device includes SQLite, making it available without any external dependency. It is well-suited for structured local data that requires querying, sorting, and filtering.

Direct SQLite API (low-level, rarely used directly)

The raw API uses SQLiteOpenHelper to manage database creation and upgrades:

class AppDbHelper(context: Context) : SQLiteOpenHelper(context, "app.db", null, 2) {
    override fun onCreate(db: SQLiteDatabase) {
        db.execSQL("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL)")
    }
    override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) {
        db.execSQL("ALTER TABLE users ADD COLUMN email TEXT")
    }
}

You then query and insert using db.query(...), db.insert(...), etc. This approach is verbose, type-unsafe, and runs database operations on whichever thread you call it from (you must manage threading manually).

Room (recommended — Jetpack)

Room is the Jetpack abstraction over SQLite. It is the standard approach in modern Android development. Room provides compile-time verification of SQL queries, type-safe Kotlin APIs, coroutine and Flow support, and automated migration generation.

@Entity
data class User(
    @PrimaryKey val id: Int,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user WHERE id = :id")
    suspend fun getById(id: Int): User?

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insert(user: User)

    @Query("SELECT * FROM user ORDER BY name ASC")
    fun observeAll(): Flow>
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Key points about Room

• @Entity annotates data classes that map to database tables.
• @Dao annotates interfaces with query methods. Room generates the implementation.
• suspend functions work directly with coroutines — Room runs them on an IO dispatcher automatically.
• Flow return types give you a reactive stream that emits new values whenever the underlying table changes — no manual re-querying needed.
• SQL queries are validated at compile time; a typo in a table name causes a build error.
• RoomDatabase should be injected as a singleton — Hilt provides @InstallIn(SingletonComponent::class) for this.

Schema migrations

When you increment the database version, Room requires you to provide a Migration object describing the schema change:

val MIGRATION_1_2 = object : Migration(1, 2) {
    override fun migrate(db: SupportSQLiteDatabase) {
        db.execSQL("ALTER TABLE user ADD COLUMN email TEXT NOT NULL DEFAULT ''")
    }
}

Room 2.4+ also supports auto-migrations for simple schema changes (adding/removing columns).

When to use SQLite/Room vs. alternatives

• Room: structured relational data, complex queries, need for reactive updates. The default choice.
• DataStore (Proto or Preferences): simple key-value settings or typed objects. Replaces SharedPreferences for new code.
• Files: binary blobs, media, large exports.
• Remote database (Firestore, Supabase): when data needs to sync across devices.

Common interview gotcha: never run database operations on the main thread. Room enforces this by default — calling a non-suspend DAO method on the main thread throws an IllegalStateException. Use suspend functions in a coroutine or Flow to observe changes reactively.

Parcelable is an Android-specific interface for serializing objects so they can be passed between components via Intent extras, Bundles, or across process boundaries via AIDL. It is the standard way to pass custom data objects between Activities, Fragments, and Services on Android.

Why Parcelable instead of Java Serializable?

Java Serializable uses reflection to inspect the object graph at runtime, which is slow and creates a lot of temporary objects (putting pressure on the garbage collector). Parcelable requires you to explicitly write each field to a Parcel and read it back in the same order, which is much faster and creates fewer allocations. Benchmarks consistently show Parcelable to be roughly 10× faster than Serializable for the same object graph.

Implementing Parcelable

The traditional manual implementation is verbose. Modern Android uses the Kotlin Parcelize plugin, which generates all boilerplate at compile time:

// build.gradle.kts (app module)
plugins {
    id("kotlin-parcelize")
}

import android.os.Parcelable
import kotlinx.parcelize.Parcelize

@Parcelize
data class User(
    val id: Int,
    val name: String,
    val email: String
) : Parcelable

That's it — @Parcelize generates writeToParcel(), describeContents(), and the CREATOR factory, all from the data class properties. No boilerplate needed.

Passing Parcelable data

// Sending
val intent = Intent(this, DetailActivity::class.java).apply {
    putExtra("user", user) // user is Parcelable
}
startActivity(intent)

// Receiving
val user: User? = intent.getParcelableExtra("user", User::class.java) // API 33+
// or on older APIs: intent.getParcelableExtra("user")

Parcelable in Fragments

// Sending via Bundle (Navigation Safe Args or manual)
val args = Bundle().apply { putParcelable("user", user) }

// Receiving
val user: User? = arguments?.getParcelable("user", User::class.java)

With Jetpack Navigation's Safe Args plugin, argument types are validated at compile time, including Parcelable types.

Common gotchas

• Order matters: writeToParcel() and createFromParcel() must read and write fields in the same order. @Parcelize handles this automatically.
• Parcelable is not persistent storage: it is for in-memory IPC and Bundle passing. Don't use it to save data to disk — use Room or DataStore.
• Size limits: Binder (the IPC mechanism underlying Intents) has a ~1 MB buffer limit across all concurrent transactions. Avoid passing large bitmaps or collections via Parcelable; pass identifiers and load data from a repository instead.
• API 33 getParcelableExtra(String, Class): the old getParcelableExtra(String) is deprecated on API 33+ and generates unchecked cast warnings. Use the class-typed version on API 33+ with a Build.VERSION.SDK_INT check or use the BundleCompat / IntentCompat compat classes from androidx.core.

SharedPreferences is Android's legacy key-value store for persisting small amounts of primitive data (strings, ints, booleans, floats, long, sets of strings). It persists across app sessions and process deaths. For new code, Jetpack DataStore is the recommended replacement — it is asynchronous, safe on the main thread, and does not have SharedPreferences' data consistency issues. That said, SharedPreferences is still widely used and appears in many existing codebases.

Basic usage (SharedPreferences)

// Writing
val prefs = getSharedPreferences("settings", Context.MODE_PRIVATE)
prefs.edit()
    .putString("username", "alice")
    .putBoolean("notifications_enabled", true)
    .apply() // async commit; use .commit() only if you need a synchronous return value

// Reading
val username = prefs.getString("username", "guest") // "guest" is the default
val notificationsEnabled = prefs.getBoolean("notifications_enabled", true)

// Observing changes
prefs.registerOnSharedPreferenceChangeListener { _, key ->
    if (key == "username") { /* handle change */ }
}

apply() vs commit()

• apply(): writes to the in-memory copy immediately, persists to disk asynchronously. Returns void. Safe to call on the main thread.
• commit(): writes synchronously to disk, returns true on success. Blocks the calling thread — avoid on the main thread.

Prefer DataStore for new code

Jetpack DataStore (in androidx.datastore) offers two variants:

Preferences DataStore (drop-in replacement for SharedPreferences):

// Define
val Context.dataStore: DataStore by preferencesDataStore(name = "settings")
val USERNAME_KEY = stringPreferencesKey("username")

// Write (suspending, runs on IO dispatcher internally)
context.dataStore.edit { prefs -> prefs[USERNAME_KEY] = "alice" }

// Read (returns Flow — observe reactively)
val usernameFlow: Flow = context.dataStore.data.map { it[USERNAME_KEY] ?: "guest" }

Proto DataStore: stores typed objects defined with Protocol Buffers. Provides full type safety and schema evolution, but requires a .proto schema file.

Why DataStore over SharedPreferences

• SharedPreferences performs disk I/O on the main thread when you call getSharedPreferences() the first time (it reads the entire XML file). This can cause ANR (Application Not Responding) under load.
• SharedPreferences apply() can cause StrictMode violations and occasionally data corruption on process crashes.
• DataStore is built on coroutines and Flows — reads and writes are non-blocking and composable.
• DataStore is scoped to a coroutine scope and integrates cleanly with the ViewModel lifecycle.

When to still use SharedPreferences

• Maintaining an existing codebase that already uses SharedPreferences widely.
• Third-party libraries that expose SharedPreferences-based APIs.
• Very simple, one-off preference reads during initialization where DataStore's async nature adds complexity without benefit.

Common gotcha: SharedPreferences stores data as an XML file in the app's private directory. The file is loaded entirely into memory when first accessed — storing large datasets in SharedPreferences (e.g., a serialized list) causes performance problems. Use Room for structured data and files or DataStore Proto for typed complex objects.

Content Providers are one of Android's four core application components (alongside Activities, Services, and BroadcastReceivers). They expose structured data from one application to other applications or system components through a standardized URI-based interface.

What they do

A Content Provider sits in front of a data source (typically a Room/SQLite database, but also files or network data) and exposes it via URIs of the form content://authority/path/id. Other apps (and system components) query, insert, update, and delete data through a ContentResolver, which routes the call to the appropriate provider process.

How they work

// Querying a Content Provider (consumer side)
val cursor = contentResolver.query(
    Uri.parse("content://com.example.myapp.provider/users"),
    arrayOf("_id", "name", "email"), // projection (columns)
    "name = ?",                        // selection
    arrayOf("Alice"),                  // selection args
    "name ASC"                         // sort order
)
cursor?.use {
    while (it.moveToNext()) {
        val name = it.getString(it.getColumnIndexOrThrow("name"))
    }
}

Implementing a Content Provider

You extend ContentProvider and override query(), insert(), update(), delete(), and getType(). You declare it in the manifest with an `element and setandroid:exported` to control visibility.

When are Content Providers actually needed?

This is the key question interviewers probe. In modern Android development, you rarely write a Content Provider for internal use within your own app:

• Internal data sharing: use Room, DataStore, or a Singleton repository accessed via Hilt — these are simpler and faster.
• Exposing data to other apps: Content Provider is the correct tool. Example: an app that exposes contact data, media files, or custom data sets for other apps to read.
• System integration: required for specific system features — CameraX and FileProvider for sharing files safely, SyncAdapter for background syncing with an account, SearchSuggestionProvider for system-wide search suggestions, and AutofillService for exposing fillable fields.

FileProvider (most commonly encountered in 2026)

FileProvider is a concrete ContentProvider subclass from androidx.core that generates content:// URIs for files in your app's private storage. It is the standard, required way to share files with other apps (camera apps, email clients, etc.) since Android 7 Nougat, which blocked file:// URIs in Intents:

val uri = FileProvider.getUriForFile(
    context,
    "${context.packageName}.fileprovider",
    file
)
intent.setDataAndType(uri, "application/pdf")
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Permissions and security

Content Providers enforce access control via:

• android:permission / android:readPermission / android:writePermission on the `` element.
• Intent.FLAG_GRANT_READ_URI_PERMISSION for temporary, single-use URI grants to specific apps (used with FileProvider).
• android:exported="false" to prevent other apps from accessing it at all.

Common gotcha: Content Providers are initialized before Application.onCreate() is called, making them an (ab)used vector for eager library initialization (the startup library's InitializationProvider does this). Be aware that a misbehaving third-party Content Provider can slow your app startup — the App Startup library lets you control initialization order and laziness.

Loaders were introduced in Android 3.0 (Honeycomb) to solve the problem of loading data asynchronously in a way that survived configuration changes (like screen rotation). They are now deprecated as of Android 9 (API 28) and the deprecation was further emphasized in subsequent Jetpack releases. You should not use Loaders in new code.

What Loaders did

The LoaderManager and CursorLoader / AsyncTaskLoader APIs allowed you to:

• Load data in a background thread.
• Deliver results to the UI thread.
• Survive Activity/Fragment recreation (configuration changes) without restarting the load.
• Automatically restart the load when the underlying data changed (for CursorLoader backed by a ContentProvider).

Why they are deprecated

The same problems Loaders solved are now solved better by the Jetpack ViewModel + LiveData/Flow pattern, which is cleaner, more testable, and composable:

The modern replacement pattern

// ViewModel
class UsersViewModel(private val repo: UserRepository) : ViewModel() {
    val users: StateFlow> = repo.observeUsers()
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), emptyList())
}

// Repository
class UserRepository(private val dao: UserDao) {
    fun observeUsers(): Flow> = dao.observeAll() // Room Flow
}

// Fragment / Activity (Compose)
@Composable
fun UsersScreen(viewModel: UsersViewModel = hiltViewModel()) {
    val users by viewModel.users.collectAsStateWithLifecycle()
    LazyColumn {
        items(users, key = { it.id }) { user -> UserItem(user) }
    }
}

This pattern:

• Survives configuration changes because the ViewModel is retained.
• Loads data off the main thread (Room dispatches Flow emissions to an IO dispatcher).
• Delivers results lifecycle-safely (collectAsStateWithLifecycle stops collecting when the lifecycle is stopped).
• Reacts to database changes automatically via Room's Flow.

When you might still encounter Loaders

In legacy codebases (pre-2019) that use CursorLoader with Content Providers, or in apps targeting older API levels that have not been modernized. Migration is straightforward: replace LoaderManager callbacks with a ViewModel that collects a Flow from Room.

Note on AsyncTask: AsyncTask was the other common background-threading mechanism from the same era. It was deprecated in Android 11 (API 30). Both AsyncTask and Loaders should be replaced with Kotlin coroutines in any modernization effort.