[android-developers] New mobile number | Neue Handynummer
Hi everyone, As of today, I've got a new mobile number: +49 176 39160894 Home number: +49 241 53808454 Kind regards, Simon - Hallo in die Runde, Ab heute habe ich eine neue Handynummer: +49 176 39160894 Festnetz: +49 241 53808454 Gruß, Simon -- 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
[android-developers] Re: Background apps (Instant Messaging) being killed without user notification
Hello everyone! Aftera few months of living with the problem, I'd like to try to understand what's going on here. In the mean time, I've switched to the HTC Desire, and even though I constantly have 200MB+ of RAM free, IM apps are still crashing and burning in the background, with the exact same symptons (except for the low memory warnings - haven't spotted any of those on the Desire yet). Guess it's not just a lack of free memory? I have, in the mean time, discovered an app that manages to work around the problem by restarting itself each time it's closed: IM+ 2.x. However, the developers seem to have removed this feature in their latest release, 3.0.11, which exhibits the same symptoms as all the other apps. The new Nimbuzz 2.x release also displays the same unfortunate behaviour. Is it really possible that the devs of _all_ these applications are doing something wrong? Is there no possibility that there is an error of some sort in the frameworks and APIs used for building background apps? How can I gather more information about this problem? I'd love to see it solved, as the only functioning messaging program (IM+ 2.x) has other problems of its own and lacks support for Skype. Thanks everyone! On Jun 24, 9:10 am, FrankG frankgru...@googlemail.com wrote: Hello Kostya, can you please elaborate this a little bit : a) For me it seems, that the Notifications from a service without the foreground stuff are not deleted when you kill the service ( i.e. using Settings-Applications-Running Services ) b) what did you mean with 2.x -API ? I use notify nd cancel normally. Thanks a lot ! Frank On 23 Jun., 19:17, Kostya Vasilyev kmans...@gmail.com wrote: Simon, Android 2.x framework has an important change in this area, trying to nudge developers towards better behaving services. Since 2.x, marking a service as foreground requires a status bar notification, so the user knows that a service is running. Regarding lingering status bar notifications - I just verified that if a notification is displayed using the new 2.x API, it disappears when the service is killed. -- Kostya 23.06.2010 20:36, Simon Broenner пишет: By the way: All the apps have already implemented the notifcation icon in the status bar. The problem is, it doesn't change when the app is killed in the background, so the user doesn't know that it's been killed. :( Kostya Vasilyev wrote: Simon, I think this should be taken up with developers of these apps. In particular, my recommendations to them would be: - Use a startForeground / setForeground call to mark the service as being important to the user, do it only while the user is logged in. - Display a notification the phone's status bar, so the user knows if the service is still kicked out of memory. - Consider using AlarmManager to restart the service and re-login if there is an active logged in session. -- Kostya 23.06.2010 20:07, Simon Broenner пишет: 1. Why am I, the user, not informed the the application has died, and hence, the connection has been lost? 2. Why are all the IM apps being killed, and not my other background apps? Sipdroid and Locale have NEVER been killed in this fashion. -- Kostya Vasilev -- WiFi Manager + pretty widget --http://kmansoft.wordpress.com -- Kostya Vasilev -- WiFi Manager + pretty widget --http://kmansoft.wordpress.com-Zitierten Text ausblenden - - Zitierten Text anzeigen - -- 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
[android-developers] Are Android apps developed with the NDK slower than their counterparts on other OS's?
Hello developers! I've been wondering lately, about the sad situation of media playback on Android - namely: Video that isn't supported in hardware and/ or natively supported by Android OS. Coming from Windows Mobile devices, I was suprised (and frankly, dismayed) to see that things like simple playback of an XviD-encoded AVI file were not possible, even with third party apps. Currently there is only one application available (RockPlayer, currently in beta), and it only runs well on high-end devices, due to the need for immense CPU power. The same videos that stutter using this only usable DivX/XviD player on Android (I need to overclock my Milestone's Cortex A8 to get it smooth) run perfectly well on older Windows Mobile devices such as the Touch Diamond/Touch Pro/Touch Pro 2 - all of which use far slower CPUs. Android devices with the same CPUs can't even run RockPlayer because it uses CPU features that aren't even available on these older Qualcomm chips - probably needed because otherwise the performance wouldn't be up to par, even on a Cortex A8 or Snapdragon... So what exactly is the problem with Android? Why is it so difficult to develop efficient decoders for video formats that aren't natively supported? Are codecs usually written in a way that makes them impossible to implement with the tools available for Android (Assembly?)? Or does the fact that ...the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine. limit the speed of the software so drastically that it makes implementation of highly efficient software such as a decent XviD decoder impossible? I look forward to hearing your input on this, and would be very thankful for links to resources concerned with the issue of performance and efficiency in Android applications. Thanks in advance! -- 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
Re: [android-developers] Are Android apps developed with the NDK slower than their counterparts on other OS's?
Hello Vedran! Thank you for your answer! Do you know whether these low-level APIs are exposed on other platforms (Windows Mobile, iPhone and so on)? I always thought that DivX playback on Windows Mobile, for instance, was purely software decoded. The VFP instructions you referred to are actually being used in RockPlayer, and are what causes the current public beta version to only run on certain devices (MSM720x doesn't have the instruction set, AFAIK), but they don't seem to help all too much - smooth playback, even on the TI OMAP in the Milestone/Droid, seems to be very, very taxing, with significant performance improvements through overclocking (indicating that the processor is very much the bottleneck). I just have a hard time believing that even my old HTC Prophet (200MHz TI OMAP 850) had hardware support for DivX - and it still played back 480x360 DivX files flawlessly. I also find it a little puzzling that Android devices have trouble playing simple video files, while games such as Asphalt 5 or FIFA 10 (both games with incredibly detailed graphics) run smoothly... shouldn't these be far more taxing than playing back a measly standard definition video file? Don't get me wrong, Rockplayer is great, and it runs smoothly enough for daily use, but I just have the feeling that the processors in the Android devices aren't being used anywhere near their full potential. The CPU needs to be cranked to 100% for smooth playback, and that drains the battery like crazy... Thanks again for the explanation! Simon On Tue, Jul 6, 2010 at 2:13 PM, Vedran Rodic vro...@gmail.com wrote: Hi Simon, (I've put you in CC because for some reason my mails to android-developers are still not getting through.) I've also asked myself the same question. The thing is that Android API probably doesn't expose low level APIs for doing hardware accelerated surface scaling and color space ( YUV- RGB ) conversion. These are two basic conditions for building efficient video decoders since they offload the CPU from doing stupid work where every byte of every frame must be processed individually by the CPU. This hardware is present in most 2D accelerators in mainstream hardware for at least 10 years now, so it should be in every android device also. This is probably the main reason for high CPU usage, since it destorys both the CPU cache and uses resources. Other than scaling and color, other things can be accelerated by using DSP hardware that could be different on different android devices. Also using VFP/NEON instructions can help, but for scaling and colorspace conversion, it's best to offload it to dedicated hardware. It is possible that hw scaling and colorspace conversion could work with OpenGL ES, but not all devices support that. I guess that even the devices without OpenGL ES hw acceleration still have sufficient 2D and video acceleration to support this. NDK r3 and r4 added some OpenGL ES and VFP/NEON support. It's unclear from the ChangeLog if this can be used on Android 2.2 only or if it works on older Androids. You can try your look by looking at Android platform source code and finding where is low level video implemented for the standard media player. And lets hope somebody from google has a better answer :) Vedran On Tue, Jul 6, 2010 at 11:25 AM, Simon Broenner simonbroen...@gmail.comwrote: Hello developers! I've been wondering lately, about the sad situation of media playback on Android - namely: Video that isn't supported in hardware and/ or natively supported by Android OS. Coming from Windows Mobile devices, I was suprised (and frankly, dismayed) to see that things like simple playback of an XviD-encoded AVI file were not possible, even with third party apps. Currently there is only one application available (RockPlayer, currently in beta), and it only runs well on high-end devices, due to the need for immense CPU power. The same videos that stutter using this only usable DivX/XviD player on Android (I need to overclock my Milestone's Cortex A8 to get it smooth) run perfectly well on older Windows Mobile devices such as the Touch Diamond/Touch Pro/Touch Pro 2 - all of which use far slower CPUs. Android devices with the same CPUs can't even run RockPlayer because it uses CPU features that aren't even available on these older Qualcomm chips - probably needed because otherwise the performance wouldn't be up to par, even on a Cortex A8 or Snapdragon... So what exactly is the problem with Android? Why is it so difficult to develop efficient decoders for video formats that aren't natively supported? Are codecs usually written in a way that makes them impossible to implement with the tools available for Android (Assembly?)? Or does the fact that ...the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine. limit the speed of the software so drastically that it makes
[android-developers] Re: Are Android apps developed with the NDK slower than their counterparts on other OS's?
Hello Tim! Thanks for clearing up the detail about NEON, I'll read up on that. However, the thing that I'm trying to get at here is that as far as I know, the Windows Mobile platform doesn't have any form of hardware support for decoding XviD either, but still manages to play it back fine with processors that are far outclassed in terms of pure computational horsepower by a Cortex A8 or Snapdragon, even completely discounting the additional instruction sets and other features found in the newer processors. Please correct me if I'm mistaken, but it seems to me that even without any specialized support for instruction sets or hardware support on either side, Android is just less efficient. Or am I just completely confused, and WinMo devices have had specialized instruction sets and/or even hardware support for this sort of thing all along? Kind regards, Simon By the way, here's the message Vedran sent, which did not get posted: Hi Simon, (I've put you in CC because for some reason my mails to android- developers are still not getting through.) I've also asked myself the same question. The thing is that Android API probably doesn't expose low level APIs for doing hardware accelerated surface scaling and color space ( YUV- RGB ) conversion. These are two basic conditions for building efficient video decoders since they offload the CPU from doing stupid work where every byte of every frame must be processed individually by the CPU. This hardware is present in most 2D accelerators in mainstream hardware for at least 10 years now, so it should be in every android device also. This is probably the main reason for high CPU usage, since it destorys both the CPU cache and uses resources. Other than scaling and color, other things can be accelerated by using DSP hardware that could be different on different android devices. Also using VFP/NEON instructions can help, but for scaling and colorspace conversion, it's best to offload it to dedicated hardware. It is possible that hw scaling and colorspace conversion could work with OpenGL ES, but not all devices support that. I guess that even the devices without OpenGL ES hw acceleration still have sufficient 2D and video acceleration to support this. NDK r3 and r4 added some OpenGL ES and VFP/NEON support. It's unclear from the ChangeLog if this can be used on Android 2.2 only or if it works on older Androids. You can try your look by looking at Android platform source code and finding where is low level video implemented for the standard media player. And lets hope somebody from google has a better answer :) Vedran On Jul 6, 2:35 pm, Tim tdh...@gmail.com wrote: On Jul 6, 10:25 am, Simon Broenner simonbroen...@gmail.com wrote: RockPlayer because it uses CPU features that aren't even available on these older Qualcomm chips - probably needed because otherwise the performance wouldn't be up to par, even on a Cortex A8 or Snapdragon... True but it still doesn't use NEON instructions:http://www.diffthink.com/forum/viewtopic.php?f=2t=11 So what exactly is the problem with Android? Why is it so difficult to develop efficient decoders for video formats that aren't natively supported? Are codecs usually written in a way that makes them impossible to implement with the tools available for Android (Assembly?)? It takes time to implement a codec using SIMD/DSP instructions. It's nothing to do with the NDK. -- 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
[android-developers] Background apps (Instant Messaging) being killed without user notification
Hello everyone!
I'm having another problem with my milestone that I'd like to share
with developers and Android coders: Whenever I run memory-intensive
applications while I have an IM app running in the background, the IM
app is often killed without any user notification whatsoever.
Take this scenario for instance (works every time on my Milestone):
1. A few background apps are already running: Sipdroid, Locale,
Titanium Backup's service...
2. Launch Nimbuzz (or Fring, eBuddy or Meebo - it's reproducible on
all of them)
3. Use lots of memory - for instance with a browser (open lots of
windows will full desktop sites), or by launching multiple memory-
intensive applications at once (Maps Navigation or other navigation
apps work well)
Sure enough, the logs show the following:
06-23 17:39:44.542: INFO/ActivityManager(1286): Displayed activity
com.nimbuzz/.MainScreen: 705 ms (total 705 ms)
06-23 17:39:44.558: WARN/InputManagerService(1286): Client not active,
ignoring focus gain of: com.android.internal.view.IInputMethodClient
$stub$pr...@4514e388
06-23 17:39:45.402: WARN/KeyCharacterMap(12195): Can't open keycharmap
file
06-23 17:39:45.410: WARN/KeyCharacterMap(12195): Error loading
keycharmap file '/system/usr/keychars/qtouch-touchscreen.kcm.bin'.
hw.keyboards.65538.devname='qtouch-touchscreen'
06-23 17:39:45.410: WARN/KeyCharacterMap(12195): Using default
keymap: /system/usr/keychars/qwerty.kcm.bin
06-23 17:39:45.456: INFO/ActivityManager(1286): Starting activity:
Intent { act=android.intent.action.MAIN
cat=[android.intent.category.HOME] cmp=com.fede.launcher/.Launcher }
06-23 17:39:45.628: WARN/IInputConnectionWrapper(12195):
showStatusIcon on inactive InputConnection
06-23 17:39:47.331: INFO/ActivityManager(1286): Starting activity:
Intent { act=android.intent.action.MAIN
cat=[android.intent.category.LAUNCHER] flg=0x1000
cmp=mobi.mgeek.TunnyBrowser/.BrowserActivity }
06-23 17:39:53.941: WARN/InputManagerService(1286): Window already
focused, ignoring focus gain of:
com.android.internal.view.iinputmethodclient$stub$pr...@44f9bbf0
06-23 17:39:55.777: WARN/webcore(13158): Can't get the viewWidth after
the first layout
06-23 17:39:58.652: WARN/InputManagerService(1286): Window already
focused, ignoring focus gain of:
com.android.internal.view.iinputmethodclient$stub$pr...@451162b0
06-23 17:40:02.886: WARN/webcore(13158): Can't get the viewWidth after
the first layout
06-23 17:40:04.277: INFO/ActivityManager(1286): Process
com.motorola.worldclock (pid 13198) has died.
06-23 17:40:04.277: INFO/ActivityManager(1286): Low Memory: No more
background processes.
06-23 17:40:51.339: INFO/ActivityManager(1286): Process com.nimbuzz
(pid 12195) has died.
06-23 17:40:51.347: WARN/ActivityManager(1286): Scheduling restart of
crashed service com.nimbuzz/.services.NimbuzzService in 5000ms
06-23 17:40:51.347: INFO/ActivityManager(1286): Low Memory: No more
background processes.
06-23 17:40:51.355: INFO/WindowManager(1286): WIN DEATH:
Window{44fad130 com.nimbuzz/com.nimbuzz.MainScreen paused=false}
06-23 17:40:51.355: INFO/WindowManager(1286): WIN DEATH:
Window{452b9728 com.nimbuzz/com.nimbuzz.InitScreen paused=false}
06-23 17:40:56.371: INFO/ActivityManager(1286): Start proc com.nimbuzz
for service com.nimbuzz/.services.NimbuzzService: pid=13215 uid=10122
gids={1006, 3003, 1015}
06-23 17:40:57.839: INFO/ActivityThread(13215): Publishing provider
com.nimbuzz.contactlistsearchprovider:
com.nimbuzz.services.ContactListSearchProvider
06-23 17:40:57.870: WARN/Service(13215): setForeground: ignoring old
API call on com.nimbuzz.services.NimbuzzService
06-23 17:41:00.097: INFO/ActivityManager(1286): Start proc
com.motorola.worldclock for broadcast
com.motorola.worldclock/.WorldClockWidgetProvider: pid=13221 uid=10029
gids={}
06-23 17:41:00.222: INFO/dalvikvm(13221): Debugger thread not active,
ignoring DDM send (t=0x41504e4d l=38)
06-23 17:41:00.245: INFO/dalvikvm(13221): Debugger thread not active,
ignoring DDM send (t=0x41504e4d l=50)
06-23 17:41:00.753: INFO/ActivityManager(1286): Process
com.motorola.worldclock (pid 13221) has died.
06-23 17:41:00.753: INFO/ActivityManager(1286): Low Memory: No more
background processes.
06-23 17:41:03.941: INFO/NotificationService(1286): enqueueToast
pkg=mobi.mgeek.TunnyBrowser callback=android.app.ITransientNotification
$stub$pr...@45260c28 duration=0
06-23 17:41:58.808: INFO/ActivityManager(1286): Starting activity:
Intent { act=android.intent.action.MAIN
cat=[android.intent.category.LAUNCHER] flg=0x1020
cmp=com.nimbuzz/.InitScreen }
06-23 17:41:58.824: WARN/ActivityManager(1286): Activity
HistoryRecord{44ec7da0 com.nimbuzz/.MainScreen} being finished, but
not in LRU list
06-23 17:41:59.324: WARN/ActivityManager(1286): Activity pause timeout
for HistoryRecord{45345898 mobi.mgeek.TunnyBrowser/.BrowserActivity}
06-23 17:42:00.003: INFO/ActivityManager(1286): Start proc
com.motorola.worldclock for broadcast
com.motorola.worldclock/.WorldClockWidgetProvider: pid=13231 uid=10029
Re: [android-developers] Background apps (Instant Messaging) being killed without user notification
Hello Kostya, Do you think that they really all just made a mistake with their programming? I thought that since it happens with all four apps, it must be a general Android problem... I'll post on their forums though. Thanks for your advice so far. :) Kind regards, Simon Kostya Vasilyev wrote: Simon, I think this should be taken up with developers of these apps. In particular, my recommendations to them would be: - Use a startForeground / setForeground call to mark the service as being important to the user, do it only while the user is logged in. - Display a notification the phone's status bar, so the user knows if the service is still kicked out of memory. - Consider using AlarmManager to restart the service and re-login if there is an active logged in session. -- Kostya 23.06.2010 20:07, Simon Broenner пишет: 1. Why am I, the user, not informed the the application has died, and hence, the connection has been lost? 2. Why are all the IM apps being killed, and not my other background apps? Sipdroid and Locale have NEVER been killed in this fashion. -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- 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
Re: [android-developers] Background apps (Instant Messaging) being killed without user notification
By the way: All the apps have already implemented the notifcation icon in the status bar. The problem is, it doesn't change when the app is killed in the background, so the user doesn't know that it's been killed. :( Kostya Vasilyev wrote: Simon, I think this should be taken up with developers of these apps. In particular, my recommendations to them would be: - Use a startForeground / setForeground call to mark the service as being important to the user, do it only while the user is logged in. - Display a notification the phone's status bar, so the user knows if the service is still kicked out of memory. - Consider using AlarmManager to restart the service and re-login if there is an active logged in session. -- Kostya 23.06.2010 20:07, Simon Broenner пишет: 1. Why am I, the user, not informed the the application has died, and hence, the connection has been lost? 2. Why are all the IM apps being killed, and not my other background apps? Sipdroid and Locale have NEVER been killed in this fashion. -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- 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
Re: [android-developers] Background apps (Instant Messaging) being killed without user notification
Hi Kostya, Thanks for the tips. I'll forward that to the developers... :) Kostya Vasilyev wrote: Simon, Android 2.x framework has an important change in this area, trying to nudge developers towards better behaving services. Since 2.x, marking a service as foreground requires a status bar notification, so the user knows that a service is running. Regarding lingering status bar notifications - I just verified that if a notification is displayed using the new 2.x API, it disappears when the service is killed. -- Kostya 23.06.2010 20:36, Simon Broenner пишет: By the way: All the apps have already implemented the notifcation icon in the status bar. The problem is, it doesn't change when the app is killed in the background, so the user doesn't know that it's been killed. :( Kostya Vasilyev wrote: Simon, I think this should be taken up with developers of these apps. In particular, my recommendations to them would be: - Use a startForeground / setForeground call to mark the service as being important to the user, do it only while the user is logged in. - Display a notification the phone's status bar, so the user knows if the service is still kicked out of memory. - Consider using AlarmManager to restart the service and re-login if there is an active logged in session. -- Kostya 23.06.2010 20:07, Simon Broenner пишет: 1. Why am I, the user, not informed the the application has died, and hence, the connection has been lost? 2. Why are all the IM apps being killed, and not my other background apps? Sipdroid and Locale have NEVER been killed in this fashion. -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- 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
[android-developers] Admob ads linking to scam sites, possible additional app-security problems
will be shrugged off easily, considering the amount of money at stake. Possibly it would be more effective to contact Google itself (a chance to prove themselves once again in their Do no evil! stance) and have them take care of it. Maybe a few Google employees will read this post and know where to go from here. If you have any ideas on how to procede, or information about the technicalities concerning the methodology used by Blinkogold (and similar services) to trap unsuspecting Android users, please chime in! Kind regards from Germany and the members of android-hilfe.de, and thanks for reading! -- 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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Emulator kills sounds on Mac OS X
I'm going out on a limb here, because I use Windows myself, but I've seen similar behaviour with external sound cards and ASIO drivers/ applications. Some of the sound cards (my EMU 0202USB, for instance) aren't capable of processing a second audio stream in addition to the ASIO stream, which leads to the active ASIO application hogging the sound card for itself, and sound from other applications doesn't work at all. Maybe there's a similar problem on OS X? Does the same thing happen with the internal sound chip (I'm assuming even iMacs/MacPros have one?)? On Jun 13, 11:39 am, sebsto sebastien.storm...@gmail.com wrote: Hello, I am using Android SDK on Mac OS X with an external sound card (Edirol) When I do start the Android Emulator, it stops all sound output on the Mac. iTunes does not play anymore, no application (including the emulator) produce sounds through the external sound card. Only solution is to reboot. Is this a known problem ? How to workaround it ? Thanks Seb -- 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
Re: [android-developers] Re: Multitasking on Android - Why So Incredibly Bad?
That's actually a very good point - sometimes the window just reloads, sometimes all the windows are gone altogether, so this has probably already been implemented some way or another. It's just failing for some reason... On Mon, Jun 7, 2010 at 12:59 PM, mort m...@sto-helit.de wrote: From what I got so far, it seems like the browser tries to save the entire page contents, which might cause troubles - either because it's too slow (1/5s time limit) or because there's not enough free space on the internal flash. Maybe it'd be a solution to save the state in steps. First the URLs, then form data, then the latest window's contents, then the remaining windows. Better to reload a page when coming back than losing it all. -- 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.comandroid-developers%2bunsubscr...@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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Multitasking on Android - Why So Incredibly Bad?
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 hack...@android.comwrote: 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
Re: [android-developers] Re: Multitasking on Android - Why So Incredibly Bad?
Hello everyone! The solution (or rather, workaround) for me, so far, has been to root the device and move my apps to the SD card, freeing up more of the phone's internal memory. I now have around 60MB of free device memory (albeit with 200MB+ of apps installed), and have only been able to reproduce the problem once (tried about 10-15 times). Obviously this situation is still not ideal, but it's one I can live with. Hopefully the problem will more or less subside as device memory becomes larger and larger, and less and less applications need to be installed on the device memory itself due to Apps2SD being built in from Froyo onwards. Thank you all for your help! On Sun, Jun 6, 2010 at 6:11 PM, Dianne Hackborn hack...@android.com wrote: It's a constant in ActivityManagerService. You wouldn't want to just change it, because it could seriously impact responsiveness. The solution would be to have the activity manager be able to go on with the switch, but keep the application in foreground for longer, giving it a chance to respond with its state. On Sun, Jun 6, 2010 at 3:27 AM, Mark Murphy mmur...@commonsware.comwrote: Simon Broenner wrote: 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? It's not something an application can choose on its own, but rather would be in the device's firmware, somewhere. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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.comandroid-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.comandroid-developers%2bunsubscr...@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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Multitasking on Android - Why So Incredibly Bad?
Hello Diane! I think you've misunderstood me somewhat. The problem doesn't seem to be that there isn't enough RAM available - that's a given already (because I know I'm using way too much RAM with all my open browser windows), and the process will be stopped anyway, no matter what I do. The thing is, I'm guessing that WHEN the browser is closed, the browser state is saved in the phone internal storage (which is what I've been talking about this whole time - maybe I just haven't been clear enough in that respect - any time I don't explicitly say RAM when I'm talking about memory, I'm talking about the phone's internal application storage and _not_ the RAM), and the browser's state would require more space than the phone storage currently has available. That would at least explain the symptoms I've been having, and the fact that the workaround, well, works. On Sun, Jun 6, 2010 at 8:42 PM, Dianne Hackborn hack...@android.com wrote: Um, internal storage has very little to do with available RAM. In fact apps on the SD card use a little more RAM than those in internal storage. So this solution is just happening to do something as a side-effect... maybe things are paging slightly faster because the SD card is faster than internal storage, so the browser isn't as slow to save its state. On Sun, Jun 6, 2010 at 9:18 AM, Simon Broenner simonbroen...@gmail.comwrote: Hello everyone! The solution (or rather, workaround) for me, so far, has been to root the device and move my apps to the SD card, freeing up more of the phone's internal memory. I now have around 60MB of free device memory (albeit with 200MB+ of apps installed), and have only been able to reproduce the problem once (tried about 10-15 times). Obviously this situation is still not ideal, but it's one I can live with. Hopefully the problem will more or less subside as device memory becomes larger and larger, and less and less applications need to be installed on the device memory itself due to Apps2SD being built in from Froyo onwards. Thank you all for your help! On Sun, Jun 6, 2010 at 6:11 PM, Dianne Hackborn hack...@android.comwrote: It's a constant in ActivityManagerService. You wouldn't want to just change it, because it could seriously impact responsiveness. The solution would be to have the activity manager be able to go on with the switch, but keep the application in foreground for longer, giving it a chance to respond with its state. On Sun, Jun 6, 2010 at 3:27 AM, Mark Murphy mmur...@commonsware.comwrote: Simon Broenner wrote: 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? It's not something an application can choose on its own, but rather would be in the device's firmware, somewhere. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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.comandroid-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.comandroid-developers%2bunsubscr...@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.comandroid-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
Re: [android-developers] Multitasking on Android - Why So Incredibly Bad?
I'm using a Motorola Milestone, running Android 2.1 (stock unrooted). Does your browser stay active if you open up the maximum amount of tabs, launch a different application and then come back? Do all the tabs stay open, and not refresh (or close altogether) when you reopen the browser? On Sat, Jun 5, 2010 at 4:10 PM, Anton Persson don.juan...@gmail.com wrote: What phone are you using? I do that stuff on my HTC Magic everyday, no issues. (Android 1.5 FTW? ;-) On Sat, Jun 5, 2010 at 3:00 PM, bemymonkey simonbroen...@gmail.comwrote: Hello everyone! First of all, I hope this is at least somewhat on-topic for this discussion group, as it seems to be the only way to reach Android developers easily. The problem I would like to discuss is the way Android handles running multiple applications at the same time. Take the following scenario, for instance: 1. Open the browser 2. Open a few links that you want to read later in new windows/tabs 3. Open another app (Say you received an SMS, for instance) 4. Reopen the browser, expecting to continue where you left off 5. Browser has closed all open windows WITHOUT saving the state or notifying the user This happens even if you're only jumping between completely Android- Native apps that came with the OS. There are various other similar scenarios, but this is easily the most annoying, since it results in complete loss of stuff I was actually planning on reading later. Why would anyone consider this to be actual multitasking? If there's no guarantee that the app you just left will still have the same state when you come back to it from your other tasks, it's NOT MULTITASKING. How is it that this is still an issue? We've arrived at Android 2.2, and we still can't minimize a program without running the risk of losing everything we just did? Are there at least plans to integrate proper multitasking in the future? Or a way to allow users to specifically select tasks that are not to be killed under any circumstances? -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Simon Broenner Kasinostr. 94, 52066 Aachen, Germany +4917661249070 (Mobile) +492415903431 (Home) -- 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
Re: [android-developers] Multitasking on Android - Why So Incredibly Bad?
Obviously the windows (which is what I meant - I _am_ using the native Android browser) stay open as they should in most scenarios - it's usually when the memory starts to get low and the OS starts killing tasks that this becomes a problem. There are a few similar experiences listed in this thread: http://androidforums.com/android-lounge/23356-multitasking.html The problem seems to be that Android is killing the task to free up memory even though it was in use until 10 seconds ago, and doesn't bother to save the state so that it can restore it when the app is restarted... As a reference, I have around 30-40MB of free memory when this starts happening - so it's not likely to be caused by too much stuff running in the background. On Sat, Jun 5, 2010 at 5:02 PM, Mark Murphy mmur...@commonsware.com wrote: Simon Broenner wrote: Does your browser stay active if you open up the maximum amount of tabs, launch a different application and then come back? The standard Android browser does not have tabs. Perhaps you installed a different browser. If by tabs you mean windows, then, yes, they stay open on every Android device I have used, including the DROID (CDMA equivalent of the Milestone). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.5 Available! -- 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.comandroid-developers%2bunsubscr...@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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Multitasking on Android - Why So Incredibly Bad?
Hmmm, I'm beginning to get that feeling too. Any idea what the cause could be? Obviously I'm not using any auto task killers or anything like that... :( On Sat, Jun 5, 2010 at 5:26 PM, Mark Murphy mmur...@commonsware.com wrote: Simon Broenner wrote: Obviously the windows (which is what I meant - I _am_ using the native Android browser) stay open as they should in most scenarios - it's usually when the memory starts to get low and the OS starts killing tasks that this becomes a problem. I use Android devices a fair bit, and I have not encountered this problem. That does not mean that the problem does not exist for you, but that the situation is probably a wee bit more complex than your subject line indicates. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android 2.2 Programming Books: http://commonsware.com/books -- 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.comandroid-developers%2bunsubscr...@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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Multitasking on Android - Why So Incredibly Bad?
I just went through the whole process and logged it: 1. Open browser 2. Open maximum number of windows by using open in new window (set to open new windows in background, in case that matters), all with different content (so not all the same link) 3. Switch to a different application (in my case I clicked an e-mail address from the browser, which launched the Gmail app) 4. Then switch back to the browser, either via a long hold on the Home key or from the Home Screen Launcher Log: http://www.narcotic-symphony.de/simon/androidlog.txt Relaunching the browser (Step 4) takes place at around line line 161. Can you make heads or tails of it? Thanks for your help so far! On Sat, Jun 5, 2010 at 5:51 PM, Mark Murphy mmur...@commonsware.com wrote: Simon Broenner wrote: Hmmm, I'm beginning to get that feeling too. Any idea what the cause could be? Obviously I'm not using any auto task killers or anything like that... :( Off the top of my head, no. If you're a developer, and you can get it to happen, plug it into USB and scan logcat for any interesting messages. Usually, Android logs when it is killing off processes, and it feels like your Browser process is getting killed. If you're not a developer, the only advice I can offer is for you to come up with a repeatable scenario that consistently causes the problem, preferably from a freshly-rebooted phone. (even more ideally would be a phone with no third-party apps, but I'm guessing this is your personal phone, so having you wipe it would be a bit intrusive) If you can find such a scenario, post it here or on [android-discuss], so we can see if other devices exhibit the same behavior. If we can find cases across several devices, it's probably an Android bug. If the only other cases are Milestones, it might be a Motorola bug. If we can't reproduce the problem, I'd start taking a real close look at any third-party apps you have installed. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- 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.comandroid-developers%2bunsubscr...@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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Multitasking on Android - Why So Incredibly Bad?
This is the relevant part of the log, as far as I can tell:
06-05 18:02:21.531: INFO/ActivityManager(1282): Displayed activity
com.google.android.gm/.ComposeActivity: 2025 ms (total 2631 ms)
06-05 18:02:22.101: ERROR/cache(2780): disableTransaction is out of sync
06-05 18:02:22.242: INFO/ActivityManager(1282): Process com.android.browser
(pid 2780) has died.
06-05 18:02:22.242: INFO/ActivityManager(1282): Low Memory: No more
background processes.
06-05 18:02:22.242: INFO/WindowManager(1282): WIN DEATH: Window{4507b368
com.android.browser/com.android.browser.BrowserActivity paused=false}
06-05 18:02:25.187: WARN/KeyCharacterMap(4253): Can't open keycharmap file
06-05 18:02:25.187: WARN/KeyCharacterMap(4253): Error loading keycharmap
file '/system/usr/keychars/qtouch-touchscreen.kcm.bin'.
hw.keyboards.65538.devname='qtouch-touchscreen'
06-05 18:02:25.187: WARN/KeyCharacterMap(4253): Using default keymap:
/system/usr/keychars/qwerty.kcm.bin
06-05 18:02:26.555: INFO/NotificationService(1282): enqueueToast pkg=
com.google.android.gmcallback=android.app.itransientnotification$stub$pr...@44de28d0duration=0
06-05 18:02:26.601: ERROR/Workspace(1364): mCurrentScreen = 1
06-05 18:02:26.633: WARN/InputManagerService(1282): Starting input on
non-focused client
com.android.internal.view.iinputmethodclient$stub$pr...@44e4edb0 (uid=10007
pid=4253)
06-05 18:02:26.633: WARN/IInputConnectionWrapper(4253): showStatusIcon on
inactive InputConnection
06-05 18:02:28.000: INFO/ActivityManager(1282): Starting activity: Intent {
act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER]
flg=0x1020 cmp=com.android.browser/.BrowserActivity
bnds=[125,446][235,564] }
06-05 18:02:28.055: INFO/ActivityManager(1282): Start proc
com.android.browser for activity com.android.browser/.BrowserActivity:
pid=4265 uid=10045 gids={3003, 1015}
06-05 18:02:28.109: INFO/dalvikvm(4265): Debugger thread not active,
ignoring DDM send (t=0x41504e4d l=38)
06-05 18:02:28.180: INFO/dalvikvm(4265): Debugger thread not active,
ignoring DDM send (t=0x41504e4d l=42)
06-05 18:02:28.289: INFO/ActivityThread(4265): Publishing provider browser:
com.android.browser.BrowserProvider
06-05 18:02:29.164: DEBUG/BrowserSettings(4265): Enter
getFactoryResetHomeUrl()
06-05 18:02:29.164: DEBUG/BrowserSettings(4265): http index is 14
06-05 18:02:29.164: DEBUG/BrowserSettings(4265): Preload homepage is
http://www.google.com
06-05 18:02:29.398: DEBUG/dalvikvm(4265): GC freed 1981 objects / 142280
bytes in 175ms
06-05 18:02:30.453: INFO/ActivityManager(1282): Displayed activity
com.android.browser/.BrowserActivity: 2410 ms (total 2410 ms)
It starts more or less at the launching of the Gmail app and ends at the
browser being relaunched after it was killed due to low memory.
On Sat, Jun 5, 2010 at 6:09 PM, Simon Broenner simonbroen...@gmail.comwrote:
I just went through the whole process and logged it:
1. Open browser
2. Open maximum number of windows by using open in new window (set to
open new windows in background, in case that matters), all with different
content (so not all the same link)
3. Switch to a different application (in my case I clicked an e-mail
address from the browser, which launched the Gmail app)
4. Then switch back to the browser, either via a long hold on the Home key
or from the Home Screen Launcher
Log: http://www.narcotic-symphony.de/simon/androidlog.txt
Relaunching the browser (Step 4) takes place at around line line 161.
Can you make heads or tails of it?
Thanks for your help so far!
On Sat, Jun 5, 2010 at 5:51 PM, Mark Murphy mmur...@commonsware.comwrote:
Simon Broenner wrote:
Hmmm, I'm beginning to get that feeling too.
Any idea what the cause could be? Obviously I'm not using any auto task
killers or anything like that... :(
Off the top of my head, no.
If you're a developer, and you can get it to happen, plug it into USB
and scan logcat for any interesting messages. Usually, Android logs when
it is killing off processes, and it feels like your Browser process is
getting killed.
If you're not a developer, the only advice I can offer is for you to
come up with a repeatable scenario that consistently causes the problem,
preferably from a freshly-rebooted phone.
(even more ideally would be a phone with no third-party apps, but I'm
guessing this is your personal phone, so having you wipe it would be a
bit intrusive)
If you can find such a scenario, post it here or on [android-discuss],
so we can see if other devices exhibit the same behavior. If we can find
cases across several devices, it's probably an Android bug. If the only
other cases are Milestones, it might be a Motorola bug. If we can't
reproduce the problem, I'd start taking a real close look at any
third-party apps you have installed.
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
Android Training...At Your Office
Re: [android-developers] Multitasking on Android - Why So Incredibly Bad?
I'm pretty sure the browser is using a lot of memory, and the OS is perfectly within its rights to close the application when it's in the background - but not without saving the state first. I'm currently testing with more free phone storage memory (previously about 22MB free, now 53MB), and so far I haven't been able to reproduce the problem (only the reloading - the entire browser just being gone hasn't happened so far). Is it possible that the saved states are placed in the same storage space that installed applications occupy? That would explain the change in symptoms... will get another log when I get home later. On 5 Jun 2010 19:02, Frank Weiss fewe...@gmail.com wrote: This might be a longshot. Perhaps it's not the browser, but the web pages. If you have many browser windows open, each web page contributes to memory pressure. I have the same experience on my desktop with 2 GB. After power browsing for a while - that is, having multiple open tabs for several days - I frequently have to close the browser because the system gets sluggish. This happens for both IE and FF. In my case, I keep SFGate and Gmail open. Of course, I'm just speculating. Is there any easy way to check the Android browser's memory usage relative to the other applications? -- You received this message because you are subscribed to the Google Groups Android Developers group... -- 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
Re: [android-developers] Multitasking on Android - Why So Incredibly Bad?
When I reach the max., the new window and open new window buttons just disappear. Max. is something like 8 or 10 windows. On 5 Jun 2010 19:11, Kostya Vasilyev kmans...@gmail.com wrote: 05.06.2010 20:09, Simon Broenner пишет: 2. Open maximum number of windows by using open in new window (set to open new windows in bac... What do you mean by maximum number of windows ? How many is that? What happens if you try to open one more? -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group... -- 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
Re: [android-developers] Multitasking on Android - Why So Incredibly Bad?
Just reproduced again with all the newly freed program memory (albeit with relatively memory-heavy web sites like Engadget and Slashdot) :( Looks like having more free application memory delays the process somewhat though... On 5 Jun 2010 19:11, Kostya Vasilyev kmans...@gmail.com wrote: 05.06.2010 20:09, Simon ... 2. Open maximum number of windows by using open in new window (set to open new windows in bac... What do you mean by maximum number of windows ? How many is that? What happens if you try... You received this message because you are subscribed to the Google Groups Android Developers group... -- 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
Re: [android-developers] Multitasking on Android - Why So Incredibly Bad?
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.comwrote: 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.comandroid-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.comandroid-developers%2bunsubscr...@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
