1

I am developing an Android Application with Android Studio in Java, that should do the following thing: Connect with one or multiple BLE-Devices and receive GATT-notifications of those over a long period of time (4-10h) in the background. I wrote a Service for this which sends me an android notification when a critical value is received and only hands the data to my Activity, when the app is opened.

The whole thing works fine on the LG G6 I am testing with and also on a Huawei Mate 10 Pro. Now I wanted to try the same App on a Samsung S9 (and S8) and the result was, that the background service stopped after 2 or 3 minutes...

I've run through every energy setting of the phone, that I found and I thought it could cause this trouble, but I found nothing.

Therefore my question: What does Samsung do different from LG and Huawei? Are there any known issues? I have no idea, what may be the problem.

André Frings
  • 119
  • 1
  • 5
  • 15
  • 1
    Do you use a foregroundService? Use startForegroundService from your app to start the service and inside the service class call startForeground(1, notification). If your service still gets killed you could check https://dontkillmyapp.com/ to search for solutions for specific models. Could you post your code? – HarmenH Apr 09 '20 at 06:08
  • No, I am currently using a bound service as I need to communicate between the service and my activity (I also have some write-operations for the ble-devices, that are initiated by user inputs). Is a foreground service also able to do this? I will post my code later, when I am at home. – André Frings Apr 09 '20 at 06:38
  • 1
    A service that is bound to an activity will prevent the process running the service from being killed by the system, but only as long as the activity is alive. If you turn off the screen for example you don't get any guarantees anymore. If you have a Foreground Service however the process should stay alive. – Emil Apr 09 '20 at 07:27

2 Answers2

0

The problem was indeed, that I did not use a foreground service like HarmenH told in the comments. Since I use a foreground service instead of a bound service, everything works as expected on every phone. I can't tell you why the behaviour diverged between the different phones, but since I use the correct way it does not matter anymore. I recommend to dive into Android services overview if you are struggeling with a similar problem.

André Frings
  • 119
  • 1
  • 5
  • 15
0

The contract of Android stipulates that it will not kill bound services, as long as the binding context is still in scope/alive.

Say you have process A, and in its application context, bind another process's (Process B) service. That service should not be killed as long as process A is still alive.

If you want to be extra sure that the binding process (Process A) will be reaped/killed by the OS before the process/service it binds (Process B) is killed, you can use BIND_ABOVE_CLIENT flag when binding the service from the client. (see https://developer.android.com/reference/android/content/Context#BIND_ABOVE_CLIENT)

I find that in reality, when killing the main process, the OS will often kill the bound process first. That is, if, while the binding process is attempting to communicate with the bound process as part of a cleanup (onDestroy) action, it may encounter a RemoteException when writing. The binding client can also receive an onServiceDisconnected callback as the binding process is disconnected.

It seems that for some manufacturers, apps that are opened by sticky services in the background are then subsequently killed quite quickly, and can result in a lot of these transient service exceptions, which can look bad in metrics/analytics.

In reality, my team has not found an instance of the binding process, which is operating nominally, to disconnect from a bound service, even on Samsungs.

Brian J. Roberts
  • 100
  • 8