Update dexlib2 dependency - new smali repository

[auermich93]

Hi @Lanchon,

would you mind to point the dexlib2 dependency to the new smali repository at https://github.com/google/smali? Also apktool made this change in order to receive new updates.

Thanks in advance.

[Lanchon]

dexlib2 does not have a stable enough API so that it can be changed from under multidexlib2 haphazardly. every commit of dexlib2 must be checked to asses possible implications. so i won't change the dexlib2 version until i can prioritize this work.

thanks!

[auermich93]

Hmm, I am using now multidexlib2 in combination with dexlib2 2.5.2 since more than two years and didn't face any issue that is related to dexlib2. The code has been tested on more than 1000 APKs from my side, so it might be safe to update at least to version 2.5.2 before finally switching over to the new smali repository.

[Lanchon]

well, i can't really vouch for compatibility before examining all commits. in the past, compatibility issues and bugs in dexlib2 did arise, and led me to request changes or fixes in dexlib2.

in reality, the chances of failure have always been extremely small. in these scenarios, you'd have to be writing a dex file part of a multi-dex containing newly introduced features of dex, and this particular dex file would need to be overflowing to the next dex file by a small miscounted margin and/or by involvement of newly introduced pool within the dex. the fact that your testing didn't uncover issues is not really enough.

on the other hand, i see that you have been able to replace the dexlib2 binary from under the multidexlib2 binary, using gradle's dependency management i'd guess. so what stops you from building your own forked multidexlib2?

i'm not saying that i can't do what you ask of me -switching to goog's dexlib2-, and i do want to help, but i want to understand why i should prioritize this work.

thanks!

[auermich93]

Of course, testing doesn't prove the absence of bugs and every software has bugs. And yeah, I let gradle handle the dependencies. I could build a forked version on my own but forks have the disadvantage to diverge too much at some point in time and managing multiple versions is cumbersome. The smartest way would be to stick to a single repository. Well, if you update to the new smali repository and in particular to the newest dexlib2 version, it allows you to handle the latest dalvik bytecode versions. Also apktool made this step to fix some bugs in dexlib2 that caused some decoding issues.

I can only encourage you to prioritize this work.

[auermich93]

@Lanchon You may wanna examine my pull request: #15.