Skip to main content

Android lifecycle weirdness with singleTop and foreground service?



Here's the scenario:





  • Start Activity A



  • Activity A starts service S



  • Service S runs in foreground mode and shows up a notification which when pressed takes the user to Activity B (which has launchMode="singleTop")



  • Activity B shows up



  • Press HOME



  • Go into DDMS and kill your application process to simulate that your app died (press red STOP button)



  • Android will say "Rescheduling crashed service in 5000ms" (sometimes longer)



  • Service S restarts and notification is shown.



  • Press the notification icon when the service restarts...







...at this time, Android will recover both Activities A and B due to the fact the process ended unexpectedly. But despite the fact Activity B is singleTop android will spawn it AGAIN because the user clicked on the notification. This results into having A -> B -> B on the activity stack. Pressing back will take you again onto the first recovered instance of Activity B.





Can someone from the Android team clarify what is happening behind the scenes and how to avoid this? What is the best way to simulate that Android killed the process due to low memory? Is pressing STOP from DDMS good enough or an edge case and this should never happen under normal circumstances?





What is the difference between 'Force Stop' from Settings --> Applications versus STOP from DDMS?





Thanks in advance!



Source: Tips4all

Comments

  1. This behavior should not change based on whether or not the process is killed. The activity manager first looks through the server-side stack to decide what to do, and once the stack has been adjusted appropriately it resumes whatever is now at the top of the stack.

    Check your app to make sure it is not calling startActivity() when re-initializing or doing something else like that. Look in the log to see what activities are being started and the intents being used. Use "adb shell dumpsys activity" to see what the current activity stack looks like. Maybe you have cleared the task affinity, so the second activity B is being started in its own task (in which case singleTop would have no impact)?

    Also it is really hard to help people if you don't include useful details about what you are doing. The relevant log statements at the different steps, the state of the activity stack shown by "adb shell dumpsys activity", etc.

    ReplyDelete
  2. I am not too sure about the detailed differences between STOP in DDMS and Force Stop, but I am pretty sure DDMS bypasses some internal Android functionality that Force Stop would perform since I do not remember Android ever reinitializing my activities when i did a Force Stop. If this is true, then I am suspecting that what you are seeing is the result of two different tasks started by Android: one for the old, killed activities and another for when the killed service restarts. You can test this theory by setting the flag to "singleTask" and checking if the same behaviour occurs. Hope this helps.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex