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

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.

A09d066cc67c557f9eaf4403b8f8d444?s=128

EmmettWilson

July 13, 2017
Tweet

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