Difference between getDefaultSharedPreferences and getSharedPreferences
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Android gives you two common ways to open SharedPreferences, and they solve slightly different problems. PreferenceManager.getDefaultSharedPreferences(context) opens one conventional app-wide preferences file, while context.getSharedPreferences(name, mode) lets you choose the file name yourself.
What getDefaultSharedPreferences() is for
getDefaultSharedPreferences() is the convenience option. It returns the default preferences file that Android and older preference-screen APIs commonly expect.
In Kotlin, that looks like this:
The advantage is consistency. If your app has one central set of settings, every screen can read and write the same file without repeating a file name constant everywhere.
This method is especially common in older Android examples that use framework preference screens, because those APIs often assume the default preferences file.
What getSharedPreferences(name, mode) is for
getSharedPreferences() is the explicit version. You provide the file name, so you can split data into multiple files when that makes the design clearer.
This is useful if you want to separate user-visible settings from other small persistent data such as cached metadata, onboarding state, or feature flags.
On modern Android, the mode is almost always Context.MODE_PRIVATE.
The main difference is which file gets opened
After you obtain the SharedPreferences object, the API is the same either way. You still call getString, getBoolean, edit, apply, and commit.
So the important difference is not the read and write syntax. It is the underlying file choice:
- '
getDefaultSharedPreferences()means "use the standard default preferences file"' - '
getSharedPreferences(name, mode)means "use this exact named file"'
That distinction matters the moment you have more than one preferences file in the app.
Example: default settings versus feature-specific storage
Here is a concrete comparison:
The first value goes into the app's default settings file. The second value goes into a different named file. If you write with one and read with the other, the key will seem to "disappear" because you are looking in a different store.
When to use each approach
Use getDefaultSharedPreferences() when the app has one obvious bucket of shared settings and you want a simple convention.
Use getSharedPreferences(name, mode) when:
- you want multiple files with clear boundaries
- you need a stable custom name for migration or debugging
- you want to keep non-settings data out of the main settings store
The default API is about convenience. The named API is about explicit control.
A modern note about DataStore
For new Android projects, Jetpack DataStore is often recommended over SharedPreferences because it handles asynchronous I/O more cleanly and offers better structure. That does not change the answer here, but it matters if you are designing fresh persistence code rather than maintaining existing app settings logic.
Common Pitfalls
- Assuming
getDefaultSharedPreferences()andgetSharedPreferences()refer to the same file. - Writing a key to the default file and trying to read it from a custom-named file.
- Creating many preference files without a clear reason, which makes app state harder to track.
- Storing large or relational data in
SharedPreferencesinstead of a database or file. - Ignoring DataStore when starting new Android persistence work.
Summary
- '
getDefaultSharedPreferences()opens the app's conventional default preferences file.' - '
getSharedPreferences(name, mode)opens a specific named preferences file.' - Both return the same
SharedPreferencesinterface once the file is opened. - The real difference is file selection and organization, not the read or write methods.
- Use the default file for app-wide settings and named files when you need explicit separation.

