skylot / jadx

Dex to Java decompiler
Apache License 2.0
41.81k stars 4.88k forks source link

[core] generated resource names use capital letters #1043

Open hedwinkoning opened 3 years ago

hedwinkoning commented 3 years ago

Resource file names are created using a capital "RES_" as a prefix. From what I know capital letters are not allowed for resource file names.

From looking at the code using "RES_" is hardcoded in ./xmlgen/ResTableParser.java

jpstotz commented 3 years ago

Android Studio does not complain about resource names with capital letters. Also apps that use such resource names seem to work without problems, at least for those resources I have tested. Or may be this was an limitation of older versions of Android resource compiler?

anr2me commented 3 years ago

I had similar issue when opening a decompiled apk saved as gradle project, opened using Android Studio 4.1.1 with gradle 6.1.1 or newer

With "RES_" i'm getting this kind of error:

'R' is not a valid file-based resource name character: File-based resource names must contain only lowercase a-z, 0-9, or underscore

And also found this kind of error(unrelated to case-sensitivity) when trying to rebuild the decompiled apk: (might be to be similar issue with https://github.com/ThisIsLibra/AndroidProjectCreator/issues/9 )

\src\main\res\drawable-v21\$avd_hide_password__0.xml: Error: '$' is not a valid file-based resource name character: File-based resource names must contain only lowercase a-z, 0-9, or underscore

It's probably related to AAPT v2 https://github.com/DexPatcher/dexpatcher-gradle/issues/21

solarkraft commented 2 years ago

Hey, I'm using jadx 1.4.0 from homebrew with --export-gradle and face a similar issue - I get issues like the identifier "do" or "if" in a strings file (if is not a valid resource name (reserved Java keyword)) and names like tG.png ('G' is not a valid file-based resource name character: File-based resource names must contain only lowercase a-z, 0-9, or underscore).

Is there any good workaround for this? It seems like the naming rules can't easily be circumvented. Could this be an obfuscation/annoyance technique by the app's vendor?