I'm rather sure fidotron is talking about the technical aspect of the updates. Which has practically nothing to do with the political aspect you're talking about.
It's not about politics. You're putting words in my mouth. Android is pretty much devoid of an update mechanism. You're left to to swapping out the entire OS image to update it. That won't work in the server space when you need a new ssl lib deployed now.
I think this snappy scheme of Ubuntu might actually be what Android should have had from the start. It seems like it work in the embedded space when you don't want a traditional package manager.
What are you talking about? OTA updates have been in every Android version for years now. And it is not just a full image update system it also fully supports partial delta updates.
Just because a few phone vendors stop pushing out updates after a period of time after launching the phone doesn't mean that Android doesn't support it. This might have been a valid criticism about years ago. But one that should be aimed at vendors and not Android.
Regarding vendor support, Google launched an initiative called "Compatibility Program" which every vendor must now agree to. Part of the agreement means they are required to support OTA updates if they plan to use the Android OS.
If I understand what xorcist is saying, is that Android does not have updates for components of the core system. So replacing a specific library has to wait until the next complete push of Android. Phone makers package up system updates as full android releases rather than component releases. You can update apps, but now your App is at version X and the android it is running on is at version Y.Q.R (my phone is sitting on 4.4.2 atm) so App vendors are at the mercy of keeping as many versions out there as there are Android versions (which vary with respect to the needed component).
All of which could be fixed with something like Snappy where the OS component that is improved could be pulled OTA by the customer.
The meta discussion is that customer cannot do that because a handset maker has no way of reasoning about how changes to a component of the system will affect all handsets out there, and so new versions of android sit in all-or-nothing testing limbo at the handset QA lab.
> So replacing a specific library has to wait until the next complete push of Android.
I know for a fact (because I've created my own ROM) that Android's OTA system is fully capable of updating single components. And the update the user downloads is not the entire ~200mb Android ROM, it could be a small 1mb zip file that only updates a specific library. For example a security release updating only OpenSSL.
Why Google doesn't do this and prefers using a point release system - instead of rolling releases - is a complicated question. One that I'd be curious to hear the reasoning for.
One UX consideration is that the users need to reboot their phone since the OTA update writes to the /boot partition and then triggers a reboot into recovery mode. Then recovery mode will automatically install the new update (preserving all user data) then boots back into the OS. This would be annoying to users if they had to do it often.
But the same behavior exists for any OS updates on OSX, linux, etc.
I did not know what, I tought you had to build a new release (from which you could distribute deltas), for the simple reason that no Android device does that.
It's not a viable method for updating generic servers however. An update system needs to do a lot more than just swap out a file. You need to know about dependencies, restart services etc. It's also important for real world usage to be able to skip one update for one reason or another.
It could be interesting for single purpose Docker containers which can be restarted at will.
If you're going to count every derivative of AOSP Android, to make a fair comparison you'll also have to count every for single distro that is based on Ubuntu - how frequently do they all get kernel updates, etc?
Yes, the Android ecosystem has an update problem. But that problem is largely due to external companies and not a technical limitation of Android.
I think he's talking about the literal update mechanism on your phone. It's usually a literal flash over the existing rom, not a delta or single packages like most linux distros enjoy.
That's not always true. Most ROMS update by first downloading, then flashing the entire rom with the new version. And most OTA updates kill your root if you have it because they reset the entire system partition back to factory state, not just the updated part.
CyanogenMod OTA updates preserve root... because the OTA image contains root access and SuperSU.
So what OTA updates do you mean? If you mean stock Android updates removing root access...then that is exactly the expected behavior. Root is considered a security hazard and not supported by ASOP. As it should be.
I find it hilarious when people who use ROMs complain about how hard it is to modify the OS then complain about lack of security updates in the same thread. Bootloader locks and read-only filesystems are there for a very good reason.
Who's complaining? Cyanogenmod absolutely does a full rom flash, you can look at the download... it's the full shebang. Other stock roms might just unzip overtop the system partition, which would "update" anything that it overwrites. They usually kill root because they reset the system partition back to stock as for a normal user is should be unmodified (yes for security reasons, but also because that's how they want it to be).
perhaps we're talking past each other... because you seemed to miss my point... phones don't update single packages as updates are available like a typical linux distro would.
Lots of ROM people complained when Android locked down bootloaders and when SELinux went into enforcing mode, making /system read-only, etc, etc. Google is attempting to help protect users from bootkits/rootkits which has a side-effect of making modding harder.
See my other comment, Android's OTA system is fully capable of updating single components. The downloads can be patch releases and not full images. Google actually recommends that vendors do this, over pushing full ROMs.
Vendors often don't do it because they are lazy or for logistical reasons. But it doesn't mean they can't.
That's a device/vendor choice, not Android as a whole.
> and when SELinux went into enforcing mode
On my stock rom it was in Permissive mode, as it is now on Cyanogenmod.
> Google is attempting to help protect users from bootkits/rootkits which has a side-effect of making modding harder
This is generally not Google's doing, it's the device manufacturers/carriers. And it's not always in the name of end-user security... which far too often abandon any updates on 1 year old devices.
> See my other comment, Android's OTA system is fully capable of updating single components
But it's not really. It's just downloading a zip file and extracting it. There is not 'apt-get' or 'yum update' functionality built into Android, and there probably can't be due to how custom every rom (even stock from the manufacturer/carrier) is. I would love it if my phone could do a "yum update" like thing and just yank down individual components as soon as they are available... but that's not reality unfortunately. When users do get updates, it's usually months after they were discovered to be at risk for some exploit due to carrier bureaucracy.
> Google actually recommends that vendors do this, over pushing full ROMs.
Mostly in the name of saving bandwidth for data capped users.
> Vendors often don't do it because they are lazy or for logistical reasons. But it doesn't mean they can't.
The notion of "updates" for most rom users (I'm on Cyanogenmod), is literally a flash over the existing rom.
However my busybox updater app does run in the background and does update busybox as needed automatically. Same with my su updater. So I suppose parts of my android are indeed auto-patched without my noticing.
Pretty much every device out there has multiple known security holes and they're not getting updated.