yashsingh1/xdaforums huggingface dataset:
[Android Software Development] Lanchon:
hi, thanks for asking!

ideally you'll keep the framework dir within the project structure (eg: <root-project>/source/framework) so that the complete project is held in the version control system (VCS).

you can set what you need directly in the apktool decode task.

you got the frameworkTag property in the decode task:

https://github.com/DexPatcher/dexpa...patcher/gradle/tasks/DecodeApkTask.groovy#L45

and the framework dir properties in the base apktool task inherited by decode:

https://github.com/DexPatcher/dexpa...adle/tasks/AbstractApktoolTask.groovy#L78-L80

there are 3 properties because apktool uses the dir as both input and output, and gradle doesn't like that at all when evaluating up-to-date-ness of tasks. all 3 properties set the value passed to apktool, but gradle checks up-to-date-ness differently:

frameworkDir: only the location of the dir is important, change the location and the tasks will re-run.

frameworkDirAsInput: the contents of the dir is important before starting the task, change the contents and the tasks will re-run. the task is not expected to modify the contents when run. (this is what you want!)

frameworkDirAsOutput: the contents of the dir is important before starting the task, change the contents and the tasks will re-run. the task is expected to produce the contents when run.

usually frameworkDirAsOutput is set by default to a dir inside the build directory, so output of the project doesn't depend on stuff outside of the project.

so in source/build.gradle you can add this line to clear the default and have apktool use the framework in your home directory, which is NOT recommended:

decodeApk.frameworkDirAsOutput = null

better to set a framework dir inside the project in source/framework (after manually populating it), like this:

decodeApk.with {
frameworkDirAsOutput = null
frameworkDirAsInput = 'framework'
frameworkTag = 'yourTag'
}

if you want to set defaults for all apktool tasks you might create (you will probably use just the apk-library plugin that creates one apktool task, but you can do a lot of apktool stuff from gradle with my dexpatcher-base plugin) then you can use the apktool extension object like this:

dexpatcherConfig {
//dir = '~/android/dexpatcher/dexpatcher-gradle-tools'

apkLibrary {
disableClean = true
}

apktool {
frameworkDir = '~/android/apktool-framework'
//frameworkTag = 'someTag'
}
}

But instead of defining the directory there, better add a 'dexpatcher.apktool.frameworkDir' entry to the 'local.properties' of the source project or the root project. That way the local configuration is not posted to the VCS.

btw, in the next release of dexpatcher-gradle you will be able to simply do this instead of directly messing with the decodeApk task:

dexpatcherConfig {
apkLibrary {
disableClean = true
}

apktool {
frameworkDirAsInput = 'framework'
frameworkTag = 'yourTag'
}
}

hope this answers everything you need.
[Android Software Development] Lanchon:
hi,

recognizing that things weren't perfect in this regard, i just made a new dexpatcher-gradle plugin release (0.4.4) with fixes for you.

Now both of these examples are valid:

dexpatcherConfig {
apktool {
// Set defaults for all ApkTool-based tasks.
frameworkDirAsInput = 'framework'
frameworkTag = 'tag'
}
}

decodeApk.with {
// Set values for a specific ApkTool decode task.
frameworkDirAsInput = 'framework'
frameworkTag = 'tag'
}

details here:

https://github.com/DexPatcher/dexpatcher-gradle/releases/tag/v0.4.4

thanks!
[Android Software Development] apc:
Thanks for your reply and it is actually both: updating a patch to a newer version makes sense in the way you described it.

What about distributing a "standalone" patch to other users of the app? Is there an elegant way to this or can it be done on the device itself respectively?
[Android Software Development] btothefifth:
Great Tool! Some Feedback

[Redacted]
[Android Software Development] esun:
I'm trying to include a certain dependency only on debug builds but I get an error about the Gradle Android plugin. It seems the compileDebug method doesn't exist without this plugin. Do you have an idea of how to work around this with the DexPatcher project structure?

I'm trying to include Stetho.
[Android Software Development] Lanchon:
hi,

1) if the patch is a code-only patch...

you can easily distribute the patch dex file. a shell script or a gradle task or a simple java program could be implemented to patch the apk and produce a new one. unfortunately there is the business of signing the resulting app, with all the issues that that brings to the table. (what signature should the user use? yours made public?... security nightmare! their one?... but will they know to keep it in order to be able to upgrade the app?)

then there is dexpatcher-live, an unreleased on-device JIT patcher that hooks dex2oat. it's the ideal vehicle for code-only patches, a sort of competitor to xposed. unfortunately it has rough edges (eg: requires deodex rom to patch rom itself) and i really don't have time to develop it beyond the proof of concept stage.

