In a Thanksgiving surprise, a new code change has revealed the first Android smartphone to be used as a testbed for Fuchsia, Google’s in-development operating system for devices of all kinds. The bigger surprise – it’s a Huawei.
Fuchsia is still such a mystery – there’s clearly a lot of effort being put into it, but at this point, we still have no solid word on that, exactly, Google intends to do with it.
It all* looks to be developed in plain sight, it’s clear what it is – a whole top to bottom OS and app dev platform – the complete package.
All we don’t know is if/when it will ever ship. I suspect there is no word on Google on this, because they simply haven’t decided. Google have the resources to fund experiments.
It might end up being junked, a testbed for ideas that get pulled into something else, or it shipped as a complete package.
If I had to bet, I’d be learning towards the latter right now.
From a developer point of view it has a number of interesting ideas and it’s nice to see innovation in this space – current OS’s feel very ossified.
*obviously can’t be sure as parts that are not public are by definition not visible.
It kind of reminds me of the research operating systems that came out of Microsoft Research a couple years ago. They were functional and really polished compared to hobbyist ones, but ultimately they were just experiments:designed to explore an approach to better inform future products.
While stuff from Singularity, Midori and Drawbridge landed up on mainstream Windows and .NET, if you pay attention to everything that Joe Duffy has written and presented about safe systems research at MSR, he has some side remarks about the political resistance from WinDev regarding those platforms.
One of the things that makes me lean towards a wholesale android replacement is the effort and thought that has appeared to have gone into managing a developer transition to the new platform.
If you can’t get app developers to transition – doesn’t matter how technically good your platform is – it’s dead – and no apps, no sales, therefore no developers.
It’s really hard to break that cycle.
They appear to be approaching this two ways – Android compatibility – run existing apps, and Flutter – which is trying to be a killer app development stack for Android and IOS and oh btw also will work on this new thing.
Only time will tell.
That’s the obvious thing. With project Treble’s modularization it’s easier to do. The most difficult thing they have to do is a compatibility layer for Linux’s system calls for code that calls them directly without using Android’s apis and it’s not that difficult: Freebsd did it before.
Linux system calls are not allowed for user space apps on Android.
https://developer.android.com/ndk/guides/stable_apis
Taken from https://android-developers.googleblog.com/2016/06/android-changes-fo…
So the only ones that would care about them are Google and the OEMs.
So it’s even easier.
I’m not sure that’s true (the restriction against non-public APIs). The syscall APIs are part of the standard C runtime. Certainly include/unistd.h and fcntl.h and friends are still present in a current NDK sysroot. What makes you think that the linux/posix system calls aren’t part of the “public API”?
The fact that I am quite comfortable with the ISO C standard.
Don’t mix whatever Linuxisms and what the C standard runtime is supposed to offer.
Try to find those syscalls APIs you refer to, in the latest draft of ISO C.
http://www.iso-9899.info/wiki/The_Standard
Additionally Android team removed all the POSIX APIs that they consider irrelevant for Android purposes.
And as of Oreo, they enabled a syscall filter that kills misbehaved apps.
https://android-developers.googleblog.com/2017/07/seccomp-filter-in-…