5 ms·

That "custom-patched kernel with a bizarre build process" is a self-inflicted wound on the part of both Google and the carriers. It could have been corrected ye

That "custom-patched kernel with a bizarre build process" is a self-inflicted wound on the part of both Google and the carriers. It could have been corrected years ago.

cogman10 6y ago
Yup, and to that point, the fix is really stupid simple, push the drivers into the linux kernel mainline and give google (or whoever) a kernel build profile for your device. Done. You don't have to support the device for an eternity and, as a bonus, you can benefit from OS improvements to your drivers/etc. Hell, you and other manufactures using the same broadcom SOC (and hear me out... this might sound crazy) wouldn't have to spend the same engineering effort building drivers! Of course, that would require manufactures to actually give a damn about driver quality, whereas the current situation allows them to push out the most broken patch imaginable to pass whatever conformance tests google asks for. That would also cut into manufactures bottom line which is why I suspect they've not gone down this route. Gotta sell them phones every year... (they'd cut support to 1 month if they could)
- ebg13 6y ago
  > Yup, and to that point, the fix is really stupid simple, push the drivers into the linux kernel mainline and give google (or whoever) a kernel build profile for your device. "If only the bad people would just stop being bad!" This mantra continually assumes goodwill from people who continue to show that they have none. At some point one needs to stop gaslighting themselves and their users and make the system more robust to bad actors. Manufacturers don't want to mainline their drivers? Fine. You can work on getting drivers mainlined while also stabilizing the interface so that it doesn't injure a billion customers when they don't.
  - cogman10 6y ago
    Yeah, there definitely needs to be some sort of enforcement that keeps bad actors from misbehaving. Google seems like the natural point for that. Maybe a law is needed? Too bad most law makers are completely tech illiterate. But I agree, it won't change without some central force to kibosh it.
  - JetSpiegel 6y ago
    Google earns more money with the current scheme, so they have no incentive to improve this. Android One is a joke, it should be the baseline for Android, not a "special" version. They could force the OEM to play ball, like they require Google Play Services to be pre-installed.
    - kelnos 6y ago
      > They could force the OEM to play ball, like they require Google Play Services to be pre-installed. I think Google really has to walk a fine line here. Android OEMs are already not thrilled with their lack of freedom when it comes to changing the experience on their phones. The more restrictions Google adds on, the closer some of them (especially Samsung) will be to cutting ties with the Android name and forking.
      - GeekyBear 6y ago
        Google had absolutely no problem with forcing the hands of device makers when it came to their ability to build devices running a fork of Android. They are not powerless. They simply made the decision to treat carriers and device makers as the customers they cared about and not the people using the devices.
      - JetSpiegel 6y ago
        And lose access to the Play Store? Ain't gonna happen! Not even Microsoft was able to break the duopoly. Huawei only stopped shipping the Store because they were legally obligated.
- ansible 6y ago
  So this situation has persisted for years, across the entire Android ecosystem. You're not going to just fix it with "one simple trick". > Yup, and to that point, the fix is really stupid simple, push the drivers into the linux kernel mainline and give google (or whoever) a kernel build profile for your device. Yeaaaaahhh... I don't see most companies doing that. 1. It is a lot of work to clean up your driver (that will only ever be used on one product) enough to be accepted into the mainline kernel. It takes time, effort and skill. Companies don't want to pay for that, because it doesn't contribute to bottom line. The MO is: get the product out... yesterday so we can sell it and make some money. 2. Even if it was accepted, does that mean it is going to work forever afterwards because the Linux kernel fairies / pixies / whatever will maintain it? No. If you're going push out a new release to end users, you'd better make damn sure it works. So that means each Android release has to go through a long round of QA. Who's going to pay for that? There's only a couple ways out of the current mess we are in. Only one is likely to actually work. Option 1: Release the IP! Have basically all phone SoCs (system on chip) use the same IP blocks for the display, I2C, SPI, memory controllers, GPIO, various sensors, power management, etc. Then you can be more like a PC where the system can basically boot up, and you can then download additional drivers as needed. This will never happen. Option 2: Fuchsia style microkernel. Create a device driver API for the various SoC hardware blocks, and make it good and flexible enough that you never, ever have to change the API. The device driver binary is written once during initial product development, and can be carried into newer OS updates with no changes at all. People need to realize that the SoC world is not like the PC world. Hardware interfaces change all the time, with every release of a new family member. Some stuff doesn't change much, like a USB host controller, because the SoC world has standardized that somewhat. Other stuff like power management is a total pain.
