Last year the introduction of RISC-V support to the Android-specific, Linux-derived Android Common Kernel (ACK) made it seem that before long Android devices might be using SoCs based around the RISC-V ISA, but it would seem that these hopes are now dashed. As reported by Android Authority, with a series of recently accepted patches this RISC-V support was stripped again from the ACK. While this doesn’t mean that Android cannot be made to work on RISC-V, any company interested would have to do all of the heavy lifting themselves, which might include Qualcomm with their recently announced RISC-V-based smartwatch Snapdragon SoC.
No reason was provided by Google for this change, and the official statement from Google to Android Authority says that Google is not ready to provide a single supported Android Generic Kernel Image (GKI), but that ‘Android will continue to support RISC-V’. This change however, removes RISC-V kernel support from the ACK, and since Google only certifies Android builds which ship with a GKI featuring an ACK, this effectively means that RISC-V is not supported at this point, and likely won’t be for the foreseeable future.
As discussed on Hacker News, a potential reason might be the very fragmentary nature of the RISC-V ISA, which makes a standard RISC-V kernel very complicated if you want to support more than a (barebones) profile. This is also supported by a RISC-V mailing list thread, where ‘expensive maintenance’ is mentioned for why Google doesn’t want to support RISC-V.
I consider this anti-competitive behavior. As it is an intentional action designed to help Google’s partners and harm RISC-V vendors that do not have a close relationship with Google.
I’m not a lawyer, and besides it’s probably legal, not all anti-competitive behavior is regulated.
Harm what risc-v phone vendors? None exist. Zero.
You are demanding someone (not you of course) spend money on making software that literally no one is using.
I think that Jon Mayo is right, and that you (wow) are completely missing the point. Obviously, not one phone running on RISC V exists “now”, but they need some development time, don’t you think ????
The perspective to get a royalty free RISCV CPU instead of an ARM based not royalties free one is for sure something interessant for a phone maker. And more of that: I am quite sure that RISCV CPUs are ITAR free. The endeavour of destroying chinese concurrence with the Huawei affair was not enough, china is too resilient, so they use now the hardware method.
Supporting Risc-V in Android costs Google money. Android is still open source and a third party can step up and add support to android for it.
We live in a strange world when a company deciding to not spend money on supporting something is considered anti competitive behavor. I am sure that if a company wanted to have Android support on a Risc-V CPU and put resources into it then it would happen. As far as your anti-chinese theory. Well the ISA really can not be covered under ITAR and China is already making Arm CPUs and RISC-V so the whole ITAR thing just doesn’t make sense. But then I work under ITAR all the time.
As far as RISC-V and android goes that is just a not big deal. The reason that RISC-V is not in phones is that it doesn’t work for phones as well as ARM yet. Where I see RISC-V are as softcores for FPGAs. Eventually you will see them become more popular in specilized ASICs.
Yes, riscV is a open standard. At the chip level, Google is currently doing the heavy lifting to make it compatible with the Android ecosystem. They’ve learned the hard way that the companies [from China] are just forking and created closed ecosystems and dropping Android & competing head-to-head. It’s like SCO/Novell all over again.
Now if risc-v can provide 100x AI compute and 10x battery life, then end users will care and google will respond considering they are still working on it internally. Otherwise, as google stated, this doesn’t stop riscv on Android as other can “pick up the slack” (i.e. funding from others). This reaction is natural open source.
I might be missing “your” point, but “the” point is anyone can go download the linux kernel from the kernel foundation. That’s what google did and put in their android kernel repo. Google made zero changes to that source code. They deleted their repo, their copy, of the unedited unmodified linux kernel that is still available.
Or let me put it another way. You can right now go and download googles risc-v android kernel, there is an exact copy of it up on kernel.org
So yes I fail to see what development time has to do with the point. Development of a risc-v phone has to come first, then they develop drivers second, and finally once those drivers exist google can copy the linux kernel again and put that companies drivers in their copy of the kernel.
This is a simple “time” thing, before and after. Google can not host software that hasn’t been written yet. Writing that software does not depend on 3rd party hosting to exist in advance.
Moreover it is open source. Rivalry with ARM, which has just seen a new partnership with Google in Google Axion, may also be a cause for that.
I consider this an anti-competitive comment. As it is an intentional action designed by Jon Mayo to clearly discriminate against certain types of open architectures and, ultimately, harm SPARC vendors that do not have a close relationship with Jon Mayo.
I want a SPARC smartphone. I will recharge it every 2 minutes
I wonder is this a move by Google to delay the progress of others (mostly China) and give them time to define and create their own internal set of RISC-V security requirements for devices to be allowed access to their play store. And to create and put in place RISC-V applications as a requirement for play access for new applications as well as ARM. I guess what I am suggesting is that allowing RISC-V today without everything in place could reduce reduce Googles telemetry slurping from RISC-V devices and income from pushing ads to eyeballs in applications .
Nailed it.
You got it. Google hasn’t figured out to controll all the money for RISC, so they trashcanned it for everyone else
As if China was somehow limited to RISC-V or Android and didn’t have alternatives since ages ago. That would make zero sense, esp. given how big market China is for Google.
Such speculations make no sense, especially in the light of what the developers themselves (and not just Google management) said.
This is most likely simply a resource/manpower problem – similarly like they discontinued support for GPUs in Windows in Tensorflow recently. Basically if you want to do machine learning with Tensorflow in Windows you must either use WSL/Docker or have no GPU acceleration. Or move to Linux which has first class support for it.
Don’t forget that while Google is huge, it was going through rounds of layoffs and many teams got axed. Plenty of projects are maintained by a team of a few engineers that simply don’t have the means to support everything at once.
Specifically RISC-V is such case in the point – with the ISA allowing optional proprietary extensions, those have, of course, proliferated. This is great for companies tailoring the ISA for their microcontrollers and SoCs, so that they have unique selling points – and a bloody nightmare for every tooling/middleware vendor. Supporting that is a royal PITA because everything has to be compiled, tested and integrated multiple times, sapping resources. It is not only Google/Android affected but also compiler vendors (GCC …).
It was bad enough when Android software had to support multiple ARM instruction sets (ARMv6, ARMv7, with NEON extensions/without, later AArch64) and also x86 for a while. They have also deprecated/removed support for the older ones now. Given how niche RISC-V is in this market (as opposed to low end microcontrollers) it doesn’t surprise that they have simply decided to ax the whole thing outright.
“That would make zero sense, esp. given how big market China is for Google.”
How big? They shut down their offices there. Most services offered by Goggle are blocked in China. All phone vendors there have their own flavor of Android, with their own apps, and many of them with their own store, circumventing Play Store. The only real income for them from China since the sanctions are the licence fees from those vendors who didn’t simply decide to fork AOSP. I’m sure China is still highly profitable for them, but let’s not act like its market is comparable to US or EU, Google simply “doesn’t exist” there.
All these conspiracy theories are at best diapointing.
Yes it is as simple as RISC-V support costs money, RISC-V supports does not add any profit to Google’s bottom line, so you stop spending money on RISC-V support. Hey it has been branched and if people want RISC-V support they can write the code for it.
Google only maintains an ARM kernel branch to include hardware support for their phones and tablets, because for years the official kernel wouldn’t.
Google also forked a RISC-V branch but there are no changes in it, it is identical to the official kernel, so they deleted their copy.
The reason there were no changes is because no hardware exists to run android on, and thus there are no drivers for non-existent hardware, so there is nothing to add into their kernel fork.
If ever some hardware manufacturer decides to make a risc-v phone, and then they write drivers for their custom stuff, one of two things will happen.
The manufacturer will write drivers and put them in their own copy of the linux kernel, and/or, they ask google to do it for them, at which point google can click a button and recreate a new linux kernel fork again.
I wished that RISC-V had learned from ARMs mistake and had set a standard for what is in a “PC” cpu core and how it boots.
The IBM PC accidentally set the standard but it has been really use for end users.
Booting is only a tiny fraction of what makes PC different from ARM (and most other platforms). A much bigger aspect is plug-and-play, or autodetection of available hardware. On PC, you can just auto detect whatever hardware is available. On ARM, you need a device tree that describes this to your kernel, which pretty much makes it impossible to make a single distribution that you can deploy to a lot of hardware.
It’s why Ubuntu installs on any PC hardware, and only on Raspberry Pi ARM hardware.
Anything that helps prevent Android from spreading further is a good thing, in my opinion.
Now it has become yet another entry in Google’s long list of graveyard products.