I have created a service which i want to run forever without showing foreground notification. I have Firebase
listener in onStartCommand
that liste
Before you can do so successfully, you need to instantiate FireBaseApp in your service class that has the child eventlistner. This worked for me.
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:
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.
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