SecurityException: Caller no longer running, last stopped about android-sdk HOT 9 CLOSED

It appears from the error that it timed out after 8+ seconds which is pretty long for a job to be running. Could this be related to a network issue? If it is a event, it should have been saved to SQLite and attempted to resend later. Do, you know if this is something that clears up?

from android-sdk.

At the moment we are currently using the sdk only to log events. This seems to be a network issue however I'm unable to figure out the root cause. We have not changed our event logging much other then adding some params to an event.

from android-sdk.

The good news is that it should retry and eventually succeed at some interval if you use EventDispatchInterval.

Pretty sure this would be happening at wifi change. Also, this would be a Android O+ issue (only in Android O and later). Do you have the following in your manifest?:

<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>

Also, in the test_app as in your app, you need to register the intent filter in code now for Android O:

    // with the new Android O differences, you need to register the service for the intent filter you desire in code instead of
    // in the manifest.
    EventRescheduler eventRescheduler = new EventRescheduler();

    getApplicationContext().registerReceiver(eventRescheduler, new IntentFilter(WifiManager.SUPPLICANT_CONNECTION_CHANGE_ACTION));

from android-sdk.

Our manifest file is setup correctly like the test-app however we didn't know that we had to register an intent filter in code for Android O.

I'm wondering why in the test-app this is done in a Splash activity and not in the Application class? My first instinct would be to do this in the Application class so that it is only done once. Also why is this code not wrapped in a if-statement that checks for Android O version?

from android-sdk.

1. The reason it is in the Splash activity is just a bad refactor. At first, we had the register inside the activate for asynchronous. Then, we added a synchronous example and just left the register in the splash activity on start. It can definitely be done in the application.
2. There is no need to wrap the register since it is from Android 2 and works for all versions (the manifest entry is just a fallback or a notation).

from android-sdk.

Thanks that makes sense!

from android-sdk.

This is now mentioned in the README, CHANGELOG, and developer docs. So, going to close it.

from android-sdk.

I used to work with Marco but he left the company, so I'm taking over this issue. This bug has re-surfaced as of/around March 23rd. Would you prefer I open a separate issue? (To clarify, it seems to have never fully went away, we were still seeing ~30-50 crashes a day after we released the above code changes)

99% of the crashes we're seeing in Crashlytics are users on Android O. The changes referenced above (creating an intent filter in code in addition to the manifest) were released to our users back in December and we saw the problem go away (or was significantly reduced) until now. We're currently seeing about 800-1000 crashes a day.

from android-sdk.

@rykugur I would say open a new issue. Can you provide us with a crash log and/or stack track? Is it a specific version of Android O? How about specific device? I don't know of any change on March 23. Are you sure you are registering the intent filter on the application context? As a fix, I will also wrap that dequeue call in a exception and return. Thanks

from android-sdk.