当前位置：文江博客话题详情

onStartCommand中传递的Intent为NULL的原因

发布于 2024-12-20 02:27:05 字数 623 浏览 1 评论 0原文

除了系统通过START_STICKY等标志重新启动服务之外，是否还有其他原因导致传递给onStartCommand(Intent, int, int)的Intent为NULL？

另外，当系统重新启动服务时，Intent.getAction() 方法有时会返回 NULL。意图不是 NULL 只是 getAction()

我问，但尚未收到答复。

更新：与 Mark Murphy 聊天后，他建议我在服务的 onStartCommand() 回调中返回 START_REDELIVER_INTENT，而不是 START_STICKY 以便在重新启动后发送整个意图。

我最初没有这样做，因为我担心如果服务试图做某事，那么在这件事的中间，服务会重新启动......它会认识到它开始做那件事吗？我想这是我需要负责的逻辑:)

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

听不够的曲调 2024-12-27 02:27:05

我很惊讶没有讨论传入的标志。我将使用以下内容在日志中监视这一点：

if (null == intent || null == intent.getAction ()) {
        String source = null == intent ? "intent" : "action";
        Log.e (TAG, source + " was null, flags=" + flags + " bits=" + Integer.toBinaryString (flags));
        return START_STICKY;
}

更新：标志为 0，因此那里没有任何可操作的内容。我把空检查留在那里，没有丧失功能。

编辑：好的，我在各个地方的START_STICKY的文档中找到了它！ “如果没有任何待处理的启动命令传递给服务，它将使用空意图对象来调用，因此您必须小心检查这一点。”

http://developer.android.com/reference/android/app/Service.html

I'm surprised there's no discussion of the incoming flags. I'm going to monitor this in the logs with the following:

if (null == intent || null == intent.getAction ()) {
        String source = null == intent ? "intent" : "action";
        Log.e (TAG, source + " was null, flags=" + flags + " bits=" + Integer.toBinaryString (flags));
        return START_STICKY;
}

Update: Flags were 0 so there was nothing actionable there. I've left the null check in there with no loss of function.

Edit: Ok, I found it in the documentation of START_STICKY of all places! "if there are not any pending start commands to be delivered to the service, it will be called with a null intent object, so you must take care to check for this."

http://developer.android.com/reference/android/app/Service.html

回复收藏 0 原文

谷夏 2024-12-27 02:27:05

在回调中返回 START_REDELIVER_INTENT：

    public int onStartCommand(Intent intent, int flags, int startId) {

        // your service code here

        return android.app.Service.START_REDELIVER_INTENT; // make sure restart delivers the intent
    }

这是意外的默认值，大多数时候您不需要 START_STICKY，而是 START_REDELIVER_INTENT。 START_REDELIVER_INTENT 是预期行为。

Return START_REDELIVER_INTENT in your callback:

    public int onStartCommand(Intent intent, int flags, int startId) {

        // your service code here

        return android.app.Service.START_REDELIVER_INTENT; // make sure restart delivers the intent
    }

It's an unexpected default, most of the time you don't want START_STICKY but START_REDELIVER_INTENT. START_REDELIVER_INTENT is the expected behavior.

回复收藏 0 原文

~没有更多了~