Hot update Sophix's pit climbing road


The purpose of writing this blog is to summarize some of the bugs and pit crawls encountered in the process of using Sophix. I hope that all geeks have not encountered them. After reading my review and summary, it will be helpful for possible confusion.

The pit-climbing journey records the process of communicating and discussing bugs between me and the Sophix technical support team. Every software product will have bugs and areas to be optimized, so be bold in doubting and believing in yourself

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

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

Pit 1: AndroidX is not compatible

Development environment

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

Climbing process

This bug is simply when Sophix 3.2.10 is used

  • Androidx is not supported, and patch initialization checks are not supported.
  • After the patch is successfully loaded and restarted, there will be a problem that resources cannot be found

Android 5.1.1 will report an error as shown in the figure when it is updating resource resources.
Insert picture description here
The Sophix hot update tool used is version 3.2.4. At this time, the check initialization of Androidx is not supported.
​​Insert picture description here

In 2019.11, the DingTalk support group said that I was the first to use Androidx for hot updates. It is estimated that at that time Ali had not done a lot of Androidx compatibility tests on Sophix. The final solution is through my insistence, Sophix finally modified and optimized compatible with Androidx. After upgrading to 3.2.12, Androidx is supported. The sad process let me come one by one.

I’m a person with upgrade madness, and I often like to upgrade dependencies, Gradle, plugins, etc. Anyway, as long as I can update, I have to upgrade and update immediately, so I stepped on a lot of pits and encountered a lot of thunder . In the spirit that I will not go to hell who will go to hell, I still go forward and enjoy it. Not far, back to the topic.

First of all , I found that after converting the project to Androidx, I found that my Sophix was not working properly, and the app crashed after patching, so various tests, testing other projects that have not been converted to androidx were normal. There is no other way but to ask for all-around technical support.
Insert picture description here
At this time, I began to suspect that Sophix itself had problems. Although Sophix was developed by Ali's technical team, I was also confident in it, but my skepticism defeated the admiration and bold speculation. Although the technical support insists that there will be no problems with the SDK, I have always insisted on my opinion.
Insert picture description here
Insert picture description here
By constantly a variety of tests, I come up with more Gradle version, and more Android SDk test version of the hot update, finally persuaded Sophix be Androidx compatibility check, found sophix 3.2.8之前的sdk确实不兼容android 5.0、5.1、 6.0的androidx apk进行热更新.
Insert picture description here
Insert picture description here
the problem solved
OK, after Sophix engineers repair, Sophix 3.2.10 Upgrading to Sophix 3.2.12 can solve 5.0, 5.1, 6.0 after the Androidx apk is installed, and the resource is used to fix the error and crash bug.

to sum up

  1. We often see the products of major manufacturers such as Alibaba and Tencent, and we feel that their products must be great and there must be no problem. In fact, this is a misunderstanding. As programmers, everyone actually agrees that software products must have bugs. The good and bad depends on the bug rate. Software products are a process of gradually improving and fixing bugs.
  2. For any problems encountered in development, we have to make bold assumptions and guesses, and we cannot think that it is impossible based on our own experience.
    Everything is possible, not to mention that most of us are not super gods. We need to suspect that we need to assume, and through actual investigation and verification, we can rule out that it is not those factors that caused our problems.
    实践是检验一切真理的唯一标准

Pit 2: Patches repeatedly fail

The bug encountered this time is that the patch repeatedly fails. The specific symptoms are: after the patch is successful, the software will be restored to the original state after the next restart, and the patch will be successfully restarted, and the restart will be restored to the original state. It is simply endless for descendants!

Development environment

  1. win10+gradle-5.6.4+android studio 3.6.3 + device API 5.1.1+jdk1.8
  2. ‘com.aliyun.ams:alicloud-android-hotfix:3.2.14’
  3. There is a special case that my software needs to be signed by the system and made into system software to facilitate the silent installation of the software. The generated apk needs to be signed by the following files to allow the program to obtain system-level permissions.
    Insert picture description here
    The system signature also needs to be configured in AndroidManifest.xmlandroid:sharedUserId="android.uid.system"

Climbing process

First, check the relevant factors, and then make the hypothesis based on your own, step by step to verify the exclusion hypothesis until you find the final truth.

1. Cache cleaning
Insert picture description here
First of all, I suspected that I had performed a cache cleaning operation, so I shielded the various code operations that automatically clean up the garbage cache and uninstalled the management software, and continued to test Bug未解决,该Bug与缓存清理无关.
Supplementary note: 后面交流才知道patch的下载路径在/data/data/com.axecom.smartweightdj/files/sophix/patch(非系统签名app的路径,系统签名的下载路径我也没权限看不到啊)。

2. MultiDex is abnormal.
Various log analysis tests found that there are multiple .dex files in the apk, and it is suspected that MultiDex failed . There are 7 .dex files in my apk, and there are only a few hundred methods for the following .dex files. Generally speaking, only if the number of methods exceeds 65535, there will be two .dex files, and then calculated in turn, there will be 3 .dex files if the number of methods exceeds 65535*2.
Insert picture description here
The technical support guy asked me to generate a normal apk. This is stumping me. I can’t find the reason why my apk generates multiple .dex files. I can only do a stupid way to rebuild the project and use the content in the past. Okay, It is found that the apk is normal, and there are only 2 .dex files.
Insert picture description here
Insert picture description here
Insert picture description here
I was so happy that I thought it was done, so I tested it. I bug还是没解决,依然存在go .

