Introduction

If PreferenceManager.getDefaultSharedPreferences(...) is marked deprecated in your Android Q era code, the important question is which API package you are using and what problem you are solving. For simple key-value storage, the modern answer is to choose an explicit preferences file with Context.getSharedPreferences(...) or to move to Jetpack DataStore. For preference-screen UI code, the AndroidX preference library is the maintained path.

Why the Old Call Was Deprecated

The old framework preference APIs encouraged a hidden global default file. That was convenient, but it also made preference storage less explicit. When you read code that calls getDefaultSharedPreferences, you do not immediately know which file is being used or which part of the app owns those keys.

Modern Android APIs push developers toward:

• explicit storage names
• AndroidX libraries instead of old framework preference classes
• stronger separation between UI preferences and data persistence

So the deprecation is less about breaking behavior and more about steering code toward clearer storage choices.

Replacement Option 1: Use getSharedPreferences

If you just need a place to store flags or settings, use a named preferences file directly:

1val prefs = context.getSharedPreferences("settings", Context.MODE_PRIVATE)
2
3prefs.edit()
4    .putBoolean("notifications_enabled", true)
5    .putString("theme", "dark")
6    .apply()
7
8val enabled = prefs.getBoolean("notifications_enabled", false)
9val theme = prefs.getString("theme", "light")

This is explicit and easy to reason about. Anyone reading the code can see that the values live in a file named settings.

If you want to preserve the same file that the old default mechanism used, keep the legacy file name consistent across the migration instead of inventing a new one casually.

Replacement Option 2: Use AndroidX Preference

If your code is part of a settings screen built with preference fragments, move to AndroidX:

1import androidx.preference.PreferenceManager
2
3val prefs = PreferenceManager.getDefaultSharedPreferences(context)
4val darkMode = prefs.getBoolean("dark_mode", false)

This keeps the familiar preference-screen workflow but moves you off the deprecated framework package. In many migrations, the real fix is simply changing imports from old framework preferences to AndroidX equivalents.

Replacement Option 3: Prefer DataStore for New Code

For new development, Jetpack DataStore is often a better choice than SharedPreferences. It has a cleaner API surface and avoids some of the limitations of the older preference system.

1import android.content.Context
2import androidx.datastore.preferences.core.booleanPreferencesKey
3import androidx.datastore.preferences.core.edit
4import androidx.datastore.preferences.core.emptyPreferences
5import androidx.datastore.preferences.preferencesDataStore
6import kotlinx.coroutines.flow.catch
7import kotlinx.coroutines.flow.map
8import java.io.IOException
9
10val Context.dataStore by preferencesDataStore(name = "settings")
11
12object Keys {
13    val NOTIFICATIONS_ENABLED = booleanPreferencesKey("notifications_enabled")
14}

And writing a value:

1suspend fun setNotificationsEnabled(context: Context, enabled: Boolean) {
2    context.dataStore.edit { prefs ->
3        prefs[Keys.NOTIFICATIONS_ENABLED] = enabled
4    }
5}

DataStore is a larger migration than a one-line replacement, but it is a strong choice if you are already modernizing the storage layer.

How to Choose

Use explicit getSharedPreferences when:

• you only need a small key-value store
• you want a direct replacement with minimal refactoring
• you prefer explicit file naming

Use AndroidX Preference when:

• you are working with settings screens and preference fragments
• the deprecation comes from old framework preference imports

Use DataStore when:

• you are building new code
• you want a more modern persistence API
• a migration effort is already acceptable

Common Pitfalls

The biggest pitfall is mixing old framework android.preference imports with AndroidX preference APIs. The names look similar, but the maintenance status is different.

Another pitfall is migrating to a new preferences file name without realizing that existing user settings live in the old file. If you change storage names carelessly, the app appears to "lose" saved preferences.

Developers also replace the API call without deciding whether the use case is a UI preference screen or general application storage. Those two cases often deserve different migration paths.

Finally, do not treat DataStore as a drop-in rename. It is a different API and should be adopted deliberately rather than half-migrated.

Summary

• The deprecated call points you away from old framework preference APIs and hidden default files.
• For simple storage, use Context.getSharedPreferences(...) with an explicit file name.
• For settings UI, prefer the AndroidX preference library.
• For new persistence code, consider Jetpack DataStore.
• During migration, preserve the old file name intentionally if you need existing user settings to remain visible.