7 ms·

ChromeOS already has an Android runtime. There's no reason an Android runtime couldn't be portable. There's no reason Android apps could not, if using the APIs

by Zigurd 8y ago

ChromeOS already has an Android runtime. There's no reason an Android runtime couldn't be portable. There's no reason Android apps could not, if using the APIs appropriately, adapt to all the different devices and other parameters of an Android runtime that's implemented on a variety of OSs. As long as their apps work, users won't care.

servercobra 8y ago
That's a big if on whether apps work or not though. It's already a pretty big hassle to design/test for the permutations that exist (with or without Play services, testing on ChromeOS, etc) compared to iOS development.
- Zigurd 8y ago
  Since very early versions of Android, APIs existed for determining the characteristics of the hardware/software environment: What sensors exist, input methods, etc. If your app works on tablets and phones and handles orientation changes correctly, it will probably work in a window on a Fuchsia OS device.
- izacus 8y ago
  It's about as much of a hassle than developing desktop app and less of a hassle than developing web apps. Meaning: really not that much of a hassle unless you're deliberately shooting yourself in a foot by doing equivalent of "position: absolute;" everywhere. Which, for some reason, some iOS developers really loved doing which cause endless headaches when adding support to yet another form factor of those devices and endless "fragmentation" complaints.
glenrivard 8y ago
Big difference is Android on ChromeOS is using the Linux kernel that is part of ChromeOS. Here Android will be on top of Zircon. Which is the fuchsia kernel. Now gnu/linux on ChromeOS is using a completely different Linux kernel. It was important Google did it this way so gnu/Linux would still work when they update ChromeOS to Fuchsia. Google already has Gnu/linux running on fuchsia with something called Machina.
- Ericson2314 8y ago
  It doesn't make sense to say GNU/Linux on Zircon. That would be GNU/zircon. Unless you mean syscall translation layer.
  - jpeeler 8y ago
    It does though, assuming that machina is doing virtualization for zircon. Or am I confused? If I'm understanding correctly, this would work the same way that the GNU/Linux termina VM is booted when using crostini currently.

by Zigurd 8y ago

servercobra 8y ago

That's a big if on whether apps work or not though. It's already a pretty big hassle to design/test for the permutations that exist (with or without Play services, testing on ChromeOS, etc) compared to iOS development.

Zigurd 8y ago
Since very early versions of Android, APIs existed for determining the characteristics of the hardware/software environment: What sensors exist, input methods, etc. If your app works on tablets and phones and handles orientation changes correctly, it will probably work in a window on a Fuchsia OS device.
izacus 8y ago
It's about as much of a hassle than developing desktop app and less of a hassle than developing web apps. Meaning: really not that much of a hassle unless you're deliberately shooting yourself in a foot by doing equivalent of "position: absolute;" everywhere. Which, for some reason, some iOS developers really loved doing which cause endless headaches when adding support to yet another form factor of those devices and endless "fragmentation" complaints.

glenrivard 8y ago

Big difference is Android on ChromeOS is using the Linux kernel that is part of ChromeOS. Here Android will be on top of Zircon. Which is the fuchsia kernel. Now gnu/linux on ChromeOS is using a completely different Linux kernel. It was important Google did it this way so gnu/Linux would still work when they update ChromeOS to Fuchsia. Google already has Gnu/linux running on fuchsia with something called Machina.

Ericson2314 8y ago
It doesn't make sense to say GNU/Linux on Zircon. That would be GNU/zircon. Unless you mean syscall translation layer.
- jpeeler 8y ago
  It does though, assuming that machina is doing virtualization for zircon. Or am I confused? If I'm understanding correctly, this would work the same way that the GNU/Linux termina VM is booted when using crostini currently.