10 ms·

They 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

by awill 3y ago

They 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 ago
Most java only apps will Just Work as you just add another compiler option.
- lxgr 3y ago
  What 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 ago
    Small 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 ago
      Yes, 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
That's because nobody shipped devices that mattered with that architecture.
- Georgelemental 3y ago
  Could the causal chain go the other way? (Nobody shipped any devices with that architecture, because app availability was too low)
  - toast0 3y ago
    It's possible, but I think the more likely issue is nobody shipped very many devices with x86, because Intel cancelled development of x86 for phones[1] before they had many design wins. Also, and I missed this at the time, it seems like Qualcomm was restricting manufacturers from also using competitors chips[2], although it seems the ruling was reversed on appeal [3], there's still evidence of restrictions. It would be unappealing to market an x86 device if it means losing access to Qualcomm cpus, especially in an era where Qualcomm modems were practically mandatory, so it makes sense that the only x86 (Asus Zenphone) I can think of is made by a company that didn't make a lot of phones. Personally, I don't think the lack of app support would have been that much of a problem for sales of phones in the 2012 to 2016 time frame. If you got a couple hundred thousand phones out there, app developers would add support, because it wasn't too hard, a lot of developers were running x86 Android emulators, and they may have already had the x86 native code libraries and just didn't ship them because why bother when there's no phones. Some of the first generation Asus Zenphone ran on x86, and it might have been rough for a while, but I think they sold reasonable numbers, and app developers started shipping x86 libraries. I don't know when Google Play added support for ABI specific APKs, maybe that was a factor too (if you have to have everything you support in the APK, then you'll be careful about what you support) [1] https://www.pcworld.com/article/414673/intel-is-on-the-verge-of-exiting-the-smartphone-and-tablet-markets-after-cutting-atom-chips.html https://www.pcworld.com/article/414673/intel-is-on-the-verge... [2] https://www.cnn.com/2019/05/22/tech/qualcomm-antitrust/index.html https://www.cnn.com/2019/05/22/tech/qualcomm-antitrust/index... [3] https://www.reuters.com/article/us-qualcomm-antitrust-idUSKCN25729F https://www.reuters.com/article/us-qualcomm-antitrust-idUSKC...
leonidbelyaev 3y ago
I don't think that makes sense. RISC-V is by definition a new ISA, M1 is based on the existing ARM ISA.
- gumby 3y ago
  That transition was from x86 to ARM. This is ARM to RISC V.
  - spookie 3y ago
    From a mature architecture to another, versus going to a "pretty much only used on embedded devices" arch? Yeah, they really have got their work cut out for themselves!
    - IshKebab 3y ago
      Android phones are pretty much embedded devices though (unfortunately) so I suspect we'll see a load of phones that have super custom kernels with tons of hard-coded driver configs etc. Similar to SBC other than the RPi. It's kind of an issue for ARM too but they're a bit further towards solving it than RISC-V. In any case it's mainly a problem for people that want OS updates or the ability to install other OSes, so it's not going to affect app writers or normal users much.
      - snvzz 3y ago
        >It's kind of an issue for ARM too but they're a bit further towards solving it than RISC-V. Can you elaborate on why you think so? I understand it is the opposite: RISC-V is much further towards solving it. This is because RISC-V has put effort from the start into standardizing boot process (spl -> sbi -> uboot|uefi), ISA (profiles), the firmware-kernel interface (sbi, uefi protocol, acpi) as well as the platform itself (platform spec, standards for interrupts, timers, hypervisor support, the uart requirement, the watchdog and further platform standardization efforts). This has happened (and is happening still) before significant deployment of SoCs using RISC-V microarchitectures as the application processor. Meanwhile, ARM realized, quite late, that this is important, and is lagging behind, with plenty of non-fixable, bespoke platform hardware deployed, and low vendor uptake as they are asking their clients to change what they already have in place.
ojn 3y ago
Zero work? I guess memory fades quickly sometimes. Apple rented out DTK systems for $500 for developers to get their hands on ARM hardware and port their applications. Hardly zero work. You couldn't even keep the hardware, you had to send it back (and originally you wouldn't even get $500 in credit to buy a production system with, luckily they fixed that after the easily predictable uproar). Google is providing software emulators instead, much easier to work with and doesn't require complicated device logistics. Not only that, but the only audience that really needs to do work to get ready, are either those producing NDK applications, or those working on hardware support for RISC-V. Java/Kotlin applications would not need any porting. Sounds like zero work to me!
- lxgr 3y ago
  If you were initially fine with software emulation (i.e. Rosetta 2), as were many small and large software projects for macOS or Unix, you had no need whatsoever to get a DTK.
  - makeitdouble 3y ago
    > If you were initially fine with software emulation (i.e. Rosetta 2) You'd need a DTK to know if you're fine with emulation or not. If you cared at all about your app running, you wouldn't just assume that it magically runs fine on an emulation layer you never touched, and that at speeds that are reasonable. For a reference point, Rosetta was far from being great, and while some apps could run against it, it was most of the time an ultra painful experience. That pain helped devs to put the effort into making native versions, but it also means you couldn't expect Rosetta 2 to give acceptable performances from Apple's track record.
    - xvector 3y ago
      Are you talking about Rosetta 1 or 2? Because Rosetta 2 was not an "ultra painful experience" in any sense of the phrase. Rosetta 2 was straightforward and surprisingly fast, requiring zero tweaking or user interaction. Most people never even noticed.
