Comment Re:Is this Google's fault? Yes. (Score 3, Interesting) 434
In other words, it's a lose for everyone involved, due to the way the Android/OEM/Carrier relationship is structured, and there's no product continuity upsell like you have with the various iPhone models.
This is only true as long as consumers don't prioritize upgrades at point of purchase. If we could get OEMs to begin making binding upgrade and update support commitments, and get consumers looking at and comparing devices on that basis, then OEMs would be motivated to provide updates.
They can prioritize all they want, but no one wants to pay for the carrier certification of thee modified SDRs, particularly when using a T-Zone on a Snapdragon chip in order to run the baseband, and the FCC demands that the SDR be certified as a unit (software + hardware). That's a carrier certifiiation per carrier, per country, per device, per version update.
Also no carrier using a contract lock-in revenue model is going to provide an update that doesn't lock you into a new contract, and a version update won't do that unless there's a charge for the update, based on FAS (Federal Accounting Standard) rules, since without an exchange of consideration, there is no contract. This is why Apple charged for the WiFi software update on iPods, and non-cellular network iPads, but didn't charge for cellular connected iPads and iPhones. It had to do with realization of revenue over time, versus a one time sale, and adding features to the device via software.
You should also be aware that the image that's shipped by the OEM is often not even buildable by Google engineers; apart from the fact that the devices used during development are generally signature neutered, and it's impossible to cryptographically sign the image for the given device without it either being neutered like that, or signing code that they device manufacturer generally does not share due to it containing a signing key they don't want out there... they entirety of the board file is generally not committed back to the Google maintained Android source tree. Nor is it maintained going forward so that it's up to date, nor is the remainder of the OS productization standardized across all the OEMs. They are trying to differentiate their products, after all, and my Samsung device looking and feeling exactly like a non-Samsung device is not in Samsung's interest: it makes them into a commodity, which is a quick race to the bottom on margin.
Google has significant dictatorial powers when it comes to Chromebooks, which are not available to the Android folks, even if they had the ability to code sign, and could dictate a code cut, the Android in the tree is pretty raw, and never productized.
Finally, Android lacks a uniform app ecosystem; this is a more or less direct consequence of having allowed third party stores, without a strong compatibility for the apps across all devices.
Seriously, one of the smartest things that Apple did was keep the baseband processor separate from the application processor so that there was no telecom recertification required, unless they were explicitly hacking the baseband for some reason (e.g. the carrier lock they did by re-doing the SIM/IMEI handshake when doing a hand-off between cell towers in order to intentionally break SuperSIMs and similar techniques for hardware carrier unlocks).
Without the app ecosystem and the continuity of app and other content going forward on Android -- which it doesn't -- I don't see a means of enforcing carrier lock-in to support that economic model, particularly if you started supporting software updates.