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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 [email protected] > >> To unsubscribe from this group, send email to > >> [email protected]<android-developers%2Bunsubs > >> [email protected]> > >> For more options, visit this group at > >>http://groups.google.com/group/android-developers?hl=en > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > 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 [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%2Bunsubs > > [email protected]> > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
