5 ms·

I find it hard to believe that 8+ years of APIs and OS level code would be abandoned just like that, especially given the scale of Android. If this ever happen

I find it hard to believe that 8+ years of APIs and OS level code would be abandoned just like that, especially given the scale of Android. If this ever happens, it would probably be an extremely slow, well thought out (hopefully), well documented (also hopefully) rollout.

techenthusiast 10y ago
That's what I'm saying :) An (extremely) gradual phase-out of the Android API.
- relics443 10y ago
  I'm not sure the API can ever really be phased out due to the vast amount of legacy apps and libraries. Besides I'm sure a lot of developers wouldn't be happy that their domain knowledge just went flying through the window. Even if that is a risk inherent in the job.
  - techenthusiast 10y ago
    Extremely, extremely? :) Apple kept Carbon apps running on OS X for a very long time.
therealmarv 10y ago
Exactly. This sort of switch seems for me also a good way to increase the amount of bugs by a large scale. It may only work for very specific hardware I think.
- BrailleHunting 10y ago
  Job security and Apple-ish custom OS may long-term reduce support burden because Linux is like OpenSSL: a giant refrigerator, stove, oven, typewriter, glass kiln, laundromat kitchen-sink. It will take a very long time to reinvent the wheel and also deliver a PG "quantum of improvement," but there are plenty of Alphabet employees to do it. Also, similar Apple, it's an OS they control so there's less rejection / ignorning of Google's desired direction as with FLOSS.
  - pawadu 10y ago
    You grossly overestimate Googles ability to support an OS on multiple platforms. Do you remember the why Samsung Galaxy Nexus was abandoned? Apple supports iOS on two platforms (32-bit and 64-bit A-series). Microsoft who has been in the OS business much longer than than Google only have resources to support Windows 10 Mobile on a handful of carefully chosen Qualcomm chips. So basically the only way this could work is if Google would create their own SoC and mandate Android vendors to only use that SoC. I don't think Samsung would like that too much.
    - BrailleHunting 10y ago
      That's a given. Google also needs to control the hw platform to be successful. Open platform equals shoddy service/product because it would require adding a Microsoft-sized operation.
      - pawadu 10y ago
        Allow me to disagree. Open platform works great when people collaborate. Google has not collaborated with the Linux community.
cpeterso 10y ago
I agree. Why throw out the whole stack: kernel, APIs, and applications? OTOH, why is Google developing the Fuchsia? It is clearly more than a hobby project.
rdtsc 10y ago
They've already replaced Dalvik with ART for bytecode and it was mostly transparent from what I understood. But popping up with a completely new platform API without any backwards compatibility would be very bold and risky. There would have to be a good compatibility story there. Also there is talk in the article about a POSIX layer. Now that's easier said than done. But it is Google we are talking about so they certainly have the manpower and resources to try.
- loeg 10y ago
  It isn't too hard to do Linux ABI emulation. The interface there has mostly been stable for the last several years. That would enable just using the same userspace as Linux distributions like Android.
- relics443 10y ago
  A new runtime is very different then a new framework/API/OS. The former doesn't necessarily require code changes (dalvik -> ART did not), the latter requires new everything.
  - techenthusiast 10y ago
    The Android API wouldn't be going anywhere. That's what I say in the article - Fuchsia would continue to support the Android API seamlessly.
- Aissen 10y ago
  They did not. ART is here on-device architecture-specific and version-specific; Dalvik bytecode is still the portable bytecode used in all APKs. If they had replaced it, we wouldn't still be dealing with the 65k methods limit for example.
techenthusiast 10y ago
You wouldn't have to do it all at once. You'd emulate the Linux user space, and do everything incredibly gradually. Both APIs would be supported for many, many years. But they could stop advancing the Android API within a shorter timeframe.

techenthusiast 10y ago

That's what I'm saying :) An (extremely) gradual phase-out of the Android API.

relics443 10y ago
I'm not sure the API can ever really be phased out due to the vast amount of legacy apps and libraries. Besides I'm sure a lot of developers wouldn't be happy that their domain knowledge just went flying through the window. Even if that is a risk inherent in the job.
- techenthusiast 10y ago
  Extremely, extremely? :) Apple kept Carbon apps running on OS X for a very long time.

therealmarv 10y ago

Exactly. This sort of switch seems for me also a good way to increase the amount of bugs by a large scale. It may only work for very specific hardware I think.

BrailleHunting 10y ago
Job security and Apple-ish custom OS may long-term reduce support burden because Linux is like OpenSSL: a giant refrigerator, stove, oven, typewriter, glass kiln, laundromat kitchen-sink. It will take a very long time to reinvent the wheel and also deliver a PG "quantum of improvement," but there are plenty of Alphabet employees to do it. Also, similar Apple, it's an OS they control so there's less rejection / ignorning of Google's desired direction as with FLOSS.
- pawadu 10y ago
  You grossly overestimate Googles ability to support an OS on multiple platforms. Do you remember the why Samsung Galaxy Nexus was abandoned? Apple supports iOS on two platforms (32-bit and 64-bit A-series). Microsoft who has been in the OS business much longer than than Google only have resources to support Windows 10 Mobile on a handful of carefully chosen Qualcomm chips. So basically the only way this could work is if Google would create their own SoC and mandate Android vendors to only use that SoC. I don't think Samsung would like that too much.
  - BrailleHunting 10y ago
    That's a given. Google also needs to control the hw platform to be successful. Open platform equals shoddy service/product because it would require adding a Microsoft-sized operation.
    - pawadu 10y ago
      Allow me to disagree. Open platform works great when people collaborate. Google has not collaborated with the Linux community.

cpeterso 10y ago

I agree. Why throw out the whole stack: kernel, APIs, and applications? OTOH, why is Google developing the Fuchsia? It is clearly more than a hobby project.

rdtsc 10y ago

They've already replaced Dalvik with ART for bytecode and it was mostly transparent from what I understood. But popping up with a completely new platform API without any backwards compatibility would be very bold and risky. There would have to be a good compatibility story there. Also there is talk in the article about a POSIX layer. Now that's easier said than done. But it is Google we are talking about so they certainly have the manpower and resources to try.

loeg 10y ago
It isn't too hard to do Linux ABI emulation. The interface there has mostly been stable for the last several years. That would enable just using the same userspace as Linux distributions like Android.
relics443 10y ago
A new runtime is very different then a new framework/API/OS. The former doesn't necessarily require code changes (dalvik -> ART did not), the latter requires new everything.
- techenthusiast 10y ago
  The Android API wouldn't be going anywhere. That's what I say in the article - Fuchsia would continue to support the Android API seamlessly.
Aissen 10y ago
They did not. ART is here on-device architecture-specific and version-specific; Dalvik bytecode is still the portable bytecode used in all APKs. If they had replaced it, we wouldn't still be dealing with the 65k methods limit for example.

techenthusiast 10y ago

You wouldn't have to do it all at once. You'd emulate the Linux user space, and do everything incredibly gradually. Both APIs would be supported for many, many years. But they could stop advancing the Android API within a shorter timeframe.