Invalid character for resource #21
Comments
|
yes. what version of the gradle plugin are you using? |
|
I'm using the 2.0.0-alpha4 along with the Android Gradle plugin 3.3.2. I'm so excited about that tool, and I'd really like to give it a try 😏 |
|
as you've read, this is a limitation of AAPT. i really can't tell you much about the reason behind it all, i'm not too familiar. but apktool ran into the same issue, and their solution (as always have been for similar aapt limitations) is to bundle their own patched aapt2 that sidesteps the issue. the android gradle plugin used to invoke the aapt1/2 binary that users installed as part of the android sdk. but this caused issues for them because it forced loose coupling between their gradle plugin and aapt. so to be able to upgrade them in lockstep, current versions of the android gradle plugin download the aapt binary they were designed to work with from google's maven repo, expand it into some temp dir, and run it form there. i'm sure the android gradle plugin must provide a way to override the aapt2 version to use, but so far i haven't been able to find it. if you happen into some info about this, please share it. anyway, my plan is to use this mechanism to direct google's plugin to use the aapt2 version patched by the apktool project. this should solve your issue and others too. this is one of 2 showstopper issues preventing the my plugin to move form alpha to beta stage. (the other issue is not so much an issue but an enhancement: i want to get rid of the dependency on my own dexpatcher-gradle-tools local clone.) |
|
as a workaround for you, you can try this: instead of patching the apk directly, try patching an apklib. take a look at the apklib sample where there are 2 projects: one builds the apklib and the other consumes it. you can use a similar setup, except that you make the second project consume a copy of the apklib directly (place it in the dir you are placing the apk now) instead of consuming a reference to the first project. you get the apklib from the output of the first project. with this set up, try manually removing the offending files from the apklib. i've heard many times this produces a working apk anyway. |
|
you can also try building using aapt v1 (requires android gradle plugin 3.2.x). dubious, but it might work. also... MAYBE the android gradle plugin uses aapt v1 from the sdk instead of downloading it... MAYBE. in that case, you can take the patched aapt v1 from apktool and replace the one in the sdk so that the plugin will pick it up (yes, a mess). sorry, these are all untested workarounds. i don't really have a lot of time for this for now. |
|
i suggest: before going deep into this issue, first check that the app you want to mod is not hardened with anti-tampering. first try simply resigning the app. some apps will query their own signature and fail to work (or work incorrectly) if the result is unexpected. AFAIK, a resigned app will always work unless it implements anti-tampering. next, try decoding and rebuilding with apktool. then sign and test. if it doesn't work, again, this is probably some anti-tampering at work. please report your progress |
|
Thanks for such details. Will definitely try to workaround it following your recommendations and will post my results asap (I already consumed most of the weekly time I dedicated to play with it). Dexpatcher reminds me the amazing Nokix tool, back from the early 2000's, used to patch Nokia DCT3 firmwares |
|
:) thanks! |
SOLUTION (for dexpatcher-gradle 2.0.0-alpha4)
i didn't test any of this, but it should work. if it doesn't, point to a nonexistent file from please report! |
|
Using the Android Gradle plugin 3.2.x, the build is still using the downloaded Unfortunately, using 3.3.2 along with the latest I'm sure he's picking the configuration, since pointing to an non-existing file instead of Using an empty (executable) Decompiling/building the APK using apktool is working flawlessly, thus I'm sure I'm using the right |
|
Looking at the stacktrace, it seems that the exception is not thrown by |
|
thanks! nice digging around.
most likely, 3.2.x doesn't know about the override.
the resources go though many stages in the process pipeline in dexpatcher, which is more complex than apktool. any one stage could check for filename validity. so we now know that the resource merger checks... tough luck. possibilities:
after merger, resources get to aapt2. btw, processing here didn't get to the point that aapt2 is invoked, so we don't know if the override trick works. dexpatcher uses incremental resource compilation and a separate resource linking step, and i don't know how apktool works or whether the patched aapt2 they provide. anyway, for now you can still try this workaround: |
|
|
|
Mmm... Interesting thought. Will try the apklib workaround and also deleting them. Will keep you posted, but can't wait for 2.0.0-beta 😉 |
|
i spent a long time planning for the move to per-tool gradle configurations to download the required tools at build time instead of relying on a local clone of both gradle and github have bugs that precludes them from working together and no side is fixing their code. the alternative (regular download tasks) is ugly and potentially inefficient. so i decided to scrap all the work and keep the :( |
|
FYI, i discuss your specific case here: #22 |
SUCCESS!!! :-)you need this reference: #21 (comment) |
|
OMG! I assume you tested it already? Will try at home this weekend! Congratulations! |
yes i did :) |
|
Almost there: Looking at the incriminated file, there's indeed a suspicious invalid style: ...
<item type="style" name="APKTOOL_DUMMY_9d">false</item>
</resources>Looks like an apk tool issue anyway. |
|
same error. mark first. |
yes, definitely. many obfuscation tools choke on malformed data that android never checks because maybe the resource is never referenced.
i made the whole .apklib thingy precisely as a way to manually intervene problematic stuff. you can generate an apklib (which in the dxp 2.x branch is basically just the zipped output of apktool so you can create it yourself or use my plugin) and mod it. how to do this "manual intervention to recreate the styles and/or remove them" is beyond this project and should be taken to apktool. sorry about that :( |
|
Yup. Thanks for the follow up. I guess you can close that issue! Great job! |
UPDATE: solution here |
Patching a 3rd party APK fails because of some "invalid" characters found in resource names. For example :
I've read the whole XDA post, and I understand that's an aapt limitation, but it's still not clear to me what's the official recommended workaround. I'm not interested in patching those resources (if any at all).
Any recommendation?
The text was updated successfully, but these errors were encountered: