We’ve long suspected that Google’s upcoming operating system, Fuchsia, would join the ranks of Chrome OS (and Android) in its support for Android apps. Today, that suspicion has been confirmed by a new change found in the Android Open Source Project, and we can say with confidence that Fuchsia will be capable of running Android apps using the Android Runtime.
This just adds more fuel to the fire for Fuchsia’s future.
This needed to be confirmed? LOL Who would switch from an established ecosystem to a platform that has no apps?
Fuchsia will support most Android apps. Come again please.
And it won’t depend on the Linux kernel which is a huge plus in my book.
Ummmm Did you actually read my comment (in the context of the article)? I knew Fuchsia would support Android apps and was questioning that needed to be confirmed.
Mozilla. Firefox 57 (Nov 2017) dropped support for all existing apps (“add-ons”).
But not before large percentage was rewritten using new API.
Good story, Bra. Except I worked for Mozilla at the time, in the addons group, and was responsible for outreach to addon devs. We trackee conversion very closely. Your story just isn’t true, whether or not you want to believe me doesn’t really matter to me.
Cause Firefox has less to loose by not keeping compatibility with those old apps/modules than Google does by not creating a “smooth” transition from Android to Fuchsia.
It’s no rocket science…
You worded this strangely. What you mean, I think is “Why would this need to be confirmed? Of course they’ll support Android apps!” We all agree.
When Google made it a requirement to not use non-SDK calls, it was clear Google was making the Android API a proper standard that can be re-implemented on another OS, and even be extended with desktop functionality.
Naturally, with Fuschia everyone is looking forward to a proper desktop OS that will replace Chrome OS, which is a “worst of both worlds” operating system. It has to be updated like a normal OS (with support timelines for updates and everything), you have to manage local storage on the box, and at the same time it’s cloud dependent, unable to function without being tied to an account. Google has hit a brick wall with Chrome OS, since the more “native” (aka useful) Chrome OS apps become, the more Chrome OS behaves like a normal OS, but without having the functionality to support such a role. I really hope Fuschia is the successor to this mess.
“Fuchsia, would join the ranks of Chrome OS (and Android) in its support for Android apps”.
Why are all Os-ses that support running Android-Apps made by Google?
Why aren’t tools like BlueStacks used more often? Why wasn’t the Windows-Android-Bridge kept alive* or open sourced?
Would it be because Android Apps are 100% focussed on phones and don’t even scale/function well** on most tablet/chromebooks, let alone laptops/pc’s?
The problem with Android/ChromeOS isn’t so much the underlying OS but the apps that run on top of it. ***
Fuchsia seems to have a lot of great design goals. Extremely safe environment, Easily managed and updated, running Android apps, PWA/Chrome, probably Linux programs and maybe more. But for now it mostly seems to be “by and for developers” with no real thought about users. It is going to take a couple more years before regular users are going to be using this. Very excited to follow the progress on OSNews
* To not compete with UWP of course
** Games/Browsing seems to work quite well
*** Update-issues and driver-issues
You are conflating two different things.
– Google sabotaging independent Android API implementations by EEE-ing their own supposedly open API with proprietary Play Services APIs
– Google failing to convince developers to “scale up” the UI of their apps beyond the phone/7-inch tablet screen which is the comfort zone for most Android developers.
Google has no interest in solving the first problem (duh, they created it on purpose), but when it comes to the second problem, they hope Chrome OS apps can be used as a way to plug the desktop apps hole, possibly with some Android functionality infused in them (say managing local storage better). Hence, Fuscia being able to run Android and Chrome OS apps. And I wouldn’t be surprised if it could run a hybrid of the two, aka Chrome OS+ apps.
Android app compatibility is a small piece of the puzzle. Blackberry 10 had it, as does Jolla/Sailfish.
The main thing are the Google play and map services.
Keeping this API compatibility alive will be the killer feature which previous OS didn’t have access to. Another way to look at it is its only anti-competitive behaviour and not a technical hurdle that killed the competition…
Blackberry 10 only had partial support though – no NDK support early on, and it turned out that really supporting Android apps meant supporting the Play Store for consumers. Nook’s OS And FireOS to an extent both have the same problem.
As a side note, the Blackberry Playbook is one of the best tablets I ever owned. I’m annoyed that didn’t work out better for them.
I dunno, Google owns Play Services, they could just put it in Fuschia. But I agree that Google lied when they said the Android API is open. They EEE’d their own “open” standard. But that’s well-documented history…
I still have the idea that part of the “Android Fragmentation” problem comes in part because the Linux monokernel needs to be compiled for each device model that is available. In theory a microkernel can help on that area.
Maybe partly – I think it has more to do with simple laziness on the part of OEMs. OEMs sell hardware, not software platforms, at least from their perspective (I mean, they are pretty lazy even there, mostly just using whatever the “platform” providers like Qualcomm and Intel provide). Microsoft has had similar issues on commodity PC hardware, and their solution was to pull a lot of driver development in house over the long term.
it’s a fact that “fragmentation” is caused in part by OEMs modifying the entire stack, from the kernel to the Gallery app. The Android Compatibility Test Suite keeps those modifications non-compatibility breaking sure, but the modifications exist and hinder updates. Even Google ships a modified version of the Linux Kernel, with proprietary drivers in it, different for every Pixel or Nexus device.
BUT, that’s the start of the issue. Another issue is hardware. If your SoC doesn’t support some new OpenGL or Vulkan version that the latest version of Android requires, you will still have fragmentation. This reason, and driver unavailability for the new Android version, are the reason so many xda ROMs for non-Treble devices have problems.
Which brings me to the point: Fragmentation is inevitable. Windows has it, Mac OS X has it, even frickin iOS has it. But a good OS vendor provides tools that plug the gaps between OS versions and make new apps work on old OS versions. Which means that theoretically the device can coast with an old OS version for years, just with security updates (if they exist).
Basically fragmentation is a fact of life that Apple pretends doesn’t exist in their devices to badmouth Android (it exists, even in diminished form). It’s not an Android exclusivity like most people think it is.
Hm, Android kinda excels in that, more than say iOS …though I’m not sure if you were going there ;P
Theory and reality are two different things. History of open source Symbian that was a open source microkernel with a liberal license sends a clear warning. To get improved benchmarks ODM with open source Symbian started extending the microkernel and it started growing in a monolithic kernel direction.
Really the hint out of this hell you find in ACPI bytecode. Linux kernel does not need to be perfectly built for every x86 system because the differences can be covered by bytecode.
This ACPI bytecode is not the best performing.
Linux kernel device tree allows different parts of the kernel to be turned on and off at boot to allow one kernel to support multi devices.
You look at ebpf and fuse that is current work. Its really simple to miss that the Linux kernel is monolithic and microkernel. The microkernel parts like fuse drivers have not been as high performing as the kernel mode drivers due to context switches and other overheads.
http://vger.kernel.org/lpc-bpf.html
Compile-once and run-everywhere
http://vger.kernel.org/lpc_bpf2018_talks/bpf_compile_once.pdf
This was a very interesting presentation at this years Linux Plumbers Conference.
This open up a very interesting route.. You make drivers in bytecode that can be validated for stupid security flaws that will be built by the kernel the to native code to run in kernel space.
Reality is ODM will want to run code in kernel space to do the best in benchmarks. Also ODM will want to rebuild the kernel to exactly match their hardware again to-do well in benchmarks not that is required.
It really simple to forgot most Linux distributions ship Linux drivers by DKMS. So in theory all android devices could have the same version kernel if vendors had been mandated to-do so. Also mandated to provide the source to their drivers. The reality is they are not going to provide source to all their drivers.
And no matter what the kernel design they are going to modify the core kernel for performance if they are allowed to.
By the way there was a project to make binary unified drivers for unix freebsd and linux systems at one point it was given up on because vendors decide that making each of their drivers unique for each platform resulted in 2 percent better performance. Yes that the performance difference for vendors to give up on stable ABI. If you think for one min vendors are not as performance greedy now you have another thing coming.
Symbian wasn’t open-source, not the flavors that actually mattered. That’s S60v2, S80, S90, S60v3 and UIQ. Symbian was a proprietary OS with a source code dump of the largely irrelevant S60v5 and Symbian^3 flavors at the end of it’s life.
Also, Symbian was never a true microkernel and was never a “pure” OS anyway, its development was always aimed at commercial requirements.
That said, I am interested how the microkernel ss monolith will play out in Zircon. Will we see a microkernel GPU driver?
https://en.wikipedia.org/wiki/Symbian
kurkosdr Symbian did start life as a pure micro kernel. When Symbian was open source so it was not NDA to access source as it was early on they did not just release the source code the released information in the comments in the code that gave history back into prior versions.
Please note the NDA that was on Symbian before it was released under a open source license stated that vendors could extend it and never give back.
S60v5 contains most of the source of S60v2 and S60v3. Allows you to work out what was vendor modifications to those.
“Will we see a microkernel GPU driver” we have already seen this in minix and other places already.
Still, Symbian was made open only (too) late in its life as a response to Android… by then only Nokia was using it, anyway (well, not counting Japan-only MOAP(S) which had from the start different userland from Symbian S60 anyway)
Nokia 5230, a S60v5 hanset, sold 150 million units ( https://en.wikipedia.org/wiki/List_of_best-selling_mobile_phones ), so it was quite relevant / that’s likely more than all S80, S90 and UIQ handsets which you list as “actually mattered”…
Probably they will drop this support once Fuchsia will start taking over Android.
Google needs a unified OS that can scale on all devices and usages. Fuchsia might be able to do that.
Linux can do that now. There is no need at all to build a new OS for this particular problem. ChromeOS and Android are just two different beasts and always have been – the OS underneath them has nothing to do with any inability to scale. There’s no reason Android (with Linux kernel) couldn’t scale up with development and design effort in the GUI tier alone.
I think maybe they want to get around the challenges that the GPL presents – with a little NIH, and some microkernel ideology. It’s still a research OS at the end of the day.
I wonder how this switch over is going to work? At present, the silicon vendors are doing all the hard work of providing drivers for Linux for the hardware they’re selling. Are they going to be so keen to be doing the same work when it’s explicitly for the sake of a platform Google has total control over?
The pseudo open source status of Android has been a boon for fostering cooperation between companies that are at least notionally in competition with each other. Replacing it with a platform that is explicitly “shared source” might be a political hurdle as well as a technical one. I wonder if they’re planning on going the Windows Phone route and just mandating a set of hardware platforms that all “nu-Android” phones must be based on?
Vendors don’t give two bits about Linux, they just add their binary blob to make their hardware work.
If silicon vendors can move a couple million units by supporting Fuchsia or Tizen with drivers – they will.