问题描述
最近我们购买了搭载 Android 5.1.1 的新 Galaxy S6，但我们在使用它附带的新三星 SPCM 内存管理器时遇到了一些问题.它正在积极关闭我们应用程序的后台服务，即使设置为 START_STICKY，它也不会重新启动.
Lately we acquired a new Galaxy S6 with Android 5.1.1 and we are having some troubles with the new Samsung SPCM memory manager that comes with it. It is aggressively closing our app's background service, which even though is set to START_STICKY, it is not being restarted.
此外，该服务占用的 RAM 不超过 5MB，但我们仍然以某种方式最终获得 SPCM 算法的最低分数并被选择杀死.
Additionally, the service takes no more than 5MB of RAM, but still somehow we end up with the lowest score of the SPCM algorithm and gets chosen to be killed.
这是我们的服务:
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
}
}
在清单中:
<service
android:name="com.services.IncomingService"
android:enabled="true"
android:priority="999" >
</service>
SPCM 杀死我们服务的日志:
A log of SPCM killing our services:
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 日志指出它正在为我们的服务重新安排重新启动，但它实际上从未重新启动.
Even though the ActivityManager log states it is rescheduling a restart for our service, it never actually gets restarted.
我们已经看到有关其他应用(Facebook、TrueCaller 等)的相同 SPCM 日志，但他们的服务以某种方式设法重新启动.
We have seen the same SPCM logs regarding other apps (Facebook, TrueCaller, etc.) but their services somehow manage to restart.
总而言之，我们的问题是:
So to sum up, our questions are:
- 如何防止 SPCM 将我们的应用定位为最低分包?
- 如果我们被攻击了，如何确保我们的服务在被杀后能够成功重启?
- 还有其他可以帮助我们的想法吗?
推荐答案
我会尽力帮助您回答第三个问题:
I will try to help you answering your 3rd question:
我面临同样的问题，我发现的最佳解决方法是使用 AlarmManager 启动我的服务.所以我将 AlarmManager 设置为每 30 分钟运行一次并启动我的服务.如果它仍在运行，则将再次调用 onStartCommand，否则将重新创建服务.我对代码进行了一些调整，以每 30 分钟处理一次对 onStartCommand 的新调用，它按我预期的方式工作.缺点是电池消耗，因为我的服务始终在运行并且 Android 从未进入睡眠模式(仍在处理它).另一种方法是将您的服务设置为在前台运行，但在我的情况下，我不想这样做.
I'm facing the same issue and the best workaround I found is to use AlarmManager to start my service. So I set AlarmManager to run each 30 minutes and start my service. If it's still running, onStartCommand will be called again, otherwise service will be recreated. I did some adjustments in my code to deal with new calls to onStartCommand each 30 minutes and it's working the way I expected. The downside is the battery drain, since my service is always running and Android is never entering in sleep mode (still working on it). Another approach is to set your service to run in foreground, but in my case it's not I want to do.
您可以尝试禁用 SPCM，打开您的 build.prop 并更改以下行(需要 root):
You can try to disable SPCM, open your build.prop and change the following line (requires root):
sys.config.spcm_enable=true
到:
sys.config.spcm_enable=false
希望有帮助.
这篇关于对付三星SPCM杀手的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！