Why avoid plain SharedPreferences for secrets and what to use?

WHAT THIS TESTS: This question checks whether you understand the difference between app-private storage and encrypted-at-rest storage on Android. Many candidates know that SharedPreferences is convenient for key-value pairs, but the interviewer wants to see if you recognize that convenience does not equal security, and whether you know the modern Jetpack library designed for this exact problem.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, explain the threat model: plain SharedPreferences writes to an XML file inside the app's private directory. While unrooted devices enforce file permissions, that data is plaintext on disk, so it is readable on rooted devices, via adb backup on older Android versions, or if the device is compromised. Second, mention the Android Keystore system, which generates cryptographic keys that never leave secure hardware when hardware backing is available. Third, name EncryptedSharedPreferences from the Jetpack Security library as the correct API; it uses AES256 to encrypt both keys and values, and it stores the master key inside the Android Keystore. Fourth, add nuance: client-side storage is never fully safe, so the best defense is to avoid storing long-lived secrets on the device at all, using short-lived tokens or server-side proxies instead.

COMMON WRONG ANSWERS: Red flags include claiming that MODE_PRIVATE makes the data safe, suggesting code obfuscation or ProGuard to hide a hardcoded key, recommending hiding the value in NDK or BuildConfig, or confusing EncryptedSharedPreferences with SQLCipher. Another red flag is ignoring backup risks; even app-private files can be extracted via full-device backups if not excluded.

LIKELY FOLLOW-UPS: The interviewer may ask how EncryptedSharedPreferences handles key rotation, what happens when a user clears the app data or uninstalls, how to handle devices without hardware-backed Keystore, or whether you should store an OAuth refresh token locally. They might also ask you to compare EncryptedSharedPreferences with the DataStore library and explain if DataStore has a built-in encrypted equivalent.

ONE CONCRETE EXAMPLE: Suppose your app needs a third-party API key. Instead of putting it in default SharedPreferences, you create a MasterKey in the Android Keystore with setUserAuthenticationRequired(false) for background access, then build an EncryptedSharedPreferences instance with AES256_SIV for keys and AES256_GCM for values. You store the API key there. If an attacker pulls the app's XML files via rooted access, they see ciphertext only; the decryption key remains inside the Keystore and is not extractable.