3. System.exit(0)
continues to test and find Back Pot Man. In the process of shutting down, there is an operation System.exit(0). Okay, could it be caused by it? I guess it should have nothing to do with this.
Insert picture description here
Sure enough, after shielding the System.exit(0) method, the bug is still not resolved. Continue other conjectures.
Regarding the usage and difference between System.exit(0) and android.os.Process.killProcess(android.os.Process.myPid()) , please check the analysis introduction of my other blogs.博客地址待补充,文章已写完还未发布

4. Is the patch loaded normally?
No way, for the same patch, Sophix will not download the same patch continuously, so observe its status in real time.
Insert picture description here
Do not try to get two summaries at this time:
1. 为了能看到data\data\package中的patch文件,我取消了系统签名,发现补丁竟然成功了。
2. The 非系统签名app,如果系统未root,一般也看不到data\data\package中的信息,此时只能通过配置debuggable true,此时我们能通过 看到data\data\package中的数据。
unexpected surprise is that when the non-system signed app debuggable=true, the patch works normally. At this point, you can see the content in data\data\package. When
Insert picture description here
debuggable=false is tested quickly, the patch can also be normal. At this time, the permission problem cannot see the content
Insert picture description here
in data\data\package. Insert picture description here
3我的bug造成的原因肯定和系统签名有关系

5. The system of privileges
through long and detailed Verbose-level logging, analysis to: 合成的补丁 ,新的补丁加载可以成功,合成的补丁 拒绝执行denied execute. If the apk is not signed by the system, there will be no such problem, so the positioning can be determined by the system permissions.

The number of logs that we can see using Android studio is generally limited. In order not to miss the logs, it is recommended to use adb log technology, such as: adb logcat -s :V> d:/999.log. Detailed usage will be more detailed when searching online.

After hard work, we have found the reason why the system app’s Sophix hot update patch repeatedly fails. This is indeed related to the system permissions. Setting the enforce to 0 means reducing some of the Android system’s security requirements and loan permission restrictions.

By comparing the sophix patch folder of system app and ordinary app.
The
Insert picture description here
following system app is a normal app.
Insert picture description here
At this point, you will find that the RW permissions of the two are the same, and the patch is also downloaded from the background. But in the end, the System app could not succeed because of the security restrictions of the system. Setting setenforce 0 can solve the problem.

注意:System App的目录我们看不到,可以通过adb shell 进入通过shell命令查看文件夹详细信息
Insert picture description here

Problem solving: The
bug source code has been solved. This bug took me a week to sort out and eliminate it, and it was heartbreaking.

This bug of mine cannot be encountered by ordinary people. Software that requires system signatures will encounter such problems. I hope you will not encounter such problems. As of 20200516, I know that apps that can be signed by the system also support Sophix. Only the Android system setenforce 0 lowers safety standards.

Pit three: abandon initialization: callRealAppAttach

Insert picture description here
This kind of problem is relatively simple. In a low Android system, when the number of methods in Apk exceeds the limit, MultiDex technology is required. The error is reported because MultiDex.install(this) is not configured, and the two applications SophixStubApplication and RealApplication are not in the same dex. It can be resolved as long as the configuration is correct. Note that this problem MultiDex.install (this) to be in SophixStubApplication.java file, other Application shall not have MultiDex.install (this).
Insert picture description here
Insert picture description here

to sum up

  1. In fact, the reason for generating multiple .dex is: set debuggable=true, then 7 .dex files are generated, and the apk generated when debuggable=false has 2 .dex files.

  2. This bug has nothing to do with the debuggable setting, that is, it has nothing to do with the amount of .dex. This is what I finally understand after many tests. `**

  3. When you encounter technical bugs, you can study, investigate, and search information online, and you can always solve the problem.

  4. The only solution to my bug is to root the system or download the patch to an external space such as public\download ( 但是Sophix现在是不支持修改设置patch下载地址的)

Supplementary knowledge

1. enforce

**enforce:**Enhanced, here refers to security enforced security, that is SELinux, setenforce 0 means to turn off SELinux (Linux firewall) enhanced mode.
After we set setenforce 0, we can see the setting status through the shell command getenforce . If permissive is displayed, the firewall is closed.
Insert picture description here
0: Switch to permissive (permissive mode)
1: Switch to enforcing (forced mode)

2.Root

The Android system is essentially a Linux system. The power of the Linux system lies in multi-user management. Different users are given different permissions. There is a super user in the Linux system called su.
If you can get the commands executed by the su user, then you have super user privileges. It is visible to the files and apk that comes with the system, and can be deleted and modified.

Conclusion

  • First of all, I would like to thank myself for perseverance, the bugs encountered and the process of crawling pits, the time span is one week and more than one month. Various test operations and verifications were to be done in the process, and relevant arguments were added to support. Every time I did not want to give up the idea, despite the headache, I insisted on investigating and finally solved it.

  • Thank you very much for Sophix's technical support @涂中和@徐厚, @刘宝文. These Sophix technical support teams are very patient, answering technical doubts in a timely manner and answering all questions of the questioner. I admire their professionalism very much, and I really feel that Ali's signature is not covered.

  • My hot update direction is from the Bugly platform to EMAS. Regardless of the technical level of the two for the time being, the technical support is high and low. I really recommend that you prefer Sophix and step less on Bugly. In my blog post " What do you know about hot updates? "We will analyze why Sophix is ​​preferred.

Guess you like

Origin blog.csdn.net/luo_boke/article/details/106145150