android - 对付三星SPCM杀手

最近，我们购买了搭载 Android 5.1.1 的新 Galaxy S6，但我们在使用它附带的新三星 SPCM 内存管理器时遇到了一些问题。它正在积极关闭我们应用的后台服务，即使设置为 START_STICKY，它也不会重新启动。

此外，该服务占用的 RAM 不超过 5MB，但我们仍然以某种方式最终获得 SPCM 算法的最低分数并被选择杀死。

这是我们的服务:

Public class IncomingService extends Service {

    @Override
public int onStartCommand(Intent intent, int flags, int startId) {
    super.onStartCommand(intent, flags, startId);
    return START_STICKY;

}

@Override
public void onCreate() {
    if (mPhoneListener == null) {
        mPhoneListener = new CallStateListener();
        TelephonyManager tm = (TelephonyManager) getApplicationContext().getSystemService(Context.TELEPHONY_SERVICE);
        tm.listen(mPhoneListener, PhoneStateListener.LISTEN_CALL_STATE);
}

    /**
 * Listener for call states
 * Listens for different call states
 */
private class CallStateListener extends PhoneStateListener {

    @Override
    public void onCallStateChanged(int state, String incomingNumber) {
       // Doing something with incomingNumber
    }
}

在 list 中:

    <service
        android:name="com.services.IncomingService"
        android:enabled="true"
        android:priority="999" >
    </service>

SPCM 杀死我们服务的日志:

Force stopping com.special.app appid=10499 user=0: SPCM kill lowestscore package!
03-18 22:48:11.280 3562-3562/? I/ActivityManager: Killing 2279:com.special.app/u0a499 (adj 8): stop com.special.app cause SPCM kill lowestscore package!
03-18 22:48:11.280 3562-3562/? W/ActivityManager: Scheduling restart of crashed service com.special.app/com.services.IncomingService in 1000ms
03-18 22:48:11.280 3562-3562/? I/ActivityManager:   Force stopping service ServiceRecord{27d2c408 u0 com.special.app/com.services.IncomingService}

即使 ActivityManager 日志声明它正在为我们的服务重新安排重新启动，但它实际上从未重新启动。

我们已经看到有关其他应用程序(Facebook、TrueCaller 等)的相同 SPCM 日志，但他们的服务以某种方式设法重新启动。

总结一下，我们的问题是:

如何防止 SPCM 将我们的应用定位为最低分包？

如果我们被攻击了，如何保证我们的服务在被杀后能成功重启？

还有其他可以帮助我们的想法吗？

最佳答案

确保 ActivityManager is not targeting your service too 。

AFAIK 除了持续通知之外，没有其他方法可以确保生存，这也是三星的开发人员文档所述。至于 Facebook 和 TrueCaller，我没有答案。可能他们利用其他相关流程来恢复服务。

至于受影响的设备，我最早看到的是 5.0.2 的 Galaxy Tab S SM-T805。许多 5.1.1 三星设备也有 SPCM。我们最初也在 S6 上重现了这个问题，我可以确认它仍然存在于 6.0.1 上。

至于文档， this Samsung forums topic 尽可能。

对于测试和复制步骤，我建议:

确保设备实际上具有 SPCM adb shell getprop | grep spcm 。

将其从任何电源上拔下。

安装 Tinycore 以观察 RAM 使用情况(为其启用持久通知)。

加载大量占用内存的应用程序以降低您的服务分数。或者试试 Developer Toolbelt ，它应该比手工填充更快，但我还没有测试过。

关闭屏幕并给设备 15 分钟。

adb shell logcat -v threadtime | grep spcm 确认进程被杀死。

冲洗并重复直到成功。