Around 30-40% of Android apps published on play store include native binaries. Such apps need to be recompiled for RISC-V otherwise they won’t run. Neither Qualcomm nor Google can do that because they don’t have source codes for these apps.
It’s technically possible to emulate ARMv8 on top of RISC-V, however doing so while keeping the performance overhead reasonable is going to be insanely expensive in R&D costs.
Apple gross revenue is 10x the Qualcomm, and the difference in net income is even larger. Apple could easily afford these R&D costs.
Another obstacle, even if Qualcomm develops an awesome emulator / JIT compiler / translation layer, I’m not sure the company is in the position to ship that thing to market. Unlike Apple, Qualcomm doesn’t own the OS. Such emulator would require extensive support in the Android OS. I’m not sure Google will be happy supporting huge piece of complicated third-party software as a part of their OS.
P.S. And also there’re phone vendors who actually buy chips from Qualcomm. They don’t want end users to complain that their favorite “The Legendary Cabbage: Ultimate Loot Garden Saga” is lagging on their phone, while working great on a similar ARM-based Samsung.
> I’m not sure Google will be happy supporting huge piece of complicated third-party software as a part of their OS.
Yeah, for the upcoming/already happening 64-bit-only transition (now that Qualcomm is dropping 32-bit support from their latest CPU generations), Google has decided to go for a hard cut-off, i.e. old apps that are still 32-bit-only simply won't run anymore.
Though from what I've heard, some third party OEMs (I think Xiaomi at least?) still have elected to ship a translation layer for their phones at the moment.
Around 30-40% of Android apps published on play store include native binaries. Such apps need to be recompiled for RISC-V otherwise they won’t run. Neither Qualcomm nor Google can do that because they don’t have source codes for these apps.
It’s technically possible to emulate ARMv8 on top of RISC-V, however doing so while keeping the performance overhead reasonable is going to be insanely expensive in R&D costs.