yashsingh1/xdaforums huggingface dataset:
[Android Software Development] fritznet:
for me android studio 3.2.1 is working with the sample config/app.

For Versions look here:

https:// github.com/DexPatcher/dexpatcher-gradle/releases

---------- Post added at 02:16 PM ---------- Previous post was at 02:06 PM ----------

First of all i would like to thank for the great tool.

The 'patched-app' sample works great for me.

So i tried to change the apk to something else. Decompilation and so on works fine but then I get the following error:

Execution failed for task ':patched:patchDebugDex'

Caused by: org.gradle.process.internal.ExecException: Process 'command 'C:\Program Files\Android\Android Studio3\jre\bin\java.exe'' finished with non-zero exit value 3
at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:367)
at org.gradle.process.internal.DefaultJavaExecAction.execute(DefaultJavaExecAction.java:31)
at org.gradle.api.tasks.JavaExec.exec(JavaExec.java:74)

My Problem with this error is that I can't get more information on this error to properly debug it.

On Stackoverflow they mention to low heap size (or low system memory) which I changed and to change `compile fileTree` to `provided fileTree`. I tried 2 maschines with win7 and win10 wirth 32GB and 16GB ram. On both I get the same Error. The example app is however working fine. (when I delete the application tag in the manifest the example app gives me the same error)

I adopted the min and target SDK versions to the information i got from `aapt list -a target.apk | grep SdkVersion` and removed all the sample app specific stuff (all the java code, activity stuff in manifest, ...)

So my question is how to get more information on the exit code to fix the issue.
[Android Software Development] fritznet:
I made a script as workaround for this issue since I get the same error on some apks:

task fixRes(description: 'fixRes') {
new File('.').eachFileRecurse(FILES) {
if(it.name.contains("\$") ) {
println it

String oldFilename = it
String newFilename = oldFilename.replace("\$", "")

it.renameTo(newFilename)
}
}
}

the only problem I have is to get gradle to execute it after the right task. (I have nearly no experience with gradle). If someone can tell me how to add the task properly to the plugins build task it would be nice. I had no luck with things like

task(':patched:mergeDebugResources').dependsOn(fixRes)
// or
fixRes.mustRunAfter ':source:apkLibrary'
[Android Software Development] Lanchon:
hi,

i've been travelling for the last few months and unable to look at this stuff, sorry.

vishal, would you be ok with just patching the code of your app? or do you need to add android resources as well?
[Android Software Development] fritznet:
This would be a nice workaround (if this feature is fast forward to add). If he has to patch resources as well i build a gradle script to rename all files, but I don't know how to run it with your plugin (see post above).
[Android Software Development] Lanchon:
the problem is how fast google changes, deprecates and abandons its software.

dexpatcher-tool modifies dex code and is up to date for working with android 9.

dexpatcher-gradle are gradle plugins that hack into google's android build system to integrate with IDEs, add modify and remove resources, patch manifiests, add full android libraries etc, and it works perfectly with android gradle plugin 2.2.x (their old build system).

then google updated to plugin 2.3 but it has a showstopper bug that i reported. they acknowledged the bug but refused to fix it saying that they would abandon the 2.x branch. so dexpatcher cant work with android plugin 2.3.x.

then they switched to plugin 3.x, which is a complete rewrite, meaning i have to rewrite my plugins too. at the same time, they also provided alpha plugin 4.x, which is a complete rewrite again, so you don't know what to do. now they seem to have killed 4.x.

they switched from javac/dx to jekill, and i support both. then they killed jekill and went back to javac/dx. then they switch from dx to d8.

it's a complete mess, and i have little time for it.

in parallel, they switched from AAPT to AAPT2, and that's when the $ naming issues started to crop up. there is no fixing of this with google's software, so apktool has to distribute their patched AAPTs.

a possible working solution would be to rewrite dexpatcher-gradle to the newest android plugins, and patch the android plugins to use apktool's patched AAPTs. this will probably fix all issues... but for how long???

an alternative is to drop the android plugin and use apktool exclusively.

if i made a such a gradle plugin, we would gain:

-it just works!® the apktool people do the heavy lifting of keeping up with android changes. the fidelity in rebuilding apps with dexpatcher would be state of the art.

and we would loose:

