问题描述
我正在使用BOOT_COMPLETED广播事件调用以下内容:
I'm using the BOOT_COMPLETED broadcast event to call the following:
public class OnBootReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
Intent service = new Intent(context, ShakeEventService.class);
context.startService(service);
}
}
依次将其称为:
public class ShakeEventService extends Service {
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
sManager = (SensorManager) getSystemService(SENSOR_SERVICE);
sensor = sManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
sManager.registerListener(thisSensorEventListener, sensor, SensorManager.SENSOR_DELAY_NORMAL);
return Service.START_STICKY;
}
}
该类中还有许多其他功能,而从技术上讲一切正常,除了不管我返回什么标志(START_STICKY,START_STICKY_COMPATIBILITY,START_NOT_STICKY或START_REDELIVER_INTENT),该服务在两次之间的任何时间被杀死5和25分钟,直到下一次启动后才重新启动.
There are lots of other functions and whatnot within that class, obviously, and technically everything works fine, except that regardless of what flag I return (START_STICKY, START_STICKY_COMPATIBILITY, START_NOT_STICKY, or START_REDELIVER_INTENT), the service is being killed after anywhere between 5 and 25 minutes and doesn't re-initiate until the next boot.
我已经阅读了很多有关Android 4.2的文章,其中介绍了一些新的电池优化措施,这些措施可以消除后台进程,并且我阅读了各种错误报告,但START_STICKY不再起作用,但是各种解决方法似乎都无法解决任何问题我的情况有所不同.不知道我是尝试错误地实现它们,还是这些变通办法只是在较新的版本中停止了工作.我的测试设备正在运行5.1.1.
I've read a lot about Android 4.2 introducing new battery optimisations that kill off background processes, and I've read all sorts of bug reports with START_STICKY no longer working, but the various work-arounds seem to not be making any difference in my case. Not sure whether I'm attempting to implement them wrongly or if these workarounds have just stopped working in the more recent versions. My test device is running 5.1.1.
我在这里有些茫然,请再次提供帮助.
I'm at a bit of a loss here and would appreciate some help again please.
编辑对于陷入此问题的其他人,下面接受的答案包括一个有效的唤醒锁,该唤醒锁可使该服务在运行Android 5.1.1的Nexus 7和运行Android 6的LG G4上保持活动状态.
EDITFor anybody else stumbling into this problem, the accepted answer below includes a working wakelock that keeps the service alive on Nexus 7 running Android 5.1.1 and LG G4 running Android 6.
此外,在清单文件的android:process属性前加冒号似乎对于保持唤醒锁很重要.引用 http://developer.android.com/guide/topics/manifest/service-element.html
Additionally, prefixing the android:process attribute of the manifest file with a colon does seem important for keeping the wakelock in place. Ref http://developer.android.com/guide/topics/manifest/service-element.html
尽管在运行相同Android 5.1.1的Samsung S6 Edge上还算不上运气,所以看起来三星在其电池优化中实施了某些措施,导致了过早的死机..
Still no luck on a Samsung S6 Edge running the same Android 5.1.1 though, so it looks like Samsung implement something within their battery optimisations that's causing a premature kill..
推荐答案
您需要使用部分使用该服务的唤醒锁.如果您的服务与用户互动,则可以考虑使服务成为前台.
You need to use a Partial Wakelock with the service. If your service is interactive with the user, you might consider making the service foreground.
这是部分Wakelock的工作示例:
This is a working example for a Partial Wakelock:
在启动服务时使用它:
PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock cpuWakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, TAG);
cpuWakeLock.acquire();
服务停止后,请致电cpuWakeLock.release();
您需要导入支持库那个.
这篇关于使后台服务在Android上保持活动状态的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!