解决MIUI8的冻结反弹

2016-12-27 本文已影响3102人何晓杰Dev

看到这个标题我觉得某司的程序员又要紧张一下了，怎么好不容易搞出了个冻结反弹又被人搞了。恩，要搞的就是这种流氓行为。

首先来看一下具体的现象，所谓的冻结反弹，就是当你使用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

解决MIUI8的冻结反弹

猜你喜欢

热点阅读