2) if the patch is an android studio-style code and resources patch...

then a full build system is needed (android sdk, gradle or wrapper, probably java sdk). if you dont want to distribute the source of your patch, you can create a patch library and distribute that. the user will still need a build system and a complex project structure to apply the patch. in this case you'd be wise to distribute the patch library and the apply project together, so that the user only needs to copy the apk inside and "./gradlew build". (note that your code can still be distributed in compiled binary form if you choose to distribute a patch library instead of the patch project. see the patch library sample.)

a shell script or a gradle task or a simple java program could be implemented to generate the patch library apply project and build it, so you distribute only the patch library, i really don't have time for this.

3) finally the user can use a bin-diff tool to produce the patched apk from the source apk + bin-diff patch. ideally you'd use a bin-diff that understands and crawls into zipfiles.

all in all, there no naive user front end for dxp. for now dxp is a developer's toolchain.
[Android Software Development] Lanchon:
what do you mean by method? a gradle task?

when you use my plugins, you get android build system (extended), because my plugins apply android plugins.

these plugins:

com.github.lanchon.dexpatcher.patch-library

com.github.lanchon.dexpatcher.patched-application

will give you a task called:

compileDebugSources

you really need to figure out how to do what you want on the standard android build system. whatever works on it should work on my plugins too.

plus, i can't really help if you dont post a working project structure, sorry.
[Android Software Development] CosmicDan:
Hi,

Nice to see you are still active on this. Is coming along nicely.

I want to make some MIUI framework dex mods as an alternative to using Xposed modules. I want to include in my CosmicTweaks, the idea being that I prefer to make an Aroma-based "patcher" rather than releasing custom ROM's. It requires much less maintenance this way, I use patching systems rather than hard replacements where possible.

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?

