[Android Software Development] Lanchon:
> Perfectly fine. My own device is stuck on Android 6.0...

Xposed anyone?? :)

> Trying patches in sequence is a "good enough" approach for now (I'm hoping DexPatcher uses exit codes so I can easily script this?)

yep! non-zero on errors or fatal, which is what you want.

> An example of what I want to do is a DexWrap for MediaSessionLegacyHelper#sendVolumeKeyEvent (to add a "Hold volume keys to skip music" feature to firmware) and I was wondering if this would pass as long as the exact method and signature exists in the target class, e.g. DexPatcher won't throw a tantrum if methods or fields exist in the class that didn't exist in the original "base" of the patch.

yes, it cares about finding stuff you explicitly target. other changes, it is insensitive to.

now that i know more about bytecode, some warnings should be promoted to errors. for example, a private instance method (which is "direct" in dex parlance) converted to a static method (also direct) with the exact same arguments will be found and only a warning will be generated (because they are both direct). but the methods are not dalvik bytecode compatible because of the implicit this reference, so actually an error would be more appropriate. this is a contrived example, but not terribly so: i can see someone adding a 'static' to a private helper method once they realize the this reference is not being used. to complicate maters, if 'this' is not used, the code might actually be compatible anyhow (but DexWrap always uses 'this' for the reentrancy invocation(s)), but the methods are invoked differently with invoke-direct vs invoke-static, so no go. but... a planned feature (inPlace=true) would make it work. i think i should just detect this as an error... one day...

in the meantime, i hope i release 1.4.0 in time for your work, it'll have productivity features that will hopefully save you time.

> The dynamic analysis is not necessary - I agree that it's a downside. I want to get rid of my reliance on Xposed because it seems so unreliable and generally dodgy - it causes performance and stability issues with some modules and options. Doesn't help that the modules I use are closed source and bloated with 90% of things I don't need.

RANT MODE ON:

yesss! xposed is a mess. the repo should be source-only and a bot should build from source, just like F-Droid. in fact, they should use F-Droid's server code, which is free, or even F-Droid itself. all modules in the repo are effing root and effectively closed source, it's scary!!! once i wanted to fork Xposed into SEXposed (security enhanced xposed) a.k.a xposed with condoms. it would have the ability to restrict modules to patch only an specific app and the modules would only have the privileges of them plus the app they are patching (no root, no system-wide mess). so patching a closed source app with a closed source mod would not be more dangerous than running the closed source app itself. but i have a life too...

> I really don't want to have to learn Android Studio... (I'm inclined to Eclipse as I do Java stuff outside Android - I'm aware that Android Studio is based on IDEA but Eclipse is the more powerful IDE in my experience).

nooooo! i use Eclipse for C++ development. i used to use it for Java too. but intelliJ IDEA is sooooo much better in every sense. i mean, eclipse is a complex mammoth full of bugs. it just fails all the time in small ways. IDEA is faster, more stable, more powerful, it's just a pleasure to use. IDEA has 15 years of development under its belt, it's not a new toy, it's mature as hell. the people behind IDEA also designed a new language (targeting java bytecode) that is the only alternative to Java officially accepted for android development by google tools. also the embedded build system from eclipse is just simplistic and anachronistic. IDEA uses gradle as it's first class build system. gradle is... quirky; but what build system isn't? like all successful tools it has shameful past that brought it to be what it is today: one of the best tools even if it has a lot of baggage. i strongly encourage you to take the plunge and switch to IDEA. it's very low cost if your project is already on gradle. for other stuff, i'm sure solutions exist but i dont know much.

> Never heard of Avian VM, looked it up... that is awesome! Though Avian Pack hasn't had any updates in over a year, I hope I don't run into any serious issues...

you will. i didn't put in a lot of time, but i was unable to repro the binary builds for x86. i'd suggest: don't try this build at home! set up a VM to build avian-pack. you might want to build on the same platform they used to build, which seems to be older than ubuntu trusty. (once building for x86, arm should be easy. if only these guys would have published their arm builds...) otherwise, fork avian-pack and fully bring it into the 21st century.

> Just wanted to make sure whether I would be allowed to redistribute a "converted" dex file. I guess anybody can take your jar, dex it and see that it's identical to the one I'll be redistributing so that's evidence enough of it not being a modified codebase.

if you want to be fully compliant, just dex a released binary and state which version it is, and that is all (which i think you would have done anyway). if you dont dex an 'official' release, it's easier to fork my repo on github with your changes than to provide patches, etc.

> Cool, thanks!

thanks for using dxp!