Any way to save information without writing it to flash? (Must survive app close, doesn't need to survive power off)

They probably won't survive a reboot though. For example steps are stored in the Bangle and if you reboot (long press reboot) the watch you will lose a days step count as it gets reset to 0. I suspect an app switch does not cause these value to be reset in the ram used by the core Espruino operating system. But a reboot will.

It's perfectly fine if the data doesn't survive holding the button for 10 seconds. (If that's what you mean by a long-press reboot.) But yeah, it looks to me like the data is stored in the interpreter, based on https://github.com/espruino/Espruino/blo­b/d1f2ed061f7417c76587a6c4d6b641f74d2245­2d/libs/banglejs/jswrap_bangle.c. Modifying the interpreter is beyond my capabilities, and for good reason I don't think the app loader easily supports doing this, nor do I think users would like that.

What I suspect is needed long term is a way to request that a variable is made non volatile and stored in the Espruino Ram - that way it will survive an app switch BUT will get reset and cleared if the watch is rebooted. Something like Bangle.writeMemory(INT, 'freds_int', 57); and Bangle.readMemory('freds_int'); might do it. Of course such a scheme would be open to abuse by app writers who could just hog all the ram at the point of boot. So it might not find favour with Gordon.

That looks like exactly what I was hoping to find. I'm not sure whether it being able to be abused by malware is a very compelling argument against it because this is ultimately a device about giving users full control, and apps run without restriction so they can do plenty of other evil stuff like wiping the filesystem and attempting to hack other devices through Bluetooth. Plus, if someone does make an app that abuses it, there's always the option to hold the power button and reset without loading code to remove it. (Of course, others are free to disagree.) The more compelling argument against it is that it's probably quite a lot of work to implement a new feature just to make one user (who isn't providing any extra payment) happy when there are better uses of time.

There are apps that write state to flash using the onKill() event hook. I dont think a few writes a day to flash is going to massively reduce the life of the watch.

That's a good idea. I guess I'll go with one single write and recalculating the time from that rather than continuously updating, and try to only do that write when killed if necessary. This should only be a few writes per day.

Does anyone know what flash chip is in the watch/have a datasheet? Or is it a situation where the upstream manufacturer just uses whatever 8MB chip they can find that day and there's no way to know what I have?