It is well known that Android will "randomly" decide to kill the GL context of apps that is switched to the background or if your device goes to sleep, etc. If that happens all your textures are lost when the context is lost.
This is not random. Like I have mentioned before, this happens when the device decides it needs to flush the memory of its current contents in order to guarantee another application enough memory to function correctly. This depends on a number of factors, such as if other applications even request GL resources and how the subsystem chooses to compact everything. Logically, if nobody else requires resources, there would be no need to free up the space we take up. The point in time at which the system decides this should happen might be determined by some heuristic, but even that is deterministic. Computers are really bad at doing things "randomly", even when we want them to. What people perceive as random is often just something they don't fully understand, either because they lack the knowledge (e.g. proprietary software), or they don't know where to look for more information.
Does SFML recreate the GL context when it is lost? The way to do it, according to Google, is when you try to do a eglSwapBuffers, and get an error, the error returned will be that one of the 3 parts of the context is lost. Surface/Display/<Something else>.
To my knowledge, no. And judging by
the implementation, it doesn't seem to be the case. I am not the primary maintainer of the Android port, so this is all based on my brief inspection of the code.
So doing a proper shut down of everything and recreating when that happens seems like a simple thing to do.
This would be the only sane thing to do, yes.
The harder part is to reload all the textures that is lost, but this is not SFML's responsibility. There should however be some way to tell if the context was recreated or not at runtime so that the app can respond appropriately.
Your idea of leaving it up to the user to reload all their resources is indeed the simplest solution. Like you said, all that is needed for this is some way to notify them of this event (perhaps through sf::Event) and let them take corrective action on their own. The only other solution would be for SFML to store a client-side copy of every GL resource and re-upload it when the context is automatically recreated. This would mean a lot of space overhead, and just a general mess of code all over the place. It would also mean that we need a separate implementation of each GlResource class just for EGL platforms. This would become a nightmare to maintain as well.
Like I said, I'm not the primary maintainer of the mobile ports although I do work on the desktop GL implementation, so this is just my preference regarding how it should be done. Leave it to the user to sort out. It keeps the implementation simple and uniform across desktop/mobile and might even be what other libraries already do (I haven't looked around that much in this respect).
