> 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).
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.