莫问天涯路几重,轻衫侧帽且从容。这篇文章主要讲述Android混淆总结篇相关的知识,希望能为你提供帮助。
Ⅰ.前言 上篇文章总结混淆相关的知识点,
基本的技术点都有罗列到。如果项目开发比较紧张,
可以考虑套用混淆配置的模板,
复制粘贴的基础上再修修补补. 上篇文章说到和朋友讨论的问题,
前几天也基本探究完了,
那么也得理理思路~总结总结,
期望有更多的问题出现~才可以去探讨.
Ⅱ.异常收集 上篇混淆知识点的总结文章写得还是挺完整的,
可点击查看 Android混淆总结篇(一)
这篇文章主要的技术点是异常收集,
项目上线前除了混淆、打包、加固、签名和发布等,
还有一项是无可避免的,
就是对线上的应用进行各种统计,
对应用进行各种统计包括异常的收集统计、应用的渠道下载率、活跃量、留存率和页面访问路径统计等等,
有很多第三方的统计SDK可供接入使用,
比如友盟+
、百度、诸葛IO 等第三方,
精细点的话可以考虑下无埋点技术等. 只要在上线前集成了统计SDK,
那么就可以在其相应的后台看到上线后各种数据的统计报表.
统计对于运营和项目维护还是很有必要的,
开发人员可以看到收集到的异常,
然后对异常进行分析并找到相应解决的方案,
那么这里就要开始文章的主题了,
下面的截图是友盟+
后台收集到的异常信息,
在其异常信息下面还可以收集到该异常发生的手机型号、版本和渠道。看下异常信息吧,
当看到红圈圈出来的部分,
是不是就迷惑了,
异常信息里怎么会有abc 这样的替代符,
本来异常信息可以让开发者清楚知道异常发生的地方,
可以使其轻易定位到,
但现在呢?难不成靠猜的方式去定位异常,
那就呵呵了.怪不得朋友说异常信息定位问题非常迷惑,
那么下面开始来整整这迷惑.
Ⅲ.还原混淆信息的方式
文章图片
针对上面的异常信息出现abc 的替代符, 主要是由于混淆打包导致的, 上面abc 其实是项目的类名或变量名的代替符, 那么如果apk没有经过混淆就会导致apk源码泄露或被二次打包, 虽说混淆了之后的apk还是很大风险会泄露, 但相对来说代码泄露的难度是增大了, 所以混淆是不可缺的。那么上面的异常信息又该如何定位Bug呢?
android SDK工具包就提供了解决的工具, sdk\\tools\\proguard\\bin路径下名为”proguardgui.bat”和”retrace.bat”(windows和linux下, 工具的后缀名不同)的两个工具, 前者是通过图形化的方式去将被混淆的异常信息反编译, 后者则通过命令行的方式将被混淆的异常信息反编译.那么在使用这工具前, 还得有一个叫”mapping.txt”的文件, 看下面截图, 这是在打包apk完成后生成的一个文件, 主要记录着混淆前后的信息映射关系。
文章图片
每次打包apk 完成后生成的mapping.txt 都是有必要保存的, 那怎么使用上面提到的 “proguardgui.bat”和”retrace.bat” 这两个工具呢? 看下面截图即可, 简简单单搞定proguardgui.bat ,但抱歉的是本人试了很多次, 都不能将异常信息转换回去, 而最无语的是搜索到的文章介绍的方法跟我操作的完全一样, 这时候我就发现了经常碰到的奇葩问题, 基本文章上演示截图的异常信息都是一样的, 尼玛这些文章的截图既然都是抄袭的, 难不成Android SDK提供的”proguardgui.bat” 图形化工具已经失效了, 接着试试”retrace.bat” 工具.上面也提到了 “proguardgui.bat”和”retrace.bat” 这两个工具基本是一样的, 只是使用方式不同, 一个是图形化方式, 一个则是命令行方式。
文章图片
在retrace.bat命令行工具里反编译异常, 使用的指令为
格式:
retrace.bat|retrace.sh [-verbose] mapping.txt [<
stacktrace_file>
]
例如:
retrace.bat -verbose d:/mapping.txt d:/wyk_stacktrace.txt
那么接着就验证下命令行形式的 “retrace.bat”, 并不同于上面的proguardgui.bat 工具有面板可以粘贴报错信息, 所以先把异常信息保存为txt文件, 然后命令行进入Android SDK存放的路径sdk\\tools\\proguard\\bin目录, 根据上面的指令格式进行输入, 结果如下:
文章图片
结论: ”proguardgui.bat”和”retrace.bat” 这两个工具包无法还原Apk线上被混淆的异常信息.
上面的截图就是使用”retrace.bat” 工具的反编译异常信息的结果, 可以看到abc 的标识符依然存在, 所以仍得不到完整的异常信息。反复试了很多次, 依旧无果, 还是找找有没有其他方式吧~~话说在Android SDK的sdk\\tools\\proguard\\lib目录下有”proguardgui.jar”和”retrace.jar” 这两个jar包, 上面使用到的”proguardgui.bat”和”retrace.bat” 这两个工具可能是基于这两个jar包的, 思考如果直接使用这两jar包尝试反编译异常信息的话是否有解。先试试retrace.jar 这个jar包, 命令行进入到jar包所在的目录, 在命令行输入如下指令, 输出的信息和上面的retrace.bat工具输出的一样, 依然没有完整的异常信息.
格式:
java -jar retrace.jar [-verbose] mapping.txt [<
stacktrace_file>
]
例如:
java -jar retrace.jar -verbose d:/mapping.txt d:/error.txt
接着试试proguardgui.jar, 命令行进入jar包所在的目录, 输入 “java -jar proguardgui.jar” 启动proguard工具, 看到的界面和proguardgui.bat 是一样的, 应该说proguardgui.bat 启动的也是这个jar包, 验证之后还是没有得到完整的异常信息.
结论: ”proguardgui.jar”和”retrace.jar” 这两个jar包无法还原Apk线上被混淆的异常信息.
Ⅳ.根据mapping.txt文件验证 【Android混淆总结篇】上面的工具可以还原被混淆的异常信息, 其原理是因为mapping.txt存在其混淆前后的映射信息, 那是不是可以根据被混淆的一小段异常信息在mapping.txt文件查找相应的映射关系, 拷贝被混淆的异常信息在mapping.txt文件进行全文搜索, 下面图1是收集在统计异常后台的信息, 图2是在mapping.txt文件查找图1红圈部分的映射信息.图3也是异常信息和映射关系.
文章图片
文章图片
文章图片
结论: 通过上面异常信息混淆前后的映射关系, 切记打包时将相应的apk和生成的mapping.txt进行对应保存, 这将对上线之后的Bug追踪和维护起着非常重要的作用;
Ⅴ.其他还原混淆异常信息的方式 上面根据mapping.txt查找信息映射关系的方式, 显然不适合线上Bug的追踪和应用的维护, 因此就得另找出口, 经常使用到的统计异常SDK有友盟+ 和Bugly, 早前一直都在用友盟+ 的统计异常SDK, 之后由于统计数据不及时和疏漏, 所以之后的应用选择接入Bugly, Bugly针对异常的收集还是非常及时和准确的。
这些统计异常的SDK其实都有提供还原被混淆异常信息的功能, 这样对开发者就非常友好了, 该功能的位置在SDK后台的异常信息上边, 只需要导入异常信息对应的应用版本的mapping文件, 点击”解析”按钮就可以看到原始的异常信息。
文章图片
文章图片
在友盟+ 的统计后台亲测发现, 被混淆的异常无法还原, 探究了几番仍找不到原因.而在Bugly的统计后台亲测是有效的, 可以看到下面被混淆的异常信息和还原之后的异常信息.
文章图片
Ⅵ.总结
- App线上异常的追踪, 可以选择友盟+ 、百度、诸葛IO等第三方, 精细点的话可以考虑下无埋点技术等;
- 经过测试发现, Android SDK包的”proguardgui.bat” 和”retrace.bat” 这两个工具包无法还原Apk线上被混淆的异常信息;
- Apk打包后生成的的mapping文件保存着代码混淆前后的映射关系;
- 第三方SDK的统计后台一般都提供还原 “被混淆异常信息” 的功能;
- 切记 打包时将apk版本和生成的mapping.txt进行对应保存.
推荐阅读
- Android Studio SugarORM No Such Table
- Android 优化APP 构建速度的17条建议
- 修改Delphi 10.1.2 edit控件在android的复制剪切和粘贴样式
- Android学习总结(十八) ———— SQLite数据库使用
- Android 自定义View 多片叶子叶子旋转滑动
- Retrofit+RxJava-在Android Studio中配置
- android 所有焦点问题--Focus
- C#装箱与拆箱介绍和用法示例
- C#字符结构用法介绍和示例