Work on this Fuchsia project within Android — dubbed “device/google/fuchsia” — stalled in February 2021, with no public indication of how things were progressing. This week, all of the code for “device/google/fuchsia” was removed from Android, formally signaling the end of this particular avenue.
In its place, we have a lone “TODO” message, suggesting that Google may be building up something new in its place. The developer responsible for the change primarily works on Fuchsia’s “Starnix” project.
First shared in early 2021 as a proposal, Starnix is designed to make it possible for Fuchsia to “natively” run apps and libraries that were built for Linux or Android. To do this, Starnix would act to translate the low-level kernel instructions from what Linux expects to what Fuchsia’s Zircon kernel expects.
Fuchsia is still very much in flux, and stuff like this further illustrates that while I firmly believe it’s the future of Google’s consumer operating system efforts, it’s still got a long way to go.
The android SDK is fairly well abstracted and should run very transparently on fuchsia. Android packages running native code/libraries may be more challenging. I’m not sure how prevalent precompiled android native binaries are in the wild?
Obviously they’re not there yet, but I don’t see a technical reason google shouldn’t be able to get this working. Most users probably won’t even realize there’s a new kernel under the hood. I think the success of fuchsia will ultimately come down to whether or not they get this right. Companies must never underestimate the power of network effects since it’s usually more important than merit. It doesn’t matter how good a platform is, if it doesn’t support a critical mass of apps and devs out of the box then failure is almost certain.
Essentially all OpenGL-ES, OpenGL, and Vulkan games for Android are written in C or C++ and compiled to native binaries using the Android NDK. Multimedia codecs (like the ones bundled in MxPlayer) are also native code.
Indeed they are, and per definition of what public APIs are available to NDK, nothing Linux specific is exposed.
Code that ignores that and still tries to use Linux specific stuff, might get lucky, work on some devices, fall spectacularly on others, or be killed by the Android security measures on later versions.
ISO C and ISO C++ standards aren’t Linux specific, not are OpenGL and Vulkan.
The codecs use Android specific NDK APIs.
So even on worse case, it is a recompile away of running on those games on Fuchsia based Android.
Sorry but this is pretty much the best-case scenario. Worst case is that there’s no-one to recompile the original code. While not probably an issue for anything found publicly on Play Store, corporate apps might be a different story.
It’s also possible that the Android native APIs just aren’t compatible with how the Fuchsia works in general, or that Google has no intention of providing the same APIs for Fuchsia directly.
sj87,
That’s interesting to hear. I would have thought the opposite. Corporate software is more likely to be supported whereas many of the studios developing for app stores may be defunct. But this is just speculation, I don’t have data.
I do agree with you about the problem of unsupported apps not having anyone to recompile them. But this is exactly what Starnix is aiming to solve. As long as they actually follow through and don’t cancel it, then I think it should work.
That’s interesting to hear. I would have thought the opposite. Corporate software is more likely to be supported whereas many of the studios developing for app stores may be defunct. But this is just speculation, I don’t have data.
I don’t think that’s a reference to corporate software, but to in-house “we funded a team to write an app for our employees or a customer and then there’s no budget to maintain it”. I work for a large company and this happens *all* *the* *time* (addmittedly not apps, but web sites tools, etc.). No one wants to budget on-going maintenance.
Alfman,
There are also quirks in licenses that might not allow recompilation.
Microsoft currently has that problem with Xbox backwards compatibility. After the PowerPC -> AMD64 switch, they decided to add a back-compat layer after many requests.
However they cannot release more than half of the back catalog, since they need to ask permission to recompile and re-distribute the binaries. Technically Xbox One was a different platform than Xbox 360.
I have no idea how App store licensing works. Yet, if the apps themselves have asked to be run on only certain hardware, even with the best emulation of the APIs, it might not be possible to support some of the software.
Hope I am wrong about this.
kurkosdr,
Developers can use the android classes for opengl too…
https://developer.android.com/guide/topics/graphics/opengl
I don’t have a good handle on how many developers have chosen to use NDK version of opengl versus the android framework.
Anyways, if we’re talking about 1st party NDK APIs (including those for opengl), obviously google can port those so it won’t be a problem. My gut feeling is that 3rd party code/libraries google doesn’t control could be a bigger problem (like the multimedia codecs you mentioned). But then the question is whether this 3rd party code relies on linux specific APIs? I don’t know. My own code does use linux primitives like epoll, but I’m not an android developer and I am not familiar with what practices are typical in android development.
Even in the worst case scenario though Starnix can just emulate the linux userspace APIs, so I don’t see anything insurmountable at least for the majority of apps.
Officially you aren't allowed to use Linux primitive on NDK applications, that is why Termux guys are having such a hard time moving forward, because they refuse to acknowledge the fact that they are required to use JNI calls instead.
> Native libraries must use only public API, and must not link against non-NDK platform libraries. Starting with API 24 this rule is enforced and applications are no longer able to load non-NDK platform libraries.
https://android-developers.googleblog.com/2016/06/android-changes-for-ndk-developers.html
Later Android releases claped down this security restrictions even further.
Meaning these NDK platform libraries, https://developer.android.com/ndk/guides/stable_apis
Maybe in the next 10 years then. Anyway. Google just RTFM on how to use Linux properly. Provide maintained and upstream FOSS device drivers for your lineup of mobile devices. After that is done you have resolved all the issues you are having. Due to misuse of GNU/Linux. And on top of that you resolve all the problems you are trying to resolve with Fuchsia. You will do that eventually anyway. It’s not like there is a choice involved. Superior solutions and technology in the end wins. Not even Google can hold the progress back. Hence stop with this foolishness and just do your job instead.
Geck,
Google’s own phones are a tiny fraction of the market.
https://www.statista.com/chart/25463/popularity-of-google-smartphones/
Meanwhile almost all arm devices fail to work with mainline drivers. You should take aim at companies like qualcom instead who are the ones directly responsible for proprietary code. I know you are hell bent on blaming google because you’ve got some kind of political axe to grind there. I’m no fan of google, but the fact is this is an industry wide problem; you need an industry wide solution instead of taking pot shots at google.
These are some bad stats the contradict pretty much everything else, which is unsurprising for a voluntary survey of ~5000 people. If you quickly Google some real market share numbers you’d see Android dominates everywhere other than highly developed countries, and only in highly developed countries is there a decent amount of iPhone market share.
dark2,
I don’t think the numbers are bad. Here’s a different source that puts google’s phone marketshare in the same ballbark.
https://www.androidauthority.com/google-pixel-market-share-3167012/
About half of smartphones run the android OS, but then you’re including non-google phones. Google’s own phones are only about 3% of the market. The hardware driver problem is much bigger than google.
At least with google’s in house silicone, they are pushing for mainline source…
https://www.xda-developers.com/google-pixel-6-6-pro-mainline-linux-kernel-support/
Alfman,
Yes, in a hindsight, I am pretty sure Android teams would have designed the core system very different back in the day.
Maybe repeating this point we have talked for the n’th time, but given so many chefs in the Linux ARM driver support ecosystem (Linux kernel developers, chipset developers, phone developers, GSM operators, probably others I don’t know, and of course Google/Android), it is not an easy problem to solve.
Pretty sure it’s more of a cost benefit analysis of all the work they’ve put into trying to keep the Linux kernel while using hostile OEM drivers that don’t release updates to drivers for new kernels, keeping their own separate Linux fork maintained, however many millions of dollars project Treble costed, etc. They’ve surely run the numbers as found developing a true purpose built OS from scratch is more cost effective than trying to keep Linux on their mobile devices. When Silicon valley needs to rush a product out so they aren’t pushed out of the competition they use Linux, but it’s time to move on to something better for customers. You can fully expect Fuchsia devices will be as upgradable as iPhones and have as much fragmentation when they come out.
dark2,
+1
I won’t commit to the fuchsia bandwagon yet…we’ll have to see where it goes.. But given the systemic troubles we’ve been having under the current technology I am ready to welcome more competition to this space. We desperately need new ideas and other options.