That would just make them look for alternatives asap.
The basic problem is that updates are an expense once the SKU starts shipping, while spending the same money on a new SKU is an investment.
Apple get around this because they own the whole stack. Thus keeping a device going longer means more exposure to their stores.
Never mind that even though they release a new iOS in name, major new features are left out for the version pushed to the older devices.
Never mind that on Android APIs can be supplied by APKs, and thus we have Play Services.
Frankly the only thing Google can do is adopt something akin to what they have on ChromeOS.
Split the Android VM layer from the Linux layer, so that they can update the VM layer independently of the kernel and userland layer.
Another issue is unless you are looking at white box rebrands, each OEM tailor the Android UI/UX.
Unless Google makes it possible to isolate this tailoring from the core Android code, there will still be lag time between Google releasing a new version, and it hitting devices. And that is reliant on the tailored variant fits inside the storage space of the device.
> Never mind that even though they release a new iOS in name, major new features are left out for the version pushed to the older devices.
This is simplistic and largely wrong. Only when there is a lack of appropriate hardware e.g. noise cancellation in the A5 chip or inadequate RAM has Apple decided not to port to those older devices. It's not a deliberate policy especially since they have been selling older devices alongside the newer ones.
That said for developers it's been about 99% of features available on all devices.
Yes, Apple is much better about it; but there are instances where Apple has limited certain features to newer devices when there was no real reason for doing so. Most recently they blocked trivial features such as content blocking and Night Shift from 32 bit devices in their push for 64 bit adoption.
The basic problem is that updates are an expense once the SKU starts shipping, while spending the same money on a new SKU is an investment.
Apple get around this because they own the whole stack. Thus keeping a device going longer means more exposure to their stores.
Never mind that even though they release a new iOS in name, major new features are left out for the version pushed to the older devices.
Never mind that on Android APIs can be supplied by APKs, and thus we have Play Services.
Frankly the only thing Google can do is adopt something akin to what they have on ChromeOS.
Split the Android VM layer from the Linux layer, so that they can update the VM layer independently of the kernel and userland layer.
Another issue is unless you are looking at white box rebrands, each OEM tailor the Android UI/UX.
Unless Google makes it possible to isolate this tailoring from the core Android code, there will still be lag time between Google releasing a new version, and it hitting devices. And that is reliant on the tailored variant fits inside the storage space of the device.