-no IDE integration.

-no adding of android libraries (but java libs can be added).

-no patching of resources or manifests. such changes, if needed, would have to manually be handled by file, in a copy and modify fashion. so updating the source app with a new version would be a bit of a nightmare.

-no APK signing, so i would need to provide gradle tasks for that somehow.

-no launching from the IDE, unless i build my own solution.

-no debugging.

-etc...

still it would be a good solution for cases where only the code needs to be patched.

the implementation of this would be greatly simplified if there were apktool gradle plugins, but AFAIK there arent any except my own (in dexptacher-gradle).

in the meantime you can use this approach yourself without a plugin. you can call apktool using my tasks in https://plugins.gradle.org/plugin/com.github.lanchon.dexpatcher.base and asking the tool not to process source code. then have dexpatcher-tool patch the dex. finally rebuild with apktool. signature and deployment you would have to handle yourself.

start by checking out this sample that uses the base plugins to invoke dexpatcher-tool directly:

https://github.com/DexPatcher/dexpatcher-gradle-samples/tree/master/patched-dex
[Android Software Development] CosmicDan:
How's the situation these days regarding Gradle?

I'm planning to use DexPatcher in an open source project for modifying stock ROM's, aka a "kitchen" (think Xposed but compile-time) but the uncertain future of DexPatcher is a concern. Annotation based patching is fantastic and would save me a lot of time in writing my own patching system.

If you remove support for patching resources completely, would that help keep DexPatcher more maintainable?

My use case is a bit different - I want to be able to call DexPatcher from my own Java-written kitchen, but don't care about resources - only the actual dex part. I've been wondering if I can ignore Gradle tasks entirely and just call DexPatcher as a library, but of course the patches themselves still need to be developed and I guess that is where the Gradle problem is - if IDE support is removed though I personally don't see the advantage of DexPatcher at all :\

If newer Gradle versions cause issues, is there no way to just use the old Gradle wrapper version manually? Even if it requires a modified SDK/Platform?

APK signing, resource modification, IDE launching and debugging are not so important IMO. All that can be worked around or done by other means without great difficulty. But just being able to use an IDE is pretty important, with android.jar (platform) as a library. But writing Java blind with absolutely no type of validation or assistance from an IDE... :(
[Android Software Development] btothefifth:
Error: '$' is not a valid file-based resource name character

Were you ever able to get a gradle renaming workaround to work or does anyone have any updates on AAPT2 support? I am having the '$' issue as well.
[Android Software Development] Lanchon:
dxp-tool is a command line tool independent of gradle and it only deals with code. it also has a java API and can be used as a library (it's a fat jar, but inside each fat jar there's a thin version).

to develop patches, in general IDEA support is accomplished by creating a gradle build script. gradle has a tooling API that exposes the build and IDEA is very good at jacking into it: the whole of an IDEA project can be set up and kept in sync from a gradle script automatically.

there are many useful gradle plugins for dexpatcher that could be implemented by me or anyone else. the current plugins are the most complex and difficult of the lot (and unfortunately they are outdated). a plugin that should exist would rebuild an APK with apktool instead of the android build system, mostly for patching only the code of apps. for patching framework jars, another plugin could be developed, but it would see much less use i think.

in any case, whatever can be done in a plugin can also be done directly in the build script code, so plugins are never necessary. there is a sample that does what you want in this way (well it actually uses the dxp base plugin to get some basic dxp tasks taken care of for free). it can be improved in a million ways but it's enough for the task. take and in-depth look, it's here:

https://github.com/DexPatcher/dexpatcher-gradle-samples/blob/master/patched-dex/build.gradle

you don't need to remove anything from dexpatcher; just use only the tools you need.
[Android Software Development] Lanchon:
gradle breaks if tasks modify their inputs: tasks should never alter their inputs. this means that a task that renames some files is a big no-no.

the gradle way is to create a modified copy of the file set, which due to some optimizations might not be as bad as you think. the problem is that later tasks must now get their input from the copy. one way to accomplish this -it would seem- is to change the destination dir of the task that produces the file set to be modified, and then add a task that copies with rename from that dir to the original destination dir, so tasks down the line will find their input in the same location as they've always had. well... it's not that simple: later tasks might get their input dir from the value stored at the output dir of the preexisting task, so changing the output dir accomplishes nothing. further, that connection is many times the only indication of task dependency in a build, so the problem remains of how to trigger the added task at all (this would benefit from composed tasks, which dont exist at least in gradle 2).

this is a whole mess and shows why the dexpatcher-gradle plugins were so time-consuming to write, interfacing with the implementation of a 99% undocumented huge and complex build system: Android's.

however in this case there is a simpler solution. you can piggyback actions (eg: the renames) to the task that first creates the resource directory: the ApkToolTask that is part of my apk-library plugin. you add an action to a task by calling task.doAfter(...with some code here...). this is NOT a new task: a task is executed or not completely and as a unit, with all its actions in sequence. and actions don't have order/dependency/up-to-date resolution; whole tasks do. so if you modify the output the built-in actions in ApkToolTask IN-PLACE (eg: renaming) with a later action, you are just producing a different output for the task, and you are not breaking any rules. the modded resources would then be packed into a modified APK library that is the output of the build by later tasks, and then that lib would be consumed by an independent patched-app build as always.

was this clear?
[Android Software Development] CosmicDan:
Thanks a lot mate, it was perfectly clear - I'm always impressed with your verbosity :D

I have plenty to go on now, will let you know if I encounter any problems that I'm certain aren't my fault :)
[Android Software Development] Lanchon:
UPDATE: DexPatcher-gradle v2.0.0-alpha1 is out!

