SharedPreferences is the easy way to persist small values on Android, and it is not secure: it writes plain, unencrypted data, so a token or secret stored there is readable on a compromised or backed-up device. For years the answer was Jetpack Security's EncryptedSharedPreferences, but that library is now deprecated with no further releases, so it is no longer the recommendation for new apps. The underlying principle has not changed: keep secrets out of plain storage and protect them with the Keystore. Here is whether SharedPreferences is secure, what the deprecation means, and how to store sensitive data on Android now.
Short answer
SharedPreferences stores key-value data in plain, unencrypted form, so it is not a place for secrets, which can be read off a compromised or backed-up device. Jetpack Security's EncryptedSharedPreferences used to provide Keystore-backed encryption for preferences, but per Android's release notes it is deprecated as of version 1.1.0 with no further releases, and Google advises against using it in new apps. The durable approach is unchanged: keep cryptographic keys and small secrets in the Android Keystore, store any sensitive values with Keystore-backed encryption or a maintained secure-storage solution, and reserve plain SharedPreferences for non-sensitive settings. The principle is that secrets do not belong in plain preferences.
What you should know
- SharedPreferences is plain: it stores values unencrypted.
- Secrets there are exposed: readable on a compromised or backed-up device.
- EncryptedSharedPreferences is deprecated: no further releases; not for new apps.
- Use the Keystore for keys and secrets: hardware-backed and not extractable.
- Plain prefs are fine for non-sensitive settings: just not for secrets.
Is SharedPreferences secure?
No, not for sensitive data. SharedPreferences persists its data as a plain XML file in your app's data directory, with no encryption, so any value stored there, including a token, password, or API key, is readable by anyone who can access the app's files, which includes someone inspecting a rooted device or a device backup. It is a convenient store for small, non-sensitive values like a theme setting or a flag, but treating it as secure storage is the mistake. This is the Android equivalent of the iOS UserDefaults situation: a fine place for preferences, a leak for secrets. So the question is not how to make SharedPreferences itself secure, but where sensitive data should go instead, since plain preferences will always expose it.
What does the EncryptedSharedPreferences deprecation mean?
That the convenient drop-in for encrypted preferences is no longer the path forward. The table summarizes the situation.
| Aspect | Status |
|---|---|
| Plain SharedPreferences | Unencrypted; not for secrets |
| EncryptedSharedPreferences (Jetpack Security) | Deprecated at 1.1.0; no further releases |
| Google's guidance | Advises against it in new apps |
| The Keystore | The durable place for keys and secret protection |
EncryptedSharedPreferences offered Keystore-backed encryption of preference data, and it still functions for apps that use it, but its deprecation means it will not receive further updates and is not recommended for new development. That does not change the goal, encrypting sensitive data at rest, only the specific library you reach for. The Android Keystore, which holds keys that cannot be extracted, remains the foundation, and you protect sensitive values with a Keystore-backed key rather than relying on a deprecated convenience wrapper.
How do you store sensitive data on Android now?
Keep keys and small secrets in the Keystore, and encrypt sensitive values with a Keystore-backed key. For cryptographic keys and small secrets like tokens, use the Android Keystore directly, generating and using keys that stay in secure, often hardware-backed, storage and cannot be exported. For larger sensitive values you need to persist, encrypt them with a key held in the Keystore rather than writing them in plain SharedPreferences, using a current, maintained approach for the encryption rather than the deprecated library. Reserve plain SharedPreferences for genuinely non-sensitive settings, where its convenience is fine. And the strongest option for some data is not to store it on the device at all, keeping it on your backend. The principle is the same one that predates the deprecation: secrets are protected by the Keystore, not by a plain preferences file.
What to watch out for
The first trap is storing a token, password, or key in plain SharedPreferences, which exposes it; keep secrets in the Keystore. The second is reaching for EncryptedSharedPreferences in a new app, since it is deprecated and unmaintained; use a current Keystore-backed approach. The third is treating any local storage as a vault for a long-lived secret that would be safer on your backend. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and flags sensitive data stored insecurely, such as secrets in plain SharedPreferences, so you can move them to secure storage before you ship. The storage choices you make in the app.
What to take away
- SharedPreferences stores data in plain, unencrypted form, so it is not a place for tokens, passwords, or keys.
- EncryptedSharedPreferences is deprecated as of 1.1.0 with no further releases, so it is not the recommendation for new apps.
- Keep cryptographic keys and small secrets in the Android Keystore, encrypt sensitive values with a Keystore-backed key, and reserve plain SharedPreferences for non-sensitive settings.
- Use a pre-submission scan such as PTKD.com to catch secrets stored in plain SharedPreferences before you ship.
