热更新Sophix的爬坑之路

写该篇博客就是为了总结下使用Sophix的过程中碰到的一些Bug及爬坑过程，希望各位极客还没碰到，看了我的回顾总结后能对可能出现的困惑有帮助。

爬坑之旅记录着我和Sophix技术支持团队的交流和探讨Bug过程。每个软件产品都会有Bug和待优化的地方，大胆怀疑和相信自己

Sophix与EMAS中的其他产品不一样，需要单独的进行稳健接入，使用EMAS的统一接入无效。

爬坑之路会 随着路程越远逐步完善

坑一：AndroidX 不兼容

开发环境

win10 + android studio 3.5.1 + gradle-5.4.1 + 设备API 5.1.1 + jdk1.8+ alicloud-android-hotfix:3.2.10

爬坑过程

这个Bug简单来说就是Sophix 3.2.10的使用的时候

• 不支持androidx，不支持生成patch初始化检查。
• 补丁在加载成功重启后，会出现资源查找不到的问题

Android5.1.1在进行resource 资源更新是就会报如图错误。

使用的Sophix热更新工具使用的是3.2.4版，此时是不支持Androidx的检查初始化。
​​

在2019.11，钉钉支持群说我是第一个使用Androidx进行热更新的，估计当时阿里对Sophix还未做大量的Androidx兼容测试。最终的解决方法是通过我的坚持，Sophix最终进行修改优化兼容Androidx。版本升级为3.2.12后支持了Androidx。心酸过程让我一一道来。

我这个人有升级狂魔症，经常喜欢升级依赖，Gradle、插件等，反正只要能更新的，能升级的我都要立马升级，更新，因此踩了不少的坑，碰到了不少的雷。本着我不入地狱谁入地狱的精神，依然一往无前，乐此不疲。 不扯远了，回正题。

首先，我发现将项目转为Androidx后，发现自己的Sophix不能正常工作了，app打完补丁就崩溃，于是各种测试，测试其他还未转androidx的项目正常。没办法只能求助全能的技术支持。

此时自己开始怀疑Sophix自身有问题，虽然Sophix是阿里的技术团队开发的，我也对它迷之自信，但是我的怀疑心战胜了崇拜心，大胆的猜测。 虽然技术支持坚称SDK不会有问题，但是我一直坚持自己的观点。


通过不断地多种测试，拿出我的多Gradle版本,多Android SDk版本的热更新测试，终于说服了Sophix 进行Androidx的兼容检查，最终发现 sophix 3.2.8之前的sdk确实不兼容android 5.0、5.1、 6.0的androidx apk进行热更新.


问题解决
OK,经过Sophix的工程师修复，Sophix 3.2.10升级到Sophix 3.2.12就能解决5.0，5.1,6.0 中安装了 Androidx的apk后，进行resource修复报错崩溃的bug。

总结

1. 常常看到阿里腾讯等大厂的产品我们就会觉得他们的产品肯定厉害，肯定没问题，其实这是个误解。 作为程序员大家其实是认同软件产品不能不存在Bug,好的和坏的就看bug率的多少了。 软件产品是一个逐步完善逐步修复bug完善的过程。
2. 对于任何开发中碰到的问题，我们要大胆的假设和猜测，不能根据自己的经验去认为不可能。
   一切皆有可能，何况我们大多数人还不是特级大神，我们需要怀疑需要假设，通过实际的排查和验证，才能排除不是那些因素造成了我们的问题。
   实践是检验一切真理的唯一标准

坑二：patch 补丁反复失效

这次碰到的Bug是补丁反复失效，具体症状是：补丁成功后，下次重启软件又恢复了原样，继续重启补丁成功，继续重启恢复原样。简直就是子子孙孙无穷尽也！

开发环境

1. win10+gradle-5.6.4+android studio 3.6.3 + 设备API 5.1.1+jdk1.8
2. ‘com.aliyun.ams:alicloud-android-hotfix:3.2.14’
3. 有个特殊的情况是，我的软件需要进行系统签名，制作成系统软件以便于软件的静默安装。生成的apk需要经如下文件签名，让程序获得系统级权限。
   
   系统签名还需在AndroidManifest.xml中配置android:sharedUserId="android.uid.system"

爬坑过程

首先进行相关因素排查，然后根据自己的进行假设，一步步验证排除假设直至找到最终真相。

1. 缓存清理

首先怀疑我进行了清缓存操作，于是我把各种自动清理垃圾缓存的代码操作屏蔽 和管理软件卸载，继续测试，Bug未解决，该Bug与缓存清理无关。
补充说明： 后面交流才知道patch的下载路径在/data/data/com.axecom.smartweightdj/files/sophix/patch(非系统签名app的路径，系统签名的下载路径我也没权限看不到啊)。

2. MultiDex不正常
各种日志分析测试，发现apk中有多个.dex文件，怀疑MultiDex失败的问题。我的apk中有7个.dex文件，后面几个.dex文件方法数只有几百个。 一般来说只有方法数超过65535，才会有两个.dex文件，后面依次计算，超过65535*2才会有3个.dex文件。

技术支持小哥让我生成正常的apk,这可难倒我了，找不出我的apk生成多个.dex文件的原因，，我只能笨办法，重建工程把内容以过去，好了，发现apk正常了，只有了2个.dex文件。



