嘿，针对你遇到的这个混淆APK逆向+客户侵权的问题，我来给你拆解下可行的解决方案，都是行业里常用的实操思路：

ProGuard混淆确实会把类名、方法名改成a/b/c这种无意义的命名，但不是完全没办法还原：

• 优先找ProGuard映射文件（mapping.txt）：这是最省心的办法！如果你们开发时没丢ProGuard生成的mapping.txt，直接把它导入反编译工具（比如JADX、Luyten），工具会自动把混淆后的代码还原成你们当初写的类名、方法名和变量名，几乎和原始代码一致。
• 没映射文件的话，只能半自动还原：
  • 用工具的智能重命名功能：像JADX、Luyten这类工具，会根据方法的参数、返回值、调用的SDK接口（比如支付、分享SDK）自动推测合理的名称，能省不少手动改的功夫。
  • 结合业务逻辑逆向：比如从Manifest里的Activity名称、strings.xml里的业务文案（比如“会员开通”“提交订单”），对应到混淆后的类，手动给关键的业务类、方法重命名——比如找到调用微信支付的混淆方法，直接改名叫wechatPay，方便后续验证。

说实话，dex2jar+JD-GUI已经是老组合了，现在有更高效的一站式工具：

• JADX：目前最火的Android逆向工具，直接把dex转成可读性极强的Java代码，支持导入mapping.txt反混淆，还能直接查看资源文件，不用像dex2jar那样先转jar再打开，效率高太多。
• Luyten：JD-GUI的升级版，支持更多反混淆选项，比如批量重命名、自定义规则，对混淆代码的还原效果比JD-GUI更出色。
• GDA（Android逆向助手）：国内开发的全能逆向工具，集成了反编译、动态调试、脱壳等多种功能，适合复杂场景，对混淆代码的分析支持也很全面。
• 轻量化资源处理工具：AXMLPrinter2：如果只需要处理Manifest或XML资源文件，它比apktool更轻便，能快速把二进制格式的XML转成明文。

你提到的验证思路非常靠谱，这里补充几个关键细节，确保能顺利拿到有效证据：

1. 反编译与修改步骤：
   • 执行命令反编译APK：apktool d 目标APK文件.apk
   • 找到反编译文件夹里的AndroidManifest.xml，删除目标Activity的整个声明代码块
   • 重新构建未签名APK：apktool b 反编译后的文件夹，生成的APK会在dist目录下
2. 签名与安装：
   • 必须使用你们开发时的原始密钥库签名，命令如下：

     jarsigner -verbose -keystore 你的密钥库文件.jks dist/生成的APK文件.apk 密钥别名
     

     只有签名与原应用一致，才能覆盖安装客户的应用（如果用调试签名，需要先卸载客户的应用，可能影响后续验证场景）。
3. 崩溃日志提取与反混淆：
   • 连接设备后，用命令过滤错误日志：adb logcat *:E，找到导航到被删除Activity时的崩溃堆栈轨迹，里面会显示混淆后的类名/方法名。
   • 若有mapping.txt，直接用ProGuard自带的retrace.sh（Windows用retrace.bat）工具反混淆：

     retrace.sh mapping.txt 崩溃日志文件.txt
     

     执行后就能得到原始的类名和方法名，直接对应到你们的源代码，这是最有力的侵权证据。
   • 若无mapping.txt，可以用Vaiden提供的反混淆方式（本地或在线工具），上传堆栈轨迹后，工具会根据常见混淆规则和代码特征尝试还原名称，但效果远不如使用mapping.txt理想。

内容的提问来源于stack exchange，提问作者Lars