I meant - If we use the app for a longer duration of time without navigating out or switching to a different app we see Canvas Lock with Bad address.
Hmmm... since that [particular case] pretty much eliminates problems caused by activities going to the background and possibly being killed, that suggests that the problem is in how you are rendering to the surface. See below.
Even when we keep transitioning between activities quickly, after 15-20 tries, we observe the same "Lock Canvas" issue.
(Which suggests a resource / other memory leak or releasing problem, or threading issue. Can't think how to progress that one for a moment.)
The first activity has a GLSurfaceView on which we render Bitmaps(drawing in DIRTY MODE). This activity is never finished.
But have you accounted for the possibility of your app being killed under heavy device load while it is in the background, for the case where fast switching back and forth causes the failure ('fast' implying that it might not be getting time to garbage collect properly, causing allocated memory build-up)?
(I don't know how one should protect against that other than to save program state on a pause - I'm hoping more experienced members are still reading this along with us.)
These bitmaps are rendered/cleared from the GLSurfaceView everytime an activity is Entered/exited from, using Broadcasts.
Can you be sure you are not trying to use information in a broadcast receiver that may no longer be valid because the calling (= broadcast-sending) code has dumped it too early? (It is my understanding that broadcasts are asynchronous - if that is not the case, then ignore this bit.)
After a bitmap object becomes useless in the context, we pop it from the stack, call recycle to free native memory and nullify the java reference.
Sounds pretty sensible. In case the problem is gc not getting enough time to do its job, might be worthy temporarily calling System.gc() every time you dump a bitmap - I'm not sure this is a wise choice for permanent code, but it might help show if the problem lies in this area.
Yes, if we remove the calls to GLSurfaceView.requestRender() the issue goes away.
OK, but now a slightly different test: go back to calling requestRender() as before, but in your custom renderer, just do some standard OpenGL stuff like outputting a dummy triangle or two; don't try rendering the bitmap to the surface. So we're going through the frame rendering process (basic OpenGL stuff), but avoiding doing anything fancy with a bitmap (not that rendering an image to an OpenGL surface should be a problem, but still). Don't create any bitmaps or destroy them - so we're basically trying to take the bitmap itself out of the equation and see if that is where the problem lies).
(This should be a separate test from trying System.gc() mentioned above - try gc() first, as is the quickest to try.)
-- 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
