As the title says, I'm looking for the cause of ActivityThread: Schedule relaunch activity: foo.bar.MyActivity in my application log. I'm seeing this entry after MyActivity.onResume() but I'm not overriding that method and I'm not restarting the activity myself. I found this question related to the log entry but I'm not issuing any network requests or doing anything complicated in onCreate(). There are no configuration changes in the log, either, that might explain the activity being restarted.
I can't reproduce this on my devices and I only know of one instance of it happening so it seems to be something that happens very sporadically. In short, does anyone know why Android will sometimes restart my activity with the message in the title?
This might be happening if the app is in the background for awhile, Android kills off the OS process hosting the app, and then the user returns to the app (selects it from the list of recent tasks, or just clicks on the app icon on the HOME screen again). Android will then create a new OS process for the app and relaunch the Activity that was on the top of the Activity stack.
Related
I am trying to understand some behavior of the android apps, now that I faced the following issue :
After device restart my app launches by default, but with one issue : If I put it in the background, and I try to resume it from HOME launcher, it restarts from splash
Weird is that this happens ONLY & ONLY after the device it was installed on, is restarted ! To break this behavior I have to kill the app and launch it again. From that point it works as expected -> If in background, using launcher icon restore the app state
Looking a bit in the logs from lifecycles of the activities in cause, I noticed that the flow is pretty much the same ! With the difference that after onResume of last active activity, the SplashScreen gets launched (this being LAUNCHER activity)
Now, I've seen that this might be already an issue reported to Google, even multiple times, but .. If I cannot fix or workaround it, I am at least trying to understand the flow of what happens on these cases.
Edit:
Seems to be related to FLAG_ACTIVITY_NEW_TASK set in the Receiver, but.. then again I cannot start the app after boot is completed without this flag! Feels like a cycle I can't get out of..
In Android when you hold down the home button you can bring up a task list of your recent apps. And each "card" in the task list should have a preview of the app. However, this time I opened the task list and the previews were blank (except for the app title).
I had the phone Settings in the task list and every time I would tap on the task and try to open it in would close immediately.
I also had this app I was developing and when I tapped on the task to open the app my RecyclerView wasn't showing anything, when it should be.
I also was playing AngryBirds 2, so was it that Android had silently killed those apps for memory? If so, does onCreate() of the killed apps get called again when this happens?
Edit: I just noticed if you close an app too quickly when it's transitioning to an Activity you can get a blank preview.
Edit 2: So to answer my question, after referencing the Activity lifecycle diagram this is what I found. When another application needs memory, the app's process will be killed and when the user navigates back to the app, onCreate() will be called again. However, that doesn't explain why I couldn't reopen the Settings. And I have no idea how to reproduce this weird behavior!
Ok after some debugging, I found out that Android did indeed kill my app because it needed memory. When you resume to your app however, onCreate will be called with a savedInstanceState that is NOT null. I had some logic that required savedInstanceState to be null and therefore my RecyclerView wasn't populated.
To recreate this scenario of Android killing my app I had to open a ton of apps lol. Is there way I can reproduce Android killing my app without opening all those apps? Hm...
Clicking my app icon will sometimes take me to the launcher activity, but other times it will resume the activity where it left off (emulates the behavior of clicking the application in recents).
I've read (can't find concrete docs about this, other than a one off post from 3 years ago by Diane Hackborn) that after about half an hour, the OS will make sure that when you click the app icon, it will relaunch the app, but sometimes it seems to do this directly after I exit the application (with the home button, not the back button as that will call finish on the activity).
Why is this?
Is there any way to force the launcher activity in the Android OS without killing the app first then restarting it? I need to test how my app handles the launcher activity after the application may already be running.
Android will free up memory whenever it feels necessary. For that, it will kill inactive apps. If your app goes to background, at some point Android will probably kill it. Matter of time.
You can kill your app, or you can make it kill itself when it goes to background. No more options.
in order to make your app kill itself, you should override the onPause() method (which is always called when the app goes to background) and add in it a call to onDestroy().
I noticed that after I quit an app using the back button, when I go to the "Manage apps" menu I still have an option "Force Stop". Shouldn't the app be already dead at this point? (I made sure that OnDestroy indeed runs).
Why would I have an option to force stop an app that's officially dead?
Thanks,
Geva Tal.
I noticed that after I quit an app using the back button, when I go to the "Manage apps" menu I still have an option "Force Stop". Shouldn't the app be already dead at this point?
No.
Why would I have an option to force stop an app that's officially dead?
Because the process is not "dead". Android will keep your process around for a bit, in case the user happens to pop back into your app in the not-too-distant future. Android will terminate your process if and when it needs the RAM to support other apps.
The behavior you are seeing is perfectly normal.
Using the BACK button finishes an Activity, i.e., the current UI part of an 'app'.
A common mistake is to assume that an Activity is the entire 'app' which is not necessarily the case. As CommonsWare points out, it is not necessary for the OS to immediately clean up all of the parts related to the process in which an Activity runs - in fact it can be counter-intuitive if a user briefly leaves an Activity but then re-visits it shortly after.
Android is actually very efficient at managing resources and releasing them (if needed for other 'apps'). What gets retained / maintained after a particular Activity finishes isn't worth worrying about...or at least it shouldn't be if the developer has correctly cleaned up things in their code.
Part of the culture of 'App Killer' apps is related to people assuming that apps don't clean up properly when an Activity finishes. If written correctly, they do and Android will do the rest if/when necessary.
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