The error is basically described here. If an activity is finished to quickly after it is created, the UI is locked with an exception: "IllegalArgumentException locking surface" This is a huge problem and I'm looking for the cleanest possible workaround.
Cheers,
Whenever possible I use a Runnable instead of an Activity. However, it is messy to move data in and out of a Runnable. It's a stable workaround, but not clean.
This issue is only seen with short duration Activity instances on the Galaxy Nexus. It does not happen on older Android phones.
Related
This is a problem that kind of baffles me. I'm an experienced developer, but I am pretty new on Android and Xamarin, so I thought I'd mine the ole SO for expert input.
My app has started behaving strangely - sometimes the UI just.. stops drawing things, when exchanging a Fragment. -It's like it just gives up in the middle of drawing, so you can see that for example a label which is supposed to have the text "Search" just has the text "Sea".
Everything else in the fragment is blank, though it seems that the fragment has been created OK, and it has a filled out-layouted view and everything, when I'm debugging.
Interestingly enough; if I switch away from the app, in Android, and then back again - everything is dandy and works fine again!
There's too much code to post - what I'm looking for is clues - what kind of situation is this behaviour a symptom of? What should I start looking for?
The problem was twofold:
We tried to change the text in a UI label, from a timer handler, which was not OK, since the timer handler was in the wrong thread for that
This caused an exception which seemingly crashed the UI thread (I guess!), but due to settings in Visual Studio, this exception was not shown; hence the "unexplainable UI crash"
I'm writing an android game with OpenGL. Having dabbled a little bit with stuff before some time ago, I started tackling the problem of handling activity pausing/resuming and loss of OpenGL context knowing this is a tricky problem. Until now, if I hit the power button and then brought it back on, my app would restart and have all sorts of problems like empty textures. Since restoring the state of the app from scratch is just too much work in my case (there's a bunch of threads, complex AI states that I didn't design with this in mind, that sort of thing) I figured I would drop Gingerbread compatibility, start at Ice Cream Sandwich (API level 15), add
android:configChanges="orientation|screenSize"
in the manifest and just deal with restoring all things OpenGL. But just looking at how things behaved before pulling up my sleeves, I was surprised to see that everything worked flawlessly with no changes: textures, VBOs... Even the music picks up right where it left off. I've tested this for power off events and the home button. Now I've witnessed this on a Nexus 5 and Nexus 7 (2012) both running Android 4.4.2 and I can't help but feel a little suspicious...
So here are a few questions I was hoping some Android guru could answer:
Is it OK to do this? Is my app hogging up GPU resources in the background and draining the battery or that kind of thing?
Can I expect this to also work on previous Android versions? (I have nothing below 4.4.2)
Can I add calls to the config changes (mcc, mnc <- those are for calls, right?) and it's fine? (I have no way of testing this before a while)
Are there still cases where the GL context will be lost and I will have to recreate my GL stuff?
Thanks and sorry for the not very broad appeal and unfocused nature of the question (expecting downvotes but this stuff is just so hard to investigate)
The way I've seen this work is that the resources actually are recreated after a sleep/wake, without the developer having to do much to make that happen. Assuming that you are using a GLSurfaceView for your OpenGL rendering, and are following roughly this outline:
http://developer.android.com/training/graphics/opengl/environment.html
And then, as documented under "Activity Life-cycle" in the GLSurfaceView documentation, you hook up the onPause() and onResume() handlers in your activity to call the matching methods on the GLSurfaceView.
What I generally see happen after sleep/wake (including under 4.4.2) is that the onSurfaceCreated() method on the GLSurfaceView.Renderer implementation gets called again. Since this is where you normally create your OpenGL resources, they are in fact recreated when the device wakes up with the application running.
You can try setting a breakpoint in your onSurfaceCreated() and see if it stops there after you wake the device from sleep.
A very strange problem that cause the app to draw ontop of itself without cleaning the previous frame.
Its a bit hard to explain, see the next image:
Some other symptoms of this problem:
If I start it on emulator with GPU, the problem occur.
However if I start the emulator without GPU, it does not.
The actual device that I use is connected to a monitor using HDMI. Maybe it is related.
Any help will be highly appreciated.
This looks like a very similar problem I've posted before (link here) .
The problem is that I tried to use 2 tricks for optimization - have an empty background for both the window and its views.
The reason is that there is the window of the activity already has a default background, but when you remove it, and the views don't have a background, Android doesn't "clear" the content with the background, so it smears...
Do note that this "bug" might occur on some devices yet on others it would work fine.
In short, the solution is to set a background to either the window or its views.
Is it possible like in topic, I mean start camera intent and before opening that view set screen not to see rotating screen effectc? I was trying to use overridePendingTransition after startingActivityForResult, I tried also to put this overriDePendingTransition while calling onPause and OnResume. Somehow camera uses own animation. I would like to disable that animation. Is is possible? This effect doesn't affect in android 2.3.x. Does it might have connection with touchWiz?
TL:DR
As of KitKat 4.4.2 this still does not seem possible. Tested with AOSP phone app, Nexus 5 experience Phone App, Maps, AOSP Browser and Chrome.
(I would have put this in a comment, not enough rep yet. It's still an answer per-say, though not a solution to the problem)
Only thing I can say about why it's not possible is:
If you could force a transaction on the "external" intent through
your own app code, you would be basically injecting your animation
into another publisher's app, which would be a MAJOR design flaw
in the Android framework.
My guess is this will never be possible unless the OS manages such transactions in a bullet-proof way to both ends. Some AOSP branded-builds and custom Launchers can change default animations for ALL activity starts/resumes though (or even use no animations at all).
I'm first time developer for these types of devices, and UI in general, so I could be missing something basic and obvious.
Everything seems to work fine in the emulator, but I don't know how to simulate turning it.
So I tried running the app on my pandigital (white model - lowest of the low it seems), and each time I turn the Android, it freezes up. At least the UI freezes up, I believe the debug messages are still printing.
This is a home project, I don't have other devices to try it on.
Sorry for being so vague, it's an issue I have been a bit neglecting, trying to work on more interesting issues first, but it's an issue that is bothering me in the back of my mind.
Anyway, I have an Activity that starts up a thread, and creates a class which responds to various events, it implements: MainInterface and SurfaceHolder.Callback. Is there something else I should be handling? possibly?
Is there some specific call I get when the tablet is turned? I'd like to put a debug message in there.
My guess is that you state in your AndroidManifest.xml that this activity will handle rotation events itself (perhaps because you copied it from some project where the activity did do this), and that this statement is a lie, your activity actually makes no attempt to handle rotation.
If this is the case, a sound way to solve your problem is simply to remove the lying android:configChanges from your manifest.