3

Context / Current Approach

Hello, I'm curious about my usage of a Foreground Service. I have an app which performs voice communication and maintains a persistent connection to our backend via a websocket. It is a common use case for our users to background our app and do something else which is memory- and CPU-intensive, in particular playing mobile games.

In order to prevent our app's process from dying and severing the voice connection, we run a Foreground Service in our app's process (a local service, in some vocabularies). This Foreground Service doesn't actually do much, it displays a notification that allows the user to interact and mute/deafen/disconnect from the notification tray. All the voice logic doesn't actually live in the Service.

Our hypothesis is that by running a Foreground Service, we effectively mark our process as "foregrounded", and the OS is less likely to kill our app. This also allows the user to swipe away our app and have the process stay alive (including the voice connection). This appears to work and looks very similar to the process/service signatures of similar products (Skype, Spotify) using adb shell dumpsys activity services and the inspectors in the device's settings.

However, from time to time we still hear about users who experience our app being killed while gaming or streaming videos, even when they are on voice and the Service is running.

And Now For The Question(s)

After much research it FEELS like we are doing the right thing already. However, we'd like to make our voice stability more bulletproof if possible, and address those user complaints.

  1. Am I doing the right thing already, or is my understanding of using a Service to "mark our app as foreground priority" flawed? (Addendum: It took me getting to the end of writing this for this question to pop up in my searches. It reads like we're on the right track already).
  2. Is there any way I can verify that the OS is indeed killing my app process? Conventional wisdom says no. However I can imagine some solutions which abuse the STICKY flag to relaunch the Service, log to our servers that the Service was relaunched by the OS (and therefore, must have been killed by the OS), and then stops itself again. I just thought of this while writing so forgive me for not having tried it yet...
  3. Do we have other options? The UI components of our app are not particularly heavyweight. This leads me to think that even if we were to invest in a Remote Service (running in another process), if the OS is already killing our Foreground Service, then the OS will likely also just kill that Remote Service. I don't want to use STICKY to combat that as it would be a poor user experience -- it makes sense for services passively processing data but for active voice chat, restarting "later" doesn't sound great...

Thank you very much for taking the time to read the question, I'm happy to provide any additional necessary context.

Andy Garron
  • 31
  • 2
  • Making you service a foreground service does not guarantee that it never gets killed, it simply makes it less likely. A foreground service can be killed if the OS deems it needs additional resources under heavy load (which games or streaming can certainly cause). You can try override `onLowMemory` in your service to see if that gets called before your service gets killed https://developer.android.com/reference/android/content/ComponentCallbacks#onLowMemory%28%29 – tyczj Jul 24 '18 at 17:46
  • Of course -- I was wondering if using a Remote Service would allow us to let the OS target our main app (UI etc.) and keep the Service alive, but I think the IPC overhead would be too impactful on performance for the time being. Thank you very much for the pointer to something that will let us get more scientific on this! – Andy Garron Jul 24 '18 at 17:53

0 Answers0