Android Application Class Life Cycle

The android application I'm working on overrides the Application class to store light state (username, gps location, etc.) in static vars. Most of this state is set in OnCreate run activity (username derived from prefs, runer). Can I rely on startup activity to initialize the Application class? Are there any cases where an application class can be recreated without creating launch activity?

The question arises because I came across the exception of a null pointer, which accessed a variable in the Application class when resuming the application after the phone slept for several hours (the application remained in the foreground before the phone slept). Is it possible that the process was killed when the phone was sleeping, and when you woke up on the phone, the application class was recreated, the top activity on the stack resumed, but the start of activity.onCreate was not started, so the Application class was not initialized?

Please note that I tried to test these scenarios by forcing the application to stop using settings / Application Management. However, I cannot recreate the problem. On the next run, the Application class is created, followed by the start of activity.onCreate.

Is it possible to assume that an instance of the application class will exist as long as the process and that when creating the application class it is equivalent to "restarting" the application, i.e. start with a new activity stack (and the first action on the stack is launch activity)?

+55
android stack android-activity lifecycle
Jan 03 2018-11-11T00:
source share
4 answers

No. Your entire application can be killed and recreated with an intact task stack; this allows the system to recover memory on devices that need it, while still presenting the complete illusion of multitasking to the end user. From the docs:

Background activity (activity that is not displayed to the user and has been suspended) is no longer critical, so the system can safely kill its process in order to return memory to other front or visible processes. If his process should be killed when the user switches to activity (making him visible on the screen again), his onCreate (Bundle) method will be called using savedInstanceState, which was previously supplied to onSaveInstanceState (Bundle) so that it can restart itself in the same state as the user last left it.

That is, the process (to which the application is attached) can be killed, but then restarted, and individual actions must have sufficient information to recreate from what they saved before they are killed, without relying on the global state established in the process by other actions .

Consider storing a permanent general state that needs to be initialized using Activity in a SharedPreference or SQLite database, or passing it to actions that need it as an add-on.

+18
Jan 03 2018-11-11T00:
source share

You can test the script on killing the process your running application.

Step 1. Open the application and click the Home button to hide it in the background.

Step 2. Call adb shell

Step 3. Enter the su command (you need to get ROOT permission to kill the process)

Step 4. ps (list all the identifiers of the current process and find them)

Step 5. kill 1234 (suppose your application is running in process 1234)

Step 6. Then go back to your device and click the start icon again. You may find that the last action in the activity stack resumes. You can also find the onRestoreInstanceState() method for activity.

+5
Nov 27 '13 at 4:41
source share

In short: do initialization in YourApplication.onCreate , not some LaunchActivity

Documents for verification:
- Processes and threads
- API Guides> Actions

Can I rely on startup activity to initialize the Application class?

Yes, if you remember that an application can last longer than activity and activity can be killed and recreated. I am not sure that the intention will be resurrected. Activity get: LAUNCH or VIEW (For the scenario when the activity was killed as too heavy, while the long-term maintenance was tied to the application)

Are there any cases where an application class can be recreated without creating launch activity?

yes, if the last visible activity was not LaunchActivity
check the life cycle of an android application and using static

Is it possible that the process was killed when the phone slept, and when the phone woke up, the application class was recreated, the top activity in the stack resumed, but the start of activity.onCreate was not started in this way the Application class was not initialized?

If there were several different running processes, A, B, C and their entire process was killed, I think that Android OS is only good at creating applications and C-activity, while A and B will be redrawn upon access, that is, upon returning to him.

Is it possible to assume that an instance of the application class will exist as long as the process

Yes

and that when creating an application class, it is equivalent to "restarting" the application, i.e. start with a new activity stack (and the first activity on the stack is the launch)?

I'm not sure when the restart will start first, and, but the last one, that is, the one that the user should see.

+2
Feb 05 '15 at 11:03
source share

"I encountered an exception from a null pointer that accessed a variable in the Application class when resuming the application

Check out this link .. http://www.developerphil.com/dont-store-data-in-the-application-object/

0
Dec 6 '16 at 10:31
source share



All Articles