yashsingh1/xdaforums huggingface dataset:
[Android Software Development] kurtn:
Thank you. I really thought I'm an expert in microG related topics. Doday I've learned a lot.

MicroG still works well as user app. It just no longer registers as system location provider. That's why a zoo of microg bundle installers has been made. Modern proprietary apps fetch location directly from play services. That's the point where i see a renaissance of microG user app. An anwer to people that fall for the "sandboxed play services" hype of grapheneOS.
[Android Software Development] Lanchon:
what do you mean i dont plan to continue development? i just posted the whole stuff with gradle plugins!! im using and testing the thing a lot now, and the dexpatcher tool itself seems totally solid (android build system has a lot of issues, and they impact my gradle stuff here and there). i just think that the tool is finished for a 1.0 release.

i'd like to add a way to do simple edits of the insides of a method, for instance replacing invocations of a particular method with invocation of your method, but that is outside the scope of 1.0.

is there anything you think is missing? apart from me, i dont think anybody is using these tools. the right people have to find it, and i should probably document more.
[Android Software Development] agentdr8:
I've downloaded and taken a look and the tools are very impressive. Just waiting for a project to come along that I can apply these tools to :)
[Android Software Development] CosmicDan:
Ah sorry, no not at all - apart from multidex but that isn't a big deal. I just skimmed over your point about going away, coming back and forgetting everything and likely not being able to continue - I do the same thing ha-ha the amount of abandoned projects I have is shocking.

I will send you a PM soon, this has a *lot* of use for me professionally. If it pans out for my work, do you accept donations or are open to contract/bounty based work? Because this is really great stuff, but the licensing stuff is a bit scary.

Forgive my brevity, I'm just about to head to bed :)

Sent via Tapatalk on my Xperia Z
[Android Software Development] Lanchon:
im on the road, in chicago now. yeah that was an issue if i left before finishing the thing and making it work. but i didnt, so no problems, i can return to a working code. what i didnt want to do is going back to unfinished stuff.

what licensing stuff? my license or the apks u modify? if u worry about GPL sticking to patches, i could look into that. i hate everything non-free, thats why i didnt dual license the code that is included with the patches.

finally if a project is interesting i could definitely jump in, depends on many factors.

if u msg please be a little patient, im on the road. i spent the whole day yesterday in airports and planes :(
[Android Software Development] CosmicDan:
Ah cool.

Well I see that you specifically mention only the *patches* are licenced under GPL. I'm wondering if I write my own patches which are never public, and only distribute already-patched APK's - are they also under GPL?

We're often given APK's and, despite having the legal OK to modify them however we want for our market, they expect us to reverse engineer rather than share their source. Don't ask me, Chinese ODM's are weird like that!

No problem, it's no immediate rush. Enjoy your trip :)
[Android Software Development] Lanchon:
technically yes, for two reasons explained in the NOTICE.txt file. it may be considered a little overarching but it benefits the free software community, which is what i care about. if your company needs the patches not to be GPL, certainly im open to discussion. i acknowledge there are good reasons for both arguments.
[Android Software Development] CosmicDan:
Maybe I've a lack of understanding of the GPL or I have the wrong idea about what DexPatcher actually is. The patches are bound by GPL, that is clear - but even if the patches are never seen or distributed by the public, only the final patched APK is redistributed - the simple fact that I've used DexPatcher to make this final patched APK means that the patches themselves still have to be publicly released in full open source?

How exactly, is this different to say, making a model in Blender - a GPL application - yet the models you make in blender are not bound by GPL?

Not trying to worm my way out of it or anything, even if this was Apache/MIT/etc I still believe in giving credit where due - I make money off my work so it's only fair that I give something back to anybody who helped make my work easier :) Perhaps when I have a play with DexPatcher and have a look at the technical process behind it then I'll understand more clearly. I've not even moved from Eclipse to Android Studio yet so I'm not sure when I'll get a chance to try it all out.

If you intend for the patched APK's produced by dexpatcher patches to also be bound by GPL, perhaps you could add it to the notice too. Since you're the creator of the software, I'm sure that's within your rights. It's not exactly clear at the moment.
[Android Software Development] Lanchon:
well for two reasons spelled in that file, the patches are gpl: the strongest one being that when u write a patch, u r making code that works with the dexpatcher code and invokes its routines, even if though a language of annotations. the std gpl interpretation is: if ur code makes sense and works with other non-gpl implementations of something, then it's not necessarily considered a derived work. but if ur code must work with some other specific piece of gpl code, then it must be gpl too. this makes C code not necessarily gpl because there are many compilers (although c code that uses gcc's unique extensions might be up for debate). an applicable example is the gpl parser generator "bison": generated bison parsers used to be covered by gpl, meaning you had to publish their source and whatever code you link the generated parser to. these days bison has an exception in its license to make generated parsers free from gpl requirements.

the other reason why patches are gpl is that patches link and include my annotation library, which is gpl code. and some of this code even gets copied into the patched application itself.

dexpatcher could but currently doesnt have such an exemption. there is some merit to adding one, im not opposed in principle to it. but without it, since patches are gpl, the app u patch MUST be gpl v3 too (or a compatible license) in order to ever distribute the patched app.

this makes sense because usually you cant distribute patched apps anyway, because of their proprietary license (who would use dexpatcher on free code?). but patches can be distributed, so why not force gpl on them? if people will distribute patches, id like them to be open due to security and freedom issues.

now your case i didnt ever anticipate: a legal ok to distribute patched apps. my licensing model hinders its use in this setup. but making the exemption means loosing the advantages above.

id really like it if xposed modules would be covered by gpl: the world would be safer and better. they arent, and i didnt want to make the same mistake. on the other side, only respectable entities care about the licensing issue of dexpatcher, so maybe it only hinders you, but doesnt help anybody else as most people will simply not comply with the gpl.

this situation i simply didnt anticipate. is it just you working here? or are you employed or contracted to do this work? if you are, maybe your employer can offer some money for a private exemption or a general exemption (a la bison), ie: some money for licensing dexpatcher for non-gpl work. dual licensing of gpl code like this is common.

on the other hand, if this is your little business project, id be inclined to provide you with the exemption for free.
[Android Software Development] CosmicDan:
Indeed. Yes I am working on behalf of a company.

That answers that then, thanks for clarifying. As I mentioned, I'll have a play with it and see if it really is something that would benefit our production process. The produced items are Xtreamer media boxes (see my signature) which are sold worldwide, yet we're not a big company by any means - of course we'll have to do some feasibility assessment before even considering what kind of licensing scheme is appropriate, if at all beneficial. A Per-unit-sale is not really possible, perhaps a "per package" is more reasonable - as I'm sure it would be possible for you yourself to verify which jars\apks in our firmware are modified in case you were worried about us keeping secrets ;) I would also give *you* private access to any patches we write for you to personally use if it benefits you. But consider that irrelevant to any kind of monetary contribution, rather a full disclosure clause in the interests of co-operation.

There is a good chance that I myself will give you a share of my personal income at first, it's tricky to convince superiors of new investments.

Regardless, I'm getting ahead of myself here. We will need to spend a few months internally testing and assessing the practicality of this before starting negotiations. I'll be sure to let you know when that time comes.

Sent via Tapatalk on my Xperia Z
[Android Software Development] Lanchon:
or it could also be a one time thing for anything that you want to do with it. itd be cool to have some money helping the project because it really took time to build, and theres so much extra hobby time that i can devote to improve it. if there are repeated similar projects ahead, consider the possibility of a try before u buy license for the first one, if itd help your company test the usefulness of the tool without the risk of a failed negotiation making you loose the work already done. PM me if you have any news. of course tech questions are better asked here if its not a problem regarding disclosure. thanks!
[Android Software Development] CosmicDan:
Sounds decent. I'm not sure what this kind of thing is worth but if it were a one time fee for one device/firmware release, I'd be ballparking at around 1000 Usd? But that really depends how much I use it. For initial deployment at least, anything more seems a little too prohibitive (I am quite skilled with smali these days) - but again, let's see how we go with experimentation. I also have to learn Android Studio haha, still an Eclipse user though it's about time I changed to the current standard.

Anyway, I'll Pm you in a while when ready to negotiate something.

For sure if I have any issues or am stuck on something, I'll ask in public for others benefit if at all possible (even if it involves sharing example code).

Sent via Tapatalk on my Xperia Z
[Android Software Development] Lanchon:
that number sounds reasonable. AS is androids future like it or not. i have to admit that soon after switching it felt better in most respects. java-wise at least. the current dexpatcher plugins rebuild the apks from scratch merging resources and manifest and avoiding apktool, and although much more versatile, it produces output that is not as faithful as an apktool rebuild. i can make an apktool variant plugin to bring the workflow nearer to your current one if needed (but ull loose much power with that change). ill await ur PM, thanks!
[Android Software Development] CosmicDan:
Mm it's a standard migration difficulty. I read lots of users saying how IDEA/As is so superior to Eclipse, but I'm just not used to all the new hotkeys (and completely different context/completion system than intellisense in Eclipse). But it's about time I changed so no matter :) besides, gradle is far superior to ant. Just not looking forward to weeks of migrating all my custom rules over heh.

"Not as faithful output" is not an issue, as long as it works and doesn't have massive overhead (like e.g. runtime injection of Xposed or Cydia Substrate) then I'll be happy.

Anyway, probably should go back on topic.

Sent via Tapatalk on my Xperia Z
[Android Software Development] Lanchon:
dexpatcher tool is the same, but the plugin lets you add to and edit resources and the manifest on top of code changes. you can add stuff like activities or full android libraries with their own resources; you cant do this with apktool. and it does some other stuff.
[Android Software Development] PerfectSlayer:
There is a setting to use Eclipse key binding in IDEA. It could be a good way to lower the step but I recommend you to use the defaul one later ;)
[Android Software Development] CosmicDan:
Better off getting used to the new system. We're also trialling Xamarin (C# / Visual Studio 2015) so there's a possibility we'll be ditching Java entirely, so either way Eclipse is dead to me heh.

Nb: Following question is unrelated to commercial use

Working on a custom firmware for my Xperia, but it runs 5.0.2 and I want to keep it odexed. Rather than releasing a whole firmware though I'd prefer to make an update that patches an existing system. Is it possible to port this to Android (Ndk or Java? I haven't even checked the language sorry) or if it's even possible to run native oat2dex/dex2oat binaries in an Android environment? Slightly unrelated yet not, as such a thing would make your tool more useful to ROM chefs indeed.

Edit: Nevermind, I see it's Java. Still, we can compile/port Java code to Android - Random idea for future? An alternative to Xposed I.e. A root app with repository that can patch and install (via recovery commands if framework patch) all on-android, now that would be cool. Unlike Xposed it would be fast and would hard fail on incompatibilities rather than introduce possible weirdness. Something to think about for the semi-distant future anyway.

Sent via Tapatalk on my Xperia Z
[Android Software Development] Lanchon:
the tool can run on android, its 100% pure java.

if speaking legacy odex, the tool can probably patch odex files directly if you remove this line:

https://github.com/Lanchon/DexPatcher-tool/blob/master/lanchon/dexpatcher/Main.java#L97

havent tested, dont know enough of odex.

no idea about oat2dex etc

yes ive thought of that. the app doesnt have to be root at all. i dont plan to make that app, its not within my scope. also, i think that patching only code is very limited compared to what i have running on AS/Gradle (but still has its uses for sure).

IMHO xposed should be rewritten from a API to a declarative syntax like dexpatcher's. now theres no way to tell what a module does in terms of patching, save for executing the module, which is very bad. once xposed is converted, the same module could be applied JIT via xposed or ahead of time via dexpatcher. during xposed's infancy i thought of doing many changes to it including this one, but i didnt have the time.
[Android Software Development] CosmicDan:
Well, a central app to manage patching in userspace I mean (actual modification, not patch-building). To modify /data/app directly you need system Uid I thought.

