> How long before Android runs properly on RISC-V?
It's mostly up to OpenJDK and V8 porting. When it comes to porting V8, I've found out the hard way that there's more to it than a generic understanding of compilers. Somebody still has to step up to the plate for a real JVM.
> And will they be able to persuade app-makers to rebuild all apps for the platform - x86 Android shows how hard that can be.
Real x86 Android devices had libhoudini (DBT), which was pretty decent. If RISC-V starts with low-end devices, or with a high-visibility model that developers are pretty sure will sell well, then the native compilation target will become more popular over time.
If China's bizarre local app market is involved, chances are they'll start supporting the target as soon as it's available.
Slightly longer answer is that _some parts_ of the OpenJDK are used. Namely, LUNI (implementation of java.lang, java.util, java.net, java.io) run on the device, but those are high-level enough that they will require either none or minimal changes for risc-v.
Compiling applications also uses OpenJDK (or the Jack compiler in platform builds) but that is an intermediate step on the host. The produced JVM bytecode gets converted to Dex bytecode during the build process.
I think the effort for Android will be two-fold:
On the software side, Bionic (android's libc), Dalvik (runtime), LLVM, external dependencies (i.e. boringssl, lib{vpx,hecv,mpeg4,etc},) definitely need work.
On the hardware side it all lies on the practical availability of a SoC. While I have no doubt we'll have something similar to android-x86 running on discrete chips, commercial devices will need a more complete cpu+gpu+dsp+modem package.
> A small correction, Android does not use OpenJDK. It uses the ART runtime
Oops! I got confused after there was uncertainty in 2015 because of the Oracle lawsuits. I believe it was reported at that time that they would switch to OpenJDK, or something similar enough was reported that that's what I remembered.
> On the software side, Bionic (android's libc), Dalvik (runtime), LLVM, external dependencies (i.e. boringssl, lib{vpx,hecv,mpeg4,etc},) definitely need work.
Not all of those need to be in software, but yes, it all needs to come together.
> commercial devices will need a more complete cpu+gpu+dsp+modem package.
Totally, though the non-CPU bits have little to do with RISC-V either way, and the drivers for them tend to be (relatively) portable C code, so that bodes well.
It has a lot of idiosyncrasies, and the upstream is a moving target.
When I began, it was easy to write an assembler (especially for RISC-V), but it was not easy figuring out which macros and stubs you needed to fill out before you could test them. It's hard to tell if you're making progress.
Each of the existing backends has its own signature, which betrays whichever backend was copied as a starting point. Some of them have comments on a given chunk, while the same piece of code in another backend might have no comments.
The other thing is the lack of a portable interpreter. This choice makes great sense from a performance perspective, but it's a pain when you just want to make incremental progress.
I have other engaging work now, so my port is abandoned, and I hadn't committed anything worth pushing for a while when I stopped.
I think it may make more sense if you ever worked on a hotspot target.
Though all things considered, I'm fairly certain I could do it in not much time if it was my full time job (which is what I said in a couple of interviews last year, when I was looking for a company willing to make that a thing).
Many apps will work with minimal if any changes as they don't use native stuff at all. There's also some interesting solutions for this like libhoudini that emulates ARM to make many native apps work without any effort on the app developers part.
I haven't thought about it much, but first reaction - I get that it might be a good candidate to get volumes up but isn't it kind of self-defeating? Why would you want to run android, of all things, on an open CPU?
Android is the leading OS for mobile phones and tablets. It is also quite popular in embedded for devices that have a screen, mostly as a side-effect of its dominance in mobile. It can often be easier to get graphics and touch drivers/support for Android compared to Linux. It is also easier to find developers who can write a custom Android app for the UI than any of the typical embedded/Linux UI frameworks, and the tooling is better.
Besides high quality hardware support and device availability. The fact of the matter is the core of Android is OPEN SOURCE. I can and have built every last bit of software on my Moto X4 thanks to LineageOS, which is based on AOSP.
ah right. the point still stands, though. i was also under the impression that many of the device drivers that ship with with modern android phones are closed source. see the step in building lineage "Extract proprietary blobs"[0]
Those are the firmware pieces running on the cores that aren't even running Android as their OS for the most part, so it's not really applicable to the root discussion.
Not the parent commenter that you are replying to, but yes LineageOS even gets the radios working. Its a full mobile android distribution that works great
i know, it's what i use daily :)
i'm fairly confident they have no builds that are "blobless" though - part of the build process is to extract proprietary code blobs from manufacturer images which are not open source, see [0]
It's extensible, so they could in theory introduce something to the ISA which would give them a competitive advantage, maybe even a publicly available extension that their competitors have simply left out, e.g. one of the crypto extensions.
There's also the benefit of being more flexible with teams who work on your SoC. With RISC-V, everyone has an ISA license, so they can contract, team-up, collaborate, or do basically anything they want, in order to work on their chips.
This also means that acquisitions are a much richer market than they are with other ISAs; in part because you don't have to justify the cost in time, money, and uncertainty of licensing or planning to license ARM.
And will they be able to persuade app-makers to rebuild all apps for the platform - x86 Android shows how hard that can be.