Full rewrite of DexPatcher-gradle for Android Gradle plugin v3.3.2, AAPT v2 and Gradle v4.10.3.

https://github.com/DexPatcher/dexpatcher-gradle/releases
[Android Software Development] Lanchon:
UPDATE: DexPatcher-gradle v2.0.0-alpha2 is out!

https://github.com/DexPatcher/dexpatcher-gradle/releases
[Android Software Development] Lanchon:
i don't plan to add support for Android Gradle plugins v3.0 and v3.1 unless there is a compelling reason to do so. i only added support for v3.2 to be able to support AAPT v1, which was removed from v3.3.

the plugins are missing some capabilities and usability enhancements (which will be included in the beta release), and a lot of testing. so please report your findings! thanks.
[Android Software Development] o0fred0o:
Hello Lanchon,

First of all thank you for your project. It's really great, it allows me to source patch APKs much more easily. Got a question though. For a system app on a custom rom I have signature verification disabled and copy the original manifest to get it running under the same user id. This is a manual step for now. I found a copyOriginal setting in your build task that seems to do just what I want. However it does not seem to work. Is this implemented and how do I use it? I'm on 2.0 alpha 3.
[Android Software Development] Lanchon:
> copy the original manifest to get it running under the same user id.

what do you mean by that? same user id?
[Android Software Development] o0fred0o:
The apk must run under the system user id. It shares data with about 15 other APKs that I don't feel like unsigning or resigning. Somehow I cannot get the APK to share data and function without signing or with a different signature. However when I copy the original manifest + signatures (which are invalid now of course) it works and I can patch it.
[Android Software Development] Lanchon:
oh, i get it. if your rom supports signature spoofing (google lanchon haystack), you just need to add the spoofing config to the patched app.

declare the sigspoof permission in the manifest like this:

https://github.com/Lanchon/sigspoof-checker/blob/v1.1/app/src/main/AndroidManifest.xml#L6-L7

and add the signature data like this:

https://github.com/Lanchon/sigspoof-checker/blob/v1.1/app/src/main/res/values/strings.xml#L10

this usually works if you are patching an app that self-checks its signature. it also fools google's map API, which requires per-app key and payment by the app developer. sigspoof will make the original developer's API key work on the patched app.

if you just want to replace the files, you'll need to add some code like this to your app's build.gradle:

android.applicationVariants.all { variant ->
variant.packageApplicationProvider.configure { packageApp ->
packageApp.doLast {
def originalDir = layout.buildDirectory.dir('intermediates/dexpatcher/decoded-app/original')
def apkDir = packageApp.outputDirectory
for (def apkName : packageApp.apkNames) {
def apkFile = new File(apkDir, apkName)
exec {
workingDir originalDir
commandLine 'zip', '--quiet', apkFile, 'META-INF/CERT.RSA'
}
}
}
}
}