sangnoir 6y ago
Surely, you mean "Qualcomm-inflicted wound"? After TI left the Android SoC space, most OEMs and Carriers are beholden to Qualcomm, who write their own drivers and will never mainline them, if they can help it: long upgrade cycles will hurt Qualcomms bottomline, planned obsolescence via kernel incompatibility is how they achieve that. I don't think customers will upgrade from Snapdragon X05 to Snapdragon X20 for the minor gains in performance, if their old device could get the latest Android features.
- JetSpiegel 6y ago
  Couldn't Google bend Qualcomm to their will? Or even just buy them out, it's not like they lack the cash.
  - sangnoir 6y ago
    Google decided on a cheaper technical solution instead - they only recently started abstracting Android drivers from the linux kernel (Project Treble[1]), which should allow drivers to continue working after the kernel has been updgraded. 1. https://android-developers.googleblog.com/2018/11/an-update-on-project-treble.html https://android-developers.googleblog.com/2018/11/an-update-...
    - corty 6y ago
      Except Qualcom drivers are so crappy, you can rely on a remote exploit via WiFi or BT every year. So no chance to use the phone longer than maybe 2 years, even if nominally the software support might be longer. Not incidentally, "Qual" is german for "torture".
vetinari 6y ago
Partially. You know, your PC has BIOS/UEFI and PCIE busses and other ways for kernel to discover what it is really running on, which drivers to load and so on. ARM devices have none of these (except for servers, where Redhat had enough clout to say, that if your ARMv8 server has no UEFI, it will have no RHEL). Not only they add up to energy consumption (it is extra hardware, after all), they add up in the BOM as well (again, it is extra hardware). So we are stuck with kernels targeting only a known hardware (which today devicetree describes to some degree) and where a poke on a wrong port could mean that the entire device hangs. And after all, no consumers base their decision on whether a third party can replace the operating system, so why make a worse (=worse battery) and more expensive (=more BOM) than the competition?

That "custom-patched kernel with a bizarre build process" is a self-inflicted wound on the part of both Google and the carriers. It could have been corrected years ago.

cogman10 6y ago

Yup, and to that point, the fix is really stupid simple, push the drivers into the linux kernel mainline and give google (or whoever) a kernel build profile for your device. Done. You don't have to support the device for an eternity and, as a bonus, you can benefit from OS improvements to your drivers/etc. Hell, you and other manufactures using the same broadcom SOC (and hear me out... this might sound crazy) wouldn't have to spend the same engineering effort building drivers! Of course, that would require manufactures to actually give a damn about driver quality, whereas the current situation allows them to push out the most broken patch imaginable to pass whatever conformance tests google asks for. That would also cut into manufactures bottom line which is why I suspect they've not gone down this route. Gotta sell them phones every year... (they'd cut support to 1 month if they could)

ebg13 6y ago
> Yup, and to that point, the fix is really stupid simple, push the drivers into the linux kernel mainline and give google (or whoever) a kernel build profile for your device. "If only the bad people would just stop being bad!" This mantra continually assumes goodwill from people who continue to show that they have none. At some point one needs to stop gaslighting themselves and their users and make the system more robust to bad actors. Manufacturers don't want to mainline their drivers? Fine. You can work on getting drivers mainlined while also stabilizing the interface so that it doesn't injure a billion customers when they don't.
- cogman10 6y ago
  Yeah, there definitely needs to be some sort of enforcement that keeps bad actors from misbehaving. Google seems like the natural point for that. Maybe a law is needed? Too bad most law makers are completely tech illiterate. But I agree, it won't change without some central force to kibosh it.
