[Android Software Development] Lanchon:
hey,

thanks for your interest in dexpatcher!

tl;dr: dxp is not an xposed replacement and you probably don't want to move away from xposed. dxp will continue to be a fringe product for some nerds until some things change.

let me start by explaining what dxp is: dxp-tool is a tool to reengineer dex files. it is akin to disassembling dex using baksmali, developing in smali, then reassembling with smali. the difference is, in dxp you work exclusively in java, making the process orders of magnitud simpler, and thus patches can be orders of magnitud more complex in reality. besides that, it is also a way to build a self-contained dex patch that can be published and is trivial to apply. (in smali the closest would be a smali diff patch, which is extremely brittle and contains copyrighted code.)

compared to xposed, dxp is more powerful in expressiveness (what you can do) and much, much simpler to use with its extensive static type checking.

the problem is, patching dex files is not something regular users do! they install apps, and root OSes, and some install custom roms, and that's about it. so dxp is not useful for the average user at all.

besides the capability to patch dex say of an app, you also need to extract the dex, patch it, rebuild the app, and resign and zip align. and on top you probably want to alter android resources, java resources, the manifest, etc etc. and after that you still need to deal with the changed signature, and sometimes anti-tamper code such as what dexguard can inject.

besides dxp-tool, the core technology, there's dxp-gradle, which in lines of code is a much bigger project.

dxp-gradle mods the android build system to patched apps inside IDEA/Android Studio, and allows patching of code (via dxp-tool) but also doctoring of resources and manifests. you can do stuff like adding activities (code plus their resources) and other high level android objects, all the way to bringing in full android libraries (.aar files). in all cases, dxp-gradle will blend in all resources and code from all the different sources and produce a working app. it can applies mods to the app manifest via android manifest merger mechanism. the original code from the app is never back-translated to java bytecode and resources used by the original app are kept with their numeric ids constant (but they can both be changed).

the signature of course has to change, but you can use signature spoofing if your rom supports it.

dxp-gradle is waaaaay too complex to run on-device. it requires a full android developing environment and more, so running dxp-gradle on a phone is as impossible as developing android apps (today) on android (much less recovery). you can't expect people to use dxp-gradle to patch their own apps, it is more like a system i use to end up with patched apps.

on the other hand, there is some light at the end of the tunnel.

at some point i made dxp-live, a prototype live patcher. i renamed the dex2oat binary and added a shell script in its place that patched just-in-time the file being compiled before passing it to dex2oat. i would keep a dir structure within /data/dexpatcher/patches/ where i put patches i want to apply to anything in the system, for example in /data/dexpatcher/patches/data/app/com.google.suck/suck.apk/my-googlesuck-patch1.dex. the script looks for corresponding patches and run them before invoking dex2oat. and because patching happens while compiling, app signatures are not compromised. it's close to being a perfect deal.

the prototype worked, but it requires an app to front end the install of patches, a patch market, and who knows what else to compete with xposed. i don't have that kind of free time.

another issue with dxp-live is that most roms are odexed, so dxp-live can only patch apps unless you fully deodex your rom. (xposed for ART is similar in this regard, and it deodexes the full rom at install time (i guess using smali) but that's a big headache i don't want to have.) but i heard, android 7 and later no longer come odexed, which relieves me of this deodex crap.

dxp-live would be much easier to use, more powerful, much safer (app patches can only affect the app, they are not root!), can reload app patches by simply killing the app, it's much faster when executing patched code, it doesn't cripple ART optimizations, and it doesn't punch holes in android security. the only problem is... i'm lazy and i'm not developing it :)

a disadvantage is that if you add or remove a system patch, the whole framework has to be recompiled, as it is typically compiled as a single block of code. another issue is android 8's JIT: apparently oreo can run code without compiling it first. how this behavior can be handled is up for debate. (one way is disabling the interpreter, of course, and fall back to android 7 behavior.) if the interpreter can be used, then patching the framework becomes fast, because it can run before compilation (only patching is required pre-run).