(Disregard; I see I don't need Android Studio, I just need to import your annotations and compile to a jar then dex as normal) Second question: is Android Studio required? I use Eclipse (I am not just an Android developer) but am fine with manually using a text editor to write patches if needed. I've just never used Android Studio and would like to avoid learning a whole new IDE if possible.

Cheers!

EDIT: Oh, I forgot that the dexpatcher itself is written in Java, so can't be cross-compiled to work in Recovery (i.e. busybox terminal) anyway. Never mind.

EDIT2: Actually, I've discovered that it's possible to make console-mode dex files from jar files manually and run them on Android, which sounds awesome. Assuming that this is possible, would I be allowed to redistribute a dexpatcher.dex binary with my tool to provide this "on-device patching" functionality I'm after? Strictly a non-commercial, as-open-as-possible project. And also assuming that dexpatcher patches can work well the various target dex files, as originally asked above.
[Android Software Development] Lanchon:
dxp-annotations are GPL. if you include them in your patch, YOUR PATCH then technically becomes GPL (as it is linked to GPL code).

but...

dxp is designed to avoid this license creep into you code. you should reference BUT NOT INCLUDE the dxp annotations in your patch, just like you would reference eg the String class without actually bundling it into an executable jar file.

this is typically called the "provided" scope in tools such as maven, and it would be a compileOnly resource in gradle.

EDIT:

take a look at the test subproject of dxp-tool for an example of building a java patch, dexing it, and patching a dex, all in a platform portable way in gradle (look at the portable test in test/build.gradle). you will also find bash shell scripts to patch then run the patched result in both the host's JVM or a real android target (device or emulator).
[Android Software Development] CosmicDan:
No problem! I have mid-semester exams on right now myself, so this is just in the planning stage for the next week.

Perfectly fine. My own device is stuck on Android 6.0, most people aren't on O yet - those that are have AOSP-fork firmwares, and DexPatcher is of limited use to them anyway I suppose. I'm also aware that DexPatcher requires a deodexed firmware - if used for system modding - and that's fine.

Makes sense. Similar dangers to when doing smali hacks, yeah. I figured as much - no problem.

That's good, that's what I was after. Trying patches in sequence is a "good enough" approach for now (I'm hoping DexPatcher uses exit codes so I can easily script this?). An example of what I want to do is a [MENTION=4954403]dexw[/MENTION]rap 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.

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.

It's just going to be a ROM modding toolkit, a platform for others to put their ROM mods on and get a bunch of the annoying stuff pre-managed (logging, menus, etc). Nothing mission critical - people will be advised to make full backups beforehand and warned of bootloop-type issues so it's no major problem :) I'll tackle any patching fails due to target differences as they're encountered.

I don't think I will ever have a need to add resources. I'm hoping not because I really don't want to have to learn Android Studio just for that one thing (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).

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...

I have no plans to use DexPatcher commercially at all (I no longer work for that company that I was interested in doing it with) and I plan to make all my patches fully free anyway, so the licensing is not an issue. 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.

Cool, thanks!
[Android Software Development] CosmicDan:
I think I understand what you mean (since I've done diff patching on raw smali and vaguely recall a problem differentiating between method types), but it's great that you're on top of all this like a boss :D

Yeah that's it. Though I can't really complain about it being closed-source, I'm a massive MIUI fan which is known to have various mysterious backdoors/spyware in there (something that I will fully research and make patches for over the next few weeks, I hope) but since Xposed also breaks SafetyNet completely and can't be spoofed in any way I am definitely 100% done with Xposed. Too many bad experiences, too many poorly-written modules that hurt performance or stability.

Oh I forgot about those little bugs lol. There are just some things that IDEA does completely differently to Eclipse and I am making excuses to avoid learning a new IDE. The other main reason why I was sticking with Eclipse was because of the bytecode viewer for ASM coding in Minecraft mods, but I've moved on from that now...

...eh, I guess I'll try IntelliJ IDEA again. I am guessing the DexPatcher stuff specifically needs Android Studio though, right? Not very familiar with gradle either but I've heard it's much better than Ant.

No worries. After investigating I've decided to go the standalone dalvikvm route as it will result in a smaller ZIP file.

Yup, no problem :)
[Android Software Development] Lanchon:
IDEA has a full fledged java decompiler when clickin, java-searching, etc over stuff for which it has no source, it's called fernflower and it's really good. it was finally open-sourced too, so this one is the only modern free java decompiler, no small thing. in contrast, CFR's author promised to open-source (i believed him then) but never followed through.

dxp-gradle needs gradle and the android build system (a set of gradle plugins plus the android devel tools). Studio is the natural host for all this stuff, but it's not required. dxp-gradle is used to mod APKs: code, resources, manifest, etc. dxp-tool is used to mod code (dex files), and is used by dxp-gradle. but dxp-gradle uses a truckload of tools, in all.
[Android Software Development] Lanchon:
UPDATE: DexPatcher-tool v1.4.0 is out!

also check out 1.3.1 if you haven't already...

https://github.com/DexPatcher/dexpatcher-tool/releases
[Android Software Development] Lanchon:
UPDATE: multiple updates !!!

DexPatcher tool: 2 new releases!

DexPatcher Gradle plugins: 2 new releases!

Tool roadplan: updated

these collective updates make it easier to work with obfuscated code, but full obfuscation support is still far in the making.

the Gradle plugins finally look release-ready! they might be republished as v1.0.0 after some testing.
[Android Software Development] akashk07:
Hi all,

I'm trying to use dexpatcher on windows and struggled a lot.

I'm unable to find that how to start, what step by step procedure I have to follow.

How to decompile an apk via dexpatcher, then, how to generate android studio compattible project and edit it?

can someone please help me?

I'm able to find the scripts, but those are only for linux, I need the help for windows.
[Android Software Development] Lanchon:
> I'm unable to find that how to start, what step by step procedure I have to follow.

first post, START HERE section.

if you don't know how to git-clone a repo, you'll have to learn that elsewhere.

> How to decompile an apk via dexpatcher, then, how to generate android studio compattible project and edit it?

dexpatcher is not a decompiler. that's why it works; decompilers don't, in general.

> I'm able to find the scripts, but those are only for linux, I need the help for windows.

don't use the deprecated scripts.
[Android Software Development] akashk07:
Hey bro,

Thanks a lot for your help and reply.

Bro, I'm already a programmer and I very well know that how to git clone a repo.

I've read the start here section well, and understood it as well.

But now, the issue is that, I'm unable to figure out that how to work with any other app.

For exampl,e,I'm able to work with the sample app because you've provided the source code. now If I don't have the source code for an app, then what would I have to do?

I'll be very thankful to you if you guide me.
[Android Software Development] Lanchon:
i didnt provide the source code, i provided the APK. it is sitting in the 'source' subproject.

use the 'patched-app' project structure as a template, and modify according to your needs.

android studio has a built in decompiler. in the sample project structure, in the libraries section at the bottom, browse the 'source' dependency. android studio / intelliJ IDEA will decompile classes you open on-demand. that helps you to understand the app code.
[Android Software Development] akashk07:
Thank you bro.

Now, while running/building the app, I'm getting following error:

Error:Failed to notify task execution listener.

> com.android.build.gradle.internal.tasks.PrepareLibraryTask.getExplodedDir()Ljava/io/File;

> com.android.build.gradle.internal.tasks.PrepareLibraryTask.getExplodedDir()Ljava/io/File;

> com.android.build.gradle.internal.tasks.PrepareLibraryTask.getExplodedDir()Ljava/io/File;

> com.android.build.gradle.internal.tasks.PrepareLibraryTask.getExplodedDir()Ljava/io/File;

I've set dexpatcher.dir property in my local.properties to :

dexpatcher.dir=E\:\\git\\dexpatcher-gradle-tools\\tools

it didn't work, I've also tried this line:

dexpatcher.dir=E\:\\git\\dexpatcher-gradle-tools

But still it didn't work. what do I do?
[Android Software Development] akashk07:
I've compiled the sample app successfully.

But, now when I'm going to the structure, I'm not finding anything like source, other libraries are there such as:

<1.8>, Module dependencies> but there's nothing like source. what I'm missing here?
[Android Software Development] Lanchon:
->External Libraries

--->classes

----->classes.jar
[Android Software Development] akashk07:
Thank you bro. It helped me a lot. I'm able to successfully view the source code now.
[Android Software Development] CosmicDan:
Howdy,

I've spent enough time in IntelliJ IDEA and also Android Studio to finally take a crack at this. You're right, was worth dumping Eclipse for it.

Based on the patch-lib sample, I started work on a mod for framework.jar. I had to convert it into a dummy APK file by adding a dummy manifest and string XML. Would you consider making a plugin named "com.github.lanchon.dexpatcher.jar-library" to make this more graceful? Since it results in junk in the resulting patch :)

