谈谈 模块与Hide 之间的关系

在Magisk Lite刚完工时，自然测试了一番模块功能，并且得到匪夷所思的结果，有不能理解的行为异常。

从理论上看，对zygote卸载所有模块的文件，与对app卸载所有模块的文件，它们并没有技术上的区别。对app进程来说，这些文件在文件系统上均从一开始就不存在。但事实说明，事情没有这么简单。

在常规Magisk，能正常使用overlay app更改framework的资源，在lite则直接翻车。这个问题的原因很幸运地找到：日志中出现大量无法打开/product/overlay/abc.apk的错误，在打开任意app时触发。

很明显，在zygote fork并转化成app时，如果需要读取模块文件，会找不到然后翻车。这个日志表明，overlay app会在这个时候被读取一遍，载入进程内存。因为这个overlay app的target app是android，所以全部应用都需要载入它。除非某个应用完全不使用framework的资源，这是不可能的。

这个问题分析完了，链条很清晰：zygote fork后加载app→app依赖framework资源→加载framework→加载目标是framework的overlay→找不到。

这应该是lite使用模块后各种奇怪问题中最好分析的一个。它引出一些有意思的问题：

对常规Magisk来说，卸载模块的时机在哪一步？常规Magisk在UID改变并且挂载命名空间分离后立即卸载挂载，这时应用还没有加载完成，没有出现同样问题是时机刚好吗？
如果在运行时主动检索某个包的资源，而目标是这个包的overlay已经不存在，会怎么样？
zygote已经加载过framework和它的overlay，为什么要加载第二次？
这些问题需要研究源代码和实验才能解答。

说到底，Android的设计是apk的资源都是共享的，某个已安装应用的apk消失不可能不出问题。我也一再倡议，转系统应用的模块，应该放低版本apk，最好是stub，然后正常更新。

在我看来，MagiskHide实在是个危险的东西，不论从原理，还是其实现方式。仅仅把卸载时间提前一点，行为就完全不可控。或许只有修改不被载入app内存，不被app运行时读取的文件，才是安全的。