Devfest.MN 2017: 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 often hard to find. I talked about process death, 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. • Native Android developer for 2 years • Work at WWT - Asynchrony Labs • Found programming via spurned love of pure mathematics • Professionally released 4 production apps • Like to race bikes in small circles very fast About Me
3. • What is a “Zombie Android App”? • How are zombie applications created? • Symptoms of being bit • How to easily test our apps to ensure they do not turn undead. • How do we avoid being bit? What Will We Cover?
4. • 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?
5. How are Android Zombies Created?
6. How are Android Zombies Created? • System closes app due to low memory • Application crashes and is recreated on previous activity
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 Data Models ◦ Static Singletons ◦ Items stored in application instance ◦ Injectable memory data models • Retained Fragments • Static Member Variables in Activities and Fragments • Activities and Fragments 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. Use a developer utility to force low memory conditions How Do We Test Our App?
14. Android Developer Toolbelt Github https://github.com/T-Spoon/Android-Developer- Toolbelt Google Play https://play.google.com/store/apps/details?id=c om.tspoon.androidtoolbelt Use a Utility To Force Low Memory
15. Use a Utility to Force Low Memory PROS • Simulated Realism • Somewhat repeatable results CONS • Non Deterministic - Hard to ensure application is killed • Flagship devices are often good enough at reclaiming memory that applications are not destroyed
16. 1. Background our app and open another resource intensive app 2. Use a developer utility to force low memory conditions 3. The Samsung font style trick How Do We Test Our App?
17. The Samsung Font Style Trick
18. 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”
19. 1. Background app and open another resource intensive app 2. Use a developer utility to force low memory conditions 3. The Samsung font style trick 4. Use Developer options to set background process limit to “No Background Processes” How Do We Test Our App?
20. Background Process Limit
21. 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
22. 1. Background app and open another resource intensive app 2. Use a developer utility to force low memory conditions 3. The Samsung font style trick 4. Use Developer options to set background process limit to “No Background Processes” 5. Use a utility to targetedly terminate target application How Do We Test Our App?
23. 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
24. Utility to Terminate Target Application
25. Utility to Terminate Target Application PROS • Deterministic • Works on all devices • Targetedly terminates apps on demand • Faster process CONS • Most likely made by an evil nefarious developer
26. Anti Zombie Patterns and Resolution Strategies
27. A Grab Bag of Anti Zombie Strategies 1. Recover from process death seamlessly and take user to last known state via disk persistence
28. 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.
29. 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 • Ui performance impact on transitions • TransactionTooLargeException limits amount of data that can be passed
30. 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 good offline experience
31. 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 CONS • Can be prohibitively expensive for first iterations • Upgrade pathways and testing
32. Recover Seamlessly Via Disk Persistence Option 3 Flat Json 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 gel CONS • Possibility of writing corrupted models • Performance hit • Upgrade pathways are limited
33. 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
34. 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 they probably expect when launching an app via the launcher. This risks degrading UX for users on budget devices that are resource starved.
35. 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
36. 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.
37. 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
38. Questions and Discussion
39. Thanks for coming! Feedback is always appreciated! @MathematicalFnk