看到这个标题我觉得某司的程序员又要紧张一下了，怎么好不容易搞出了个冻结反弹又被人搞了。恩，要搞的就是这种流氓行为。
首先来看一下具体的现象，所谓的冻结反弹，就是当你使用pm disable使一个 APP 处于冻结状态后，重启手机，APP 自动解冻了。典型的例子就是 MIUI 内置的音乐、视频等。另外还有删除指定 APP 重启就卡 MIUI Logo 不能进系统的，这对于取了 root 想自己改改系统的人来说，简直不可忍。
那么废话不多说，直接来看解决方案，可靠的解决方案有三种，BOOT_COMPLETED消息，修改service.jar/service.odex，使用Xposed动态修改。
方法一
第一种是最简单的，维护一个列表，当有 APP 被冻结或解冻时，即修改列表内成员，在随后的重启过程中，接收BOOT_COMPLETED消息，并对列表内的 APP 再次进行冻结，具体的代码是这样的：
class BootReceiver : BroadcastReceiver() {
companion object { var inited = false }
override fun onReceive(context: Context?, intent: Intent?) {
if (!inited) {
inited = true
val pref = context?.getSharedPreferences(XpStatus.PREF, 0)
if (pref!!.getBoolean(XpStatus.KEY_PREVENT_FREEZE_REVERSE, false))
context?.startService(Intent(context, FreezeService::class.java))
}
}
}
class FreezeService : Service() {
override fun onBind(intent: Intent?): IBinder? = null
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
thread { NativeAPI.freezeOnLoad() }
return super.onStartCommand(intent, flags, startId)
}
}
同时改一下 AndroidManifest.xml 就好：
<service android:name=".FreezeService"/>
<receiver android:name=".BootReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
</intent-filter>
</receiver>
这个情况下，会遇到两个坑，其一就是在 MIUI 上，必须允许这个 APP 自启，同时它也不能被绿色守护，阻止运行等 APP 管理，否则会收不到BOOT_COMPLETED消息；第二个坑也是在 MIUI 上，BOOT_COMPLETED收到的时机问题，有可能是在手机启动后 1 分钟才收到该消息，于是就会出现用户以为 APP 自动解冻了，但是过了一阵子那个 APP 又消失(被冻结)了，给用户非常不好的体验。
第一个问题，无解，这是小米所设计的机制，绕不过去，可能对于部分用户来说，好不容易能把 APP 的自启都干掉了，结果对于这个 APP 又要给自启权限，非常的不爽。第二个问题在 6.0 和以下版本的 MIUI 中是可以解的，解法就是加入对AUDIO_BECOMING_NOISY消息的监听：
<receiver android:name=".receiver.BootReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
</intent-filter>
<intent-filter>
<action android:name="android.media.AUDIO_BECOMING_NOISY"/>
</intent-filter>
</receiver>
AUDIO_BECOMING_NOISY发送的时机远比BOOT_COMPLETED更早，在桌面启动前，就可以收到这个消息，在此处进行对 APP 的重新冻结是靠谱的。但是需要注意的是，Android N以后，启动时不再发送此消息，因此这个做法在 Android N 为基础的 MIUI 上是无效的。
同时也再说一句，同样是 Android，CM 的 ROM 就不会有BOOT_COMPLETED延迟，也无需进行允许自启这样的操作。
方法二
直接修改service.jar/service.odex也是个不错的方案，反正都已经获取到 root 了，可以随意替换。最终修改的是 jar 还是 odex，取决于你从 ROM 里面拿到的文件是哪个，它们基本上没差别。
为了方便起见，我直接给出反编译后的 java 代码，可以参照着修改 smali 代码：
package com.miui.server;
... ...
public class SecurityManagerService extends Stub {
... ...
private void checkSystemSelfProtection(final boolean onlyCore) {
... ...
while (i$.hasNext()) {
SecurityManagerService.this.checkEnabled(pm, (String) i$.next());
}
... ...
if (!(Build.IS_INTERNATIONAL_BUILD || Build.IS_CM_CUSTOMIZATION || Build.IS_CM_CUSTOMIZATION_TEST)) {
SecurityManagerService.this.enforceAppSignature(platformSignature, "com.xiaomi.market", false);
}
... ...
if (!SecurityManagerService.this.checkSysAppCrack()) {
i = 0;
}
... ...
}
... ...
}
代码太长，就贴这些关键的，它们完成了对已冻结 APP 的重新启用，和对于删除市场后直接卡 MIUI Logo 的处理，不得不说，这些代码实在是恶心。
在 smali 内，可以将checkSystemSelfProtection方法整个置空，或是修改checkEnabled，enforceAppSignature，checkSysAppCrack这三个函数，删除函数体，或是使其返回你要的值。完成后重新打包，并替换回系统的 framework 内即可。
使用这个方法的坑在于，如果系统更新了，你就必须重新做这一系列步骤，当然这一块代码可读性还是比较强的，过于底层的东西很难进行混淆处理，改起来比较方便。
方法三
最终，最完美的方法还是要借助 Xposed 框架，一劳永逸的解决这些问题，不多说，直接给代码了：
if (param.packageName == "android"
|| param.packageName == "com.miui.system"
|| param.packageName == "miui.system") {
val clsSMS = XpUtils.findClass(param.classLoader, "com.miui.server.SecurityManagerService")
if (clsSMS != null) {
XpUtils.findAndHookMethod("com.miui.server.SecurityManagerService", param.classLoader, "checkSysAppCrack", XC_MethodReplacement.returnConstant(false))
XpUtils.findAndHookMethod("com.miui.server.SecurityManagerService", param.classLoader, "checkEnabled", PackageManager::class.java, String::class.java, XC_MethodReplacement.returnConstant(null))
XpUtils.findAndHookMethod("com.miui.server.SecurityManagerService", param.classLoader, "enforcePlatformSignature", Array<Signature>::class.java, XC_MethodReplacement.returnConstant(null))
}
}
现在，又可以享受冻结不会反弹的 MIUI 了。
后记：
其实在研究的过程中，踩过的坑远远不止这三种，Xposed 还有以下的大坑，开发时需注意：
- 不能使用对应 APP 内的 JNI 库，因为不在同一进程，如果非要用的话，必须事先将对应架构的 JNI 库置入
/system/lib或/vendor/lib内 - 不能在Xposed 内调用 su，因为 Xposed 执行的时候，su 所对应的上层应用还没准备好，因此 root 请求会被直接拒绝，从而产生一个 permission denied 异常
- 不能在 Xposed 内访问 APP 所对应的 /data/data/ 内的数据，Xposed 进程并没有这样的权限，甚至简单的判断文件是否存在都只会返回 false
