A Serious Bug of Android Build.

After switching OpenBOR to backend you'll find it's still CPU consuming and eats battery quickly.
I've looked into the android source and have located where the bug caused.
-------------------------------------------------------
mAudioThread = new Thread(new Runnable() {
@Override
public void run() {
if (mAudioTrack.getState() == AudioTrack.STATE_INITIALIZED) {
mAudioTrack.play();
nativeRunAudioThread();
}
}
});
--------------------------------------------------------

I've tried a lot but failed each time....




 
What did you try so far? What version you've compiled now? Remember, what is in the main build is also in the Android build as well.
 
CRxTRDude said:
Try updating your source to the latest version and re-compile it. The repo is available in SF.
I didn't test the latest version  but I think probably the bug still exists...
But I'd love to test if you have any other builds...
 
Tested it, unfortunatelly the bug was still there.
I ran a game and switched OpenBOR to backend then lock the screen...
The result was the same, my device was alway waked up...
OpenBOR was always active...


[attachment deleted by admin]
 
SimonSmith said:
The result was the same, my device was alway waked up...
OpenBOR was always active...

That's because of two reasons:
[list type=decimal]
[*]I placed a flag on Android to prevent the screen to shut off with the timeout. This way, you can check out cutscenes and game events without turning the screen on and off again and again.

[*]I placed a wakelock, this was a problem for most people, when they turn off the screen during a game, the game will shut off directly, this is a result of the fact that SDL will shut off automatically if it is out of activity for a long time.

The wakelock prevents this from happening. If you want to just play with your level without quitting, you can go ahead and pause the game and close the screen. Unfortunately, wakelocks does not close the CPU and therefore wastes battery life.
[/list]

Naturally, when OpenBOR is exited correctly (exiting the game), SDL would normally be destroyed in the OS. This is also in my case where I have closed it in the home button and the process would be destroyed eventually. That's the case for me though. For your sit, the only way to close it is to just force stop it instead.
 
I understand your point but I still confuse a little bit...

About the Android build, as I see what's in the code, there are 2 threads:

SDLThread and AudioThread.

It's actually audiothread who waked up device frequently.
If you disable audiothread( more precisely, remove nativeRunAudioThread() ), the bug will disappear. And it won't shut off when you turn off the screen or press home button and could resume normally. Of course, no sound. But it works very well.



 
Question: Did you compile that to your own using a more recent build or is this a theory? Apparently you know a couple of stuff here

Back to the topic at hand, if that's the case, it's SDL's problem :P. There's no other way to access the sound than through nativeRunAudioThread(). Also, again, the fault is in the implementation of OpenBOR. Remember that the code for OpenBOR is pretty much a convoluted mess.

Unfortunately, I can't help with that, sorry.  :( You will need someone else who knows Android programming better, I've only just done some minor things for the port, so I can't help you with deeper stuff. There was of course uTunnels, but I don't know if he's going to come back.

For now, we just stick to what we have so far, sorry.
 
...Back to the topic at hand, if that's the case, it's SDL's problem . There's no other way to access the sound than through nativeRunAudioThread().

Yes. I see. Perhaps we misused audiothread.

For now, we just stick to what we have so far, sorry.
You really don't need to say sorry and thank you very much.

Just as I said I love OpenBOR so much and I often play games on my phone.
I just want it be better and try to do something for it and that's all.
BTW, I'm satisfied with current version.
 
Back
Top Bottom