That whole process lifecycle thing that you have to jump through with activities and bundles and what have you is so that your app disappears not just out of RAM, but out of the scheduler too from a piece of code that can make such decisions at a complete system level. Yes, it kills processes essentially arbitrarily, but the processes should have all of the hooks and places to squirrel away state to come back from the aether as if nothing happened. Programming Android code should embrace that rather than fight it.
As for webview, I think they're generally pushing a security fix and think that your app should be able to pull itself back together, the same as if a browser was refreshed.
I can't think of work that needs to be performed that requires a GUI to constantly be loaded, but doesn't require that the GUI be in the foreground.
It shows stuff like weather, clock, calendar, land-line phone calls and has buttons for light scenes.
I used to use Chrome for this, but I always had to manually maximize the page, and hosting it in a custom app has additional benefits, like loading and maximizing the page as soon as the device boots, and offering a JavaScript interface so that the page can interact with Java functionality. It's much better that just hosting the page in Chrome.
Each time Chrome gets updated, the app gets killed. And even though the app has set up an alarm which makes Android call into the app every minute to ensure it is running, for some reason this doesn't bring up the UI (probably something which I need to debug).
But I know that if this app were running on Linux directly, in some Python Qt app with a Qt WebView, it would never get killed, as it has plenty of resources available.
I've also considered integrating Mozilla's rendering engine into the app, but decided not to, I can't remember why, but there were some drawbacks in doing so.
It would be hard to imagine using such an app in an industrial setting, where the app would need to be visible all the time, displaying gauges and stuff like that. The hardware could do that, with a proper OS.
Try postmarketos, it's designed to run vanilla Linux on old devices such as phones.
CPU and USB OTG generally works, which already make for a pretty general-purpose machine. The touchscreen also works most of the time. The rest is generally hit-or-miss, depending on how much time you or the maintainer spends on making it work, or if there has been a mainlining effort.
Some of these devices already have 12 GB RAM and octacore processors, that's more than a Raspberry Pi.
When these devices reach their EOL as a phone/tablet, they would make wonderful SBCs with integrated touchscreen, camera and microphone, and in the future also good AI co-processors for good on-device speech or face recognition. All this with an up-to-date OS, and not an Android version which is over 4 years old.
Whatever I try with Android, sooner or later the processes get killed.
What's worst is that when Chrome gets updated, any app using a WebView gets killed. Why not just let it continue running and make it use the new WebView after it gets started again manually?