Google Further Shrinks the Size of Android App Updates (engadget.com) 50
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.
Compress smarter (Score:3)
Get smaller patch sizes by compressing the things that people actually change... didn't git do something like this?
Re: (Score:2)
What a breakthrough! (Score:5, Insightful)
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...
Re: (Score:3)
diff, rsync, git, et.al. are NIH, can't use them without compromising security of the user lock-in.
Re: (Score:3)
They do have their own binary diff format. They use it to update Chrome:
https://www.chromium.org/devel... [chromium.org]
Re: (Score:2)
But do the major repositories that distribute Chromium (Debian, Ubuntu, Fedora, CentOS, etc.) use this binary diff technology? Or do they still resend the entire deb/rpm?
Re: (Score:2)
I imagine that a lot of the stuff that's changed such as images and sounds doesn't really work well with diff anyway.
Re: (Score:2)
I imagine that a lot of the stuff that's changed such as images and sounds doesn't really work well with diff anyway.
See the rsync protocol, which can be used by things other than rsync. For example, BackupPC uses it to transfer only the parts of files that have changed, which includes binary files.
Re: (Score:2)
Lossless compression, such as PKZIP for Microsoft Office and LibreOffice documents, FLAC for audio, and PNG for images, makes it less trivial in the general case to find "only the parts of files that have changed". A protocol like rsync would need to have specific support for each archive container and lossless codec in order to identify said "parts". This story is about Google Play Store gaining such support for APK files, which use the PKZIP container.
Re: (Score:2)
They are unzipping the apk first. It's right in the summary. So the GP I replied to was referring to the files within the apk, and said, "a lot of the stuff that's changed such as images and sounds doesn't really work well with diff anyway". This has nothing to do with the lossless compression you mentioned (which, though I doubt they're doing this, could be diff'd very well with a slightly smarter diff, as they are lossless, so they can be decompressed first, then diff'd, and the diff can be sent and appli
Re: (Score:2)
His comment was "only the parts of [image, audio] files that changed. It seems you are agreeing with him.
Re: (Score:1)
I would argue that you don't need to worry about diff for images and sounds, because an image/sound is either wholly replaced or not changing release to release. Those would simply not be sent for most updates if not changed. The remaining content could benefit from diffs.
Re: (Score:2)
... a pretty bad idea since, if you have version 1 of something, and version 8 is the most recent, you end up having to download patch 1 to 2, 2 to 3, 3 to 4, etc, and apply them all successively ...
So the problem is obvious then, and easy to resolve. ... etc ...; from 7 to 8.
* calculate the patchset from version 1 to 8; from 2 to 8; from 3 to 8;
* provide the patchset based on their current version and target version
Alternatively
* provide the patchset between versions, but if the user is further out of date, just provide the whole new apk.
* TFS claimed a savings of only 65%, so sending more than two patches would use more than sending the whole apk.
* Patches between distant versions would likely have
Re: (Score:2)
That's because Windows users are unruly, blocking updates, etc.
How many Android users just let the updates roll in hourly?
Re: (Score:2)
Another way would be to install fewer shitty apps in the first place. I reckon half of of my phone's storage is taken up by stuff that I don't use. I don't even know what some of it even is.
Wow (Score:1)
People still have limited data plans, where this really matters to the end-user?
Why?
Re:Wow (Score:5, Insightful)
Provided some simple apps can be north of 100MB, I very much welcome that you can update without redownloading everything. That is particularly true for apps that insist on being at the latest version to run.
Re: (Score:3)
Because even unlimited plans are limited......pick one and there's a cap (usually right around 22GB for some reason) where the speed will drop. If you hit that cap often enough, you'll be dropped from the carrier. It's in the fine print.
And they aren't "cheap" unless you're a single person making decent money or with few other bills to pay. Family plans save money vs a bunch of individual plans, but they still aren't cheap.
Most people don't live in Finland (Score:2)
How many American citizens can Finland's immigration absorb?
Re: (Score:2)
*) Offer valid only in some countries.
Re: (Score:3)
Unlimited data plans have been very cheap for several years now.
Not in Slashdot's home country.
In some more remote parts of the U.S., the only option for high-speed home Internet is satellite, and satellite doesn't have unmetered data during waking hours. In other remote parts, such as East Buchanan, Iowa [slashdot.org], DSL is harshly metered as well.
Cellular carrier T-Mobile has introduced an unmetered plan [t-mobile.com], whose name reminds one of synthetic motor oil. But at $70 per month for the first of four lines on a plan, it's more expensive than metered plans, and it puts the subscriber at
Re: (Score:1)
Yes, you stupid idiot. It turns out that phone service all over the world is not the same. If you actually crawled out of the basement and walked your fat ass outside and traveled a little bit you might know that.
Google research scientists have done it again! (Score:1)
Always amazed out the fact innovation coming out of that place
Oh, sure, this willwork (Score:2)
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' hotspo
All well and good... (Score:1)
Quick get a patent (Score:1)
What a novel concept nobody has ever implemented before. Certainly worthy of patent protection.
Google discovers deltarpm (Score:1)
What about the signatures? (Score:2)
What happens to the app signatures when you do this?
It doesn't usually go so great... (Score:2)
Zip-aware Rsync (Score:2)
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.