360|AnDev - Android Zombies: How To Not Get Bit

Android process death and how to gracefully recover from it is not often discussed and information about it is convoluted and hard to find. This talk will cover process death, how it is similar to and different from configuration change, what it does to our application state, how we can cause it in order to test our apps, and common resolution strategies we can take to ensure our users have a seamless experience when it inevitably happens.

Transcript

1. ANDROID ZOMBIES: Emmett Wilson / Software Engineer How to Not Get Bit
2. • What is a “Zombie Android App”? • How are zombie applications created? • Symptoms of being bit • How to easily test apps to ensure they do not turn undead. • How to avoid being bit? What Will We Cover?
3. • Def: An android application or process that has been terminated by the operating system, but is reanimated in its last known state. Oftentimes it has no knowledge that it was destroyed and is a shell of its former self. What Is an Android Zombie?
4. What this is not • Configuration change • “Don’t Keep Activities” • Swipe app away from recents • Back entirely out of app via back button
5. How are Android Zombies Created?
6. How are Android Zombies Created? • System destroys process. Low memory? • Application crashes and is recreated on previous activity in task.
7. • Application crashes on fresh launch from launcher icon or recent apps list • On fresh launch, application lands on a screen with partially populated data • Crash and crash again and again and again… • Application crashes immediately on first user interaction • Application saves junk data and is completely unuseable until user clears data from settings. Symptoms of Being Bit
8. • Global In Memory Data ◦ Static Singletons ◦ Items stored in application instance ◦ Injectable memory data models • Retained Fragments • Static Member Variables in Activities and Fragments • Activities and Fragments that assume and rely on previous in memory state How to Know Danger Is Nearby
9. How Do We Test Our Apps For Zombie Resistance?
10. 1. Background our app and open another resource intensive app How Do We Test Our App?
11. Open a Resource Intensive App
12. Open a Resource Intensive App PROS • Most realistic CONS • Non Deterministic - Hard to ensure application is killed • Many new devices have ample memory • Android Community and operating system is getting much better at managing resources
13. 1. Background our app and open another resource intensive app 2. The Samsung font style trick How Do We Test Our App?
14. The Samsung Font Style Trick
15. Samsung Font Style Trick PROS • Deterministic - Shuts Down All Applications CONS • Slow Process • Only Works on Samsung Devices • Kills all applications • “Choco Cooky”, “Cool Jazz”, and “Rosemary”
16. 1. Background app and open another resource intensive app 2. The Samsung font style trick 3. Use Developer options to set background process limit to “No Background Processes” How Do We Test Our App?
17. Background Process Limit
18. Background Process Limit PROS • Deterministic - shuts down all applications • Works on all devices CONS • “I accidently left it on and spent 3 hours debugging” • Destroys all background processes; not just your app
19. 1. Background app and open another resource intensive app 2. The Samsung font style trick 3. Use Developer options to set background process limit to “No Background Processes” 4. Use a utility to terminate target application How Do We Test Our App?
20. App Terminator Github https://github.com/EmmettWilson/AppTerminat or Google Play https://play.google.com/store/apps/details?id=c om.mathematicalfunk.appterminator Utility to Terminate Target Application
21. Utility to Terminate Target Application
22. Utility to Terminate Target Application PROS • Deterministic • Works on all devices • Targetedly terminates apps on demand • Fast feedback CONS • Most likely made by an evil nefarious developer
23. Anti Zombie Patterns and Resolution Strategies
24. A Grab Bag of Anti Zombie Strategies 1. Recover from process death seamlessly and take user to last known state via disk persistence
25. Recover Seamlessly Via Disk Persistence Goal: All application state is persisted and accessed from on disk. Application recreation happens seamlessly and user never notices the process was killed. Special Considerations: Requires state and models to be saved on disk. On some apps requirements may prohibit this type of solution.
26. Recover Seamlessly Via Disk Persistence Option 1a Leverage Intents, Saved Instance State, and Bundles to save all models PROS • Android persists data for you • Also sets up gracefully handling configuration change CONS • Parcelable generation and maintenance • TransactionTooLargeException limits amount of data that can be passed • Network responses while backgrounded may be lost.
27. Recover Seamlessly Via Disk Persistence Option 1b Leverage Intents, Saved Instance State, and Bundles to save enough to fetch required data PROS • Android persists data for you • Also sets up gracefully handling configuration change • Mitigates risk of TransactionTooLargeExceptions CONS • Networking on fresh start limits offline and app entry experience
28. Recover Seamlessly Via Disk Persistence Option 2 Leverage SQLite Databases PROS • Robust • Can persist much more data than via intents and bundles • Local caching of server objects • Can leverage SD card storage • Robust Upgrade pathways as models change • Can cache and replay network responses that finish while app is backgrounded CONS • Can be prohibitively expensive for first iterations • Upgrade pathways and testing
29. Recover Seamlessly Via Disk Persistence Option 3 Flat Files Written to Internal Storage PROS • Robust • Can persist much more data than via intents and bundles • Local caching of server objects • Can leverage SD card storage • Allows for quick iteration early on until data models stabilize • Can cache and replay network responses while app is backgrounded CONS • Possibility of writing corrupted models • Performance hit • Upgrade pathways are limited
30. A Grab Bag of Anti Zombie Strategies 1. Recover from process death seamlessly and take user to last known state via disk persistence 2. Sense a fresh application start and navigate user to a safe place
31. Escape To a Safe Place Goal: Sense a fresh application start by checking in memory flag (Static instance, Member Variable of Application Class, etc), and navigate user to a fresh start such as splash screen, landing page, dashboard, timeline, etc. Special Considerations: In many instances this is the experience users expect when launching an app via the launcher. This risks degrading UX for users on budget devices that are resource starved.
32. A Grab Bag of Anti Zombie Strategies 1. Recover from process death seamlessly and take user to last known state via disk persistence 2. Sense a fresh application start and navigate user to a safe place 3. A Hybrid approach: Escape to a safe place and triage from there
33. Once Safe Stage an Attack Goal: Save session based data on disk, otherwise persist just enough to restore to the current state from the server. On fresh application start escape to a safe place. Then triage, load data, and navigate user back into app. Special Considerations: Can be much less work that full recovery via disk persistence, but offers benefit of a near seamless re-entry. If something terrible happens user has a clean slate within the app.
34. A Grab Bag of Anti Zombie Strategies 1. Recover from process death seamlessly and take user to last known state via disk persistence 2. Sense a fresh application start and navigate user to a safe place 3. A Hybrid approach: Escape to a safe place and triage from there 4. Anything else that makes sense for your specific use case and users
35. Thanks for coming! Feedback is always appreciated! @MathematicalFnk
36. Questions and Discussion