Made underlying DexFile of BasicMultiDexFile accessible

[mbenz89]

Hi,

I am a maintainer of the Soot - Java optimization framework. We are interested in using multidexlib2 for parsing and writing out Android Apks consisting of multiple dex files.

In our implementation, we need access the DexBackedDexFile class, to acquire the there mentioned type information. Correct me if I am wrong, but s far as I can see, there is no possibility to access the underlying DexBackedDexFile from theBasicMultiDexFile class.

This merge request virtually just adds a getter to the BasicMultiDexFile class, to make the underlying Dexfile accessible.

Best, Manuel

[Lanchon]

hi,

congrats on your project! it's been a long time in my TODO list to explore soot, but i haven't yet had the opportunity unfortunately. i'm glad you are considering using this lib for such an important project, i'll try to help you as much as i can.

i see your need. exposing the wrapped Dex in BasicMultiDexFile is certainly the quickest fix but i'm not convinced it's the best way around this. please allow me a bit of time, you'll have a solution one way or the other.

thanks!

[Lanchon]

please take a look at branch https://github.com/DexPatcher/multidexlib2/commits/wmdf .

1) i introduced interface WrappingMultiDexFile<? extends DexFile> with getWrappedDexFile().

2) made sure all MultiDexIO.readMultiDexContainer methods return a runtime type of MultiDexContainer<WrappingMultiDexFile<DexBackedDexFile>>.

3) finally -and this i'm not too sure of- i declared all static return types of the MultiDexIO.readMultiDexContainer methods to match. it feels like a little too much detail is getting through, but then the RawDexIO methods do return DexBackedDexFile(s) instead of plain DexFile(s), so it's not that weird. and i don't envision DexBackedDexFile to ever change.

these changes should provide what you need. what do you think of 3) ? with this change you won't need to ever use a cast. is it going too far?

thanks!

[mbenz89]

Thanks for your fast response and the quick solution!

Glad you heard about Soot. You are definitely welcome to check it out and even contribute if you like.

Regarding your change, I feel like 3 is totally reasonable. Knowing the concrete type of the DexFile prevents some headache from client programmers. Furthermore, if DexBackedDexFile changes, we are running into issues anyway.

Unfortunately, I just saw you are licensing under GPLv3 which seems to be incompatible to Soot (lGPLv2.1). As far as I understand, we would need to make at least the code using multidexlib2 licensed under GPLv3. At this point, I am unsure if this is an option.

[Lanchon]

published multidexlib2:2.2.1.r2 hopefully with everything you need.

[Lanchon]

hi @mbenz89,

i somehow missed your comment. please forgive my response time last week, i had an accident abroad and had to return to my country to have urgent surgery, which i'm having this week.

i will dual license this lib to LGPL2.1 and LGPL3 if soot needs it (now it's GPL3). you have my word on it, and i'll deliver fast when you ask me to.

but please, first make sure that it is actually useful to soot before asking me to relicense it.

thanks!

[mbenz89]

Sorry to hear that, get well soon!

Thanks for your efforts, I really appreciate them! We were able to accomplish the needed functionality only using dexlib2, so there is currently no point in using multidexlib2. I'll come back to you if that changes.

Thanks again! Manuel

[Lanchon]

thanks for getting back!

de dónde sos manuel?