Lifecycles are what drive your Android apps, but developers often overlook edge cases that lead to lost user inputs and mysterious crashes. This talk will focus on assumptions that you might be making in your Activities and Fragments, where those assumptions fall apart, and what you should do to avoid deviously subtle lifecycle-related issues in your apps. These are details that trip up both junior and experienced developers, so regardless of your experience, this talk will bring a new perspective to how you think about lifecycles.
Watch the Talk
Thank you to everyone who tuned in live to the Droidcon Online webinar to listen to this talk! If you missed the talk or need a quick refresher on anything I went over, you can find the recording on Droidcon’s website.
Get the Cheat-Sheet
This talk goes over a lot of information very quickly. To help you remember these details, I’ve condensed most of information into a single cheat-sheet that you can use as a quick reference.
Additional Resources
Incrementer
Incrementer is an app I built to demonstrate the most common ways that Android developers are handling Activity recreations. This ranges from best practices to less recommended techniques. You can use Incrementer to see firsthand the benefits and shortcomings of each technique. The code for Incrementer and more information about how each implementation behaves is available on GitHub.
Venom
Venom is a library (not created by me) that can help you test process death scenarios. It can display a persistent notification to you or your QA team that can directly trigger process death without the need to run your app through Android Studio. You can find the library on GitHub.
Sources
For many of the topics I discussed, the information presented has come from first-hand experiences and testing with various situations. For more lower-level operating system behaviors, I have incorporated information from the Android developer documentation.
I’ve linked these sources below both to provide more credibility to this advice and to provide a starting point if you’d like to research these details in more depth.
android:configChanges Attribute
- Should only be used when you must avoid restarts caused by a configuration change
- Not recommended for most applications
- Your app must be able to restart and save its state
- This should not be used as a technique to avoid saving state against the normal lifecycle
Source: Handling Configuration Changes Guide
Handling Process Death
- Memory pressure requires the system to release memory
- Methods of freeing memory include killing processes
- The exact behavior is device-specific and very customizable
- ViewModels do not survive process death
- You should still use
SavedStateHandleoronSaveInstanceState() - ViewModels do still have a purpose because they can prevent redundant database or network calls after a configuration change
Sources: Saving States Architecture Topic, lmkd (Viking Killer) Documentation
Bundle & Intent size limitations
- Android has a theoretical limit of 1MB when sending data between processes
- On Android 7.0+, TransactionTooLargeException is thrown while starting the activity (not when creating the Intent)
- On older versions, a warning is sent to logcat
- “We recommend that you keep saved state to less than 50k of data.”
Source: Parcelables & Bundles Guide
Backup behavior
During auto backup and restore operations, the system launches the app in a restricted mode to both prevent the app from accessing files that could cause conflicts and let the app execute callback methods in its BackupAgent. In this restricted mode, the app’s main activity is not automatically launched, its Content Providers are not initialized, and the base-class Application is instantiated instead of any subclass declared in the app’s manifest.
Sources: Testing Backup Guide, BackupAgent Guide