print aapt version

[sv99]

1. Correct OS.execAndReturn which always wait 15 seconds, even if the aapt process has been completed successfully
2. Add finding aapt executable in the PATH.
3. Print aapt version - embedded and in the path by "--version"

With this patch apktool --version with print aapt versions complited momentally, without - each process run wait 15 sec.

[iBotPeaches]

@sv99 Could you explain the context for wanting the path aapt/aapt2? I foresee folks wondering the difference and then leading to having to explain why the embedded (w/ patches) is stronger than the probably stock versions on the path.

[sv99]

What exactly is patched in aapt.
Now I compare the rebuilted apk with original and see that different algorithms are used.
For example if using aapt changed images formats.

[sv99]

What do you think about adding comare key to the apktool for comparing and printing differences original and rebuild apks. Now I add compare key to the apkanalizer extracted from android tools, but code may be simply moved to the apktool.

[iBotPeaches]

What exactly is patched in aapt. Now I compare the rebuilted apk with original and see that different algorithms are used. For example if using aapt changed images formats.

Just patches to either remove restrictions so rebuilt apps aren't binded by new build tool warnings or adding features so we can specify pkgId/name.

iBotPeaches/platform_frameworks_base@8098abd

iBotPeaches/platform_frameworks_base@0a8449e

[iBotPeaches]

What do you think about adding comare key to the apktool for comparing and printing differences original and rebuild apks. Now I add compare key to the apkanalizer extracted from android tools, but code may be simply moved to the apktool.

ApkAnalyzer looks quite powerful compared to my memory. I'm not quite sure how a compare would work in Apktool since it works with both disassembled and binary application. ApkAnalyzer works easily off the apks each time, but would Apktool just compare the source and dist apk?

[sv99]

I extracted code for OS.execAndReturn in the #3071

Interested binary apk. Diff for rebuilded apk very useful if original and rebuild apk has different behavior.

Now I compare dex classes by his smali code.

I have some difficulties with compare renamed resources.
Perhaps the problem is in the used by default aapt not aapt2 - images has changed color type in the rebuilded apk.

[iBotPeaches]

I have some difficulties with compare renamed resources. Perhaps the problem is in the used by default aapt not aapt2 - images has changed color type in the rebuilded apk.

With -a and analysis mode, we attempt to disable lots of those flags in aapt2 that lead to resource crunching/optimization.

[sv99]

For deep investigation differences need compare functionality for all apk, for resources and for dex files.

I think the mode compare will be usefulI for this purposes.

1. Compare Items in the apk (with consideration renamed resources in the rebuilded apk) simply by name and by size
2. Compare dex by smali representation
3. Deep compare resources (binary compare)

I suggest following commands

apktool compare [flags] original.apk rebuilded.apk

1. default - compare items by name
2. --compare-by-size - items by size
3. --compare-dex - compare dex by smali representation
4. --compare-resources - binary compare resources