5 ms·

Even if this were true (it's not) that was a conscious choice by Google to capture market share. This issue was predicted (and observed) years ago, almost sinc

Even if this were true (it's not) that was a conscious choice by Google to capture market share. This issue was predicted (and observed) years ago, almost since the release of Android in fact, and is only getting worse. That is all due to Google's own choices.

kuschku 9y ago
The real problem with it is Linux. Here's a few facts: The Kernel has no stable ABI for drivers. Manufacturers only ever develop a driver for their chips once, and then send that to the OEM. They never update. The Linux Kernel LTS gets 2 years of updates, Google's fork about 4. From the day a Kernel is released, to the day it ships in a phone, usually 2 years are spent integrating the blobs and code drops from the chip manufacturers. On every kernel upgrade that breaks the ABI, those 2 years would have to be redone from scratch. Linux can't mainline support for every exotic piece of hardware that ever shows up in a device. Manufacturers can't keep maintaining several developers to update every single chip they release. Google can't keep Android on 6 year old kernels forever. Now combine these facts, and you'll see the issue.
- mjevans 9y ago
  That's only a problem because they're keeping driver support closed. If they contributed a driver for their hardware upstream it would be maintained (by others) as the internal interfaces and standards change. Whenever a security issue or design change happened, their driver would also get updated and fixed with the rest of the kernel. What the hardware manufacturers SHOULD do is create hardware with a well defined control interface that they CAN make public. Any 'secret sauce', uploaded firmware blobs, etc, should be free to re-distribute since they were too cheep to ship a ROM or EEPROM with the firmware for their device with the device.
  - kuschku 9y ago
    That's often not that simple. For example, SAMSUNG might build your device, and get all of their own code openly. But now for the US model, due to CDMA, they need to use a Qualcomm processor. That needs a blob, and Qualcomm won't release that under an open license, nor update it. So the OEM can either just not have CDMA support, or accept foreign blobs. It works like this all way down the stack, down to even camera chips. And then these devices all have custom hardware. Often hundreds of customly designed parts, with custom drivers, only ever for a single device. Think of the Moto Z Play, withthe replacable components. Samsung phones with facial scanners. LG phones with 3D display. One-off features that'd never get mainlined.
    - mjevans 9y ago
      My understanding about the US side of this is that the software defined radios and FCC compliance are a major portion of the problem. STILL, that stuff should be equivalent to a firmware blob that should have been baked in to a ROM or EEPROM. The actual driver controlling it should be able to be open, and for regulatory compliance should use 'magic numbers' as specified for the configuration; which as a fact of how to use that device must be configured already /not/ be covered by copyright (in the US at least).
    - matt_wulfeck 9y ago
      Apple has the same issues, yet they keep their devices updated and secure for 5+ years.
      - pcwalton 9y ago
        Well, Apple completely controls the XNU kernel and its I/O Kit framework. By contrast, Google--and especially phone manufacturers--don't control development of the Linux kernel.
- abritinthebay 9y ago
  Well that’s not actually a problem if Google controlled the hardware (or a hardware standard, at least). But they don’t. So while you’re absolutely correct from a technical perspective it’s still a consequence of Googles strategy, and a problem for us all.
- atomicnumber1 9y ago
  Maybe Fuchsia is an effort to solve such issues? But it won't see the day of light for at least 2 or 3 years.
- fulafel 9y ago
  Android device vendors are Linux distribution vendors, and could support their releases for 5-10 years for a given device generation, like many other Linux distribution vendors are doing. (Or outsource it) Yes of course it's not free and you can save money by leaving users stranded. But it's myopic to claim it's the fault of Linux.
  - kuschku 9y ago
    That’s not really possible. Let’s imagine you try to build a phone. You buy an SoC, and you get a single kernel build. If you’re lucky, you get a few binary kernel modules. These will never be updated. You will always be stuck on that kernel version. No manufacturer of ARM SoCs for phones currently provides ever updates for these. Linux LTS Kernels get 2 years of support. Now, tell me, how do you support a kernel that was dropped by upstream, with proprietary drivers that you can’t do anything about? I’m not sure if you’ve ever tried porting a custom ROM to such a device, I have. By the time Android was on the 3.11 kernel, I had a device still using kernel 2.6. It was insanity, half the functionality wasn’t working, we were reverse engineering and hacking together the rest, and still barely got anything working. It’s impossible to use a decade-old kernel with modern Android userland, yet that’s what you ask for.
    - fulafel 9y ago
      You can support that kernel version, like distributions do now with back port etc work, or you can prefer SoC vendors that promise updated driver support. If the latter was happening, the problem would be fixed by now. So essentially phone vendors have been voting with their dollars for lack of driver updates. But even for the self caused major version jam, the "get 2 years of support from upstream" is a heavy understatement and even after the n years of community LTS support ends, it's just the baseline you get for granted and you can diy more.
- fulafel 9y ago
  The official Kernel.org LTS support is 6 years from the Linux devs, some vendors support theirs for longer.
  - kuschku 9y ago
    The Kernel.org LTS support was 2 years until a few weeks ago. Due to Google’s pressure, it’s now 6 years.
    - fulafel 9y ago
      http://web.archive.org/web/20170812023641/https://www.kernel.org/category/releases.html http://web.archive.org/web/20170812023641/https://www.kernel... says previously's been 2-6 years for the various LTS releases. But it's always been open to more sponsorship of course.

kuschku 9y ago

The real problem with it is Linux. Here's a few facts: The Kernel has no stable ABI for drivers. Manufacturers only ever develop a driver for their chips once, and then send that to the OEM. They never update. The Linux Kernel LTS gets 2 years of updates, Google's fork about 4. From the day a Kernel is released, to the day it ships in a phone, usually 2 years are spent integrating the blobs and code drops from the chip manufacturers. On every kernel upgrade that breaks the ABI, those 2 years would have to be redone from scratch. Linux can't mainline support for every exotic piece of hardware that ever shows up in a device. Manufacturers can't keep maintaining several developers to update every single chip they release. Google can't keep Android on 6 year old kernels forever. Now combine these facts, and you'll see the issue.

mjevans 9y ago
That's only a problem because they're keeping driver support closed. If they contributed a driver for their hardware upstream it would be maintained (by others) as the internal interfaces and standards change. Whenever a security issue or design change happened, their driver would also get updated and fixed with the rest of the kernel. What the hardware manufacturers SHOULD do is create hardware with a well defined control interface that they CAN make public. Any 'secret sauce', uploaded firmware blobs, etc, should be free to re-distribute since they were too cheep to ship a ROM or EEPROM with the firmware for their device with the device.
- kuschku 9y ago
  That's often not that simple. For example, SAMSUNG might build your device, and get all of their own code openly. But now for the US model, due to CDMA, they need to use a Qualcomm processor. That needs a blob, and Qualcomm won't release that under an open license, nor update it. So the OEM can either just not have CDMA support, or accept foreign blobs. It works like this all way down the stack, down to even camera chips. And then these devices all have custom hardware. Often hundreds of customly designed parts, with custom drivers, only ever for a single device. Think of the Moto Z Play, withthe replacable components. Samsung phones with facial scanners. LG phones with 3D display. One-off features that'd never get mainlined.
  - mjevans 9y ago
    My understanding about the US side of this is that the software defined radios and FCC compliance are a major portion of the problem. STILL, that stuff should be equivalent to a firmware blob that should have been baked in to a ROM or EEPROM. The actual driver controlling it should be able to be open, and for regulatory compliance should use 'magic numbers' as specified for the configuration; which as a fact of how to use that device must be configured already /not/ be covered by copyright (in the US at least).
  - matt_wulfeck 9y ago
    Apple has the same issues, yet they keep their devices updated and secure for 5+ years.
    - pcwalton 9y ago
      Well, Apple completely controls the XNU kernel and its I/O Kit framework. By contrast, Google--and especially phone manufacturers--don't control development of the Linux kernel.
abritinthebay 9y ago
Well that’s not actually a problem if Google controlled the hardware (or a hardware standard, at least). But they don’t. So while you’re absolutely correct from a technical perspective it’s still a consequence of Googles strategy, and a problem for us all.
atomicnumber1 9y ago
Maybe Fuchsia is an effort to solve such issues? But it won't see the day of light for at least 2 or 3 years.
fulafel 9y ago
Android device vendors are Linux distribution vendors, and could support their releases for 5-10 years for a given device generation, like many other Linux distribution vendors are doing. (Or outsource it) Yes of course it's not free and you can save money by leaving users stranded. But it's myopic to claim it's the fault of Linux.
- kuschku 9y ago
  That’s not really possible. Let’s imagine you try to build a phone. You buy an SoC, and you get a single kernel build. If you’re lucky, you get a few binary kernel modules. These will never be updated. You will always be stuck on that kernel version. No manufacturer of ARM SoCs for phones currently provides ever updates for these. Linux LTS Kernels get 2 years of support. Now, tell me, how do you support a kernel that was dropped by upstream, with proprietary drivers that you can’t do anything about? I’m not sure if you’ve ever tried porting a custom ROM to such a device, I have. By the time Android was on the 3.11 kernel, I had a device still using kernel 2.6. It was insanity, half the functionality wasn’t working, we were reverse engineering and hacking together the rest, and still barely got anything working. It’s impossible to use a decade-old kernel with modern Android userland, yet that’s what you ask for.
  - fulafel 9y ago
    You can support that kernel version, like distributions do now with back port etc work, or you can prefer SoC vendors that promise updated driver support. If the latter was happening, the problem would be fixed by now. So essentially phone vendors have been voting with their dollars for lack of driver updates. But even for the self caused major version jam, the "get 2 years of support from upstream" is a heavy understatement and even after the n years of community LTS support ends, it's just the baseline you get for granted and you can diy more.
fulafel 9y ago
The official Kernel.org LTS support is 6 years from the Linux devs, some vendors support theirs for longer.
- kuschku 9y ago
  The Kernel.org LTS support was 2 years until a few weeks ago. Due to Google’s pressure, it’s now 6 years.
  - fulafel 9y ago
    http://web.archive.org/web/20170812023641/https://www.kernel.org/category/releases.html http://web.archive.org/web/20170812023641/https://www.kernel... says previously's been 2-6 years for the various LTS releases. But it's always been open to more sponsorship of course.