My misadventures in Android continue, and altho it seems silly to ask about everything, I haven't had any luck with trial-and-error or even Google.
I am using C++ native SDL program in android via NDK.
So first things first: I can't get as simple thing as exiting an application to work. I have fiddled hours with SDLActivity.java and the cpp but nothing seems to work. I mean exiting a program, not just minimizing the process. I know it's not advised but I would like to implement it to some of my programs.
I have tried, according to stuff found online:
System.exit() in SDLActivity
android.os.Process.killProcess(android.os.Process.myPid() ); in SDLActivity
System.finish() in SDLActivity
System.exit(0);
But nothing works, they all just minimize the process but it's still running and continues from the moment of exit when returning
The second thing is about colors. All colors I'm drawing are off when the app is running normally but they appear what they should be when something system messages or the volume dialog appears and then return to the distorted form when it disappears. Is this because perhaps I'm having wrong pixel format for the window? I'm not initializing it to anything specific.
Related
I am using the Sfml library on C4droid which has official sfml support. Everything works just fine, I can run the program normally and it renders graphics normally. But after i like minimize the app for a second and then open it back up again, for some reason it doesn't render anything at all, not even the window. Although everything else in the program runs normally like the sound,touch input, calculations etc. And I know it's not because C4droid is doing something wrong because every other graphics library i tried doesn't have that problem. Only sfml has it. I even tried it with Cxxdroid and I get the same problem.
I ran the sample programs so it's not a coding error. I tried using the the onlostfocus event to reload the files after it loses focus, I tried using only sfml shapes and no textures. But still the same thing happened. But after I tried to create a new window onlostfocus by using window.create(), It actually did render the new window even after minimizing and reopening but it only did that and didn't render/draw anything.
Is there a reason why it is happening and is there a way to fix it?
I FOUND THE SOLUTION!
I went to the sfml discord server and a really NICE person helped me out. All you need to do is just window.setActive(false) on lost focus and window.setActive(true) on gained focus AND IT WORKS FLAWLESSLY!!!
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"
When I try sharing an image through my program, the share menu sometimes comes out looking like this.
Some Notes:
1) It doesn't seem to occur on the first run, but only after I have paused the application and gone back in.
2) My app uses OpenGL extensively. It is possible I am changing a shared setting, then not returning the value back to the original.
3) Everything else in my application works fine.
4) I have tried removing all the calls that allow transparencies, and I am still having this problem.
I have this problem too. I am using a GLES 2.0 context, the only way I have been able to get rid of this... (it's going to sound weird) is by NOT calling
GLES20.glDeleteTextures ( hTextures.length, hTextures, 0 );
It wasn't happening before I started clearing up my textures, and it hasn't happened again since removing it. I have no idea why that would be though?
I'm also not sure of the ramifications of not releasing my textures.
If anyone can shed light on the matter, that'd be great, there's a few versions of questions floating around. Appears it's a problem in Unity for android and everything.
I have sometimes this problem, and not happens ever, just randomly.
I have cleaned my project and uninstall from device, compile and install again, to me works fine.
Hope this helps.
I've been having frustrating issues with the Android debugger. I can debug and step through code sometimes, then in other parts of the code (lately in try/catch situations), it goes down to the catch {} block and there is no information on the exception and it doesn't even Log.e it to console. Notice how in the screenshot I've stepped into the catch block, but there is no live variable context, its as if it is in normal content assist mode. Watch expressions show <error(s)_during_the_evaluation>.
Can anyone shed light on these frustrating issues I'm having? The weird thing that the debugger works fine in other parts of the code.
Eclipse + ADT is notorious for acting inconsistently, which often leads me to just make sure that Project > Build Automatically is checked and then simply fire up a Project > Clean....
Sometimes even that doesn't help. So I just close Eclipse and re-start it. Works most of the time.
When even this doesn't help, I close Eclipse, run CCleaner and reboot. Works every time.
Weird but true.
You can't always believe your debugger; it's an inexact science. This is especially true when there are multiple code build steps (JVM bytecode, Dalvik code, etc). The debugger often doesn't have 100% of the information necessary to reverse engineer the location in the code back to a source code line.
In the instance above, did your code actually throw an exception, or not? It sounds like it didn't, and the debugger is showing execution on that highlighted line even though it's not really going to execute it.
I would be more inclined to believe the execution of the code - if Log.e() was never called, then you never really got any exception 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.