IMO it comes down to marketing: can't have the kayfabe of selling something that is "not a computer"/"new kind of computer" and have it act like a "computer" too
Looks like Chemical Garden trilogy by Lauren DeStefano might be a fit - but as it seems to be a cross between typical young adult fiction of 2010's and poorly made romance novel, I do hope there's something less.. pulpy.. with the same premise.
Also, isn't it really stupid to treat the wind the same way we do with rivers or with electrical current (which is actually flowing the opposite way to electrons, so not like the river/wind at all)?
E.g. country A is saying that country B is stealing their incoming (upstream) wind, but there's currently a zone of negative pressure (based on the mountains/shore/passing by cyclone/whatever) on the country A's territory which actually allows for the pressure gradient to form through both countries A and B - so there's more energy potential available to tap into on country A's territory?
There's Incredibuild (paid), might be worth investigating if it fits your scenario (I have serious doubts it'll work with anything other than basic AOSP due to how lineage's ninja behaves during its early build phase of regenerating scripts from .mk/bp's).
Mind if I ask what's your current record on build time for single device/buildtype combination's systemimage on a single node?
Looks like its easy to wipe and flash the bios chip by CH341A plus a couple diodes to get voltage down to 1.8V, likely without desoldering it too; yet finding the bios image seems to be somewhat impossible due to byte rot (adding extra steps to dump the image with the CH341A, locate the start of data blocks, wipe them).
Neither, it's unethical and there's no possibility of doing that in legal way.
However I do write 1-2 hour PoCs on my spare time and my own equipment, using only publicly available stuff - they sometimes come handy at some point later. If we assume 'remote first' development is okay - with no possibility to test stuff locally, well, we're back to either bookmark managers or pet projects to keep at least a bit of knowledge between jobs.
IMO there are some workloads, where it is beneficial for a developer to have access to a local repository with at least some snippets based on previous projects.
Having a leftover PoC of some concept written for a previous employer but never elevated to team use/production is both handy (at least to confirm that the build environment is still viable after an unspecified period of toolchain updates) and ethical (copying production code is not ethical - even if the old and new products are vastly different e.g. last job was taxi app, new app is banking app).
Making it all 'remote' and 'cloud' will eventually result in a bike reinvention penalty on each new employment - not everything can be rebuilt from memory only, especially things that are done 1-2 times a year; sure there is open-source documentation/examples, but at some point it'll just introduce even heavier penalty for a need to either know a lot of opensource stuff to have some reference points, or to work on a pet projects to get the same amount of references.
> special locally installed apps in enterprise ChromeOS environments
There was https://developer.chrome.com/docs/apps/overview though, so this seems to be a kind of planned feature creep after deprecating former one? "Yeah our enterprise partners now totally need this, you see, no reasoning needed"
And they will provide it as required per law. Note that the law does not require them to provide that in a form that would be usable for anything practical without doing moderate to heavy amount of reverse engineering (e.g. here's the source, here's the toolchain that was released in approximately same period of time, go figure out if this can even be built without recreating part of their internal build system, missing configs, etc).
Ooh substances - scary stuff. Must be very dangerous to allow selling a thing that could be made with any CNC router out of scrap, so let's also ban CNC routers.. eventually, let's ban hands as they can be used to do stuff. /s
Another reason is that giving users the option to root and unlock is possible only after ditching whatever agremeent is in place with Google. So, no Play support for this vendor at all means no sales to normal markets.
Going deeper in conspiracy theories, Google would drop Qualcomm/Mediatek from the ecosystem if they'll ever allow a single SoC licensee to do such phone.
Last decade's definition of "power user" is "being able to type on physical keyboard and have more than 1 window open at a time", and Android caters to that; it would not even remotely be decent, though it'll likely eat just a bit more battery and cpu than a pure XFCE running without compositing.
So far, we can't even get Samsung to have their FOSS kernel stuff published in a buildable and usable form - its basically impossible to build their recent kernels with their recent toolchains without finding out that some obscure config option was skipped or that some file didn't survived the pre-release purge or that it requires some obscure Linux distribution to run on. And if you get it to build, chances that it will boot are slim. (Good luck finding out if there's a working UART somewhere on chip pins and it's not hidden behind hypervisor and fuses)
There's likely a statement in Play Services ToS for vendors to do all things possible to prevent bootloader unlock/relock flow from happening - reasoning from the fact that yellow AVB state is non-existent outside Pixel devices.
Maybe it goes as far as for SoC vendors, as well.
So far, outside of Huawei, no top tier hardware vendor ever decided that denying Play functionality to their users would be profitable - also all Mediatek based devices are basically licensed by mediatek afair, so there's no chance of, say, Vivo/Realme suddenly deciding to ditch Play and do bootloader relocking.
Also the possibility of postmarket devices running non-bloated OS is a loss for a vendor since it both reduces the appeal of whatever next "+1% cpu +1% battery" lineup update (and its a bad idea to sell 200k "good device model 1" rather than 100k "bad device model 1" and "bad device model 2", because PR/stocks/whatever) and increases the possibility of having users dissatisfied with the brand name because battery/flash degradation is still a thing.
I'd go for a "real device cloud", AWS/testgrid/browserstack/whatever.
However depending on your users' demographics, it might be a good idea to take a look at https://dontkillmyapp.com/ and get few used devices from huawei/xiaomi to run local tests as well, generally the farm experience wouldn't exactly match local experience (e.g. what happens when you leave the device without usb connection running overnight, what happens when you leave device unattended for a week). US/Europe? Don't bother. EMEA? Maybe get a couple devices running lineageos/grapheneos/calyx as well. China? There's https://www.alibabacloud.com/help/en/mobile-testing but it wouldn't match real user experience due to how dpi/GFW is set up.
It is possible to have a project set up with a manifest which contains only a single activity with android.app.NativeActivity pointing to a .so, and zero lines of java/kotlin/flutter/whatever else - though your app initialization will go through usual hoops of spawning a java-based instance.