Thanks for the info though, very good to know! I might look into this myself :)

Good point about Xposed. I'm a fan of Javassist in particular, it wouldn't have been difficult to do what you describe.

Sent via Tapatalk on my Xperia Z
[Android Software Development] Lanchon:
you dont need to be root: just mod the apk then install it. no reason to mod the installed app in place. (well, unless you mod the system or the preinstalled stuff.) if you mod in place, you need to somehow run parts of the installation again (oat/odex building, etc)
[Android Software Development] CosmicDan:
True I'm getting mixed up, its /data/data/ access that needs elevation not /data/app/. Anyway, I might try this out sometime.

I just realised though that package signatures kind of prevents this though. This is where Xposed has a solid advantage. Hmm... Editing the odex/oat in-place (with conversion) could work but the system would likely detect it as stale and re-optimize, erasing any modification.

Sent via Tapatalk on my Xperia Z
[Android Software Development] Lanchon:
you just install the modded app via pm. no root required. if u want fake signatures you need root or a signature vulnerability. there is one.
[Android Software Development] Lanchon:
UPDATE: version 1.0.0 released!

Changelog in the previous link. DexPatcher graduated out of beta with no changes to its code, but with a new public and portable Gradle-based build system and integrated tests. Versions bumped on the 'DexPatcher-gradle-tools' repo. Enjoy!
[Android Software Development] Lanchon:
UPDATE:

I set up a TO-DO list of changes i would like implemented in this project, in case anyone wants to step up to the challenge.

Also entered some issues (all regarding the Gradle plugins, all enhancements for now) in Github.

DexPatcher fulfills all my needs as it is now, and although I would like to continue development, there seems to be no point to it at this time.
[Android Software Development] Lanchon:
UPDATE: Gradle plugins v0.2.0 released!

Changelog in the previous link.

Features a new DSL syntax (brakes old build scripts :rolleyes:), a new Patch Library plugin, and a companion sample.

Enjoy!

EDIT: Yes, I like to contradict myself sometimes...
[Android Software Development] PerfectSlayer:
Tanks for the update and the sample too! :good:
[Android Software Development] justdoitbk:
Does this mean that all Java coded Android apps' source codes are exposed to everyone?
[Android Software Development] PerfectSlayer:
What do you mean by "exposed to everyone"?

The whole source code of an app will be exposed to you to complete / complete the behavior of the app itself with a patch.

It will not be accessible from outside the app or after you applied your patch.
[Android Software Development] Lanchon:
no. with this toolset you can patch apps in java and edit and merge resources in android studio, instead of patching in assembler (dalvik bytecode) and edit resource files with a text editor.

in the larger view, this toolset exists because it is so far impossible to recover source code from compiled java (obfuscated or not, and from its derivatives like dalvik bytecode), and if the past is a good predictor, it looks like it will continue to be this way for a long while.

also, due to what i consider shortcomings in the design of java (eg: inlining of accesses to static final fields initialized with a constant expression) binary compatibility of compiled classes is seriously hampered, and source code can never be recovered (although a working alternative though not really equivalent source code could).

also, im not an expert, but it looks like some valid constructs in bytecode simply cannot be expressed in java, but i cant state this authoritatively.
[Android Software Development] CosmicDan:
It's not impossible to recover source code, Android Studio has a built in decompiler even :\ I see this as a better alternative to decompiling and modifying, since decompiling doesn't guarantee 100% working code, for the reasons you say. But in many cases, and I know from experience, you can decompile a large app and get the majority of working code still. Plus decompiling may be useful than smali to get an idea of what your patch should be like.
[Android Software Development] Lanchon:
well what i mean by impossible is just that: that you cannot get working code. you can't even decompile the smallest test app without obfuscation and get useful source that you can rebuild, let alone a real application.

so how you been anyway, what happened to your idea of using dexpatcher for your client?
[Android Software Development] CosmicDan:
Well that's a given, at least with Java languages you can get something though, but yes I see your point.

Company doesn't really have a use for it yet. The small things we do need is just quicker and easier to do in smali.
[Android Software Development] Lanchon:
UPDATE:

