Closed tankers746 closed 3 years ago
This issue is well-known among Android developers and there are plenty of other existing issues reported here (search the issues).
This is not directly related to this plugin. Something else in your app is blocking the main thread, preventing background-geolocation from executing startForeground
within 5 seconds android provides.
I couldn't see any solutions in the existing issues. Any tips on where to start?
So you found all these?
There is no quick solution, but a process of discovering which of your plugins are consuming too much time on the main-thread while your app boots by enabling Android StrictMode
. Examples of "consuming too much time on the main thread" typically come from file or database operations performed on the main-thread.
Duplicate #976
I no longer experience these in the SampleApp on Play Store. I used to but since I took measures within the plugin's code back in version 3.3.0 to ensure file/database operations are performed in background threads, my problems went away.
So with the SampleApp running the background-geolocation plugin in the absence of other plugins, there are no ANR.
When is Context.startForegroundService()
called? is it on app load or BackgroundGeolocation.start()
or BackgroundGeolocation.ready()
?
The plugin has many foreground-services which are capable of launching a terminated app to service a request.
Eg, if you terminate your app then start physically moving, the plugin's ActivityRecognitionService
will cause your app to re-launch headless in the background and that service will be wanting to call Context.startForegroundService
.
The next step for you is to enable Android StrictMode
and observe your logs for StrictMode
warnings.
I see, I was able to detect some DiskReadViolation by moving the strict mode statement from MainActivity to MainApplication.
@christocracy We're having the same issue here, most of our strictMode
violations take place from the same DiskReadViolation
/DiskWriteViolation
in codepush
Perhaps this “code push” should be consulted about clearing up their StrictMode violations.
My exception logging service and google play are reporting a large number of crashes after implementing this library. I've not been able to reproduce the issue myself but it has greatly affected the crash rate in the Google Play console.
Your Environment
react-native -v
): 0.63.4Plugin config
I have enabled strict mode after seeing the issue below but I couldn't see any violations. https://github.com/transistorsoft/react-native-background-geolocation/issues/976
I enabled
detectAll()
in strict mode which produced the violation below however after some googling that appears to be a common error.Debug logs
Logs
``` 2021-02-15 20:02:34.414 23875-24238/com.fleeteng.spatulago D/StrictMode: StrictMode policy violation: android.os.strictmode.UntaggedSocketViolation: Untagged socket detected; use TrafficStats.setThreadSocketTag() to track all network usage at android.os.StrictMode.onUntaggedSocket(StrictMode.java:2124) at com.android.server.NetworkManagementSocketTagger.tag(NetworkManagementSocketTagger.java:82) at libcore.io.BlockGuardOs.tagSocket(BlockGuardOs.java:52) at libcore.io.BlockGuardOs.socket(BlockGuardOs.java:372) at libcore.io.ForwardingOs.socket(ForwardingOs.java:217) at libcore.io.IoBridge.socket(IoBridge.java:658) at java.net.PlainSocketImpl.socketCreate(PlainSocketImpl.java:128) at java.net.AbstractPlainSocketImpl.create(AbstractPlainSocketImpl.java:128) at java.net.Socket.createImpl(Socket.java:489) at java.net.Socket.getImpl(Socket.java:552) at java.net.Socket.setSoTimeout(Socket.java:1180) at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:245) at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:167) at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:258) at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:135) at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:114) at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121) at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121) at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147) at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:127) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147) at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121) at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:257) at okhttp3.RealCall$AsyncCall.execute(RealCall.java:201) at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:919) ```