the above code requires android gradle plugin 3.3 or later (won't work on 3.2). you'll have to debug it, i haven't tested that code, just wrote it here for you.

EDIT: tested and updated the code. works on linux, requires the 'zip' command. note that this code breaks zipalign.

please paste your working solution here!
[Android Software Development] Lanchon:
come to think about it, it would probably be better to just disable signing in AAPT 1/2. the original signature files should already be in the patched apk then. i'll look into this at some point.

EDIT: you can disable signing in AAPT like this:

android.applicationVariants.all { variant ->
variant.packageApplicationProvider.configure {
signingConfig = null
}
}

but unfortunately AAPT filters out the old signing files that are fed into it so the apk ends up with no signature.
[Android Software Development] o0fred0o:
Thank you for being very helpful. I'm a c++/c# programmer with an iPhone and an Android head unit in my car, so all of this is new ;) I'm creating my own rom based on the original ROM from the manufacturer as none exist yet. I've been able to root the ROM, add SuperSU and Xposed + disabled signature verification. Never heard of signature spoofing. I'll try and add haystack to the ROM so signature verification can be reenabled (or at least be a choice to disable for the users of the ROM). The unit does not support TWRP and in fact will brick it. Then you have to solder to get it to accept a new firmware over USB from a PC. So I have to be careful and can only flash a working rom that will not boot loop for sure.

I'm planning on releasing full sources of all patches and build scripts so others can build upon this work. Thanks so far!
[Android Software Development] Lanchon:
WARNING: SuperSU might be a trojan!

what is your head unit? what android version?

> I'll try and add haystack to the ROM

the rom needs to be deodexed for haystack

> you have to solder to get it to accept a new firmware over USB

then don't apply haystack's UI patch to be on the safe side.
[Android Software Development] o0fred0o:
It's similar to this one. They come as different brands, but all units are the same software and MCU wise. I know that superSU is not trusted anymore but I've downloaded the original one from Chainfire as Android 7.1 is pretty old and the System method works flawlessly.

Magisk does not support Rockchip boot images, and manually creating a new boot image with systemless root or magisk added seemed a bit risky considering the inability to boot to recovery, other than from android with the factory supplied update method. Two other people tried already and bricked their units (don't know about their competence though).

Patching the ROM files can be done from my PC right? I can just manually copy the files, patch, and copy back to the mounted system.img. The rom is not odexed.
[Android Software Development] Lanchon:
yes, just pull the fileset and push it back using whatever method you want.

keep the originals!!!
[Android Software Development] o0fred0o:
Even better. I'm creating a set of bash scripts in a git repository that will allow everyone to recreate a ROM from the original ones. It's all automated and repeatable, including downloading / cloning of tools.

There are other separate repositories with dexpather android studio projects with my patches so everyone can patch to their liking.

Better invest a little time now to be able to save time later.
[Android Software Development] o0fred0o:
Here is the project right now. I went with the signature spoof. Still have to test it (as compared to the apktool modified one), but somebody is sending me a test head unit, and I'm waiting for that. Thanks for your help!

https://github.com/jspuij/eventcenter
[Android Software Development] o0fred0o:
So [MENTION=4141005]Lanchon[/MENTION] I managed to brick my unit while patching my ROM with haystack. I accidentally used API level 27 instead of 25. Patches applied succesfully, but the unit hang on boot. It's quite a pain to unbrick the head unit (soldering etc), so before I try again, could this be a symptom of the incorrect patch level?
[Android Software Development] Lanchon:
hi,

sorry to hear that. i suppose it could happen. you can mess up the numeric API level you enter into the command line, or you could mess up by applying the wrong patch for your API level (patches are broken down by ranges of API levels).

for maximum safety, don't apply the optional UI patch.

can't you adb to the unit? adbd is typically started early on during boot.
[Android Software Development] Lanchon:
Invalid character '$avd_hide_password__0'

error: resource 'drawable/$avd_hide_password__0' has invalid entry name '$avd_hide_password__0'.

hi guys, long time!

[MENTION=3239459]kanlo[/MENTION] [MENTION=6723547]edotassi[/MENTION] [MENTION=2461887]vishal.kadam[/MENTION]

please take a look here where i discuss your issue:

https://github.com/DexPatcher/dexpatcher-gradle/issues/22

UPDATE: solution here:

https://github.com/DexPatcher/dexpatcher-gradle/issues/24

thanks!
[Android Software Development] o0fred0o:
Yeah, I reflashed it from Maskmode and reapplied with the correct api level and all is well now. It works, including the UI patch. Thanks!

Is there any way to default enable the signature spoof? I want it to be part of a modified ROM, saves going to the settings page.
[Android Software Development] Lanchon:
glad to hear!

yes of course, just don't apply the UI patch and sigspoof will be enabled.

but if you want the UI *AND* also have it default to enabled, you'll need to slightly mod the patch sources and rebuild them.

otherwise take a look at the UI patch sources: find where the setting is "saved", then you can copy and invoke that same code anywhere you want (with the proper permissions).
[Android Software Development] btothefifth:
dexpatcher-gradle-tools

Just checking--is the plan to update dexpatcher-gradle-tools when 2.0 comes out of alpha?

Thanks for all the work on this project!
[Android Software Development] Lanchon:
i was hoping to retire the dexpatcher-gradle-tools repo and have the plugins dynamically download the tools according to versions the user specifies. unfortunately, gradle and github are profoundly incompatible and neither wants to change. take a look here: https://github.com/gradle/gradle/issues/5322

im evaluating options, but for now dexpatcher-gradle-tools stays.

but whats wrong with it anyway? what needs to be updated? AFAICT everything is up to date there.
[Android Software Development] Lanchon:
what are you trying to do? in the sample repo there are several samples and they are independent projects! are you trying to build one of the samples? which one? recommended: start with patched-app
[Android Software Development] ToXiTe:
I opened the patched-app directory as project in Android Studio. But, when it tries to sync it gives the same error:

ERROR: Unable to resolve dependency for ':app@debug/compileClasspath': Failed to transform file 'app-components.aar' to match attributes {artifactType=processed-aar} using transform IdentityTransform
Show Details
Affected Modules: app

ERROR: Unable to resolve dependency for ':app@debugAndroidTest/compileClasspath': Failed to transform file 'app-components.aar' to match attributes {artifactType=processed-aar} using transform IdentityTransform
Show Details
Affected Modules: app

ERROR: Unable to resolve dependency for ':app@debugUnitTest/compileClasspath': Failed to transform file 'app-components.aar' to match attributes {artifactType=processed-aar} using transform IdentityTransform
Show Details
Affected Modules: app

ERROR: Unable to resolve dependency for ':app@release/compileClasspath': Failed to transform file 'app-components.aar' to match attributes {artifactType=processed-aar} using transform IdentityTransform
Show Details
Affected Modules: app

ERROR: Unable to resolve dependency for ':app@releaseUnitTest/compileClasspath': Failed to transform file 'app-components.aar' to match attributes {artifactType=processed-aar} using transform IdentityTransform
Show Details
Affected Modules: app

EDIT: Switching build variant fixed it
[Android Software Development] Lanchon:
try getting apktool to decode and rebuild the app. if apktool fails, dexpatcher-gradle will not work either.

also, if you can post your project publicly i can take a look at it.
[Android Software Development] Lanchon:
Invalid character '$avd_hide_password__0'

error: resource 'drawable/$avd_hide_password__0' has invalid entry name '$avd_hide_password__0'.

[MENTION=3239459]kanlo[/MENTION] [MENTION=6723547]edotassi[/MENTION] [MENTION=2461887]vishal.kadam[/MENTION]

UPDATE: solution here:

https://github.com/DexPatcher/dexpatcher-gradle/issues/24

thanks!
[Android Software Development] Lanchon:
UPDATE: DexPatcher-gradle v2.0.0-beta1 is out!

IMPORTANT:

Staring with v2.0.0-beta1, DexPatcher-gradle no longer requires a local clone of the DexPatcher-gradle-tools repo (which is being deprecated as of this moment) and no longer requires entries in 'local.properties'.

More info here:

https://github.com/DexPatcher/dexpatcher-gradle/releases
[Android Software Development] Lanchon:
UPDATE: DexPatcher-gradle v2.0.0-beta2 is out!

https://github.com/DexPatcher/dexpatcher-gradle/releases