Indeed. Even the supposedly quickly updated Moto X did not receive a patch yet two weeks after the fact [1]. I feel sorry for all those people who are still stuck on Kit Kat or even worse Jelly Bean.
I feel for people whose providers won't upgrade them and I think they've got a good complaint, but if you choose to get off the upgrade path I think it's reasonable to assert that you're assuming responsibility for your own choices and security. I expect it can be backported to 4.x via custom ROMs for folks in that spot.
It's not an apples-to-apples comparison, but Android has been around since 2007, and they're up to API level 22 right now. In that same time period, Microsoft has had the following releases of Windows (excluding Mobile/Phone and Server):
Vista, which actually came out in 2006 in the OEM edition
Windows 7
Windows 8
Windows 8.1
Windows 10
Windows has had a much slower release cadence than Android. It's a much, much bigger burden on Google to continue to support older Android versions with bugfixes and security patches than it is Windows. Now, you can counter that Google decided on this release cadence, but still, I don't think it's reasonable to expect Google to support Android versions as long as Microsoft does Windows versions, as some here are stumping for.
(That said, every time I read an article about Android these days I get the urge to buy a Windows Phone.)
I have a Lumia 635, which is nice "for the price" I agree but not nice enough to switch to full-time. I'm hopeful that the new high-end phones provide a real choice.
But there is quite a difference between the 635 and the 640: non-HD vs. HD, possibly 512 MB RAM (depending on the version) vs. 1 GB RAM, 5MP vs. 8MP camera.
I agree that new flagships would be nice though. Especially with Continuum.
The fact that Google created a huge maintenance burden for themselves shouldn't absolve them of responsibility to provide that maintenance.
Microsoft supports Windows versions for ten years, and I agree that's crazy for Android. However, three years I feel is a bare minimum expectation. Devices tend to remain on the market for about a year, and the standard phone contract is two years. So three years from a version release should cover the vast majority of users for the life of their device, should they choose not to take "system upgrades" which may slow their device or change it in an unwanted manner.
I agree that DEVICES should be covered for n years, where n is somewhere between 3 and 5 and we can quibble about the specifics later. I don't think that backporting fixes should be the way we gauge this if newer versions are available instead.
The problem is that newer and better are not synonymous. And most Android users have probably learned by now that their devices getting slower with each update, not faster.
Here's the problem: It's a DROID Turbo. It's locked down by Verizon/Motorola, and neither root nor bootloader unlock has been achieved. So it's not even an option.
The problem is that the "upgrade path" and the "security fix" path need to be separate things. People should not be forced to have their device changed in an unacceptable manner (I did not buy a device with 'material design' for a reason, and being forced to get it to get a security fix is an unacceptable situation.)
I think, honestly, the only real answer is "don't buy locked devices if you want to make those choices." Google doesn't control those devices, and that part of Android is open source. You can make those decisions, but you're earning the consequences with them.
This, as it happens, is why I buy phones with unlockable bootloaders. My current phone uses the OEM build, but I like having that choice.
Google :does: control those devices. They're MADA agreement devices, which means Google approves every device that goes to sale, and Google approves every software update they release.
Unfortunately, as a Verizon customer, I don't have a wide variety of options with unlockable bootloaders. And the battery life on the Turbo was simply, the only feature that mattered. Usually there's an unlock within a few months, but there still isn't one at this point for the Turbo, I guess.
Obviously it wasn't the only feature that mattered, though? I mean, you're complaining about another feature right now. =) Like, I'm sympathetic, but this is a solvable problem with the information at hand. Buy phones with unlocked bootloaders. (As it happens, this is why I steer clear of Verizon...)
It's not just a providers. I've got a couple of el-cheapo $80 Androids just a month ago to use while traveling. They're running 4.4, Android 5 is not at all being offered for them, and probably never will. I guess I can throw them in the trash if I care about owning them myself.
Being el-cheapos, they aren't even supported by cyanogenmod. Anyone has an idea for how to use them (somewhat) securely?
This was one of the big motivating factors for me getting a nexus 6 (aside from the size) and putting it on the fi network. I got 2 updates in the period of a week.
I think the problem is vendors and carriers wanting to modify and inject their crapware and custom UIs into Android. Google is happy to provide upgrades to the OS in a timely fashion (and are going to start monthly updates), it's the vendors/carriers that delay these updates or don't even bother to port them over to devices.
Google is moving much of the core Android functionality over to specific apps that they can update as needed from the play store, instead of integrating them directly into the OS. This is good, because it allows them to push the updates quicker. They run the risk that carriers will get sick of the lack of control over the "experience" they can provide, and fork android, but it's a necessary step in many ways to ensure things like this MMS exploit can be patched on some devices at all, as vendors abandon some phones quickly, leaving users vulnerable.
If every vendor and carrier used stock nexus android without modification, the updates could be pushed out in days. The linked article blames google for these problems, but that is, in my opinion, misguided.
> Even if Google patches this, there's an incredible delay in getting the patch to users.
I don't think delay is the problem - not being able to get or apply the patch yourself is the problem. Ignoring the somewhat ridiculous requirements to compile Android (200GB of HD space and 16GB of RAM [1]) - you couldn't put it on your Android device due to proprietary drivers for wireless and/or video.
Assuming you can get an updated version - I have noticed that after getting root on my Nexus 6 it won't install new versions of Android. I don't know if it's a by-product of getting root/installing a new recovery or if they have an actual check. I have a legitimate reason for root because I use FreeOTP and it does not have an export feature - so I use Titanium backup to backup and restore the app. Getting the OTP QR codes for: dropbox, gmail, Microsoft account, facebook, srchub, github, paypal etc would take a very long time and considerable effort to recover (hint gitlab).
It's a check - as of Android 5.0, Google's OTA updater scripts refuse to overwrite your /system partition if its checksum isn't on the known-good list. Rooting inevitably involves writing files to it, so OTA updates will stop working with an uninformative "Error!" in recovery. Whoever came up with the idea should be fired, but that's Google for you.
See [1] for details from the author of NRT [2], which can update your phone from factory images without wiping it. The procedure is a bit more involved if you're not on Windows - IIRC, you have to download the correct archive from [3] and modify the update script so it doesn't try to flash userdata.
> Whoever came up with the idea should be fired, but that's Google for you.
To be fair to Google, once you've modified your /system partition, it's really case-by-case how an update will interact with it. The alternative is Google push an update that inadvertently bricks a bunch of rooted phones. Can you imagine the kneejerk reaction from the internet then?
> The alternative is Google push an update that inadvertently bricks a bunch of rooted phones. Can you imagine the kneejerk reaction from the internet then?
That already happens [1] on non-modified devices. So just come up with a "yes I know what I'm doing and accept that this may bork my phone". Or and even better idea - how about the ability to turn off OTA updates? Right now my phone says there is an update but I can't apply it due to being rooted.
Regarding exporting OTP settings: My solution was to use Titanium Backup on the Google Authenticator app, extract secret keys from that data, use them to create GA-compatible setup QR codes for each account, and save those QR codes in KeePass.
You could likely do something similar with FreeOTP, once that's done you can easily restore your codes without root. (And from then on be sure to save any future setup QR codes you use.)
> Almost all users would be incapable of applying patches themselves.
There are currently 357,101 registered users on XDA developers. Saying "almost" every android user can't apply a patch is somewhat far fetched.
Most procedures on XDA developers have a much better step by step documentation than most SDKs I've seen - and every time I've used them it's been successful. I've only had one issue regarding flashing a radio - but that was my fault for not reading/paying attention and Motorola for not allowing a lower version of radio to be flashed...
Yes - there are grandmas and people who don't even know what Linux is would not be able to apply the patch themselves - but you are going to find that in any market.
I think something got lost in translation - I'm not saying for the manufacturers NOT to release updates.
I'm advocating for the ability for people like me to be able to apply the patches manually - and thus as a result the ability to remove and tweak the underlying OS to my liking. As it stands right now I can't do that due to proprietary drivers.
> What proportion of Android users do you think would be left unpatched?
But I'll humor you. Analyzing the breakdown of Android devices [1] - I would argue at this point devices running 4.2.X and lower will never see another update (because 4.2 is almost 3 years old - if there is an upgrade available people haven't or will never upgrade). That is about 34% of Android devices who will, arguably, never see another update.
I do like how they left off Honeycomb (3.X) - I know for a fact there are still devices out there running it so that graph is a little off.
Oh, I get it, so when you said you don't think the delay is the problem, while quoting a sentence talking about getting the patch to users, you were in fact talking about what you wanted, not what would be good for general users.
There is a major issue, not sure if in the rest of the world, but in Canada, the service provider has to request, and commonly pay for, the patch to which the manufacturer completes and then the service provider then pushes out to their devices. At least that is how it was when the E911 issue happened, it may be better now, but knowing Telecoms in Canada, I wouldn't be surprised if it wasn't.
It's not better. Look at the proposed target released dates for StageFright patches by Telus. And considering that it is not even fully patches, this only adds to the insanity of the situation with regards to Android fragmentation and carrier's controlling releases.
OEM Model Target Release
HTC One M7 August 14th
HTC One M8 August 14th
HTC One M9 August 14th
HTC Desire 320a August 28th
HTC Desire 601 August 14th
LG Nexus 4 Completed
LG Nexus 5 Completed
Motorola Nexus 6 Completed
Samsung Galaxy S5 August 11th
SamsungGalaxy S5 Active August 11th
Samsung Galaxy Alpha August 21st
Samsung Galaxy Grand Prime August 21st
Samsung Galaxy S6 Completed
Samsung Galaxy S6 Edge Completed
Samsung Galaxy S4 August 28th
Samsung Galaxy Note 3 August 30th
Samsung Galaxy Note 4 August 11th
Samsung Galaxy Core September 4th
Samsung Galaxy Tab S 8.4 September 4th
Samsung Galaxy Tab S 10.5 September 4th
Sony Xperia Z3 August 14th
http://www.extremetech.com/mobile/197346-google-throws-nearl...