[Android Apps and Games] evilwombat:
Dev here. That's a good question. It is safe, and I have not added any new code of my own (only modified existing code in place, plus modifications to resources and the manifest). But of course you only have my word for this. I just compared the v8.1 release candidate against its base APK (7/25) and I am seeing that my version is bigger by 28MB! (100MB vs 72MB). So, let's dig into that.

This is what I see so far.

One of the size differences is probably from the way secondary DEX files are compressed. Since we're using the Android 4.0.3 version of the base APK (which doesn't use multi-dex natively), facebook combines its secondary DEX files into one big file (assets/secondary-program-dex-jars/secondary.dex.jar.xzs). The individual DEX files are packed into separate JAR files (with 0 compression), and the resulting JAR files are then concatenated together (with some size hints written to a metadata file). The resulting file is then compressed with XZ. When I make DEX mods, I have to reverse this process, modify the DEX files, and then repack everything back the way it was. In my repack script, I am using the standard Linux 'xz' utility to recompress everything. To make my development cycle faster (since I make many incremental attempts at changes before making a release), I am calling 'xz' with the fastest compression option (xz -0) which speeds up my rebuild operation, but results in a slightly larger XZ file. Though the APK is bigger, this doesn't matter very much in the long run because the whole XZ structure is decompressed (and individual uncompressed DEX files written directly to FB's storage area) when you run the app for the first time. In fact, when you first start FB after installing and you see the flashing FB logo for a while, this is what's happening. You are welcome to unpack the APK and un-XZ my secondary.dex.jar.xzs file, do the same to stock, and compare the sizes. After decompression, the sizes should be identical.

But.... that only accounts for 4MB of the difference! Using xz -6 (default compression level) reduces my XZ file from 26MB to 23MB (same as stock), and reduces the overall APK size from 100MB to 96MB. So where is the other 24MB coming from?

Next, let's look at the rest of the APK contents. APK files are basically ZIP files with signatures, so we can 'unzip' both versions (mine and stock) and look at the size of the overall contents. It looks like the stock version is 150MB uncompressed, but my version is 156MB uncompressed (this is *after* using xz -6 to use the same DEX compression as stock). So, it is likely that either apktool (which I use to re-pack this stuff) is not using same ZIP compression level as stock, or maybe FB is using a more optimized compression algorithm on their end to reduce space. This doesn't matter very much in the end, because the big stuff gets uncompressed to your phone during installation anyway. But there's still a gap of 6MB that is unaccounted for. Let's see where that's coming from.

Digging through the directory sizes, it looks like 3MB of differences are coming from the resource directory (and compressed resource file). It looks like apktool repacks resources a bit differently from stock, and the differences add up to 3MB because there's a lot of individual resource files. Also, it looks like apktool/jarsigner create dummy entries in the .SF (signature?) file for some dummy resources, which add up to the rest of the differences. And since resources don't contain executable code, I'm not too worried here.

In fact, if I manually unzip my patched APK and recompress it using 'zip -9', I end up with a file that's..... 65MB in size?? That's way smaller than what apktool initially generated, and is also slightly smaller than stock! Huh? Not only that, but this APK installs and runs fine (though further reading indicates this is unsafe because some resource files need to be encoded with 0 compression of some Android versions won't be able to parse them. That explains things).

TLDR:

So it looks like compression ratios are the main cause of size differences. I'm going to file a ticket on the apktool project to ask about the default compression level (and there seems to be no way to pass this by commandline). If you are worried about rogue code, feel free to un-xz the secondary.dex.xzs file and compare it to stock. After unzipping the individual JARs, you should see only spot instruction changes in the DEX (plus a different checksum in the DEX header). The "primary" DEX file is unmodified (and should be identical to stock).

EDIT: Created https://github.com/iBotPeaches/Apktool/issues/1572