Why EncryptedSharedPreferences Is Deprecated and What to Use Instead on Android

Why EncryptedSharedPreferences Is Deprecated

Google is moving away from the traditional SharedPreferences API because it can cause data inconsistency in multithreaded scenarios and is inefficient for large data sets. The new DataStore API addresses these issues and is now the preferred key‑value storage solution.

In addition, newer security libraries such as App Security (Crypto 1.1.0+) provide more flexible encryption primitives, allowing developers to choose encryption methods that fit their specific security requirements.

Although ESP is convenient, it has several drawbacks:

It relies heavily on the legacy SharedPreferences API, limiting its ability to leverage modern Android features.

Its encryption customization is limited, making deep customisation difficult.

It lacks proper support for coroutines and Flow, which are essential for modern asynchronous Android code.

What Should Replace It?

1. Jetpack DataStore (Strongly Recommended)

Google now recommends using DataStore instead of SharedPreferences. DataStore is built for modern Android apps and offers:

Kotlin coroutines + Flow for concise and efficient asynchronous data handling.

Type safety via Proto DataStore, catching type errors at compile time.

Asynchronous, non‑blocking operations that keep the UI thread responsive.

Note that DataStore itself is not encrypted; sensitive data must be encrypted before being written.

2. Tink (Google’s Encryption Library)

Tink is a cross‑platform production‑ready encryption library that provides:

Support for AES‑GCM, AES‑SIV and other algorithms, allowing flexible security choices.

Built‑in key rotation to simplify key management.

Seamless integration with Android KeyStore for secure key storage.

Example of using Tink together with DataStore:

val keysetHandle = AndroidKeysetManager.Builder()
    .withSharedPref(context, "master_keyset", "my_pref")
    .withKeyTemplate(AesGcmKeyManager.aes256GcmTemplate())
    .withMasterKeyUri("android-keystore://master_key")
    .build()
    .keysetHandle

val aead = keysetHandle.getPrimitive(Aead::class.java)
val ciphertext = aead.encrypt("my_secret".toByteArray(), null)
val plaintext = aead.decrypt(ciphertext, null)

This code shows how to encrypt data with Tink and then store the ciphertext in DataStore.

3. Encrypted DataStore (Custom Implementation)

Since there is no official EncryptedDataStore, you can create your own wrapper that combines encryption (via Tink or another crypto library) with PreferencesDataStore. A typical implementation looks like this:

class SecureStorage(private val context: Context) {
    private val Context.dataStore by preferencesDataStore("secure_store")
    private val KEY_ACCESS_TOKEN = stringPreferencesKey("access_token")

    suspend fun saveToken(token: String) {
        context.dataStore.edit { prefs ->
            prefs[KEY_ACCESS_TOKEN] = encrypt(token)
        }
    }

    // Decrypt when reading
    val accessToken: Flow<String?> = context.dataStore.data
        .map { prefs -> prefs[KEY_ACCESS_TOKEN]?.let { decrypt(it) } }
}

This wrapper provides a secure, coroutine‑friendly way to store and retrieve sensitive values.

Which Solution Should You Choose?

For new apps: use DataStore together with Tink or another encryption tool for a clean, performant, and secure foundation.

For existing apps that already use ESP: the library still works, but migrating to DataStore + encryption is advisable to stay future‑proof.

For enterprise or financial apps: adopt Tink as the encryption layer because it is maintained by Google security engineers and offers strong guarantees.

Conclusion

EncryptedSharedPreferences served developers well, but the future of secure local storage on Android lies in combining DataStore for persistence, Tink (or Security Crypto) for encryption, and Android Keystore for protecting keys. This modern, coroutine‑compatible stack receives long‑term Google support and ensures data remains safe over time.