Closed Lanchon closed 5 years ago
Thanks! Will look into that.
Would you be able to elaborate on the workaround of renaming the avd files? At which point in the build process should this be performed--to the source apk? If so, my apk in question has some resources in a binary resources.arsc file which have references to these files. I'm not aware of an easy way to edit an arsc file.
hi,
take a look at the apk-lib sample: one suproject produces an .apklib file and another consumes it. unlink the 2 projects by feeding the second project the apklib as a file (place it in directory apklib and it will be picked up by default). once you've done that, you can edit the apklib file: the resources are decompiled there. was this clear enough?
@eladkarako you are posting on an obsolete thread. which solution did not work? the linked solution is also obsolete. the proper solution is here: https://github.com/DexPatcher/dexpatcher-gradle/releases/tag/v2.0.0
the solution didn't worked for me and I even got the most recent aapt2 binary from https://maven.google.com/...
the solution works. if you are using binaries for google then you are not following the instructions. go back and reread the howto.
if you have an issue, please don't resurrect dead obsolete issues: create a new thread describing your particular issue.
UPDATE: solution here
so far this is caused by the same 6 files in all apps i've seen. i suppose these malformed files come from a google library.
these files are part of two very similar and complementary animated vector drawables:
1) avd_show_password
2) avd_hide_password
the problematic
$avd_(show|hide)_password__<n>.xml
files of these composite resources are never referenced from code. they are only referenced from their corresponding main resource filesavd_(show|hide)_password.xml
.this allows a simple workaround: you can manually rename the problematic files to make their names valid, along with their references in the main resource files. you can choose any names you want, but simply removing the dollar signs should be fine.
this workaround is a temporary stopgap measure. i'll be investigating ways to handle these corner cases in a more automated way.