App crash with Fatal Exception: android.app.RemoteServiceException

[ashwink11]

Bug Report

App crash with Fatal Exception: android.app.RemoteServiceException

Reproduction Steps

App crash reported by users, hence no known steps. Some feedback in playstore

1. App was not started and it crashed in the background.
2. Often crashes when phone connected to Bluetooth.

Expected Behavior

App should not crash

Observed Behavior

App crashes

OS & Version Information

• Android Version: Most of the devices which reported this crash is Android 8/8.1
• SDL Android Version: 4.8.1
• Testing Against: NA

Test Case, Sample Code, and / or Example App

Crash Logs 1

OS Version: 8.1.0

Device: Galaxy Tab A 10.1

RAM Free: 13.9%

Disk Free: 40.9%

Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage + 1906(ActivityThread.java:1906)
at android.os.Handler.dispatchMessage + 106(Handler.java:106)
at android.os.Looper.loop + 164(Looper.java:164)
at android.app.ActivityThread.main + 7000(ActivityThread.java:7000)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 441(RuntimeInit.java:441)
at com.android.internal.os.ZygoteInit.main + 1408(ZygoteInit.java:1408)

Crash Logs 2

OS Version: 9

Device: ONEPLUS A3003

RAM Free: 33.8%

Disk Free: 12.2%

Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{d132656 u0 com.<APP_NAME>.android/.applink.SdlRouterService}
at android.app.ActivityThread$H.handleMessage + 1835(ActivityThread.java:1835)
at android.os.Handler.dispatchMessage + 106(Handler.java:106)
at android.os.Looper.loop + 193(Looper.java:193)
at android.app.ActivityThread.main + 6863(ActivityThread.java:6863)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 537(RuntimeInit.java:537)
at com.android.internal.os.ZygoteInit.main + 858(ZygoteInit.java:858)

[joeygrover]

Can you share what apps are experiencing this crash so we can replicate the setup? Have the apps displaying the issue been certified by the SDLC?

[ashwink11]

The app is What3Words. They disabled AppLink support since a lot of users saw crashes. So, App in play store might not work.

[joeygrover]

The library enters the foreground calling startForeground as soon as the onCreate method is called (see here) so it is possibly a corner case with certain OS distros and phone models. If you could share as much of that info as you can that would be very helpful for us to try and find any offending combination.

Have you been able to replicate this issue?

[joeygrover]

Also Crashlog 1 isn't specific to the SDL library so it's hard to say if it is relevant or not.

[joeygrover]

Also for reference https://issuetracker.google.com/issues/76112072

[ashwink11]

Info received from App developers: "This crash that we are talking about seems to replicate in some situations when the app is closed and you start enabling / disabling bluetooth and start pairing to certain devices."

[joeygrover]

Would it be possible for you to get full logs so we can follow the logic? The situation given is a pretty standard test we do so there has to be something specific that is happening.

[ashwink11]

Unfortunately, I am not able to reproduce this issue. So, I do not have full logs.
I also received some more info regarding this issue.

Also reported on below devices:
Pixel - Running Android 10
Pixel XL - running Android 9

Issue reported when connected to Non-SDL enabled Bluetooth devices (e.g. Headphones).

[joeygrover]

That's another test we do before releases too, (connecting to non SDL bluetooth hardware). This bug is near impossible to reproduce in testing, but crops up in production. I have started a PR #1168 that hopes to catch any case that the startForeground promise could be broken, but I still think there is a timing element that might be out of our control. For example, if the SdlBroadcastReceiver calls startForegroundService and the OS takes longer than the promised timeout (~5seconds) to actually launch the SdlRouterService, the service's onCreate method might not get called intime which would then throw the exception even though the service calls startForeground as soon as it is created.

[ashwink11]

Thank you for this info. Can you please let us know when can we expect to get this hotfix?

[joeygrover]

My only concern is that while the PR might fix the problem, it's hard to say if it really will and if releasing a hotfix is misleading to developers that we "fixed" this bug. Is there anyway both of our teams can continue try to find reproduction steps for this bug first so we can ensure the PR actually fixes the the issue?

[BrettyWhite]

Closed with #1168

[ashwink11]

The issue still reported after updating SDL lib to 4.10.0.

Devices:
Samsung Galaxy Tab A 10.1 with Android 8.1
Moto g(6) plus with Android 9

Fatal Exception: android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
at android.app.ActivityThread$H.handleMessage + 1906(ActivityThread.java:1906)
at android.os.Handler.dispatchMessage + 106(Handler.java:106)
at android.os.Looper.loop + 164(Looper.java:164)
at android.app.ActivityThread.main + 7000(ActivityThread.java:7000)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 441(RuntimeInit.java:441)
at com.android.internal.os.ZygoteInit.main + 1408(ZygoteInit.java:1408)

[joeygrover]

1. If you can please try to remember to use code tags around logs that makes them easier to read. Also any word on reproduction steps?
2. For the Samsung Galaxy Tab 10.1 tablet, I know we don't have this one. Does anyone on your team have one? Or maybe the reporting app? My concern here is that I'm not sure the tablet supports the hands free profile for bluetooth and therefore the router service shouldn't even be starting through the library calls. Which brings me to the next point.
3. There is currently no description in the log that specifies it is the router service that is being started in the foreground and breaking the foreground promise. Can we ensure this is not the app's SdlService? The service must enter the foreground in the onCreate method and no later.
4. Based on the solution we provided there should be no possible way this exception is thrown as a runtime exception. We have tested our solution to prove that much. You can check the test steps on the PR to see that we can force this exception to happen and the solution catches it.
5. Furthermore, Google has not yet provided any word on fixing their broken behavior.

[ashwink11]

1. Sure, I will do.
2. As of now, we do not see this issue in our tests. I will check if we have the Galaxy tab.
3. We checked with the app developers, they are starting foreground service from the "OnCreate" method, same as in sample Hello SDL code.
4. I saw that the exception handler is used only for the SDL router service. setForegroundExceptionHandler is called before start foreground service for router service. As it was mentioned that this issue is seen onCreate method might not get called in time.

Should this exception handler be also used for SDL Service in Apps? SDL Service is started in onSdlEnabled in SdlReceiver. reference: sample code.

5. Do you think we could use bound services instead of foreground service for SDL Service?

[joeygrover]

So we can't use the exception handler for the app's specific SDL Service since it's outside the scope of the library. There's no way to tell what an app would name that service, or if they would want that type of exception handling. So the developer can use a similar solution as was implemented and include their service; they would need to make sure sure to grab the current handler for the thread and call super of course.

As far as bound services, it's up to app and how they want to start their service. However it's not possible to bind a broadcast receiver to a service so they would have to start their activity first and have that bind to their service. Once onSdlEnabled is called, it is up to the developer on how they want and need to prepare for that connection.

[fantasy1022]

Our company encounters this issue, too. We use SDL lib to 4.11.1.

We reference the solution #1168 using in our App and changing this crash into non-fatal event sending to Firebase Crashlytics.

We look the event stack trace and check the problem appearing firstly in SdlBroadcastReceiver line:320

Therefore, We think maybe the condition(e.getMessage().contains("SdlRouterService")) is too strict to catch the crash.
We replace the condition to e.getMessage().contains("startForegroundService"). It can catch the crash in our App side.