There are 2 sorts of course of dying in Android:
- System-initiated Course of Demise
- Consumer-initiated Course of Demise
System-initiated course of dying means the method is killed by the Android working system. It could possibly be on account of useful resource constraints (not sufficient reminiscence) or just configuration adjustments (display screen rotation).
Consumer-initiated course of dying means the method is killed by the consumer. For instance, you click on the house button, and manually shut the background app.
Often as a developer, you care about solely the system-initiated course of dying since you’re required to avoid wasting the UI state. For user-initiated course of dying, you do NOT want to avoid wasting the UI states.
| System-initiated Course of Demise | Consumer-initiated Course of Demise |
| Required to avoid wasting UI states | NOT required to avoid wasting UI states |
For saving UI states expectation, you possibly can confer with the official documentation right here.
System-initiated Course of Demise
1. Use Logcat Terminate App Button
The best solution to simulate system-initiated course of dying, use the Logcat terminate app button.
- You press the house button.
- Then, use the Logcat terminate app button as proven beneath.
Wait, this “Terminate App” button has been REMOVED in Android Studio Dolphin. See the problem tracker right here.
In line with the ticket, it has been moved to Machine Monitor in Android Studio Flamingo model. I simply tried, it does NOT work! It may well NOT be used to exchange this Logcat Terminate App Button!
Drive Cease in Machine Monitor != Logcat Terminate App
In gadget monitor (Android Studio Flamingo), there are 2 choices
- Kill course of – equal to
adb shell am killcommand - Drive cease course of – equal to
adb shell am force-stopcommand
Kill course of does nothing as a result of the gadget shouldn’t be rooted.
Drive cease course of does kill the method, BUT it does NOT simulate system-initiated course of dying. It simulates user-initiated course of dying, which is strictly the identical as utilizing adb shell am force-stop command – see beneath.
So, this isn’t what we would like. Even in the event you improve to this Android Studio Flamingo model, you will not ready to make use of Machine Monitor to simulate system-initiated course of dying.
2. Set No Background Processes – Developer Choices
The one workaround that I’m conscious is ready no background processes in developer choices. To allow developer choices, you confer with the step right here.
- Go to Setting -> System -> Developer Choices (is determined by Cellphone, Developer Choices could possibly be at totally different location)
- In Apps, Background course of restrict, choose No background processes
To simulate system-initiated course of dying, after you have launched your app
- Press the House button
- Launch different app and press the House button
Your app course of shall be killed. You need to have the ability to see that in your Logcat in the event you’re utilizing Android Studio Dolphin.
PROCESS ENDED (8227) for bundle com.instance.understandlifecyclesdemo
It’s also possible to examine the method utilizing the adb shell ps in Android Studio terminal and ensure your app bundle is now not proven up within the course of record.
I simply tried this methodology and it would not appear to work on API Stage 33. The method remains to be on the background. It labored on API degree 26 at the very least (the API degree that I’ve tried sucessfully).
Consumer-initiated Course of Demise
The best solution to simulate user-initiated course of dying is doing precisely what consumer can do.
1. Manually Shut the App
- Press the House button
- Press the Sq. button
- Shut the App – press the X or CLEAR ALL
2. adb shell am force-stop
One other method is utilizing the adb command within the terminal. You possibly can run this command even your app is in foreground. It should simply kill your app instantly.
adb shell am force-stop <applicationId>
The applicationId is the one you outline within the construct.gradle app degree. Please be aware, it’s NOT your bundle identify.
android {
compileSdk 32
defaultConfig {
applicationId "com.instance.understandlifecyclesdemo"
}
}
So the total command seems like this primarily based on the above applicationId identify.
adb shell am force-stop com.instance.understandlifecyclesdemo
Much like above, you possibly can examine whether or not the method has been efficiently killed utilizing this command adb shell ps.
I additionally attempt
adb shell am kill <applicationId>. It would not work for me. Nothing occurs, no errors. I believe it requires your gadget to be rooted.
Course of Demise Restoration
Whereas taking part in with saving UI states, I discover for user-initiated course of dying restoration, Android OS does NOT restore the UI states even you save information into the bundle earlier than your app is killed. Particularly, Exercise.onRestoreInstanceState() shouldn’t be referred to as. In Exercise.onCreate(), the Bundle parameter is null.
For system-initiated course of dying restoration, Android OS restores the UI states if there are information being saved previous to course of dying. Particularly, Exercise.onRestoreInstanceState() known as. In Exercise.onCreate(), the Bundle parameter is NOT null.
That is much like SavedStateHandle in your view mannequin. For user-initiated course of dying restoration, retrieved worth from SavedStateHandle is null even you save the information previous to that. For system-initiated course of dying restoration, the retrieved worth is the beforehand saved worth.
Right here is the abstract
| System-initiated Course of Demise Restoration | Consumer-initiated Course of Demise Restoration |
onRestoreInstanceState() known as |
onRestoreInstanceState()is NOT referred to as |
Bundle is NOT null in onCreate() |
Bundle is null in onCreate() |
SavedStateHandle.get() returns beforehand saved worth |
SavedStateHandle.get() returns null |
SavedStateHandlein view mannequin is seperated from theBundlewithin the exercise. No matter being saved from theBundlecan NOT be retrieved fromSavedStateHandle.
Conclusion
If you happen to’re on Android Studio Dolphin or later, the one solution to simulate system-initiated course of dying is Set No Background Processes in Developer Choices, however one way or the other it would not work on API degree 33. So the workaround is to make use of API degree 26. It could work on different API ranges.
Supply Code
GitHub Repository: Demo_UnderstandLifecycles
