6 ms·

They aren't Google devices. They're phones made by companies who downloaded and installed Android on them.

sbierwagen 9y ago
The Nexus 6P was developed and sold directly by Google: https://www.google.com/nexus/6p/ https://www.google.com/nexus/6p/
- bhhaskin 9y ago
  The Nexus 6P was made by Huawei. Also usually it is not the manufacturer, but the carriers that hold up or stop updates.
- rocky1138 9y ago
  Yes, I understand that Google do make some phones. I own one. But, the vast majority are not created by Google.
abritinthebay 9y ago
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.

The Nexus 6P was developed and sold directly by Google: https://www.google.com/nexus/6p/ https://www.google.com/nexus/6p/

bhhaskin 9y ago
The Nexus 6P was made by Huawei. Also usually it is not the manufacturer, but the carriers that hold up or stop updates.
rocky1138 9y ago
Yes, I understand that Google do make some phones. I own one. But, the vast majority are not created by Google.

abritinthebay 9y ago

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.