Sparkyte 3y ago
I just expect better compilers. Having a diverse platform is very healthy, but it is completely unreasonable to expect people to keep switching technology if it isn't easy to adopt.
kllrnohj 3y ago
> 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. x86 builds of Android apps & libraries are extremely common to have since it's the most common target for emulators. As for MIPS, I don't think Google ever pushed it. It was just kinda there. Also also, this blog post is aimed at device manufacturers more than app developers which is why it talks about building AOSP & pending patches. It's not asking app devs to do anything (in fact it even says at the bottom "Make sure to stay tuned as we look into ways to make it as easy for Android developers writing native to target new platforms as it is for our Java and Kotlin developers!")
a-dub 3y ago
if you don't use the ndk, isn't it, in fact, zero work? how prevalent is ndk use? games and multimedia apps maybe?
roneythomas6 3y ago
MIPS died for Android after Imagination Technologies acquired it in 2013. There is nothing for Google to do when there is no new SOC or new phones. As for x86, it is still widely used thanks to Chromebooks. Unless you use NDK there is nothing on your end to do for new targets.
- kimixa 3y ago
  MIPS died for android well before that - they only had microcontroller-level cores in development, which were rather unsuited to the performance requirements of android.
qwery 3y ago
> They expect developers to get ready? No, I don't think they do in a general sense. It's in the title: "What you need to know to be ready" --> if you would like to be ready, we have some information/advice for you. You can take it or leave it. % Note: I'm using the word "you" here as it is used in the title, not you specifically.
- Lammy 3y ago
  https://en.wikipedia.org/wiki/One_(pronoun) https://en.wikipedia.org/wiki/One_(pronoun) :)
  - circuit10 3y ago
    "The pronoun one often has connotations of formality, and is often avoided in favour of more colloquial alternatives such as generic you."
rickdeckard 3y ago
Not every developer is an App-Developer. Some develop platforms, devices, physical products
Rebelgecko 3y ago
It's a whole new architecture. Developers have to put code to support it into the AOSP. It's actually pretty similar to Apple and the M1 (although IIRC all of that development was done behind closed doors). Apple had to do a ton of work to smooth out the M1 transition, and it'll take a lot of work to make the process equally smooth on Android

by awill 3y ago

Vt71fcAqt7 3y ago

Most java only apps will Just Work as you just add another compiler option.

lxgr 3y ago
What 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 ago
  Small 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 ago
    Yes, 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

That's because nobody shipped devices that mattered with that architecture.

Georgelemental 3y ago
Could the causal chain go the other way? (Nobody shipped any devices with that architecture, because app availability was too low)
- toast0 3y ago
  It's possible, but I think the more likely issue is nobody shipped very many devices with x86, because Intel cancelled development of x86 for phones[1] before they had many design wins. Also, and I missed this at the time, it seems like Qualcomm was restricting manufacturers from also using competitors chips[2], although it seems the ruling was reversed on appeal [3], there's still evidence of restrictions. It would be unappealing to market an x86 device if it means losing access to Qualcomm cpus, especially in an era where Qualcomm modems were practically mandatory, so it makes sense that the only x86 (Asus Zenphone) I can think of is made by a company that didn't make a lot of phones. Personally, I don't think the lack of app support would have been that much of a problem for sales of phones in the 2012 to 2016 time frame. If you got a couple hundred thousand phones out there, app developers would add support, because it wasn't too hard, a lot of developers were running x86 Android emulators, and they may have already had the x86 native code libraries and just didn't ship them because why bother when there's no phones. Some of the first generation Asus Zenphone ran on x86, and it might have been rough for a while, but I think they sold reasonable numbers, and app developers started shipping x86 libraries. I don't know when Google Play added support for ABI specific APKs, maybe that was a factor too (if you have to have everything you support in the APK, then you'll be careful about what you support) [1] https://www.pcworld.com/article/414673/intel-is-on-the-verge-of-exiting-the-smartphone-and-tablet-markets-after-cutting-atom-chips.html https://www.pcworld.com/article/414673/intel-is-on-the-verge... [2] https://www.cnn.com/2019/05/22/tech/qualcomm-antitrust/index.html https://www.cnn.com/2019/05/22/tech/qualcomm-antitrust/index... [3] https://www.reuters.com/article/us-qualcomm-antitrust-idUSKCN25729F https://www.reuters.com/article/us-qualcomm-antitrust-idUSKC...

leonidbelyaev 3y ago

I don't think that makes sense. RISC-V is by definition a new ISA, M1 is based on the existing ARM ISA.

gumby 3y ago
That transition was from x86 to ARM. This is ARM to RISC V.
- spookie 3y ago
  From a mature architecture to another, versus going to a "pretty much only used on embedded devices" arch? Yeah, they really have got their work cut out for themselves!
  - IshKebab 3y ago
    Android phones are pretty much embedded devices though (unfortunately) so I suspect we'll see a load of phones that have super custom kernels with tons of hard-coded driver configs etc. Similar to SBC other than the RPi. It's kind of an issue for ARM too but they're a bit further towards solving it than RISC-V. In any case it's mainly a problem for people that want OS updates or the ability to install other OSes, so it's not going to affect app writers or normal users much.
    - snvzz 3y ago
      >It's kind of an issue for ARM too but they're a bit further towards solving it than RISC-V. Can you elaborate on why you think so? I understand it is the opposite: RISC-V is much further towards solving it. This is because RISC-V has put effort from the start into standardizing boot process (spl -> sbi -> uboot|uefi), ISA (profiles), the firmware-kernel interface (sbi, uefi protocol, acpi) as well as the platform itself (platform spec, standards for interrupts, timers, hypervisor support, the uart requirement, the watchdog and further platform standardization efforts). This has happened (and is happening still) before significant deployment of SoCs using RISC-V microarchitectures as the application processor. Meanwhile, ARM realized, quite late, that this is important, and is lagging behind, with plenty of non-fixable, bespoke platform hardware deployed, and low vendor uptake as they are asking their clients to change what they already have in place.

ojn 3y ago

Zero work? I guess memory fades quickly sometimes. Apple rented out DTK systems for $500 for developers to get their hands on ARM hardware and port their applications. Hardly zero work. You couldn't even keep the hardware, you had to send it back (and originally you wouldn't even get $500 in credit to buy a production system with, luckily they fixed that after the easily predictable uproar). Google is providing software emulators instead, much easier to work with and doesn't require complicated device logistics. Not only that, but the only audience that really needs to do work to get ready, are either those producing NDK applications, or those working on hardware support for RISC-V. Java/Kotlin applications would not need any porting. Sounds like zero work to me!

