[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
We are also having occasional problems with OutOfMemory errors in createBitmap. It tends to happen after a few orientation changes when we are allocating the backbuffers. I have made it so that it calls recycle() on the old bitmaps (if any exist) and does a System.gc() before allocating the new backbuffers. Hopefully this will solve the problem, but I'm worried that it could still happen. What we are doing is allocating a backbuffer that is twice the width and height of the screen so that we can quickly zoom in and out. With a 854x480 screen this would presumably be 6.25MB in size. The problem as I see it is the 16 or 24MB maximum heap size per process. This is unreasonably small, especially on devices that have 512MB of RAM. Ideally the max heap size should be something like 64MB, or perhaps allow apps to request a larger heap size from the user. -- 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: Bitmaps and OutOfMemoryError: Best Practices needed
We can't split up the bitmap into smaller ones. It is a drawing program and we draw shapes to the offscreen bitmap. For now we have just put a gc() and recycle() before reallocating bitmaps, and also put a gc() at the end of onDestroy() as suggested in another thread. This is working so far, but I can see that running out of memory could be an issue in many other situations where you are dealing with large documents or graphics. On Sep 2, 8:07 pm, "EnjoyLifeHappyEveryday--Jay Meng" wrote: > hey > blahblah...@gmail.com > > We meet the same question,but we thought two ways to solve it: > 1> cutting up a big bitmaps into many small bitmaps, less than 2M of every > bitmaps, and then splitting joint small bitmaps > 2> using virtual-point idea to call small bitmaps when is used at once and > release small bitmaps when isn't used at once. > > Hope it useful for you. > > Best Regards. > > Jay Meng > EnjoyLifeHappyEveryday > CodeCore Groups -- 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: Bitmaps and OutOfMemoryError: Best Practices needed
It's happening on the emulator when running 2.0 or 2.2. No compatibility mode AFAIK. I just did some testing and we are still getting OutOfMemoryError after changing screen orientation 3 times - it always gives the error the third time even though I added gc(); runFinalization(); gc() just before the createBitmap. I'm thinking it must be either a memory leak in Android or heap fragmentation. So far I don't have any workaround. On Sep 3, 2:40 pm, Matt Kanninen wrote: > I found OutOfMemory Bitmap errors happened more frequently when I had > a compatibility mode set. Although that was just on the Moto Droid, > on Android 2.1, back in December. -- 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: Bitmaps and OutOfMemoryError: Best Practices needed
More info - when I use meminfo the "native allocated" kb increases from 10MB to 15MB to 20MB after each screen orientation change, even though I am explicitly calling recycle() on the large bitmaps in our onDestroy (and I ran it in the debugger and verified that this code is being called). Also, when I reduce the size of the bitmap to the screen size (instead of twice the width and height of the screen) the "native allocated" only increases about 2MB each time, so it takes more screen orientation changes before the thing keels over (but it eventually does). So it looks like the bitmap is getting leaked somehow. We have no static members, and one thread is created (which exits after our onDestroy is called, which I have verified) and I've checked all our inner classes to make sure there is nothing getting leaked. So I'm pretty sure it's not our code leaking it (but I could be wrong). And even if it was a leak in our code, the explicit recycle() should have sorted it out. On Sep 7, 1:08 pm, Romain Guy wrote: > It could also be a memory leak in your application. -- 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: Bitmaps and OutOfMemoryError: Best Practices needed
I managed to recreate the bug with a very simple test case. It only happens when you place the Bitmap into a Canvas, so I think it is a memory leak in the Android Canvas code. I have logged a bug here: http://code.google.com/p/android/issues/detail?id=11089 As far as I can tell this bug will happen for any android app that uses Bitmaps with Canvas - basically it will crash with an out of memory error after you change screen orientation sufficient times (or do anything else that causes the activity to be destroyed and recreated). -- 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: Bitmaps and OutOfMemoryError: Best Practices needed
The workaround seems to be to put a System.gc(); System.runFinalization(); System.gc(); at the end of the onDestroy(). -- 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] Why is Android so buggy?
It seems that Android is very buggy compared not only to the iPhone, but to pretty much any other software. It's not just minor bugs either - pretty much every developer will come across many serious bugs. Some examples: - When you run the "sdk setup.exe", the very first thing that happens is that it informs you that it can't connect using https, so you have to change the options to use 'http' instead. This appears to be a bug in the .exe rather than any kind of user issue because the https url works fine in the browser and this error seems to affect everyone. Sure, it's trivial to work around (just do a google search and you figure it out in 5 seconds), but the user shouldn't have to do that. It makes it look unprofessional. - When you view a TabWidget in the layout editor it crashes. - Every time you run an app in the emulator, it starts off with the screen locked so you need to press the Menu key. - Various socket bugs (or perhaps all the same bug) related to IOException not happening. Even something as simple as just trying to connect to a remote host that is not listening will cause it to hang instead of immediately returning an error. All of these bugs have been logged for months (some by me, some by other people) with no indication of any fix. At the moment I'm just using the emulator, but I'm wondering if the phones themselves are this buggy or if all the bugs are just in the development environment and emulator. -- 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: Why is Android so buggy?
On Jun 7, 11:13 am, TreKing wrote: > Q: Why is Android so buggy? > A: Because it's software - simple as that. My software isn't that buggy. Neither is the iphone. > You compared Android to every existing piece of software there is? No, but in my 16 years of commercial software development experience I have never come across any other piece of software that has so many serious bugs that are apparently not being addressed. -- 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: Why is Android so buggy?
Yeah, I also get the feeling that Google simply doesn't put enough resources into Android. It's unrealistic to expect the open source community to fix all the bugs. Chrome seems to be having similar issues. It's a shame because I really like the idea of Android and it could be amazing if they put a bit more effort into it. -- 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: Why is Android so buggy?
I think we all appreciate the work that Google has done in open- sourcing Android. Like Olivier says, most of us don't have the time to spend in fixing open source bugs. Most of the bugs mentioned admittedly are easily worked around. The only serious ones are the socket ioexception bugs, but these may just be in the emulator. It would just be nice if Google could employ a few more people to go through the bug list and really look at the serious bugs to try and get them under control. That sdk setup.exe bug is a good example: apparently Xavier thought it was fixed, and yet it is been listed as an open bug since January 2010 (issue 5944). Oh, and while we're on the subject of wish-lists, the documentation needs work in many places. Apple has a useful feature - on the bottom of all of their documentation web pages there is a 'feedback' link allowing you to report bugs and missing information in the documentation. It would be useful if the Android docs had something similar. -- 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: Why is Android so buggy?
Actually, I've been using BSD sockets since about 1992 with about 10 OSes :) The bug I mentioned is not a 'timeout', it is for connection refused which (as you know) should return immediately (network permitting) with a 'connection refused' error. With Android the socket read is sitting there for minutes after receiving the connection refused packet from the server.This is when testing on a local server. There is another bug related to closing a socket: when you close a socket from another thread it should cause any threads blocking on the socket to immediately return with an IOException, but this is not happening. This second bug is more serious because there is no way to interrupt the blocking thread. It appears that it is a bug in both the phones and the emulator. Next time you accuse someone of not knowing what they are talking about, you might want to check your facts first :) On Jun 9, 5:29 am, Anton Persson wrote: > OK, the only example you bring up about ANDROID itself is the > IOException-part... That is not even a _bug_, that is a usage error. Have > you ever used BSD sockets in most other OS:es? It's up to you to handle > connection timeouts. TCP/IP over the globe, and over slow/delayed networks > will sometime cause big delays, so you can't just abort within a > milli-second each time. > > The other stuff is about developer environment specific stuff, and of them > only one is a real bug.. (The crash of the layout editor, which I agree is > serious, but I never used it myself so I don't know if it affects many > people..) -- 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
