A bit different, as it's mainly for voice - but I made an app 'Murmur : Bluetooth Group Calls' - that lets you hold group voice calls and message via a mesh of Bluetooth LE connections. It's available on Android and iOS. https://apps.apple.com/gb/app/murmur-bluetooth-group-calls/i...
Doesn't really get any downloads, so not sure there's much demand for this - but I use it with some shokz bone conducting headphones for talking to my wife when we're cycling (also for wrangling our two small girls)
Fuchsia has components for running APKs (Android Runner) and Linux binaries (Starnix), but that probably isn't what you meant.
The problem with replacing a UI toolkit - any toolkit - is that any change to the toolkit requires modification of all software, including third-party software. Typically, when an OS wants to provide a new toolkit, they wrap the existing toolkit in new code. For example, on macOS, UIKit wraps AppKit, and on all Apple platforms SwiftUI is a wrapper around AppKit and UIKit (depending on platform). On Windows, every UI toolkit ultimately is creating "windows" as they are understood by USER[0], which creates corresponding objects in CSRSS and/or the NT kernel, which can then be used to draw on or attach to a GPU. The lowest level UI abstraction either OS provides is the objects supported by their oldest toolkit, and the lowest level programming language you can write apps in is whatever can call it.
Linux is a bit different, because it inherits its windowing model from X11. X shipped with no default toolkit and a stable window server protocol that apps could program against directly, in an era where most GUI OSes[1] didn't have 'servers' or 'protocols'. You populated resource files and called the relevant function calls to make things happen, and those function calls became sacrosanct. Even Windows NT couldn't escape this; it still used USER despite USER being years older than NT.
The best you can do is shim the library - write something more lower level than the old junk and then rewrite the old library in terms of the new one. This is what Xwayland does to make X apps work on Wayland; and it's what Apple did (mostly) with Carbon to give a transition path to Mac OS 8/9 apps on OS X. Google could, say, ship a new Android toolkit that doesn't use Java bindings, and then make Android's Java toolkit a shim to the new native toolkit. However, this still means you have to keep the shim around forever, at least unless you want to start having flag dates and cut-offs. For context, Apple didn't kill Carbon until macOS 10.15 Catalina, and if they hadn't refused to ship Carbon on 64-bit Intel, it probably would still be in macOS today.
[0] An interesting consequence of this is that disabling "legacy input" in games turns off the ability to move the application window since all that code is intimately coupled to every app that has to open a top-level (i.e. not a widget) window.
[1] At the time that would be XEROX Star, the Lisa, and the Macintosh
[2] This is also why Apple will never, ever ship an iPad that can run macOS software in any capacity. Even if they were forced to allow root access and everything else macOS can do. The entire point of the iPad is to force software developers to rewrite their apps for touch, and I suspect their original intent was for the Macintosh to go away like the Apple ][ did.
Doesn't really get any downloads, so not sure there's much demand for this - but I use it with some shokz bone conducting headphones for talking to my wife when we're cycling (also for wrangling our two small girls)