Is there a way to increase the time that the browser (and/or other apps) has to save its state? Probably only with very deep changes in Android itself, if I'm not mistaken?
On Sun, Jun 6, 2010 at 10:44 AM, Dianne Hackborn <[email protected]>wrote: > 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 <[email protected]> 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 <[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%[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%[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]<android-developers%[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%[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
