This could be because currently we give an app at most 1/5 second to return from onSaveInstanceState() + onPause() before going to the next app. If the browser is taking longer than that, we will give up and launch the next app, causing browser to go to the background. If we are under so much memory pressure at that point that the browser is immediately killed, then it may not have actually gotten to the point of giving its saved state to the system.
On Sun, Jun 6, 2010 at 1:28 AM, lsim001 <lim....@gmail.com> wrote: > The problem here is that you're hitting Android's out-of-memory limits > as mentioned above. if you have only 20megs of memory left that means > that Android has already cleared out virtually all the empty > applications (refer to app lifecycle > http://developer.android.com/guide/topics/fundamentals.html#lcycles) > so when you open your browser with lots of tabs it will need more > memory. When you are using your browser it has the highest priority > and will only be considered for killing if your available memory is > less than 6 megs. Which is must be very close to in your scenario. > Once you switch to another app the Browser become a background app > which has lower priority and so will get killed off immediately to > free up memory for the app you are currently using. > > As suggested my Mark and the others there are really 2 problems here. > > 1/ The browser isn't saving state properly when it is killed during a > low memory kill off. Maybe this is a bug or an implementation issue? > > 2/ You may want to change you usage pattern. For whatever reason even > before you start using the browser you are already very low (by the > System's standards) on memory. This could be caused by having many > widgets and services running in the background. To be honest even a > Nexus One with more RAM than a Milestone/Droid could be made to > struggle with 8 to 10 tabs open. The thing is a lot of these web > pages are not mobile optimized so you are loading what is really meant > to run on a desktop with much more resources. > > So your scenario can be replicated on any phone. In fact you may also > notice that your Alarm may stop working and other stateful apps will > have the same problem from time to time because of the same reason. > > On Jun 5, 11:13 pm, Simon Broenner <simonbroen...@gmail.com> wrote: > > Hello everyone! > > > > First of all I'd like to thank you all for your helpful tips and > information > > about what could be causing the problem. > > > > That said, I'd like to address a few points that have been mentioned: > > > > 1. I'm not concerned about reboots or Force Closes - if the device is > > rebooted or the browser has a FC fit, I don't expect all of my windows to > be > > restored. It'd be a nice feature, but not something necessary, like being > > able to resume a browser session after only having minimized it. > > > > 2. The primary suspect, in my eyes, is still the free program memory (not > > RAM but the Flash in which applications are installed) - it seems to me > that > > if the browser cannot find enough free phone memory to save its state, > the > > saving process fails silently. This is supported by the observation I > made > > earlier - with 20MB of phone memory free, I was able to reproduce the > > problem with 8-10 simple forum/e-mail pages open. With 50MB of phone > memory > > free, I was only able to reduce the problem if at least 4 or 5 of the > open > > tabs were very graphically intensive (and therefore memory intensive) > sites. > > > > Diane wrote: > > > > *To investigate these, you can use "adb shell dumpsys activity" to see > the > > activity stack (in particular the browser activity entry) at various > points. > > When it is in the background, does it say it has the saved state? Right > > before restarting it, is the entry still there will the saved state? If > so, > > then there is most likely something going on when the browser tries to > > restore its state. If not, then something earlier is going buggy when > the > > state is saved. > > > > *I'll give this a try tomorrow... can't make any promises, however, as > I'm > > still very new to Android development - haven't gotten much farther than > > Hello World and a few pages of the Developer's Guide so far ;) > > > > Thanks again for all your help! > > > > On Sat, Jun 5, 2010 at 11:29 PM, Dianne Hackborn <hack...@android.com > >wrote: > > > > > > > > > > > > > I am pretty sure the browser saves its state in onSaveInstanceState, > not > > > persistently, and this is currently as intended. That is, it will > retain > > > its state when its process gets killed and restarted, but it is > deliberately > > > not trying to retain its state across reboots. > > > > > Note that instance state is always saved before pause, BEFORE an app > goes > > > to the background. So that is the key point for state saving; after > that, > > > it doesn't matter when the process gets killed, nor is there a need to > let > > > the app do anything before it gets killed, the activity manager already > has > > > its saved state so it can be used to restore the activity in a new > process. > > > > > There are two main ways the browser could be losing its state: > > > > > To investigate these, you can use "adb shell dumpsys activity" to see > the > > > activity stack (in particular the browser activity entry) at various > points. > > > When it is in the background, does it say it has the saved state? > Right > > > before restarting it, is the entry still there will the saved state? > If so, > > > then there is most likely something going on when the browser tries to > > > restore its state. If not, then something earlier is going buggy when > the > > > state is saved. > > > > > On Sat, Jun 5, 2010 at 12:25 PM, Frank Weiss <fewe...@gmail.com> > wrote: > > > > >> The state save I'm refering to is via SharedPreferences. I've observed > > >> this in my own application. Indeed, the Android Browser's bookmarks > are > > >> saved across reboots, and I'd suppose across force closes as well, > However, > > >> I think Mark is correct that some state may not be correctly saved in > a FC > > >> situation. > > > > >> I think my theory still stands that the browser is not saving windows > > >> across reboots and FCs. If you think about it, it may not even be > possible, > > >> depending on how you define saving windows, although FF and IE are > able to > > >> restore tabs. > > > > >> -- > > >> You received this message because you are subscribed to the Google > > >> Groups "Android Developers" group. > > >> To post to this group, send email to > android-developers@googlegroups.com > > >> To unsubscribe from this group, send email to > > >> android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com><android-developers%2Bunsubs > cr...@googlegroups.com> > > >> For more options, visit this group at > > >>http://groups.google.com/group/android-developers?hl=en > > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > hack...@android.com > > > > > Note: please don't send private questions to me, as I don't have time > to > > > provide private support, and so won't reply to such e-mails. All such > > > questions should be posted on public forums, where I and others can see > and > > > answer them. > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to > android-developers@googlegroups.com > > > To unsubscribe from this group, send email to > > > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com><android-developers%2Bunsubs > cr...@googlegroups.com> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > > > -- > > Simon Broenner > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
