What was your point exactly in that respect?
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.
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.
https://source.android.com/compatibility/overview.html
So I don't know what you're basing this off of?
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.
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.
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.
Yes, the Android ecosystem has an update problem. But that problem is largely due to external companies and not a technical limitation of Android.
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.
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.
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.
I think we agree here, but for different reasons.
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.