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 - 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/

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.

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.

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)).

The kernel isn't the problem - one of the devices I maintain runs 7.1 (mostly) fine on Linux 3.0[1]. The issues lie in the HALs - which translate between the standard Android camera/sensor/telephony APIs and the vendor's implementation in the kernel. These are device-specific, and usually provided to the OEM by a HW/chipset manufacturer.

Google is generally pretty good about keeping source compatibility, but ABIs change, and sometimes completely unrelated changes break everything for no obvious reason. Some things I've encountered include:

* sensor blobs crashing when using a clang-built libc, but working with a gcc-built one.

* blobs crashing when using jemalloc, but not dlmalloc (dlmalloc was removed with 7.0).

* Vendors introducing hacks in the OS - workarounds to deal with broken HW media encoders (which misinterpret pixel formats), misbehaving GL blobs, or devices which expect one pixel format for their display when the system provides another (e.g. RGB vs BGR).

* closed-source OpenGL drivers which use-after-free - the bug's probably existed since forever, but it only manifests after 7.0.

[1]: https://github.com/LineageOS/android_kernel_samsung_smdk4412...

Oh. I see, so the binary blobs that are not exactly user space, but not exactly non-userspace either.

That's why XDA is full of ROMs that "just need to get GPS working and camera sometimes crashes" :(

How come Google doesn't try to source better hardware for their phones? Also, is this the cause of why Apple in-housed a lot of things?

Also, how come there isn't an isolation layer for these blobs, something like docker for the phone? (So they get their runtime dependencies, and communicate with them via a socket-shim?)

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.

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/ [2]: https://github.com/torvalds/linux/blob/master/arch/arm/boot/... [3]: https://github.com/torvalds/linux/blob/master/arch/arm/boot/... [4]: https://github.com/torvalds/linux/tree/master/arch/arm64/boo... [5]: https://github.com/torvalds/linux/tree/master/arch/arm64/boo...

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.

> It doesn't have to be a mainstream kernel. The only important part is that it is a fixed kernel version

This is how it is done already. Google picks a kernel release (historically 3.0, 3.4, 3.10, 3.18, 4.4 etc.) and ports Android patches to that kernel while developing new features as well. Then SoC vendors do their bringups using that kernel tree.

My point was, kernel version should not change with every Android release...

It's not that they change kernel versions every month to the most recent ones anyway. It's roughly every year and if you check you'll see they're all upstream longterm versions which are supported 2-5 years.

A device is released with a specific kernel version and it doesn't get upgraded in devices lifetime even if the same device gets several Android upgrades. Native Nougat devices released in 2017 have kernel 4.4 which was released in early 2016, which is not even considered a new kernel by the upstream standards.

What do you expect the benefit everyone gains from sticking to the same kernel for 5 years? What is the point of developing a SoC in 2017 and bringing it up using Linux 2.6.32 instead of Linux 4.4? What is the benefit for Quallcomm, for Google or for users?

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?

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

The shelf life of _android_ phones is low, and it's strikingly different on iOS which receive updates for 5+ years.

The iPhone 5s was released in 2013 and it should get iOS 11 this year. The iPhone 5, which came out in 2012, is currently supported. However, it might be dropped this year because it's not 64-bit.

Android users should push for longer support. I had an original Nexus 1 and I was quite disappointed when it could no longer be upgraded. It cost me $600.

Aren't we comparing apples and oranges here? This is the O Beta. I'm sure O will be supported on the Nexus 6 once it's officially out.

No, the Nexus 6 has reached end-of-life and will not be receiving any more non-security updates. It already missed the tiny 7.1.2 maintenance update, so Google is serious about their EOL dates.

https://support.google.com/nexus/answer/4457705#nexus_device...

It is apple and oranges.

The situation is pretty complex but the support libs & play services are available on virtually all devices (API 9+ IIRC, but anything older would not be able to run most modern apps).

Does the same applies to old iPhones? Can the iPhone 5 run the most recent version of let's say the Facebook/Messenger app?

Yes. The iPhone 5 has received iOS 10, so it can run all iOS 10 apps in their most recent versions. There are some (mostly hardware) features that iPhone 5 users don't have access to (e.g. 3D Touch) so they might not be able to use all power features, but that doesn't prevent you from using the complete fully updated app catalog.

As an iPhone 5S user, I don't feel like I'm disadvantaged at all from having a phone that is three generations behind.

Sorry, I mean to ask about the performance aspect.

But I guess that's up to the developer anyhow.

Thanks for your reply. (A few of my friends also use 5s and they also feel it's still pretty okay.)

I believe the Nexus 6 is too old to get any future major updates. Last I read, they pulled the 7.1.1 update, downgrading these users to 7.0. It appears that you can still sideload 7.1 onto a Nexus 6, but will not currently receive OTA updates.

https://9to5google.com/2017/03/15/nexus-6-android-7-1-1-down...

Google has flat out said they won't support any devices past 18 months. The Pixel may not even receive any updates after O.

Well, to be explicit, they set the minimum timeframe. For example, the Nexus Player is still on the latest version of Android and will/should receive 'O'

(Not letting google off the hook here. What they're doing isn't great and they should do better. Just saying your statement isn't entirely correct)

I had to stop using my Nexus One when it could no longer install updates due to the limited on-device storage. I'd still be using it, otherwise.

The N1 was groundbreaking for me.

I took this shot of my Nexus One next to the new S8 Plus, highlighting 7 years of advance in technology:

http://i.imgur.com/sXnfBt4.jpg

"The shelf life of phones is embarrassingly low. For no apparent reason"

No it wasn't, and I didn't even get this phone new but a year into its life. This phone came out in 2014. It got its fair share of updates.