Hello, I recently encountered a problem. Android applications are compiled with confusion, sometimes there is a problem of variable duplicate names in the same domain (abnormal display at runtime).The problem disappears after a recompilation.
My question is why variables with different names appear duplicate names after code confusion? How to solve it? How to avoid similar problems in the future? Thank you very much.
Hi @jackkong1222,
Did you by any chance had the opportunity to look at ProGuard’s Troubleshooting guide? This issue is documented under “Note: duplicate definition of program/library class”, available on this page: ProGuard Manual: Troubleshooting | Guardsquare
From the manual;
Your program jars or library jars contain multiple definitions of the listed classes. ProGuard continues processing as usual, only considering the first definitions. The warning may be an indication of some problem though, so it’s advisable to remove the duplicates. A convenient way to do so is by specifying filters on the input jars or library jars. You can switch off these notes by specifying the
-dontnoteoption.
The standard Android build process automatically specifies the input jars for you. There may not be an easy way to filter them to remove these notes. You could remove the duplicate classes manually from your libraries. You should never explicitly specify the input jars yourself (with
-injarsor-libraryjars), since you’ll then get duplicate definitions. You should also not add libraries to your application that are already part of the Android run-time (notablyorg.w3c.dom,org.xml.sax,org.xmlpull.v1,org.apache.commons.logging.Log,org.apache.http, andorg.json). They are possibly inconsistent, and the run-time libraries would get precedence anyway.
Please let me know if anything is not clear or should this not be relevant to your question.
Kind regards,
Jonas
Thank you very much. Maybe because I didn’t describe it clearly, it seems that you didn’t understand my problem.
I define several variables in a class, for example: "public int ID; public int msg；”， However, after compiling, through the dex2jar and jd-gui decompilation, it is found that these two variables become “public int ID;”, And the application runs abnormally; Recompile again, the variable is no longer the same name, and the application runs normally.
My question is: why does the problem of variable duplicate name occasionally occur after confusion, and how to avoid it?
Hi @jackkong1222,
Can you please check your mapping.txt file generated by ProGuard to verify if these variables (or other parts of code) were assigned the same (obfuscated) name by ProGuard? If not, this seems more like a bug in either dex2jar or jd-gui.
Kind regards,
Jonas
So far, it has only happened once,The mapping.txt file was not output before, and the mapping.txt file was output later, The results are as follows:
// The first time:(in Mapping.txt):
int id → id
int cellX → nv
int msg → nx
//The second time:(in Mapping.txt):
int id → id
int cellX → ex
int msg → ez
The variable id is always id, so it is reasonable to suspect that the variable MSG is also confused with id when there is a problem. It should not be the problem of dex2jar or JD GUI. After all, the application displays an exception. Recompile once, and the application interface displays normally without any code changes.
My question is: Whether configuring “-useuniqueclassmembernames” can solve the problem, or whether there are other suggestions to ensure that the same problem will not occur in the future.
Kind regards,
Jack
Hi @jackkong1222 ,
There should not be duplicate variable names given by ProGuard. I understand that ‘int id’ will always remain as ‘id’ after obfuscation. But there should not be a case where both ‘int ID’ and ‘int msg’ both get renamed to ‘id’ after obfuscation. This is unexpected behavior for ProGuard.
As my colleague @jonas.gijbels said, please check your ProGuard mapping.txt file (if you have it) from that build, to verify that both ‘int id’ and ‘int msg’ got renamed to ‘id’ specifically by ProGuard. If no mapping file was produced for this build, it’s just not feasible for us to concretely verify it was ProGuard - or a different processing issue to blame. That said, from what I understand, this is not plaguing you anymore - and has not happened again - correct?
If you notice this behavior continues or does re-occur. please create a sample project for us on GitHub, so we can replicate the behavior, verify it’s ProGuard and implement a permanent fix from there.
Thank you very much!
Kindest Regards,
Jack