Reicast-emulator: Add background process / pausing support for android

[sergioroprado]

This has been discussed in the past, @LoungeKatt knows how to make the OS not kill the application, @skmp knows how to add the pausing functionality.

Do we have any other tickets for this?

---

Was
Title: Keep game running when switching apps or while in background
Desc:
Make the emulator to continue running the game when switching apps or while in background.

[AbandonedCart]

If it could pause (not the game, but the entire emulator), this could be useful. Right now it seems like it would lead to more harm than good, though. I guess it depends on how much of an impact it has ob battery and such while in the background and still fully loaded.

[weihan1102]

Yes i think it is a good feature.
because you can loose all your gaming progress by a incoming call for now. :P

[skmp]

Not likely to happen very soon though, the code can't pause right now. Could freeze the threads I guess (and pray for no GC) as a stopgap

[AbandonedCart]

^ Better explanation of my vague if. I think this is something to save for later, but just isn't possible for now.

Letting the emulator keep running without the pause is going to be a nightmare if, for whatever reason, it is not returned to in a reasonable amount of time. If the system kills it off, it'll crash. If the system leaves it, you are eating battery, RAM, and processor to run a background task.

[Hellghast]

Well, why not. Let him work in the background, I would have pressed the pause and turned into the background. Would do what you need and then opened, continue the game. And the system does not shut down I use DX Toolbox. When a message arrives, you have to replay all

[AbandonedCart]

http://stackoverflow.com/questions/6524212/run-android-opengl-in-background-as-rendering-resource-for-app
It looks like unless there is a way to save and then restore the view, running it in the background won't even be supported by some devices.
http://stackoverflow.com/questions/5741257/how-to-prevent-glsurfaceview-from-recreating-the-the-opengl-surface-frequently
It is somewhat possible to keep a reference to the view, but that requires 3.0 which isn't supported until Jelly Bean MR2 (API 18), so in most cases that won't help either.

[AbandonedCart]

This would require a save state capability, but keeping it running is not possible. This is being closed and can be started up again once some variation is possible.

[blackman91]

Can this be done easier now on newer Android os versions?

[baka0815]

@blackman91 Android is not the problem, the problem is global state in the emulator. It would be necessary to refactor big parts of the emulator with the possibility of regressions to erase global state.
I don't say it's impossible, but it's a big thing to do.

[skmp]

Android kinda kills the process on background so it is partially to blame
as well.

On Fri, 15 Jun 2018 at 11:52, Christoph [e-mail] wrote:

@blackman91 https://github.com/blackman91 Android is not the problem,
the problem is global state in the emulator. It would be necessary to
refactor big parts of the emulator with the possibility of regressions to
erase global state.
I don't say it's impossible, but it's a big thing to do.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/reicast/reicast-emulator/issues/152#issuecomment-397572544,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYAMr7PysvhxtcUBs-SBnh9uoYlCHTEks5t84PqgaJpZM4Bcg5J
.

>

~skmp

[AbandonedCart]

If it were just Android killing the process, you would need to attach the activity to a (i forget the specific classification) notification that keeps it running and prevents task killer from sniping it.
Problem with that being that you are now running the full emulator alongside whatever other task.

[skmp]

we can pause the cores so it’s alright?

On Fri, 15 Jun 2018 at 16:53, TwistedUmbrella [e-mail]
wrote:

If it were just Android killing the process, you would need to attach the
activity to a (i forget the specific classification) notification that
keeps it running and prevents task killer from sniping it.
Problem with that being that you are now running the full emulator
alongside whatever other task.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/reicast/reicast-emulator/issues/152#issuecomment-397647180,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYAMsy7qepQ8HI_N2DdOSwxoCfC9oPuks5t88ptgaJpZM4Bcg5J
.

>

~skmp

[jpyper]

I'm not an Android developer, but as a Linux and Windows developer, I can suggest that the app could keep track of its visible state. When the app becomes unfocused, it could write a save state file that holds all the settings and state of the emulator (with game loaded), then reload that state file when the emulator regains focus or is loaded again.

Think of it kind of like how Firefox does session recovery after it crashes. It will ask you if you want to reload your previous session so you can continue where you left off when it crashed.

Just a thought...

[skmp]

Yeah, and there is already a ticket for this. As reicast is much higher
throughput than say firefox, it is much harder to implement these features.
And I am lazy. We emulate 100 milion of opcodes per second. Compare that to
how many tabs you open per second to see the difference in scale.

On Fri, 15 Jun 2018 at 18:41, John Pyper [e-mail] wrote:

I'm not an Android developer, but as a Linux and Windows developer, I can
suggest that the app could keep track of its visible state. When the app
becomes unfocused, it could write a save state file that holds all the
settings and state of the emulator (with game loaded), then reload that
state file when the emulator regains focus or is loaded again.

Think of it kind of like how Firefox does session recovery after it
crashes. It will ask you if you want to reload your previous session so you
can continue where you left off when it crashed.

Just a thought...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/reicast/reicast-emulator/issues/152#issuecomment-397677662,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYAMjln73KNp4rsTQLgtvq4HLx-0Wg_ks5t8-O7gaJpZM4Bcg5J
.

>

~skmp

[blackman91]

Good idea. Yeah the notification to prevent Android from killing the app and just pause the cores would be a great workaround, you would no longer lose progress just because you got a phone call.

[blackman91]

Just realized that using the app Happy Chick that uses Reicast illegally
https://github.com/reicast/reicast-emulator/issues/452 you can press the Android home button or recent apps button and reicast doesn't lose its state and doesn't restart:
https://youtu.be/HH-wBw7H2Dw

Made a quick video about it, how is that possible?

[AbandonedCart]

The workaround would be requiring users to disable the battery management on reicast and rolling the dice on whether or not simply pausing and leaving it in the background would get killed.
Using a service with startForeground() is actually the proper way to run an app in the background that you don't want killed off by memory management.
Happy Chick has little concern for anything but having it run. Whether it running in the background is a lucky side effect of their wrapper or something they actually added is hard to say when they have made a dedicated effort to hide their version of the source code.

[skmp]

@LoungeKatt can you update this ticket with what you think should be done? Will make it easier for people that want to implement / post bounties

[AbandonedCart]

Attach a service to the emu
Use startForeground() when necessary to keep it running
Handle application states

It's honestly a lot less complex than it sounds in paragraph form.

[skmp]

@LoungeKatt now that the android-studio stuff is in, can you take a look at this?

[blackman91]

Are both tickets closed now?

[AbandonedCart]

I should be able to come up with something. It may not be the most friendly on battery for any long-term backgrounding, but would work for making calls or typing a quick email.