Fixed some issues for compatibility with recent Apktool versions #753
Conversation
While older versions of Apktool expect "-version" with a dash, newer versions refuse this and expect "version" without a dash. This commit changes the behavior to be compatible with both kinds.
Two command line parameters were added in a buggy way that resulted in a broken command line if those parameters were not needed, as instead of skipping the argument, the code added an empty string as an argument, which (at least certain recent versions of) Apktool refused to accept. This commit changes the behavior to be in line with other parts of the code (e.g., Apktool build).
Apparently, recent versions of Apktool started mangling the names of directories by appending a dot and a number, e.g., foo.bar.Qux class might reside in smali/foo.2/bar.Qux.smali. This commit adds a fallback mechanism that tries such paths if the standard path does not exist.
|
Now that I looked at #743, it has addressed some of the same issues – although in a different way. Extracting the version number from the banner seems to be a recipe for another similar issue where Apktool changes regarding UI not intended for machine consumption breaks Objection. The handling of command line arguments passed during |
|
Thanks, I would appreciate if you can maybe base of that PR (i.e. remove duplicate changes). I just haven't had time to fully test all the changes made in that PR hence why it isn't merged yet. Fortunately the issue regarding Apktool versioning is only present in one specific version of apktool (iBotPeaches was nice enough to quickly push out a patch iBotPeaches/Apktool#3909). |
The command
patchapkdid not work for me using Apktool 2.12.0 – however, I also found some bugs that would have prevented the command to do its job regardless the Apktool version.versioncommand instead of the-versioncommand line argument, resulting in an early crash since version detection fails.See individual commit messages for more details.