The Big TO-DO List has been updated and expanded with proposed annotations and -mostly- moved to Github.
[Android Software Development] bitstreamout:
Question on how to use?

Hi,

I run into trouble of understanding how/when to use [MENTION=4683450]Dexed[/MENTION]it(...) or [MENTION=916460]dexi[/MENTION]gnore for a subclass.. The first tag gives an error on doing the last final step

Oppo/com.oppo.mediacontrol> ~/.dexpatcher/dexpatcher/dxp-make
Note: src/com/oppo/mediacontrol/home/HomeActivity.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
dxp-make-patch: done: patch.dex
info: load 'source.dex'
info: load 'patch.dex'
error: type 'HomeActivity$MyTask': target not found
error: type 'HomeActivity$onFilelistItemClick': target not found
2 error(s), 0 warning(s)

I've used fernflower, cfr, and procyon together with a configured java 1.7 as well with the sdk target and build version as used by the original apk to get the patched class file to compile. Now I've a class file src/com/oppo/mediacontrol/home/HomeActivity.java with lot of required but DexIgnored declarations and two modified sub classes, one of them with an added method to be able to modify the other class. Which is the class I'd like to hack to my needs as I think I've found the bug I assumed. This sub class onFilelistItemClick is now with two methods replaced. But as far as I use e.g.

[MENTION=4683450]Dexed[/MENTION]it(defaultAction = DexAction.IGNORE)
// [MENTION=4683450]Dexed[/MENTION]it(onlyEditMembers = true)
// [MENTION=916460]dexi[/MENTION]gnore
// [MENTION=232767]dex[/MENTION]Replace
public class onFilelistItemClick implements AdapterView.OnItemClickListener, AdapterView.OnItemLongClickListener {

the cited results happen. When I use the DexIgnore tag as seen in the commented lines the resulting patched.apk does not show any of my debug messages AFAICS.

Maybe I've something overlooked in https://github.com/Lanchon/DexPatcher-tool/blob/master/test/patch/src/main/java/test/Main.java. For me this looks like I've done a major error in reasoning therefore I'd like to ask if anyone can give me a pointer/hint where I'm going wrong here :crying:
[Android Software Development] bitstreamout:
Mea culpa ... sorry for the noise, that is I have found my brain dead error. And indeed I'm was right about the bug I suspected in the app which, that is the guess I had get from the tcpdump I've used to listen the http protocol of this app. Now after successfully hacking this app I'm just ``hearing'' the result of gapless playback of flac files from CIFS shares.
[Android Software Development] Lanchon:
hi! im visiting toledo and on my cell. i cant say much without seeing the actual code but... it looks like: 1) if u are not editing any BYTECODE MEMBER of the outer class (class member doesnt count), then you should use DexIgnore on the outer class. you also need to redefine your used members of the outer class with DexIgnore so that ur compile unit will find them (yes, its a drag; limitation of javac). (BUT BEWARE OF USED PRIVATE OR PROTECTED MEMBERS, ask for more info if needed.) 2) use DexEdit on the inner class, assuming its non-anonymous. do not access private or protected memebers of the outer class (or ask if u need to).
[Android Software Development] bitstreamout:
Thanks for your answer. And yes there had been three anonymous classes which I've replaced with named sub classes and this seems to work flawless AFAICS. Not that bad for a Java freshman.
[Android Software Development] tanago:
downloaded the samples, edited the local.properties, replaced the apk in source dir with the one I want to modify, now what? what should I put in the patched dir?
[Android Software Development] Lanchon:
yep, that's the same pattern i use when i need to mod anonymous classes. :)
[Android Software Development] Lanchon:
you need to review and adapt all gradle configuration files in the various projects.
[Android Software Development] tanago:
Yea, I did that(just had to edit the application name in patched/build.gradle and remove your buildscript in root/build.gradle, right?)

Now AS gives me error(missing AndroidManifest) for the patched/src folder because it's empty. Is the .dex unpacking manual with apktool, dex2jar & cfr?