ANDROID ZOMBIES: Emmett Wilson / Software Engineer How to Not Get Bit

• 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?

• 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?

What this is not • Configuration change • “Don’t Keep Activities” • Swipe app away from recents • Back entirely out of app via back button

How are Android Zombies Created?

How are Android Zombies Created? ● System destroys process. Low memory? ● Application crashes and is recreated on previous activity in task.

• 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

• 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

How Do We Test Our Apps For Zombie Resistance?

1. Background our app and open another resource intensive app How Do We Test Our App?

Open a Resource Intensive App

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

1. Background our app and open another resource intensive app 2. The Samsung font style trick How Do We Test Our App?

The Samsung Font Style Trick

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”

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?

Background Process Limit

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

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?

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

Utility to Terminate Target Application

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

Anti Zombie Patterns and Resolution Strategies

A Grab Bag of Anti Zombie Strategies 1. Recover from process death seamlessly and take user to last known state via disk persistence

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.

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.

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

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

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

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

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.

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

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.

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

Thanks for coming! Feedback is always appreciated! @MathematicalFnk

Questions and Discussion