12 ms·
Android and RISC-V: What you need to know to be ready
- throwaway167 3y agoWe've come a long way when Google are peddling non-free software run on freedom hardware.
- tripdout 3y agoFreedom hardware?
- preciousoo 3y agoAssuming US-market-first hardware (As opposed to EU or China). This is my first time seeing such a term too
- tommiegannert 3y agoMore likely, it allures to RISC-V being a royalty-free open standard, unlike ARM. As teraflop said, though, in practice this doesn't mean much. Chip designers will throw in proprietary IP just for patentability and differentiation.
- teraflop 3y agoCommercially available RISC-V hardware is not more "free" than other types of CPUs, in any meaningful way. The openness of the RISC-V specification is great for chip designers, manufacturers, and researchers. But it has basically no effect on end users, except indirectly (i.e. hopefully the chips are cheaper, because there's more competition and no license fees).
- leereeves 3y agoYou could also say that open source has basically no (direct) effect on end users, because the majority of end users are not coders, and even those that are rarely look at the code of the apps they use. The indirect effects are the point.
- jowea 3y agoThe indirect effect of open source software are really strong though. It only takes one coder to remove an anti-feature that the devs decided to include and publish.
- saagarjha 3y agoThe indirect effects of proprietary extensions, which means your software isn't portable anymore?
- stefan_ 3y agoWhat are the indirect effects? You realize the least troubling part of making Android run on some proprietary hardware was the ARM processor? That part is perfectly fine! It's the graphics card, the display hardware, the camera, the video encoding/decoding - these are all proprietary, undocumented blobs of IP with no upstream support. Your RISCV Android phone is still going to have all of those, it makes exactly zero difference.
- rockemsockem 3y agoWouldn't the main indirect effect be that it's easier for new companies to enter the smartphone space due to reduced costs from the ISA being open? I'd expect that to take a while, but wouldn't that be the main benefit?
- acdha 3y agoThe cost of developing a competitive CPU is high, and then you have to package the whole thing into a SoC and optimize for power usage, support it for years, etc. The ISA is not the limiting factor there.
- snvzz 3y ago>The cost of developing a competitive CPU is high It can be dodged by either licensing some of the hundreds of commercial core designs available, or by using one of the (several) available open source RISC-V implementations. Other competitive ISAs also have a few -albeit not anywhere as many- open source implementations, but there's no dodging the ISA royalty fee on these.
- rapnie 3y agoNot into open hardware, but recently bumped into this FPGA-based approach - the MNT RKX7 Open Hardware FPGA CPU Module [0] - that is a good example of how to experiment with a RISC-V design before spending the money to produce the actual chip. [0] https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.html https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...
- kllrnohj 3y agoRISC-V isn't freedom hardware, there's no equivalent to copyleft.
- ongy 3y agoThe blog post is by the open source office in Google, not specifically the android team And so far entirely about AOSP and getting that running. GApps (the non-free part) isn't mentioned at all. And like someone else said, there's use cases besides phones that use android. And some people Run de-googled android on phones, it's just degraded :/ - googler, but far from anything android
- goodpoint 3y agoThey are peddling closed software that spies on you on closed hardware.
- tripdout 3y agoSidenote, but when I learned of the new AOSP emulator, for some reason I thought that to use the Cuttlefish emulator (as opposed to Goldfish) with AOSP, you needed to run `acloud`, which refused to run unless I was on Ubuntu. I tried the LD_PRELOAD hack where you can replace the `uname` function output, but then it started trying to run dpkg (I use NixOS). The old emulator is a real pain to get working, and the new one comes with many benefits. Somehow I never knew you could just run `launch_cvd` manually.
- synergy20 3y agoit's new to me too, I don't even know cuttlefish, it has been a while
- tadfisher 3y agoIf I don't remember, please report a feature request on https://github.com/tadfisher/android-nixpkgs https://github.com/tadfisher/android-nixpkgs so we can get this packaged, at least in my SDK repo.
- tripdout 3y agoOh, hey! Love your project for running Android Studio on NixOS, will do. Would also be cool if we could get Android Studio for Platform running as well, I'm guessing it shouldn't deviate too much from regular Android Studio.
- deleted 3y ago[deleted]
- baybal2 3y ago[dead]
- hcnews 3y agoOOTL here. Are there any major phones which implement RISC-V? Also, does this require across the stack changes? i.e. not just OS ones.
- monocasa 3y agoNot yet, but they're coming down the pipe. > Also, does this require across the stack changes? i.e. not just OS ones. I'm not sure where you draw the boundary between 'stack' and 'os'. Can you expand a bit?
- AceJohnny2 3y ago> but they're coming down the pipe. Do you have any links? I'm curious, and not a little bit skeptical about the near-term competitiveness of RISC-V in the mobile space.
- fbdab103 3y agoAlso, who would potentially be building it? Unless you tell me Samsung has a five-year roadmap, I am skeptical.
- blackoil 3y agoChinese companies? they are working hard to get away from US proprietary tech.
- snvzz 3y agoProbably the same companies that contributed the initial Android RISC-V port.
- baq 3y agoEvery hardware company makes some plans that far ahead because the pipeline is so long. Details of course change a lot up to about 18-24 months before release but general direction must be known way earlier.
- awill 3y agoThey expect developers to get ready? They're thinking about this wrong. They need to make it zero work, followed by optional optimizations, like Apple did with their M1. Remember when Google told everyone to test their Android apps on x86. And then again on MIPS? And then nothing happened. Developers will not waste their time.
- Vt71fcAqt7 3y agoMost java only apps will Just Work as you just add another compiler option.
- lxgr 3y agoWhat compiler option would a pure Java app even need? Android apps aren't AOT-compiled to any specific architecture at build time; that happens after installation on the device itself.
- pjmlp 3y agoSmall correction, on Android 5 and 6, it happened during installation hence why it took ages, and an hybrid interpreter/JIT/AOT toolchain was introduced in 7. Nowadays AOT compilation happens when the device is idle, taking into account either the generated PGO metadata gathered by the JIT, or the one downloaded alongside the APK at installation time.
- lxgr 3y agoYes, but the point is that all of these are implementation details of the runtime. From an application developer's point of view, Android executes architecture-independent DEX files. All versions of Android keep the original DEX bytecode around to allow for later recompilation (JIT or AOT) and "later" can mean anything from "seconds after the APK was downloaded" to "during/after the next Android update" or "at any convenient time" (e.g. when the phone is charging and has nothing else to do).
- saagarjha 3y ago
- synergy20 3y agoa few years back, android was used "widely" in the embedded space where a GUI touchscreen is needed other than phone and tablet, now it's pretty much just for phones, and to some extent tablets. the reason is, unlike phone and tablet vendors, small players just can't catch up the new changes from Android, which is very complex, gradually they moved away.
- dagi3d 3y agoWhat are they using instead?
- hugs 3y agoRaspberry Pi using Chromium in kiosk mode and a small touchscreen is my go-to for stuff like this.
- tentacleuno 3y agoOut of curiosity, how performant is Chromium on rPI in your experience?
- i5-2520M 3y agoI tried a pi3b for stuff like this and it is fine on 720p if you don't need many/complex animations. Fine, but not good.
- kps 3y agoSome years ago I worked on software for the Google Home Hub (v1), which according to this teardown¹ has a quad Cortex-A53, same as a Raspberry Pi 3. Before Flutter and Fuchsia, they ran Chromium² on Linux, and they were fine. There was some tuning, but Chrome's performance tools³ are not bad and work decently on remote targets. ¹ https://www.edn.com/teardown-google-home-hub-smart-speaker-and-display/ https://www.edn.com/teardown-google-home-hub-smart-speaker-a... ² Chromecast builds, which are slightly less than full Chrome: https://source.chromium.org/chromium/chromium/src/+/main:chromecast/ https://source.chromium.org/chromium/chromium/src/+/main:chr... ³ https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/ https://www.chromium.org/developers/how-tos/trace-event-prof...
- darkclouds 3y ago[dead]
- ChuckMcM 3y agoI am hoping that "Android for RISC-V" is more successful than "Android for x86" which was a completely unmitigated disaster (yes I still have a Lenovo x86 Android tablet :-)) Reading this though doesn't really give me a lot of confidence though. High hopes, low expectations.
- snvzz 3y agoThe market will unavoidably be flooded with cheap consumer devices carrying RISC-V implementations as their main processors. I'd be more concerned about ARM support stagnating.
- dathinab 3y agojust because the ISA is free doesn't mean the chips will become supper cheap RISK-V is currently not really that competitive on the lower end marked as there are just too cheap ARM chips but it is e.g. very competitive for companies needing large quantities of simple but slightly customized chips where existing cheap ARM chips aren't an option and customized arm chips are too expensive and there are currently no competitive RISK-V chips in the high end marked it can somewhat compete on the mid marked, if it wouldn't be for too low quantities driving the price up it also could be interesting if e.g. Intel or AMD decides to enter the non x86 market as they could cut out license cost to ARM but all in all I wouldn't be worried about ARM support being reduced in the ecosystem for many many years to come
- MikusR 3y agoChromebooks are mostly x86 now. They run android apps. Also android emulator (not everyone is a rich american with arm macbooks).
- ChuckMcM 3y agoA constant problem on the Lenovo machines was that there was no byte order preserving when it came to data and as a result stored "state" would often blow up apps as it came back in the wrong byte order.
- jabl 3y agoSo will this require the C extension that Qualcomm seems to be so opposed to? See the subthread at https://news.ycombinator.com/item?id=37996820 https://news.ycombinator.com/item?id=37996820 Qualcomms latest: https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOSP%20Compression.pdf https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS... where they claim that their proposed "make RISC-V a bit like aarch64" Zics extension plus a 32-bit long jump achieves better code density than RV64GC, and without the downsides of the C extension they've been harping about.
- rwmj 3y agoI don't know why you're being downvoted, because this question is very much in play. If Qualcomm decide they will produce RISC-V snapdragons without the C extension then it's hard to see how Android NDK apps using the extension would work (except incredibly slowly with some sort of trap and emulate).
- fidotron 3y agoQualcomm did almost exactly that with parts of the floating point on ARM before.
- kllrnohj 3y agoGoogle can always require it to be CDD compliant, and then those RISC-V Snapdragons simply won't run Android. Just like NEON is required for all ARM CPUs since API 21.
- pjmlp 3y agoAnd Vulkan, optional in Android 7, became required in Android 10.
- dathinab 3y agoHm, qualcomms seems to have some point there, but also seems to be driven by wanting to reuse more ARM tech. I guess google forcing RV64GC or RV64G_Zigs could be the tie braker here. But while removing or changing the C instruction when it's rolled out isn't really an option as long as it's mostly about emulator testing they probably don't care too much.
- bullen 3y agoOnly a fool would run Android if they can avoid it, even more so when you get the opportunity to switch architecture and go vanilla linux. The one problem is banking, at least in Sweden we are still dependent on mobile BankID (for online purchases above $20 f.ex.), which only runs on iOS and Android.
- deleted 3y ago[deleted]
- jansommer 3y agoWe have MitID for banks and government sites in Denmark. Sometimes you also use it to authenticate purchases. You can get a small device that you use for authentication if you don't own or want to use a smartphone. It seems odd that Sweden forces everyone with a bank account to also own a smartphone. Especially when many elderly people don't have one.
- dathinab 3y agoit's not just Sweden e.g. in Germany you have similar situations when it comes to online banking for some banks (through not when it's about card->terminal payment) for example credit card apps in the EU have 2FA (which doesn't always trigger and there is still the legacy protocols for payments from outside of the EU so a bit uh, maybe, pointless) this 2FA is for most banks handled by and app (different apps tho) and many of this apps bathed in "security" snake oil making them impossible to run even on a non-rooted but de-googled android phone same for pay with you phone over NFC, e.g. it currently doesn't work for my bank with my phone and I'm speculating that it's because the secure modules attestation is not is not whitelisted (the phone uses a "industry" ARM chip instead of a typical consumer one so attestation derived ids/keys can be "unexpected") (Through also where I live there is a law for having some kind of b2b online banking API, so theoretically a company could create an app which does work on unusual phones, or create a device like you mentioned.)
- bullen 3y agoThe "small devices" (gemalto NL vasco US) are/where made in china. Those are probably going "away", at least as we know them. To boil down the problem: To access the western systems you need to keep feeding Apple, Google and Microsoft (AGM). The alternatives are non-existing still 15 years after the release of the smartphone (that in retrospective probably was the dumbest thing humans have made). The dream device = dual boot tablet Android/iOS and vanilla linux will never exist? So you have to shoot for vanilla linux (maybe ARM, probably RiscV) and tell the banks that you are dropping support for AGM. It's a "I'm not in here with you, you are in here with me" sort of moment. This goes hand-in-hand with root certificates, taxes and the health/legal system at large; everything made by humans without consulting nature first. I got popcorn, but I'm kinda worried too.
- deleted 3y ago[deleted]
- Aldipower 3y agoThe last thing I will install on a RISC-V is Google Android.
- arein3 3y agoI am wondering if RISC-V becomes often used in mobile CPUs, will this adoption have a positive effect on the ecosystem, or the big companies will steer RISC-V towards more corporate use cases and make it less friendly to enthusiasts.
- dathinab 3y agobut maybe you will buy a RISC-V with it being preinstalled before removing it ;=)
- snappyc 3y ago[dead]