lxgr 3y ago
If you were initially fine with software emulation (i.e. Rosetta 2), as were many small and large software projects for macOS or Unix, you had no need whatsoever to get a DTK.
- makeitdouble 3y ago
  > If you were initially fine with software emulation (i.e. Rosetta 2) You'd need a DTK to know if you're fine with emulation or not. If you cared at all about your app running, you wouldn't just assume that it magically runs fine on an emulation layer you never touched, and that at speeds that are reasonable. For a reference point, Rosetta was far from being great, and while some apps could run against it, it was most of the time an ultra painful experience. That pain helped devs to put the effort into making native versions, but it also means you couldn't expect Rosetta 2 to give acceptable performances from Apple's track record.
  - xvector 3y ago
    Are you talking about Rosetta 1 or 2? Because Rosetta 2 was not an "ultra painful experience" in any sense of the phrase. Rosetta 2 was straightforward and surprisingly fast, requiring zero tweaking or user interaction. Most people never even noticed.

Sparkyte 3y ago

I just expect better compilers. Having a diverse platform is very healthy, but it is completely unreasonable to expect people to keep switching technology if it isn't easy to adopt.

kllrnohj 3y ago

> 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. x86 builds of Android apps & libraries are extremely common to have since it's the most common target for emulators. As for MIPS, I don't think Google ever pushed it. It was just kinda there. Also also, this blog post is aimed at device manufacturers more than app developers which is why it talks about building AOSP & pending patches. It's not asking app devs to do anything (in fact it even says at the bottom "Make sure to stay tuned as we look into ways to make it as easy for Android developers writing native to target new platforms as it is for our Java and Kotlin developers!")

a-dub 3y ago

if you don't use the ndk, isn't it, in fact, zero work? how prevalent is ndk use? games and multimedia apps maybe?

roneythomas6 3y ago

MIPS died for Android after Imagination Technologies acquired it in 2013. There is nothing for Google to do when there is no new SOC or new phones. As for x86, it is still widely used thanks to Chromebooks. Unless you use NDK there is nothing on your end to do for new targets.

kimixa 3y ago
MIPS died for android well before that - they only had microcontroller-level cores in development, which were rather unsuited to the performance requirements of android.

qwery 3y ago

> They expect developers to get ready? No, I don't think they do in a general sense. It's in the title: "What you need to know to be ready" --> if you would like to be ready, we have some information/advice for you. You can take it or leave it. % Note: I'm using the word "you" here as it is used in the title, not you specifically.

Lammy 3y ago
https://en.wikipedia.org/wiki/One_(pronoun) https://en.wikipedia.org/wiki/One_(pronoun) :)
- circuit10 3y ago
  "The pronoun one often has connotations of formality, and is often avoided in favour of more colloquial alternatives such as generic you."

rickdeckard 3y ago

Not every developer is an App-Developer. Some develop platforms, devices, physical products

Rebelgecko 3y ago

It's a whole new architecture. Developers have to put code to support it into the AOSP. It's actually pretty similar to Apple and the M1 (although IIRC all of that development was done behind closed doors). Apple had to do a ton of work to smooth out the M1 transition, and it'll take a lot of work to make the process equally smooth on Android