Initially it was, but Android/Google have become the establishment. And ARM-based devices are becoming our general-purpose computing devices. Having an option for running the software we choose is the question of whether we have open computing device in the future.
There actually is a solution at the hardware/firmware/driver level now, the ARM Linux community has adopted DeviceTree, actually a varient called FDT, and drivers have migrated from the one-off platform buses to FDT. Even vendors like Qualcomm are embracing it and the time to upstream is falling.
As far as bootloaders, there are a number of open options. also don't personally see anything wrong with EFI on ARM, as long as there is a way for the end user to choose what signatures are accepted when booting software. A standard for describing memory layouts independent of hardware is important, as that allows for the newer multi-SoC ARM Linux kernels along with DT for defining the hardware and what driver should bind to what hardware device.
There are standards that exist at this layer, as long as the OEMs and SoC makers adopt them.
The basic concepts of SoCs are not being obsoleted, and the basic set of devices that need to be present to boot a system are not really changing that much, specific buses are changing, better DMA mapping is supported on newer hardware, including IOMMUs, but the basic concepts are still pretty much the same.
My proposal takes place at a different layer though, and is more focused on the fragmentation problem of Android.
Essentially you have an ARM ABI standard which defines what registers a call into the Linux kernel uses, this used to be more complicated with multiple ARM ABIs. Now it's pretty simple and ARM binaries on Linux work across devices, across SoCs, across Android OEM vendors. This is not much better or worse than the same compatibility on x86/x64.
The issue lies in the "expanded ABI," the suite of drivers, libraries, daemons, configuration, RPC procedures, hardware specific IOCTLs, and other particulars of each OEM's hardware. A Samsung camera APK isn't going to work on a device with a different sensor, even though they are both coded to Android's camera APIs. They might handle zoom differently, or lighting. They might handle sending the uncompressed stream to the DSP differently, or drawing into the LCDC different for real-time previews. They might handle flash timing differently. But what would happen if this was a plugin for the standard Google or even AOSP camera instead? What if this was a defined API/ABI that CyanogenMod could use on that hardware, or Firefox Apps with embedded WebAPI camera media source and canvas? What about capturing from the command line with something like uvctool?
Numbers like 4.4 at 2% (from another story today) should scare Google. It should scare them when apps built for Chrome Mobile don't work on all Android devices. It should scare them when the improvements made to Google Now won't be usable by an overwhelming proportion of their users. It should scare them when others like Yahoo and Mozilla can come in and poach Android users stuck on an outdated version of Android and build alternatives economies on their own (Google's) partner's flagship devices. And they should respond by competing.
There actually is a solution at the hardware/firmware/driver level now, the ARM Linux community has adopted DeviceTree, actually a varient called FDT, and drivers have migrated from the one-off platform buses to FDT. Even vendors like Qualcomm are embracing it and the time to upstream is falling.
As far as bootloaders, there are a number of open options. also don't personally see anything wrong with EFI on ARM, as long as there is a way for the end user to choose what signatures are accepted when booting software. A standard for describing memory layouts independent of hardware is important, as that allows for the newer multi-SoC ARM Linux kernels along with DT for defining the hardware and what driver should bind to what hardware device.
There are standards that exist at this layer, as long as the OEMs and SoC makers adopt them.
The basic concepts of SoCs are not being obsoleted, and the basic set of devices that need to be present to boot a system are not really changing that much, specific buses are changing, better DMA mapping is supported on newer hardware, including IOMMUs, but the basic concepts are still pretty much the same.
My proposal takes place at a different layer though, and is more focused on the fragmentation problem of Android.
Essentially you have an ARM ABI standard which defines what registers a call into the Linux kernel uses, this used to be more complicated with multiple ARM ABIs. Now it's pretty simple and ARM binaries on Linux work across devices, across SoCs, across Android OEM vendors. This is not much better or worse than the same compatibility on x86/x64.
The issue lies in the "expanded ABI," the suite of drivers, libraries, daemons, configuration, RPC procedures, hardware specific IOCTLs, and other particulars of each OEM's hardware. A Samsung camera APK isn't going to work on a device with a different sensor, even though they are both coded to Android's camera APIs. They might handle zoom differently, or lighting. They might handle sending the uncompressed stream to the DSP differently, or drawing into the LCDC different for real-time previews. They might handle flash timing differently. But what would happen if this was a plugin for the standard Google or even AOSP camera instead? What if this was a defined API/ABI that CyanogenMod could use on that hardware, or Firefox Apps with embedded WebAPI camera media source and canvas? What about capturing from the command line with something like uvctool?
Numbers like 4.4 at 2% (from another story today) should scare Google. It should scare them when apps built for Chrome Mobile don't work on all Android devices. It should scare them when the improvements made to Google Now won't be usable by an overwhelming proportion of their users. It should scare them when others like Yahoo and Mozilla can come in and poach Android users stuck on an outdated version of Android and build alternatives economies on their own (Google's) partner's flagship devices. And they should respond by competing.