[Android Software Development] Lanchon:
hey whats up! please excuse the delay, i'm traveling around right now

first keep in mind that dxp should be incompatible with android O. O introduces dex version 038, that for the time being dxp can't support until such time that the smali project does. that said, ppl are telling me that dxp works with lineage os Oreo, which means that at least some oreos pack their framework in dex 037. (038 introduces features that are unused by javac and would only be used by compilers for languages with more dynamic type systems than java's, so that sort of explains this.)

> First question: How resilient are DexPatcher patches on target dex file changes? I.e. will the dexpatch need to be (re)built for every device and firmware because it's a binary patcher? Or does it have some level of bytecode examination (find and inject/replace) functionality?

it is resilient, but not extremely so; it wasn't really designed to be so. it was designed to be resilient when used alongside javac to rebuild the patches: stuff not caught by javac itself would be caught by dxp, or that was the guiding principle. when plainly applying old binary patches to new dexes, stuff can go wrong:

a) if a thing you reference in your injected code (say a field in a class) ceases to exist, dxp will happily inject the code and a verification error will be triggered at runtime when the method executes. this is similar to what would happen if you reference the field from regular java: running javac again will detect the missing field, but just running a previously compiled version of your code against the new class will trigger verification error at method execution time. dxp could do better and should. please see the tool roadplan, there's a DexCheck annotation planned to solve this. in the meantime you can target (not reference from code, target from a dxp annotation) an item that ceases to exits in the new codebase (for example, the phased out field itself) to cause the patch to early-fail when being applied.

b) if a method you are patching ceases to exist and is replaced by a similar method with a different signature, dxp will correctly fail to patch. the solution then is to have 2 patches (or more) to patch the different versions. you can detect the version or simply try the patches in sequence until one succeeds. of course this isn't ideal. i think dxp will never morph into a general language to dynamically analyze dexes at patch time and patch any code; contrary to xposed (in which a mod's actions are a priori intractable and that is one of its weaknesses in my view), dxp strives to be basically a static patching language with clear and simple patching semantics. that said, some typical and simple cases of target code evolution could be handled. please see the roadplan's DexOption tag for a simple proposal to address some target changes.

> Disregard; I see I don't need Android Studio...

well that depends. the dxp toolchain involves a couple of tools, some by me, some by others. dexpatcher-tool is the self-contained java-only tool that patches DEX files (only). keep in mind that dex files only contain CODE, but android is much more than that. dexpatcher-gradle integrates dxp-tool, apktool, dex2jar, the android gradle build system, and the android development tools and allows you to patch code AND RESOURCES. dxp-gradle is much more complex than just dxp-tool, and you can't for now expect dxp-gradle patching to happen on device, because the android build system is AFAIK still not self-hosted. (i guess it might be some day.)

so on-device, you could (and actually can) patch only code. xposed is the same: it can only patch code. where xposed seems to patch resources, it is actually patching the framework code that reads resources to inject/change some of them. you can do the exact same trick from dxp-tool (only the xposed runtime comes pre-coded for doing this).

regarding running dxp in recovery there are several solutions:

1) someone should build the avian-pack VM for ARM and that would be a perfect solution: avain-pack for x86 readily runs dxp today and performance is not bad at all, i've verified this myself.

2) you can mount /system form recovery and use the rom's ART VM to run dxp. this works today, somebody is using it to run dxp-tool, take a look: https://github.com/Lanchon/haystack/issues/5#issuecomment-326850541

3) grab some simpler dalvik VM binary from a pre-android 5 android build and use it standalone from recovery. just like solution 1) this would also be perfect. solution 1) is probably worse-performing but simpler to use, because avian-pack can be distributed as a single, statically link executable with no dependencies that also harbors within it the complete java standard classpath; so it is a complete java VM in a single file.

> I've discovered that it's possible to make console-mode dex files from jar files manually

take a look at the test subproject of dxp-tool for samples of this. it also runs patched dexes in the host's JVM (via dex2jar) to verify the correctness of dxp-tool after each build of the tool.

> would I be allowed to redistribute a dexpatcher.dex binary with my tool to provide this "on-device patching" functionality I'm after?

dxp-tool is free software licensed by GPLv3+. you can do whatever you want with it as long as you do it according to its license. i'm not a lawyer and can't give you legal advice on what GPL permits or not, but the free software foundation has very good explanations you can use to determine by yourself if your planed usage is acceptable or not. in the long run, i think that permissive licenses such as apache are detrimental to freedom and thus i never publish under those licenses. (android is becoming a closed OS thanks to its proprietizable permissive license.) if dxp-tool is a good fit for a for-profit product, you are welcome to negotiate a commercial license with me. so far i am the sole author of dxp so i can relicense it. its libraries (eg dexlib2) are all permissive so i can do this.

thanks, hope you enjoy using dxp!