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