Suffice to say, if it was as easy as waving the magic wand you think it is, it would have happened already.
Instead, if you tried to wave it, handset makers would have walked and just done something else.
Heck, some did!
Besides, why stop at Google?
Why not blame the carriers for devices like this be on their networks?
By your logic, if Verizon told Samsung tomorrow said "you must update your phone monthly with security updates in order to stay connected to our network" it would have just happened!
Maybe instead of assuming a vast lack of caring or outright maliciousnss, you should consider that maybe it's not the trivial thing you are making it out to be, and that's the real reason it hasn't happened yet.
Yes some have and some more would have. And then it would have been up to these holdouts to come up with a viable OS. Good luck with that. Almost everybody who tried has failed.
There is no doubt in my mind that Google could force it successfully, but why would they? Everything is moving in their direction anyway and users don't seem fazed.
Surely Google is not intentionally refraining from solving the high fragmentation it is suffering from (which makes developing for Android harder, and keeps some people from receiving security updates)
Because it causes friction, it's a distraction for management, and there is a danger that some of those rebel handset makers could have some success or get poached by Microsoft/Bing even if they fail at creating an alternative OS.
There is risk without much upside for Google compared to the gradual approach they are taking now.
Walking away from Android is not currently a realistic option for most of them (recent Sony Sailfish news non-withstanding).
If only they had thought of this. Oh, that's right, I forgot, it's not that this is much more nuanced and complex ecosystem interplay, it's that it's very black and white and they uniformly don't give a crap.
Sadly this also leaves us with the current sorry state of affairs. I don't think much "could've" and "would've" would be helping there, but I would very much like to see a major economic force guaranteeing some common grounds for devices. Imagine what an "IBM clone era" of phones could mean - all it would take would be a common ground w.r.t booting and a couple of drivers.
Sometimes I'm really left wondering why we can't have such nice things...
The sad part is that the 2016 security report just came out and they brag how the whole security improved, without mentioning the elephant in the room.
Google IO is around the corner and I bet they will keep talking as if everyone could upgrade right away to Android O, with N now having barely 2%.
And this mentality is eating its way into all corners of IT as there is a generational changing of the guards. More and more Linus Torvalds (Linux) and Daniel Stenberg (cURL) staying with a project for decades are massive outliers rather than a norm.
This is why they can claim that anything shipped from 2017 onwards will support Android apps, but maintain a list of potential devices from before that. Because said support need various container related features only found in newer kernels to work.
Effectively Google has further masked but not really fixed the issues that makes major updates to Android devices such a hassle.
The Pixel XL was released in October of 2017 which means updates stop one year away from today in April of 2019. Top of the line is $968 and you want top of the line for best memory performance. Why buy one of those phones and purchase sub par performance? It's a waste of money. So if I wanted one I'd pay $80/month for a device that's replaced in October of this year (Pixel 2 is supposedly an end-of-year release) and dropped from feature upgrades not too long after that.
Google need to fix their feature window by extending it to two years and fix their supply pipeline by ordering apple-like quantities of product. Otherwise they're not really competing with Apple.
But let's follow this silly thread anyway. On average, the lawsuit would take three to seven years to resolve.
Assume they win: great, they get some small amount of damages and everyone stops using Android. They can't and won't ever get the remedy of forcing security updates. It's not even something available.
Assume they lose: great, they get nothing and everyone stops using Android.
What did this solve again?
As for the other OEMs, there is this thing called contracts and legal obligations.
No updates, no access to Google services from invalid devices.
It is as easy as that, if Google actually cared about the consumers.
Also, the point is still valid that 36 months (or 3 years) is still rather short security lifetime for a device. At some point (presumably soon now that carriers are dropping most device subsidies) the 2 year replacement scheme of mobile devices stops being sustainable and you do start to have to deal with the long tail of people sticking to 5-15 year old hardware devices.
Google seems to have little interest in anything beyond the short horizon and that security tech debt is going to come due.
He stated "+1 for some fixes" which is incorrect as it implies that you may not get all of the security fixes for that additional year and only "some" of them.
>Also, the point is still valid that 36 months (or 3 years) is still rather short security lifetime for a device. At some point (presumably soon now that carriers are dropping most device subsidies) the 2 year replacement scheme of mobile devices stops being sustainable and you do start to have to deal with the long tail of people sticking to 5-15 year old hardware devices.
I agree it is rather short and the sooner Android OEM's can move from an SoC supplier, like Qualcomm, that only provides BSP support for 2 years the better.
The OP's statement was for "upgrades" not security fixes; I read it as 2 years upgrades and 1 for security fixes beyond feature upgrades. The choice of "some" was ambiguous, but "upgrades" is much less ambiguous to me than you seem to consider and not something I'd directly confuse with "security fixes" alone and something that the (+ 1) seemed to directly add "security feature" context to me, despite the ambiguous wording.
Though that still raises the question of if Google properly subsets general (feature) upgrades and security fixes across that 2 + 1 time period. The ambiguous word choice of "some" could be an editorial indication that the OP considers that Google is likely to release some fixes in more general upgrades that don't fall into that (+ 1) time period. As a non-Android user/follower, I have no knowledge in that area and no opinion to offer of my own if that may in fact be the case. I'm also not the OP so I can't express whether or not that was an editorial opinion.
Even if it was an editorial opinion that was expressed, I'm still not convinced it was "disingenuous on purpose", as it may very well be a sincere/candid opinion of the OP. I can only leave that for the OP to comment on.
Just because a fix is available today doesn't mean an old Nexus will get it.
As for agenda, as a consumer and developer, I want a device where I am able to use the same Java libraries as on a regular Java and get updates as on any of my computers without having to pay more than a month salary for such time limited privilege.
Personally, I place all the blame on Google for not making the upgrades possible from their side. It should be easy to upgrade the core operating system as easy as updating Windows, OSX, and Linux.
This makes no sense. "People associate X with Y" is not the same as "Y is responsible for X". If I associate Android with Linux, is Linus now culpable for Android's security problems?
> Personally, I place all the blame on Google for not making the upgrades possible from their side. It should be easy to upgrade the core operating system as easy as updating Windows, OSX, and Linux.
If we were living in a fantasy land where you could wave a wand and things would happen instantly, this would be the case, but mobile devices are not desktops and the challenges they face are entirely different. Google has already been moving logic as much as possible into apps like Google Play Services (updateable without OS changes_, and the fact that they haven't moved everything should make all but the most technically illiterate think "There may be technical challenges involved", instead of your "They're not making this easy" approach.
I understand that, but many of the non-tech savvy people I know do not understand that Google is not responsible for most versions of Android that run on their phones.
> ...but mobile devices are not desktops and the challenges they face are entirely different.
I do not see how they are much different. To many people, their phone is just as important as their desktop/laptop. I do not see anything stopping updates to Android being invisible to the end use as most other updates. iOS is pretty good about updating in a way that is unobtrusive to the user and Windows 10 is getting closer.
It should have been called a "platform", and, since Google has the ability to say so, they should have told each hardware maker to come up with an OS name "on Android". Tizen on Android. NexusOS on Android. So on.
OR, they should have gone Apple and said "you will have this OS, Android, and it will look as such, and it will be patched as such".
This is ridiculous. Linus in Android is a component, not a whole system, and phone vendor own SW are way too accessory in the ecosystem and add so little value in it that they don't render Android a mere component in the same way: the base Android is the system, whereas drivers and 3rd party GUI or other minor stuff are what should be sufficiently decoupled so that Android can be updated without vendor consent.
Doing otherwise has proven to expose users at risk, and given its situation Google is responsible, not a swarn of phone vendors.
I might not be saying that if Android was really open, but then Android might not have that market share. Well, in the end, even that reinforce the argument that Google is responsible...
For most people a computer, a phone, or a tablet is an appliance.
We are getting closer to the point where being secure and up to date is almost painless. That should be our goal in the tech industry.
Also, they could isolate the Java VM layer further such that it could be updated independently of the Linux kernel and related userland.
Google would like you to blame the manufacturer, but you need to realize the fact that you even can blame the manufacturer is a design flaw in the OS which Google designed.
>Google would like you to blame the manufacturer, but you need to realize the fact that you even can blame the manufacturer is a design flaw in the OS which Google designed.
This sentence makes so sense. Google cannot update an OS that they did not create. The OEM rolled the OS so only they can update it. How exactly does Google update an OS from an OEM they don't even have the source for? It's the OEM's responsibility and if that OEM doesn't do their job in updating their OS then maybe it's time to start looking for an OEM that does do their job.
2. Google created the OS. In fact, OEMs are forbidden from forking Android, and therefore, cannot "roll their own OS" from Android, without violating their agreement with Google. Yes, they sprinkle some of their own apps and drivers in, but this is a design flaw in Android: Google needs to be updating their own software independently of manufacturer-specific components.
I know for a fact you and I have had this discussion before.
Someone will mention the Kindle. The Kindle does not compete with Google products, as it is perceived in the market as an e-reader more than a "tablet". And Google barely even does tablets anymore anyways.
Forbidden from forking Android? Every OEM version of Android is a fork. What Google does not allow is for an OEM to distribute a version of Android that does not pass the Android Compatibility Test Suite.
>therefore, cannot "roll their own OS" from Android
Do you know how OEM's "roll their own OS"? They take the AOSP source code that Google drops and then they add all of their source code and then build and distribute their own version of Android that only they can update.
>Yes, they sprinkle some of their own apps and drivers
I'm not sure you really understand all of the changes OEM's make to Android if all you think they do is "sprinkle some of their own apps and drivers in"
>this is a design flaw in Android: Google needs to be updating their own software independently of manufacturer-specific components.
No it's not. Google does not build Android for the OEM's. They create their own version of Android and therefore are ultimately responsible for updating it. Once again, Google cannot update an OS they did not build.
>Google barely even does tablets anymore anyways.
Android is still the marketshare leader in tablets.
Yep that's a insanely huge design flaw, coherent with:
"Google needs to be updating their own software independently of manufacturer-specific components."
Is Debian also responsible for Ubuntu's security flaws?
Why do we fault the company for taking steps to pull Android as a brand together?
Google uses their agreements with OEMs to force them to bundle apps and including Google's branding, and protect their business, but refuses to use those agreements to ensure even basic security for their users.
Because we already lived in that world, and it was less secure than the one we live in now, to my memory. Security issue in one of the Android libraries that are now part of Play Services? Good luck; wait for your OEM to update your OS.