【问题标题】:need an android service to run always需要一个 android 服务才能始终运行
【发布时间】:2015-11-09 20:49:25
【问题描述】:

我已经搜索了很多,但我仍然无法找到解决方案

我在 onStartCommand 中有一个返回 Start_Sticky 的服务,它会在服务的 onDestroy 方法中自行启动。我认为这已经足够了,因为我的服务将被用户停止,因此将调用 onDestroy 方法。或者被android停止了,然后因为Start_Sticky,android会在kill之后重新创建,但是android在kill之后并没有启动我的服务。

所以我使用 AlarmManager 类注册广播接收器,然后在 onReceive 方法中启动我的服务,但似乎手机进入睡眠模式后,onReceive 方法不会再次被调用。我什至尝试过使用唤醒锁

无论如何,问题是如何使服务始终运行或在停止后重新创建自身,例如电报或 instagram 服务

这是我的服务:

public final class MyService extends Service {

    @Override
    public void onCreate() {
        super.onCreate();
        //some stuff

        AlarmManager am = (AlarmManager) getApplicationContext().getSystemService(Context.ALARM_SERVICE);
        Intent ii = new Intent(getApplicationContext(), MyReceiver.class);
        PendingIntent pi = PendingIntent.getBroadcast(getApplicationContext(), 12345, ii, 0);
        if (android.os.Build.VERSION.SDK_INT < android.os.Build.VERSION_CODES.KITKAT)
            am.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 1 * 60 * 1000, pi);
        else
            am.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 1*60*1000, pi);
    }

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

    @Override
    public synchronized void onDestroy() {
        startService(new Intent(ACTION_MAIN).setClass(context, MyService.class));
        super.onDestroy();
    }
}

这是我的接收器:

public class MyReceiver extends BroadcastReceiver {

    @Override
    public void onReceive(final Context context, Intent intent) {
        //WakeLocker.acquire(context);

        context.startService(new Intent(ACTION_MAIN).setClass(context, MyService.class));

        if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.KITKAT) {
            AlarmManager am2 =( AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
            Intent i = new Intent(context, MyReceiver.class);
            PendingIntent pi = PendingIntent.getBroadcast(context, 12345, i, 0);
            am2.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 1*60*1000, pi);
        }
        else
        {
            AlarmManager am2 =( AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
            Intent i = new Intent(context, MyReceiver.class);
            PendingIntent pi = PendingIntent.getBroadcast(context, 12345, i, 0);
            am2.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 1*60*1000, pi);
        }
    }
}

编辑: 好的,我有一个更简单的问题 为什么这个简单的服务在 android 杀死它后没有重新创建? 我在活动中使用 startService 启动服务,但大约 20 分钟后,我的服务在正在运行的任务中消失了……这是为什么呢?

public class NotificationsService extends Service {
    @Override
    public void onCreate() {
        super.onCreate();
    }

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

    @Override
    public IBinder onBind(Intent intent) {
        return null;
    }

    public void onDestroy() {
        super.onDestroy();
    }
}

【问题讨论】:

  • 我对你在这里尝试做的事情感到困惑。您应该有一个未列出的类来设置alarmManager 并启动警报,MyReciever 类将选择它并启动服务。我不明白为什么 MyReciever 类和 Service 类中有 AlarmManager?您也不应该对两个不同的 PendingIntents 使用相同的 ID - 我会从 MyService 中完全删除 AlarmManager,除非我在您的问题中遗漏了某些内容
  • 是的,你错过了一些东西......因为alarmmanager的android kitkat setRepeating方法不精确,所以我通过在onReceive方法中设置另一个警报来模拟setRepeating来处理它。正如你所看到的,如果是这样,我没有两个具有相似 ID 的待处理意图
  • @CommonsWare 我一直在搜索,但我没有得到任何答案,但也许你可以帮助我,谢谢

标签: android service


【解决方案1】:

android 中的任何服务都不能无限期运行(PERSISTENT)接受系统服务。

您只能让服务返回 START_STICKY。获取唤醒锁不是一个好主意,因为它会耗尽用户的电量。

即使服务被杀死,它也会被系统重新启动。

您可以实现一个 BOOT_COMPLETED 接收器,以便在设备启动时启动服务。

【讨论】:

  • 感谢您的回复。服务没有被系统重新启动,我在我的问题中提到了它
  • 这很奇怪......但对我来说系统总是重新启动服务......你可以从销毁中删除启动服务并尝试
  • 是的,我会尝试这样做,但是如果用户杀死了我的服务,我该怎么办?
  • 你应该什么都不做,因为用户不希望你的服务运行......在你的应用程序中你可以显示一个警告,即终止服务将禁用功能
  • 当用户关闭应用程序时,服务也将停止,android不会再次启动它。但这并不意味着用户不希望我的服务运行
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-06-11
  • 2021-11-23
  • 1970-01-01
  • 2020-05-26
  • 2014-01-15
  • 2017-05-29
相关资源
最近更新 更多