Slashdot Mirror
Google Further Shrinks the Size of Android App Updates (engadget.com)
Google says it has found and implemented a new way to make app updates on Android smaller. From a report on Engadget: They're introducing a new approach to app updates that promises to radically shrink the size of updates with "file-by-file" patching. The resulting patches tend to be about 65 percent smaller than the app itself, and are sometimes over 90 percent smaller. In the right circumstances, that could make the difference between updating while you're on cellular versus waiting until you find WiFi. The technique revolves around spotting changes in the uncompressed files (that is, when they're not squeezed into a typical app package). Google first decompresses the old and new app versions to determine the changes between files and create a patch. After that, updating is just a matter of unpacking the app on your device, applying changes and compressing it again.
Get smaller patch sizes by compressing the things that people actually change... didn't git do something like this?
Now, if only there were a way to shrink the update further by transferring only the parts of files that have changed -- in other words, the information that's actually different...
rsync?
Not only file by file but only changes within a file?
People still have limited data plans, where this really matters to the end-user?
Why?
Slashdot: providing anti-social weirdos a soapbox, since 1997.
Always amazed out the fact innovation coming out of that place
I thought I read something awhile ago that indicated that unity apps package all of their resources in one blob. My guess is that means no difference to those apps?
Back when I made apps I compressed with kzip and that produces smaller apk files, this will undo all that effort.
Especially the updating over Cellular vs, WiFi thing.
I regularly get updates (yeah, some of us do) that try to force going over WiFi, despite my having set updates over both Cellular (Mobile) and WiFi and expecting these to happen. Whether the carrier, Google Play Store, or the app dev do this, they try to force these over WiFi, size not being an obvious factor.
So I have to manually trigger these.
Morons. What fun it is to have WiFi enabled on my phone during lunch, when I walk by 6 different 'open' hotspots, each of which wants me to accept some T&C whatever, and each latches onto my phone and prevents it from even receiving SMS until I do something. Yes. T-Mobile. Probably due to WiFi Calling, I bet.
It's not all kittens and glitter out there. Stuff sometimes doesn't really work like ti was expected to, and I should not complain. Much. I get paid to deal with these sorts of problems, and if I were not, or they did not happen, I would have to work for a living.
It's not hard work to point out the obvious, just annoying.
deleting the extra space after periods so i can stay relevant, yeah.
But if the OEMs don't bother patching, who cares how small the patches are? Google needs to address the elephant in the room - how can google, ummmm, encourage its OEMs to patch Android systems?
What a novel concept nobody has ever implemented before. Certainly worthy of patent protection.
How old is deltarpm? I'm sure that deb packages must have something analogous. The funny thing is there has been some chatter on fedora-devel about removing delta rpms. Supposedly it's no longer considered useful anymore. Don't recall what's the status on that.
I tried doing this with some software I released back in dial-up days. On the surface it sounds great, just download a tiny binary diff and apply it to the program. In practice it was a nightmare. First, I didn't read the fine print closely enough. While the diff tool provided very small diff files, it wasn't deterministic. When you applied the patch you didn't always end up with a 100% clone of the new file. I don't have a clue how that's useful, what data format can handle random corruption? So I switched to a different diff tool. This one's diff files were larger but they always worked. Now you need to generate diff files for every release version of your software. Users don't like downloading and applying update 1, update 2, update 3, etc... But they also don't like having to skim through a ton of updates trying to matching their specific version to the patch they need. Users would grab the wrong patch then complain the software sucked.
In the end it was easier to tell them to just download the latest version (100MB instead of a 15MB diff) and install it on top of the old one. Nowadays I guess it's easier because the proper patch would be downloaded automatically, but things weren't always that simple. Now get off my lawn. I think I see a flock of pink flamingos heading this way. Time to play with the lawn darts.
What happens to the app signatures when you do this?
for tech companies that reduce the need for a commodity that their major distributors are over-profiting from.
How many American citizens can Finland's immigration absorb?
So, they're slowly moving towards a version of rsync that's aware of zip files. Hell, zip files are compressed per-file, so it doesn't even need to be aware of the compression.
And Microsoft is also looking at differential updates. Seems everyone is busy reinventing rsync or zsync.
patch -Pnes mydickapp