search

DexPatcher / multidexlib2

Multi-dex extensions for dexlib2
https://dexpatcher.github.io/
GNU General Public License v3.0
68 stars 34 forks source link

Compatibility with new Android versions #4

Closed ale5000-git closed 5 years ago

ale5000-git commented 6 years ago

The latest git master of smali/baksmali added support for new Android versions (up to dex version 39). Could you please update multidexlib2 to support the same?

PS: Now there is mapDexVersionToApi.

Lanchon commented 6 years ago

hi ale,

i won't be updating mdxlib2 until we get a proper dxlib2 release.

thanks!

ale5000-git commented 6 years ago

Hi, the version 2.2.4 is now tagged on Github.

Lanchon commented 6 years ago

lol this wasnt there when i wrote the message one hour prior to yours, JF is messing with our brains on purpose :)

Lanchon commented 6 years ago

btw, why are you requesting this update, if i may ask?

ale5000-git commented 6 years ago

Because I need a smarter app for multi-dex (especially for new Android versions) then the current workaround inside Tingle.

I have requested this update to be ready when I will have time to do the changes in Tingle; I'm still a bit busy currently and I also have to look at fixes for microG beside this.

PS: Unrelated question, does your tool work correctly also for writing files for Android 2.2?

Lanchon commented 6 years ago

but that problem has been solved! take a look at dexpatcher and haystack. you can make your own dexpatcher patches if you dont like haystack ones.

mdxlib2 should work with any android version. same thing for dexpatcher, except that it lacks support for multidex output when the output is to be ran on android 4.x and earlier.

ale5000-git commented 6 years ago

I would like to support 2 cases (selectables):

Tingle will include also other patches (always optional) beside signature spoofing. All patches will be like plugins. This is currently just an idea, I need time.

PS: I appreciate your work, I just need to do it within my needs.

Lanchon commented 6 years ago

btw, nanolx took dexpatcher and the haystack patches and made them run on-device in recovery. he did this by running dexpatcher on the existing ART of the installed rom from the recovery environment. (yes, it's kinda creepy, but he says that bundling a whole VM (i suggested DalvikVM) would create zip files too big for his taste.) since dexpatcher is 100% pure java and avoids android-unsupported java APIs, running on ART is a non-issue. he also added addon.d support so that the patching runs every time the rom is updated.

i'm thrilled that he did all this, but i just wish he had made it clear that his patcher is verbatim haystack/dexpatcher running on recovery instead of distributing it like it were a new thing. but both my projects are GPL so he is absolutely in his right to do this; it's just not what i would do. but i know he does thank me somewhere though.

anyway... so keep in mind that if you use dexpatcher you gain on-device patching capability almost for free, courtesy of nanolx.

regarding multidexlib2, you seem to be misunderstanding it. multidexlib2 is a multidex extension to dexlib2. smali/baksmali don't use multidexlib2, and in fact the stated position of their author is that those tools should never support multidex as they deal with the contents of a dex file, not with the contents of an android apk.

so multidexlib2 will not help you in any way unless you write a client for dexlib2.

btw, i disagree with JF's view. i think smali/baksmali should have optional mdex support where the smali files would be placed in and processed from a single directory, as if all code were coming from/going to a single dex file. this would be trivial to implement using multidexlib2.

~but JF has been reticent to my simpler pull requests, so something of this scope i wouldn't dare try.~ [EDIT: JF was just busy with other things for a while. a long while...] and of course multidexlib2 license is different than smali's (though i'd seriously consider relicensing if JF asked for it). a fork is totally possible though.

JF seems to care more about what he thinks his tool should do and less about what other people want to do with his tool. (or at least this is my limited experience so far with the project anyway.) a case in point is an actual automatic client of smali that needs to make changes to code (such as tingle) and all the headaches that not supporting multidex in smali brings to its clients. JF says mdex doesn't belong in smali; but as you well know by now, it sure as hell doesn't belong in smali's clients! the reality here is that smali, by limiting its scope, is choosing not to support some of its clients. because if these actions are to be done anywhere, they seem to need be done in smali.

dexlib2 could be (and should be) mono-dex. it is not, it has some rudimentary multidex support. if the project started from scratch again, i would remove that rudimentary support and move it to an isolated package structure but adding full multidex support, a la multidexlib2. smali/baksmali on the other hand, totally should support multidex as an option IMHO.

Lanchon commented 6 years ago

All patches will be like plugins.

all that is needed is DexPatcher-live, an ART modification that patches dex just-in-time. and yeah, you can install many "modules". it patches code after signature checking so signatures are not an issue. this would be a direct competitor to Xposed. i did a proof of concept of this for an older android and it worked well. it hooked the dex2oat compiler by renaming it and placing a shell script in its place. but the full project would have taken too much of my time and i could not have supported, so i didn't publish. it wasn't production ready anyway, it was just a PoC.

Lanchon commented 6 years ago

i pushed new versions of multidexlib2 and dexpatcher that support android O and P but i haven't announced yet. i worry there might be a bug in smali 2.2.4: https://github.com/JesusFreke/smali/issues/615