android.app.RemoteServiceException$ForegroundServiceDidNotStartInTimeException

[aashi-09]

Expected behaviour : Service should start when calling Context.startForegroundService()

Actual Behaviour : Throwing crash in the library as this exception is not handled

Steps to reproduce : Issue is happening when app is in background. Not able to reproduce this manually

Mobile device model and OS version : Crash is happening on android 12 on model Samsung Galaxy A23 5G, Galaxy A03s, Model:Moto G Pure and Android 13 on Model:Galaxy S21 FE 5G, Galaxy S22+, Model:Galaxy A42 5G, Model:Galaxy A53 5G

Android Beacon Library version implementation : 'org.altbeacon:android-beacon-library:2.19.5'

[aashi-09]

Adding a stacktrace for more info

com.wrkspot.employee.prod_issue_bf0aa132fee08d894d95a404d1a44d14_crash_session_641CF98F012800017AF59016EA0B89A2_DNE_0_v2_stacktrace.txt

[davidgyoung]

I have also seen this and investigated it for specific applications using the library. The core issue is that Android OS will crash the app if starting a service in foreground mode is not confirmed by the service with a foreground notification within 5 seconds. Usually this happens fine, but there are lots of edge cases where things can prevent this from happening. There is a long discussion of those edge cases on this Google issue tracker.

One common cause is that the UI thread is sometimes overwhelmed at the time of app launch and prevents completion of this transaction within 5 seconds. (React Native apps often make heavy use of the UI thread -- a typical app boot on a Pixel 3a in four seconds.) This can contribute to the problem.

Library release 2.19 included a change here that tries to expedite the call to confirm the foreground service as quickly as possible after the library is activated. But there is only so much the library itself can do if the main thread is busy and code runs slowly.

Two things you can do in your app to help prevent this:

1. Do a test to see how long it takes to run a small block of code on the main thread. If it takes more than a millisecond, that means the thread is busy, and you should delay starting the library in a mode that also starts a foreground service until a time that the main thread is not busy.

2. Stop using the built-in foreground service in the app and instead use your own custom foreground service so you have more control over when it is started and stopped.

[aashi-09]

Hi @davidgyoung Thank you for the quick response!

We feel and suggest that if you could handle ForegroundServiceDidNotStartInTimeException/RemoteException in BeaconManager class and return it as a function callback so that we can start the service again.

Thank you

[davidgyoung]

@aashi-09 I'm not sure it is possible to catch this exception. If you look at the stack trace, there does not appear to be any library or application classes where the exception can be caught. Do you see otherwise?

[davidgyoung]

closed due to inactivity

[pravingaikwad07]

Any update on this issue ?