Background Service with Firebase childeventlistener not working after few minutes

后端 未结 3 1389
猫巷女王i
猫巷女王i 2020-12-14 11:09

I have created a service which i want to run forever without showing foreground notification. I have Firebase listener in onStartCommand that liste

相关标签:
3条回答
  • 2020-12-14 11:16

    Before you can do so successfully, you need to instantiate FireBaseApp in your service class that has the child eventlistner. This worked for me.

    0 讨论(0)
  • 2020-12-14 11:22

    First answer:

    Your service is being killed because you might be attempting to do something that Google/Android OS explicitly doesn't want to happen. Here's a cut from the SDK docs and then I'll explain:

    (From Service Lifecycle) Because only a few processes are generally visible to the user, this means that the service should not be killed except in low memory conditions. However, since the user is not directly aware of a background service, in that state it is considered a valid candidate to kill, and you should be prepared for this to happen. In particular, long-running services will be increasingly likely to kill and are guaranteed to be killed (and restarted if appropriate) if they remain started long enough.

    You see, they're actually trying to make sure that the user doesn't have hundreds of SpyServices running perpetually, hogging resources or whatever. How can you avoid this? The answer is right there...show some type of Notification, even one that simply says 'service running' will keep the service from being destroyed. Of course, if you're actually trying to 'spy' on the user, putting a notification that the spy service is running isn't a good idea. If you want to proceed with this pattern, try an 'invisible' notification icon and non-printing text. If the user's looking at the notifications, they might not see it, or think it's just a glitch.

    Second answer:

    Switch to a more 'event-driven' design. I'm assuming that you're able to catch the 'on-boot', 'call-received' and other messages, so register receivers for events that would indicate handset usage, that way you could easily stitch together multiple 10-15 minute segments to get almost full coverage.

    I'd aim for events like:

    • Power connected / disconnected
    • WiFi state change
    • Screen Backlight On/Off and/or screen lock status changed.

    Third answer:

    Take a look at the 'binding' pattern. If you can get any of the activities to 'bind' to the service, its guaranteed NOT to be killed as long as it's bound. If you combine the 'START_STICKY' with the binding pattern, you'll be able to keep running for some period after the binding is released.

    0 讨论(0)
  • 2020-12-14 11:28

    This topic came up in following presentation at DroidconIn ("Firebase Realtime Database deep dive"). Realistically you can't depend on getting 'normal' firebase sync updates while in background but rather need to have some kind of setup that can send Push notifications.

    https://www.youtube.com/watch?v=1nUSoCZlnDo&t=25m10s

    0 讨论(0)
提交回复
热议问题