- JetSpiegel 6y ago
  Google earns more money with the current scheme, so they have no incentive to improve this. Android One is a joke, it should be the baseline for Android, not a "special" version. They could force the OEM to play ball, like they require Google Play Services to be pre-installed.
  - kelnos 6y ago
    > They could force the OEM to play ball, like they require Google Play Services to be pre-installed. I think Google really has to walk a fine line here. Android OEMs are already not thrilled with their lack of freedom when it comes to changing the experience on their phones. The more restrictions Google adds on, the closer some of them (especially Samsung) will be to cutting ties with the Android name and forking.
    - GeekyBear 6y ago
      Google had absolutely no problem with forcing the hands of device makers when it came to their ability to build devices running a fork of Android. They are not powerless. They simply made the decision to treat carriers and device makers as the customers they cared about and not the people using the devices.
    - JetSpiegel 6y ago
      And lose access to the Play Store? Ain't gonna happen! Not even Microsoft was able to break the duopoly. Huawei only stopped shipping the Store because they were legally obligated.
ansible 6y ago
So this situation has persisted for years, across the entire Android ecosystem. You're not going to just fix it with "one simple trick". > Yup, and to that point, the fix is really stupid simple, push the drivers into the linux kernel mainline and give google (or whoever) a kernel build profile for your device. Yeaaaaahhh... I don't see most companies doing that. 1. It is a lot of work to clean up your driver (that will only ever be used on one product) enough to be accepted into the mainline kernel. It takes time, effort and skill. Companies don't want to pay for that, because it doesn't contribute to bottom line. The MO is: get the product out... yesterday so we can sell it and make some money. 2. Even if it was accepted, does that mean it is going to work forever afterwards because the Linux kernel fairies / pixies / whatever will maintain it? No. If you're going push out a new release to end users, you'd better make damn sure it works. So that means each Android release has to go through a long round of QA. Who's going to pay for that? There's only a couple ways out of the current mess we are in. Only one is likely to actually work. Option 1: Release the IP! Have basically all phone SoCs (system on chip) use the same IP blocks for the display, I2C, SPI, memory controllers, GPIO, various sensors, power management, etc. Then you can be more like a PC where the system can basically boot up, and you can then download additional drivers as needed. This will never happen. Option 2: Fuchsia style microkernel. Create a device driver API for the various SoC hardware blocks, and make it good and flexible enough that you never, ever have to change the API. The device driver binary is written once during initial product development, and can be carried into newer OS updates with no changes at all. People need to realize that the SoC world is not like the PC world. Hardware interfaces change all the time, with every release of a new family member. Some stuff doesn't change much, like a USB host controller, because the SoC world has standardized that somewhat. Other stuff like power management is a total pain.

sangnoir 6y ago

Surely, you mean "Qualcomm-inflicted wound"? After TI left the Android SoC space, most OEMs and Carriers are beholden to Qualcomm, who write their own drivers and will never mainline them, if they can help it: long upgrade cycles will hurt Qualcomms bottomline, planned obsolescence via kernel incompatibility is how they achieve that. I don't think customers will upgrade from Snapdragon X05 to Snapdragon X20 for the minor gains in performance, if their old device could get the latest Android features.

JetSpiegel 6y ago
Couldn't Google bend Qualcomm to their will? Or even just buy them out, it's not like they lack the cash.
- sangnoir 6y ago
  Google decided on a cheaper technical solution instead - they only recently started abstracting Android drivers from the linux kernel (Project Treble[1]), which should allow drivers to continue working after the kernel has been updgraded. 1. https://android-developers.googleblog.com/2018/11/an-update-on-project-treble.html https://android-developers.googleblog.com/2018/11/an-update-...
  - corty 6y ago
    Except Qualcom drivers are so crappy, you can rely on a remote exploit via WiFi or BT every year. So no chance to use the phone longer than maybe 2 years, even if nominally the software support might be longer. Not incidentally, "Qual" is german for "torture".

vetinari 6y ago

Partially. You know, your PC has BIOS/UEFI and PCIE busses and other ways for kernel to discover what it is really running on, which drivers to load and so on. ARM devices have none of these (except for servers, where Redhat had enough clout to say, that if your ARMv8 server has no UEFI, it will have no RHEL). Not only they add up to energy consumption (it is extra hardware, after all), they add up in the BOM as well (again, it is extra hardware). So we are stuck with kernels targeting only a known hardware (which today devicetree describes to some degree) and where a poke on a wrong port could mean that the entire device hangs. And after all, no consumers base their decision on whether a third party can replace the operating system, so why make a worse (=worse battery) and more expensive (=more BOM) than the competition?