The Dangers of SharedPreferences: An API allegory
summary
SharedPreferences’ default apply has no callback, so writes go to an in‑memory map and an async OS threadpool (CuedWork) and can silently fail when flash is full or flaky; commit returns a boolean so you can detect disk failures but most apps ignore it. Investigation uses Android xref to inspect SharedPreferencesImpl, AtomicFile and backup behavior. Mobile flash failures are non‑negligible across millions of devices, so teams replace SharedPreferences or add a callback to make writes observable.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:55OS API design challenges
- 10:11Key-value storage options
- 14:21SharedPreferences overview
- 21:24Why flash writes fail
- 23:32Apply vs commit behavior
- 27:11Source code deep dive
- 33:21API contract flaws
- 34:47When to use SharedPreferences
- 36:55Alternatives and fixes
related talks
34mStoring app data reliably & performantly with SimpleStore
27mSharing my preference for DataStore
43mSecurity First Android Apps
43mSecurity First Android Apps
53mA More Secure World for Android Apps
26mSafely Migrating to DataStore in Production
24mModern Android App Security: Protecting Code, Keys, and Data
27mCommon Poor Coding Patterns and How to Avoid Them