...but now I'm stuck at my first test attempt. When I build the patch I get an aar, and I have no idea how to use that. I have tried the other gradle plugins to no avail. How do I actually compile a patch dex for use with the dexpatcher jar?

EDIT: Oh, I see that I can just get the classes.jar from this aar and convert it to a dex manually. I'm assuming there is a better way though...?

EDIT2: I'm trying to set a volatile variable from a Runnable (I'm using postDelayed and I need a flag to decide whether it ran or not) but I get an error. Here is the code...

@DexAdd
private volatile boolean volSkipPerformed = false;

@DexAdd
private Runnable skipForwardRunnable;
@DexAdd
class SkipForwardRunnable implements Runnable {
@Override
public void run() {
volSkipPerformed = true;
Log.e("VolumeSkip", "Fire forward skip!");
}
}

... which isn't all that different from one of the samples, I can see that you are setting outer class instance variables fine. But DexPatcher throws an error when I try to apply it:

error: type 'com.android.server.policy.PhoneWindowManager': direct method 'access$002(com.android.server.policy.PhoneWindowManager, boolean):boolean': (PhoneWindowManager.java:16): no action defined

Couldn't find a solution to this.
[Android Software Development] Lanchon:
hey!

sorry i might not have time to answer this today until late at night, hold on...
[Android Software Development] CosmicDan:
No problem, take your time :) I've always got other things to work on.
[Android Software Development] Lanchon:
very quick pseudo reply:

[MENTION=377209]DeXa[/MENTION]dd

volatile boolean volSkipPerformed;

remove the private to make the field package-private.

ill explain later.

watch it! initializers are embedded in constructors, so if u dont patch them the = false part will not be executed. fortunately its redundant in this case
[Android Software Development] CosmicDan:
Ohhh because it's a separate class, of course!

Yeah I've noticed I can only initialize primitives to their default in this way, as you said this is redundant. I read about that when I realized I couldn't initialize skipForwardRunnable here either. For the moment I just assigned it (if null) in the method before it's used.

With that said, a couple more questions (totally non-urgent, don't stress):

1) Regarding the initialization, I don't understand the examples and docs in Main.java for this. How does one initialize their variables if the target class (a) has no explicit constructor or (b) append the class's existing constructor (if possible)? I noticed that you've said "This limitation might be partially relaxed in the future" regarding DexAppend for instance constructors, implying that this is an intentional design choice.

2) This class PhoneWindowManager class i'm patching implements WindowManagerPolicy which is hidden in the Android API so obviously I can't match the exact signature. I got around that by using contentOnly = true which works fine but I am concerned about the disclaimer you gave - "this has complex implications affecting the type system and the constructors of the class. It is generally not recommended". Sounds scary. So I should try to always avoid this? Could it be avoided by making dummy/skeleton classes (e.g. an empty WindowManagerPolicy class matching the same package as the original) but then using @ DexIgnore on the class? Hope that makes sense.

Also, lol with the @ Dex stuff triggering XDA forum mention feature for random users.