满心欢喜的以为搞定了，测试看看。我去，bug还是没解决，依然存在。

3. System.exit(0)
继续测试找背锅侠。在关闭的过程中，有System.exit(0)这个操作，好吧会不会是它造成的，我猜一般应该和这个没关系吧。

果然屏蔽了System.exit(0)方法后，Bug还是没有解决。继续其他猜想。
关于System.exit(0) 与 android.os.Process.killProcess(android.os.Process.myPid())的使用和区别，请查看我其他博客的分析介绍。博客地址待补充，文章已写完还未发布

4. patch补丁是否加载正常
没办法，同样一个补丁，Sophix是不会不断下载同一补丁的，那么实时观察它的状态吧。

此时不尝试获得两个总结：
1.为了能看到data\data\package中的patch文件，我取消了系统签名，发现补丁竟然成功了。
2.非系统签名app,如果系统未root，一般也看不到data\data\package中的信息，此时只能通过配置debuggable true，此时我们能通过 看到data\data\package中的数据。
意外惊喜是非系统签名的app debuggable=true时， 补丁能正常。此时能看到data\data\package中的内容

赶紧测试debuggable=false时，补丁也能正常。此时权限问题无法看到data\data\package中的内容

在这里插入图片描述
3我的bug造成的原因肯定和系统签名有关系

5. 系统权限
通过长长的详细Verbose级日志，分析到:合成的补丁 ，新的补丁加载可以成功，合成的补丁 拒绝执行denied execute。如果apk不经系统签名，不会有该问题，所以定位可定是系统权限哪里的问题。

我们使用Android studio能看到的日志条数一般是有限制的，为了不得漏掉日志，建议使用 adb log技术，使用如： adb logcat -s :V > d:/999.log 。详细使用方式网上搜索会更详细。

经过努力已经查找出system app进行Sophix热更新的补丁反复失效的原因，这和系统权限确实有关系，将enforce设置为0 ，也就是降低Android系统的一些安全要求，放款权限限制。

通过对比system app 和普通app的sophix的patch补丁文件夹。
system app

如下是普通app的

此时你会发现两者的RW权限是一样的，patch也从后台下载了。但是最终System app不能成功，是因为系统的安全限制作怪，设置setenforce 0即可解决问题。

注意：System App的目录我们看不到，可以通过adb shell 进入通过shell命令查看文件夹详细信息

问题解决：
bug源码解决了。这个bug折磨了我一个周的时间去整理和排除，可谓是伤透了心。

我的这个Bug一般人是碰不到的，需要系统签名的软件才会碰到如此问题,希望你们不会碰到，截止20200516，我所知道能让系统签名的app也支持Sophix的只有让Android 系统 setenforce 0 降低安全标准了。

坑三：abandon initialization: callRealAppAttach

这种问题比较简单，在低Android系统中，当Apk中的方法数量超过限制时，就需要使用MultiDex技术。该处报错就是因为未配置MultiDex.install(this)， SophixStubApplication和RealApplication两个Application没在一个dex中引起的，只要正确配置即可解决。
​​

注意这个问题的 MultiDex.install(this)要在SophixStubApplication.java文件中，其他Application中不得有 MultiDex.install(this)。

总结

1. 其实生成了多个.dex的原因是：设置了 debuggable= true，此时生成了7个.dex文件，debuggable= false时生成的apk有2个.dex文件。

2. 这个Bug其实与debuggable的设置其实毫无关系，也即与.dex的多寡无关。这是后面经过我多次测试终于明白的。`**

3. 碰到技术bug能耐下心来去研究，排查，网上搜资料，始终能解决问题的。

4. 我的这个Bug的唯一解决方式是系统要root,或者将patch下载到外部空间如public\download中(但是Sophix现在是不支持修改设置patch下载地址的)

补充知识点

1. enforce

**enforce:**加强，这里指 security enforce安全加强，也就是SELinux，setenforce 0就是表示关闭SELinux（Linux的防火墙）的加强模式
当我们设置setenforce 0 后，可以通过shell 命令getenforce可以看到设置状态。显示permissive即为防火墙关闭了。

0： 切换成 permissive（宽容模式）
1： 切换成 enforcing（强制模式）

2.Root

Android系统本质就是一个Linux 系统，Linux系统的强大在于多用户管理，对于不同的用户给不同的权限，Linux系统里面有一个超级用户，叫做su。
如果你能获取su用户执行的命令，那你就获得了超级用户权限。对于系统自带的文件和apk可见，并且能进行删除和修改操作。

结语

• 首先要感谢自己的持之以恒，碰到的bug和爬坑过程，时间跨度在一个星期和一个多月。中间要做各种测试操作和验证，补充相关论点支持，每次自己都未有想放弃的想法，虽然头疼还是坚持排查最终也得到了解决。

• 非常感谢Sophix的技术支持@涂中和@徐厚、@刘宝文，这些Sophix的技术支持团队非常的有耐心，对于技术疑惑回答都很及时且对提问者的问题都是有问必答比解决。非常敬佩他们的敬业精神，果然觉得阿里的招牌不是盖的。

• 我在热更新方向是从Bugly平台转到EMAS的，两者的技术高低暂且不论，技术支持方面是高低立下的，真的建议大家更偏向Sophix,少踩Bugly的坑，在我的博文《热更新你都知道哪些？》会分析为什么优先使用Sophix 。