I have been playing with the states all day trying to figure out why, when I press the power button to bring up the lock screen, my app loses focus and calls it's onStop() (as it should) but then it calls the onStart() again before hte screen goes off. This is causing me a problem because some sounds in my app (and presumably other stuff) start playing again while the lockscreen is active.
how can I make sure it is properly backgrounded and stopped when the lockscreen is active?
I faced this exact problem not long ago. In AndroidManifest.xml, make sure you have this:
android:configChanges="keyboardHidden|orientation"
This will prevent your activity from being restarted on runtime 'configuration changes'. See handling the configuration change yourself. That way your app will listen for events that would cause a restart - like orientation and keyboard visibility changes -- and handle them within your Activity.
There is also a very similar question on SO here:
Activity restart on rotation Android
Related
I've an app that should always start from the initial activity when its icon on home screen is pressed.
I've managed to make this work in every situation by finishing the current activities when the application was going to be exited.
But there's a point in the app where this is not possible unless I ruin user experience a lot, which is if the user opens an ad offered by the app and then either goes to home screen (via home button for example) or press back button to keep on using the app.
In both cases the following events are fired: onAdLeftApplication-> onAdClosed-> on Resume (although as how I understand documentation onAdClosed shouldn't fire in the case of opening the browser, but well... it happens).
With this I find no way to differentiate between the 2 cases, although there might be an event, that would allow to differentiate them-
Think the easiest way to solve this problem is to always force that if the icon is pressed what is fired is never onResume, always onCreate, this way I don't have to worry about the app not starting from beginning for whatever, by default it's going to do that.
But maybe what I'm mentioning is not possible anyway, so maybe some event like the one I'm mentioning might help with this problem. I'll happily listen to any recomendation about that.
What code is required to keep an app live when it is "pushed" to the background?
My app USED to behave this way. If a user multitasked or hit home, my app would minimise, and they could later return to it. Now, and I have no idea what change I made to cause this, my app is closed by the Android system whenever it is minimised.
I have checked memory, and it doesn't seem to be an issue. My app is actually using LESS memory now than previously.
When the app is minimised and closed, OnPause and OnStop are being called for the current activity, but onSaveInstanceState is not.
SOLVED: It was caused by android:noHistory="true" in my manafest
My application is written with React Native with Redux. It appears as though my MainActivity is destroyed on back button press. When the app is re-opened from the Task Manager or re-launched from the app menu, the app has lost its previous state, which I would like to avoid or work around.
I have read solutions around overriding the onBackButton() method with moveTaskToBack(true), etc. but I'm not convinced it's the right solution.
Is there a clean / correct way to make sure that my app is restarted with the most recent application state? Perhaps this involves persisting the app state somewhere and restoring it when the application comes into the foreground.
The easiest way around this was to set the launchMode of MainActivity to singleTask in AndroidManifest.xml. Read more about launch modes in the Android docs.
I have an application that has many screens. Is it possible to detect if the screen NOT belonging to the application (not defined in my android manifest) comes into visibility?
onPause() will be called when an Activity loses focus (to any screen, be it your own or someone elses). When your user launches another activity from your app, you can set a flag when they do so and check for it in onPause(). If the flag isn't there, you can assume another app has gained focus.
If it's something like go back to login screen, try to read about android:finishOnTaskLaunch
http://developer.android.com/guide/topics/manifest/activity-element.html#finish
It solved my similiar problem ;-)
I am running into a critical conflict of sorts. My app is a remote service which essentially starts an activity when the screen goes to sleep. How it does this is very simple via screen off broadcast receiver and then an explicit intent to start the activity as a new task. The activity is basically in charge of responding to key events and displaying some simple text.
Thanks to a few window flags added in 2.0, activities can do this. They can be created in a way that either puts them on top of the lockscreen, or completely dismiss the lockscreen. This way they basically have focus without the lockscreen having to be dismissed by user. The alarm clock in 2.0 uses the flags to wake up the device and show the alarm dialog. I use them to place my activity when the screen sleeps so the user sees a custom wakeup lockscreen. The reason we create it at screen off is to get rid of lag the user experiences at wakeup involving first seeing the lockscreen, then seeing the activity appear. Also doing it immediately at sleep allows it to have focus so it can handle key events effectively.
The process works perfectly except in certain apps. So far, it seems the bug is consistent while browser (and even dolphin browser) as well as the facebook app are running. The bug never happens in GTalk or Launcher. It is rare but can still be duplicated in the messaging app every so often. I can't figure out why my activity doesn't get created at sleep while these apps are active. My remote service still gets the screen off broadcast and does the startActivity for the explicit intent, and that's all I get in the log. My onCreate is not being called. Instead it gets called when we wake the screen up again.
I have tried, as a control, to hold the partial wakelock starting when my remote service gets created, and the issue persists. So I don't believe it is a problem that the CPU has gone to sleep. Since only these particular apps cause the issue to duplicate, I can't imagine why the activity start fails. What could those apps be doing to interfere with another app's ability to get created? I use singleInstance as the launch mode so that I can ensure that the activity will never be able to be recalled by user process. I want it to go away when user unlocks and it is working fine like this, as long as it is able to be created. The singleInstance ensures I can have the same lockscreen handle an intent to do something specific based on user actions that the remote service monitors.
my source code can be viewed on my project page. http://code.google.com/p/mylockforandroid/source/browse/#svn/trunk/myLock/src/i4nc4mp/myLock
the issue happens to both my CustomLockService and NoLockService variations. These two services will start Lockscreen or ShowWhenLockedActivity and the bug is witnessed. The build illustrating the bug's end result-- user has to try to unlock 3 times due to the bug because on wakeup when the oncreate finally succeeds, user is seeing the activity when normally it would have auto-dismissed thanks to key event logic that also isn't seeming to happen due to the delayed onCreate, so they have to send it to sleep again. Now that the activity is properly done being started, and screen is asleep, the expected functionality happens at next wakeup-- can be downloaded also from the downloads tab.
This seems like an extremely irrational thing to be caused only by specific apps. I am quite baffled and out of ideas for a solution unless I've made some critical mistake in my activity definitions.
The answer is actually a bug in android that has been in review for a while. It has to do with the home key. For some reason start activity calls as new tasks are getting stopped after the home key has recently been launched. I never noticed the connection during the testing of this. The bug was not consistent and the factor of consistency was whether home button had been used during the wake in question
Here is the bug report: http://code.google.com/p/android/issues/detail?id=4536