What does "too little, too late" mean? Is Android now doomed?
Android updates have been incremental updates for three years now (introduced at the 2012 I/O, and immediately enabled). Your point on that is confused in any case -- why can't it do delta updates (it does...), and why can't the developer do it, but also why does the developer have to do it? You're incredibly complaining about a situation you invented.
And larger APKs are a problem because now the ridiculously easy tools that Google already provides (generating thin binaries for varied targets is extraordinarily simple. A bug regarding expansion files...what is the point of even linking that?) will somehow be unused?
Your post is a very poorly informed rant. I have no idea how it sits on the top.
What does "too little, too late" mean? Is Android now doomed?
I'm just frustrated that they're just doing tweaks, rather than any deep fixes. Obviously the platform isn't doomed, because the competitors aren't much better!
Android updates have been incremental updates for three years now.
Hmm, OK! I have seen some news articles around that, but I can't find an authoritative bit of documentation or official blog post. If you have a link handy, that'd be great.
I've observed in practice that all my test devices seem to do full downloads rather than deltas, though many of them are running older OS versions. And I'm mostly concerned about expansion files. It's possible that the APK parts use deltas at least some of the time, though again, in my spot checks that doesn't seem to be the case.
why can't the developer do it, but also why does the developer have to do it?
What I'm envisaging is, the developer builds APK version 2 locally. They send a v1 -> v2 patch to the Play Store (which already has the master copy of APK v1). Use checksums to ensure it's all working as expected, and in the worst case fall back to a full upload of v2.
Maybe from Google's point of view it isn't worth spending any engineering effort to help developers who don't have access to really fast uploads. But it's not rocket science and it sure would be nice.
A bug regarding expansion files...what is the point of even linking that?
I think it's relevant because their recommended method of shipping a really big app is to put resource data into an OBB (a virtual filesystem), but the tools for building an OBB don't actually work reliably. Worse still, Android itself can't mount an OBB reliably! So if you care about stability and/or supporting a decent range of OS versions, you can't use OBBs at all. You have to use a zipfile or something as your expansion file, and manage it yourself. Not a huge deal, but it's more work, and it all contributes that little bit more to the bloat many people complain about.
Google announced smart updates and then enabled it (they had already been using this for Nexus system updates). There is absolutely nothing any developer or user has to do, so there is no documentation on it because none is needed. If you actually monitor the connection during a smart/delta update, while the UI shows the full size of the APK it actually downloads 1/4 or less of that.
It is absolutely enabled. It is absolutely working. There is no conspiracy about this. It is one of the reasons most updates take hours to propagate.
You complained about managing thin binaries, so I don't see how the developer managing that would improve anything, not to mention that it adds difficulties to cryptographic signing and verification.
Google announced smart updates and then enabled it. There is absolutely nothing any developer or user has to do, so there is no documentation on it because none is needed.
OK, that's good news! I stand corrected.
It would still be great for expansion files to get the same treatment, or better yet to abolish expansion files and just allow big APKs.
I'm a little sceptical that absolutely no documentation or feedback is needed. Surely there are things that I as an app developer could be doing to make the deltas smaller.
You complained about managing thin binaries
To clarify, as an Android developer you can manage thin binaries yourself, as a way to reduce the download size; it's just a hassle. My complaint is really that the Play Store should do that app thinning automatically.
Updates to Xcode added what Android's tools have had for years, which is the notion of generating multiple binaries for different devices/profiles. Xcode then signs those independent sections and packages them together in an archive, while Google has you send them up separately, each signed separately.
Apple sort of presented it like the App Store is picking and choosing, but it's the enhancements to Xcode that actually enable the functionality. Google could add some tooling improvements to make it slightly easier, but really they've already done all of the hard parts.
Expansion files were a hack, and remain a hack. They are necessary for large games obviously, but really 100MB encompasses the enormous bulk of apps with ease. It would be ideal if Google simply abolished expansion files and folded the sizing into normal APKs.
Android updates have been incremental updates for three years now (introduced at the 2012 I/O, and immediately enabled). Your point on that is confused in any case -- why can't it do delta updates (it does...), and why can't the developer do it, but also why does the developer have to do it? You're incredibly complaining about a situation you invented.
And larger APKs are a problem because now the ridiculously easy tools that Google already provides (generating thin binaries for varied targets is extraordinarily simple. A bug regarding expansion files...what is the point of even linking that?) will somehow be unused?
Your post is a very poorly informed rant. I have no idea how it sits on the top.