[core] raylib application not closing properly

[Bigfoot71]

• I tested it on latest raylib version from master branch
• I checked there is no similar issue already reported

Issue description

An issue occurs when closing and reopening raylib on Android. In PR #3067, I added the use of exit() at the end of android_main to terminate the application. This doesn't pose a major problem in the context of using raylib with the official provided template or when no other background process is running. However, if we remove this use of exit(), the application appears to close correctly at first sight. We return to the Android home screen, and a log in logcat indicates that the application has indeed finished, but logcat doesn't show the end of the process, and Android Studio also indicates that the app is still running. If we decide to relaunch the application from Android (without manually closing it in the task manager nor exit()), the app reopens to a black screen, and we get the error EGL_BAD_DISPLAY twice in logcat.

This shouldn't happen. After calling ANativeActivity_finish and allowing the event loop to run during the closure, the application should close completely without having to call other C functions or Java methods.

Therefore, we need to inspect the code more deeply to understand what is preventing this complete closure on Android. It could be a native background process, improper deallocation preventing the system from closing the app, or something else...

Note that another solution, which is slightly more correct, can be implemented to stop the application without going through Java. This would involve calling exit() in AndroidCommandCallback within the APP_CMD_DESTROY case, which is called last, even after the onDestroy method in Java. This doesn't make a big difference in basic usage of raylib, as I mentioned at the beginning, but it's good to know.

[raysan5]

@Bigfoot71 Is this issue fixed?

[Bigfoot71]

No, I was just coming back to the fact that using exit() is not really desirable to terminate the application in a normal case, but we don't have a better solution at the moment.

All things considered, it doesn't have a significant negative impact currently. It's simply advised against because the Android system should handle the entire closing process of the application itself, which it doesn't do currently for a reason that I'm unaware of.

[makimy]

It is strange that I didn't notice the issue. I call the exit(0) and it exits without any black screens on my devices, can you please try any of the games in my profile, they're all use exit() ?

[Bigfoot71]

It is strange that I didn't notice the issue. I call the exit(0) and it exits without any black screens on my devices, can you please try any of the games in my profile, they're all use exit() ?

sorry if my message was not clear enough, this behavior happens if you reopen the application without using exit() at the end of android_main or in the last case of callback commands

we just shouldn't have to use exit() in a normal case

[orcmid]

See https://stackoverflow.com/questions/2425167/use-of-exit-function
and the approved answer, as well as the one just below that.

[Bigfoot71]

@orcmid I have to say that it's an old answer (over 13 years old). The issue with the exit(0) function is that it doesn't respect the normal lifecycle of an Android application, and therefore its closure won't be handled as expected in a normal behavior. If more than one activity is open, their closure won't be executed correctly. In a basic usage of raylib, the use of exit(0) shouldn't pose a major problem because it would be the "only" activity in progress, but it's still not a desirable behavior, especially if a developer using raylib is not aware of this fact and uses raylib along with other activities in their application.

There are multiple Stack Overflow answers advising against using exit(0) or the Java method System.exit(0), which is similar.

I can direct you to the Android documentation that explains the lifecycle of an activity.

[makimy]

To summarize my experience of using raylib on android:

• It does not save /restore activity states because it is a single Activity app
• It does not change screen orientation automatically

But:

• It starts and exits pretty well
• It receives calls when application is running (tested it)
• It hangs process when application is not active.

@Bigfoot71 , do you have anything to add to the list ? except maybe unimplemented functionality such as file writes.

[raysan5]

@makimy From the issues/improvements you comment:

• I think screen orientation change should be supported from code, I don't know why it does not work
• Afair, file-access was partially supported or some work on that line was done to support SDCard writing

About Activity state saving and restoring (after being destroyed), that's a complex topic.

[makimy]

@raysan5 You're right, it is not that simple, therefore, for my apps, I've choosen to maintain states manually.
The only idea is to make some support for Activities to run every game screen inside of them, or hm, we still don't have any events from outside thus we don't know when to save the game's state, oh no , stop, we can't save state because we can't write file. It is crazy, and I totally agree with you that it is too complecated to speak about it like - just try this, use that.

• The screen orientation works pretty well. The problem was that it forces orientation depending on the initial window size (though haven't tried to change it on a running application yet, it is why I watch the topic and comment my observations).
• I was trying to use it through the AssetManager which is currently looks like this.

[Bigfoot71]

@makimy You can easily set the screen orientation from the AndroidManifest.xml and set the screen resolution to '0,0' when initializing the window using raylib. I've created an Android implementation of raylib that simplifies handling display-related issues. If you're interested, you can find the repository here. It's also very helpful for debugging raylib on Android.

Other than that, I don't have much else to add.

[makimy]

@Bigfoot71 You're right, it works just fine and requires only changes in the AndroidManifest.xml file change the initial screen orientation. Thank you.

It might look a bit confusing, @raysan5 mentioned the problem from here . The confusion was because I didn't realize that raylib forcees screen orientation depending on the initial window size.
The problem rises too many questions such as : if I can change the orientation on the fly, how can I know if screen rotates and what have I do to it without entire reinitialization and so on and so forth.

[orcmid]

@Bigfoot71

@orcmid I have to say that it's an old answer (over 13 years old). The issue with the exit(0) function is that it doesn't respect the normal lifecycle of an Android application, and therefore its closure won't be handled as expected in a normal behavior.

Thank you for the explanation. I was commenting about use of exit(0) versus exit() (and apparently, omission of an #include of a Standard C library header which would have had the signature mismatch be detected).

On the other hand, if Android does not clean up properly on a proper exit(0), return 0;, or simply falling out the end of main, I don't think the problem is here exactly. If there are provisions that a raylib-based app must perform to exit clean, they should probably apply on all platforms and those should be addressed for portability reasons, even if simply hygiene on platforms that clean up anyhow.

[raysan5]

@Bigfoot71 Is this isue addressed? can it be closed? what is the current state?

[Bigfoot71]

@raysan5 Still nothing new, but I will update the raymob repository in a few days, so I'll have some time to dedicate to it.

I will investigate why the EGL_BAD_DISPLAY error appears twice in the logs on closure without using exit(0). There might be a link to the issue, and if there's something interesting on that front, I'll make a pull request. Otherwise, I'll just keep you updated here if there's no conclusive finding.

[Bigfoot71]

Problem solved in this PR: #3227