LibGDX Saving textures to avoid context loss

I have a texture in my LibGDX based Android app that is created procedurally through FrameBuffers that I need to preserve through context loss, and it seems that the only efficient way to do this is to simply save the data, whether as a full image or raw data, out, and load it back in when the time comes. I'm struggling to find any way to achieve this though, as every route I've taken has lead to complete failure in one way or another.

I've searched around quite a bit, but nothing I've come across has worked out. I am mostly just looking for a hint into the right direction, rather than the aimless searching and attempts I have been doing thus far. I would assume the best thing would be to convert all of the data from the texture into a "buffer" of some sort, save the data internally, and then reload it and recreate the texture, but I'm not sure what the best way to go about doing that is.

The PixmapIO class is supposed to help with writing a run-time generated pixmap out. Its not quite what you're looking for with an FBO texture, though. (Its easy to go from Pixmap to Texture, but not so easy to go the other way.) If the primitives you use to generate the data in your FBO are available on Pixmap (e.g., the basic geometric primitives), that may be an alternative. I believe this is the closest libGDX comes to a supported mechanism for saving a run-time texture, but I'm not positive.

There is some libGDX code around for scraping bytes off the framebuffer (the texture data of an FBO all lives on your GPU, so you need to jump through some hoops to copy it into normal memory). See ScreenUtils and the links here about screenshots and PNGs.

It should be easy to adapt the PixmapIO to write out a "CIM" formatted file using the byte[] returned from on of the ScreenUtils methods.

Alternatively, you could track the list of "operations" that were done to the FBO, so you can just replay them (reconstructing the content later). It depends a lot on what's going into your texture, though ...