I have an activity that needs to turn on the screen when it is started (just in case the screen was off). So in my onCreate, I have:
getWindow().addFlags(WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD
|WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON
|WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON
|WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED);
Using this straightforward combination, I am able to cause my activity to display whenever it is started from my background service (yes, this is a legitimate case).
The problem, however, is that there is a very strange lifecycle behavior when I start up my activity in such a case. Using extensive logging, I was able to figure out that the following 7-step process happens immediately after the activity is started:
onCreate
onStart
onResume
onPause
onStop
onStart
onResume
See that? For a simple activity start, onStart is called twice. And more importantly, onStop is mysteriously called, even though the activity was just started - and nothing happened that would cause it to stop.
I have tested this in many different scenarios and it appears that this strange behavior only happens when the screen is off and the activity is launched after it was destroyed. If the screen is on, or if the activity was stopped [but not yet destroyed] the activity launches normally, and onStart is only called once.
Bottom line: it appears that when my activity is launched and the screen is forced on, Android starts the activity, then stops it, and then starts it again for no apparent reason.
So: why is this happening? And is there anything I can do to workaround this (so that onStop isn't called until there is a legitimate cause for it to be)?
Notes:
The activity in question is using the singleTask launchmode
I have tried disabling the keyguard / lock but it has no effect
I am witnessing this behavior on a Samsung Galaxy Tab 10.1 running Android 3.2. I have not tested whether this applies to anything else...
I had a similar problem here:
Activity Lifecycle X Power Button X Lock Screen
The problem was that as my activity was forced landscape, when I turned on the screen it showed the lock screen in portrait and it was causing a configuration change and hence destroying the current activity.
The solution was to add a android:configChanges="orientation" on the Activity in my AndroidManifest.xml.
As suggested by #cyberhuman, the answer to this question OnPause and OnStop() called immediately after starting activity pointed me to the right direction.
My issue with the activity completing a full 'dummy' lifecycle before being actually displayed to the user was that my attempt to play the ringtone when the activity became visible was directly muted by the additional, subsequent "onStop()", and using flags to make the activity behave properly when launched when screen is off/when screen is locked/when screen is on/when activity is running in the background was not possible.
I finally solved my issue by overriding the onWindowFocusChanged(boolean hasFocus) method and launching the ringtone from there. Putting it here in case somebody has the same issue.
You could check for the situation in onStart, set a static or global variable, and then check the variable in onStop to override the standard behavior.
Related
I have been using log messages in the activity lifecycle functions to monitor the behaviour of applications's activity, and some time ago i discovered a weird unintended recreation of the activity. This behaviour is specific, because it occurs only, if activity at the moment of screen turning of is LANDSCAPE orientation.
The steps of this behaviour are following:
while in LANDSCAPE orientation, the screen turns off, calling the onPause() and onStop() functions (probably onDestroy(), i am not monitoring it)
after few seconds, while the screen is still off, onCreate() of this activity is called, but with PORTRAIT orientation property
this cycle goes to onResume(), which is immediately followed by onPause() function (onStop() is not called)
If the screen turns off while being in portrait orientation, the activity lifecycle follows the proper path, with no debug messages after onStop is called.
Since the activity class in question is over 1800 lines long, for now i will avoid posting it here.
I am aware, that the description of my problem is generic,but hope, that maybe someone else has experienced similar problem and can maybe point towards the possible source of the problem.
Is it Possible to see whats happening in onPause of an Android Activity?
I want to know if the app is
closing, going to background or screen is switched off
or
activity is changed or Sub-Activity is closed
is there a way to get this information?
You can see what it happening in the pause by looking at what is written in onPause().
I think you meant to ask, "What happens to the activity after onPause?"
To put it another way, you can't tell what is happening to the activity in onPause because the things that happen to the activity are taken care of in other methods. You'll have to look at these other methods at runtime.
Put a breakpoint in onRestart(), if this is hit, you can be sure that your activity was never destroyed.
Put a breakpoint in onDestroy(), if the activity is being destroyed, this breakpoint will be hit.
I've got an app that is complete, apart from the lifecycle that, guiltily, I left as last.
Things seem to work good in all cases, but one:
When I pause the app by pressing the power button, it correctly pauses and restarts when resuming.
When I rotate the screen it correctly resizes.
When I pause AND THEN rotate the screen, its behaviour is different and the app resets.
Now, obviously it's a problem of my internal code, but to help me in the debugging, I would like to understand what's the difference between the three lifecycles. Or better, if the THIRD example is some how different from the first two.
With debugging I saw that all of three do this (I resemble by mind, I hope to be right):
onSaveInstanceState()
onPause()
onStop()
onStart()
onResume()
Is it right? Or do I miss some lifecycle steps in the third example, above?
Thank you.
Please specify what you mean by the app resets.
When you press the power button, most likely your app stops. That's why you see onStart() being called after stopping (not: pausing) your app.
Given that, is it really the case that the third scenario you describe is a combination of the first two? In other words, how do you pause your app in the third scenario?
Update Regarding your comment: There is a difference between your Activity being stopped and your Activity being destroyed.
Rotation is a configuration change. In this scenario, your Activity is going to be destroyed and re-created. You can handle this case separately if you must (it depends) through the onRetainNonConfigurationInstance() callback and the getLastNonConfigurationInstance() method. Android will call onPause(), onStop(), onRetainNonConfigurationInstance() and onDestroy() in this order, and then continue with onCreate() etc and it will not handle any events in the meantime so that they won't get lost.
Most likely, some of your code is located in the wrong callback, such that in the third scenario, something does not get initialized/attached/... This is really hard to tell without the code and the exception (if it is an exception).
I suggest you proceed as follows.
Complete your understanding of the lifecycle and be precise (creation, start, restart, resume, pause, stop, destroy)
Complete your code to override the other lifecycle callbacks as well with log messages (don't forget to call the super class' callback) and analyze pause, stop, rotation and combinations
Identify the point of the crash
Analyze the life cycle of the objects involvedd in the crash in conjunction with the Activity lifecycle
Or you can post some code and the exception here, of course.
Update 2 I have made a test on an AVD. I have observed the following:
When the AVD is in landscape orientation, and I press the power button, my app receives a configuration change to portrait orientation (presumably because the portrait-orientation-only lock screen takes over). Pressing power again and unlocking the AVD, the app receives a configuration change again back to landscape orientation.
While not solving your issue, it goes to show that code must be carefully placed in the respective callbacks, because in the case above, while being re-created, the Activity will still not be shown.
Drop me a comment if you update your question.
Hi you can check the documentation regarding Managing the Activity life cycles in android .
When orientation changes Activity is re-created.
Add android:configChanges="keyboardHidden|orientation" to your activity in the manifest.
I'm developing a videogame in Android. For it, I'm using a game loop and all the typical stuff it envolves. I have a doubt about the states of the activity in android.
I need an activity to create the GLSurfaceView and so, the problem is the activity, when it finishes its onCreate method, continues this way: onCreate -> onResume -> onStart -> onStop.
I guess it goes throught those states because the activity doesn't have anything to do and it's the loop who is working. But I have a problem with this behaviour:
How can I know when the user "minimize" or put the device in a stand by state? Again, the methods onStop -> onResume -> onStart will trigger, but, how can I difference this time with the first?
I need to stop the loop when the user switch the device to stand by, but not when it starts the first time.
I hope I have explained well. Thanks.
If onStop is running immediately after onStart, something is wrong. The activity will only be placed in the Stopped state only when it is no longer visible to the user. Unless maybe your code immediately creates another activity that displaces it as the foreground activity, I guess, but if the activity is visible on the screen, onStop shouldn't be firing. Some code would be helpful in diagnosing that.
onPause occurs when the activity is still visible but there is another activity that is being resumed. If you're trying to save game data or something when the user backs out of the app, gets a phone call, turns off the screen, etc., I'd use onPause, because onStop is not guaranteed to be called and you run the risk in certain situations of the system killing your activity before you can do what you need to do.
For more info on activity lifecycle, see the Activities guide.
I am trying to handle problems that occur in my application when the phone is plugged into certain types of chargers and put into "Car Mode" or "Driving Mode".
In the running application, onDestroy() is called and immediately followed by onCreate(), and the application starts again normally. However, subsequent calls to update UI elements (in the newly created main Activity) now have no effect, and it looks like I've lost scope on my layout.
RelativeLayout splash = (RelativeLayout) findViewById(R.id.splash);
splash.setVisibility(View.VISIBLE);
What could be ocurring onDestroy() that I'm not accounting for? I don't do much cleanup onDestroy because I didn't think I needed to.
The Activity has been detached from the UI by the time onDestroy() is called so having UI calls to it doesn't make any sense. If you need the splash to be shown, set it to View.VISIBLE in onCreate(), onResume(), or maybe onPause(). I'm not entirely sure if onPause() would act any different.
When the phone rotates the activity is destroyed and recreated. Plugging into a car charger usually forces the phone to landscape mode, thus rotating it (from portrait, most likely) and calling onDestroy. There is a way to prevent this behavior with some activity flags -- but Google advises against it.
We need to see some more code for this Activity to figure out what's going on.
Also, as DeeV points out, the activity is long gone by the time onDestroy gets called, so it might not be the right place to be doing whatever it is that you're doing -- but we need more code to be sure.
As a sidenote, sliding the keyboard up (on phone's that have slideout keyboards) will produce the same effect.