6 ms·

The real issue for the Nexus 6 is that Qualcomm has completely abandoned their 32-bit mobile platforms. Look for "8084" here: https://wiki.codeaurora.org/xwiki/

The real issue for the Nexus 6 is that Qualcomm has completely abandoned their 32-bit mobile platforms. Look for "8084" here: https://wiki.codeaurora.org/xwiki/bin/QAEP/release https://wiki.codeaurora.org/xwiki/bin/QAEP/release - the Snapdragon 805 hasn't received a release since August 2016. So, Google did an in-house bringup for 7.0 - and "normal" OEMs aren't able to do that. Qualcomm usually provides a lot of pre-compiled binaries to the OEM, which either require nasty hacks to work on newer versions of Android (which won't pass CTS - so can't be shipped), or just straight up don't work. The blame here rests largely with chip manufacturers and their short support cycles. Of course, LineageOS[1] remains an option if you're looking for extended support for the Nexus 6. (disclaimer, I'm a device maintainer for Lineage) [1]: https://lineageos.org/ https://lineageos.org/

tbrock 9y ago
Cool but Apple's 32 bit iPhones still get updates and also use Qualcomm chips... What's the difference in how they operate with suppliers?
- cale250 9y ago
  Qualcomm CPUs. Modems are different and probably a lot less complex driver-wise, and thus easier and cheaper to support for Qualcomm.
dx034 9y ago
A manufacturer should have contracts with vendors to update software for at least 3 years after production has been stopped. It will cost more (which is why most manufacturers don't do it) but would be an easy way to establish compatibility similar to Apple devices. I'm sure Apple has contracts like this in place with all manufacturers they use.
pas 9y ago
And do they need a new kernel so desperately? I don't understand the problems with backward compatibility. They already provide it via the Android SDK (the support library). Java/Dex/Dalvik/ART or whatever it's called now that runs the shit works on Linux 3.0 probably. (Android 2.3 was released with Linux 2.6.35 [+ patches, I assume && hope], and that's currently the lowest supported API Level (that is api level 9)).
- pawadu 9y ago
  This is my mine gripe. Google should put some resources into kernel development for a year or so.Get the changes they want into Linux 5.0 and make it the android long-term-release kernel. Then no further changes to the kernel unless its 0.0.1 security patches.
  - forkbomb_ 9y ago
    Google does this already[1]. As far as I know, it's possible to boot Android off a mainline kernel - the main obstacle is the lack of drivers in the upstream kernel. Certainly, a lot of the SoCs (especially in older phones) can _boot_ from mainline. Maybe you could even get a serial console, or a picture of tux on the screen. But the OEMs don't really have any incentive to upstream their drivers (or port older platforms to newer kernels) - why bother? Probably the only instance that I'm aware of where an OEM has actually mainlined support for their own mobile devices is Samsung with some of their Tizen reference devices - "trats"[2], "trats2"[3] (which is pretty much identical to the Galaxy S3), "tm2" and "tm2e"[4]. Of course, these will probably never gain support for certain things like 3D acceleration and the modem in mainline, but it's certainly a good start. (Note: a few Nexus devices seem to have mainline DTS[5], but I'm not sure how complete they are). [1]: https://android.googlesource.com/kernel/common/ https://android.googlesource.com/kernel/common/ [2]: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/exynos4210-trats.dts https://github.com/torvalds/linux/blob/master/arch/arm/boot/... [3]: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/exynos4412-trats2.dts https://github.com/torvalds/linux/blob/master/arch/arm/boot/... [4]: https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/exynos https://github.com/torvalds/linux/tree/master/arch/arm64/boo... [5]: https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/qcom https://github.com/torvalds/linux/tree/master/arch/arm64/boo...
    - pawadu 9y ago
      You missed my point. It doesn't have to be a mainstream kernel. The only important part is that it is a fixed kernel version so drivers and such does not need to be re-written with each new android release.
sorenjan 9y ago
The Pixel phones use Qualcomm's flagship 64-bit SoCs, and they have a last update date of October 2018. Google's update policy is not good enough, especially now when they've started to charge premium prices.

tbrock 9y ago

Cool but Apple's 32 bit iPhones still get updates and also use Qualcomm chips... What's the difference in how they operate with suppliers?

cale250 9y ago
Qualcomm CPUs. Modems are different and probably a lot less complex driver-wise, and thus easier and cheaper to support for Qualcomm.

dx034 9y ago

A manufacturer should have contracts with vendors to update software for at least 3 years after production has been stopped. It will cost more (which is why most manufacturers don't do it) but would be an easy way to establish compatibility similar to Apple devices. I'm sure Apple has contracts like this in place with all manufacturers they use.

pas 9y ago

And do they need a new kernel so desperately? I don't understand the problems with backward compatibility. They already provide it via the Android SDK (the support library). Java/Dex/Dalvik/ART or whatever it's called now that runs the shit works on Linux 3.0 probably. (Android 2.3 was released with Linux 2.6.35 [+ patches, I assume && hope], and that's currently the lowest supported API Level (that is api level 9)).

pawadu 9y ago
This is my mine gripe. Google should put some resources into kernel development for a year or so.Get the changes they want into Linux 5.0 and make it the android long-term-release kernel. Then no further changes to the kernel unless its 0.0.1 security patches.
- forkbomb_ 9y ago
  Google does this already[1]. As far as I know, it's possible to boot Android off a mainline kernel - the main obstacle is the lack of drivers in the upstream kernel. Certainly, a lot of the SoCs (especially in older phones) can _boot_ from mainline. Maybe you could even get a serial console, or a picture of tux on the screen. But the OEMs don't really have any incentive to upstream their drivers (or port older platforms to newer kernels) - why bother? Probably the only instance that I'm aware of where an OEM has actually mainlined support for their own mobile devices is Samsung with some of their Tizen reference devices - "trats"[2], "trats2"[3] (which is pretty much identical to the Galaxy S3), "tm2" and "tm2e"[4]. Of course, these will probably never gain support for certain things like 3D acceleration and the modem in mainline, but it's certainly a good start. (Note: a few Nexus devices seem to have mainline DTS[5], but I'm not sure how complete they are). [1]: https://android.googlesource.com/kernel/common/ https://android.googlesource.com/kernel/common/ [2]: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/exynos4210-trats.dts https://github.com/torvalds/linux/blob/master/arch/arm/boot/... [3]: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/exynos4412-trats2.dts https://github.com/torvalds/linux/blob/master/arch/arm/boot/... [4]: https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/exynos https://github.com/torvalds/linux/tree/master/arch/arm64/boo... [5]: https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/qcom https://github.com/torvalds/linux/tree/master/arch/arm64/boo...
  - pawadu 9y ago
    You missed my point. It doesn't have to be a mainstream kernel. The only important part is that it is a fixed kernel version so drivers and such does not need to be re-written with each new android release.

sorenjan 9y ago

The Pixel phones use Qualcomm's flagship 64-bit SoCs, and they have a last update date of October 2018. Google's update policy is not good enough, especially now when they've started to charge premium prices.