Why avoid plain SharedPreferences for secrets and what to use?
Tests data-at-rest security awareness. A strong answer notes plain SharedPreferences writes unencrypted XML that rooted users or backups expose, then names EncryptedSharedPreferences with Android Keystore.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
Which approach best protects a locally-stored API key on Android from extraction on a rooted device?
- a.Hide the value in native code using the NDK instead of XML storage
- b.Obfuscate the key in BuildConfig and rely on ProGuard to hide its usage
- c.Store the key in EncryptedSharedPreferences with the master key in Android KeystoreCorrect
- d.Use SharedPreferences with MODE_PRIVATE so the XML is inaccessible to other apps
Why? this is the answer
EncryptedSharedPreferences encrypts data at rest using AES256 and binds the master key to the Android Keystore, so even rooted access only yields ciphertext. MODE_PRIVATE only blocks other apps but leaves plaintext readable on rooted devices or backups.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles