Android Client SDK running migrations on main thread resulting in StrictMode violations

[mikehc]

Describe the bug
Android Client SDK seems to run migrations on the main thread, resulting in StrictMode violations from Disk Access.

To reproduce
Set up StrictMode in your app.

if (BuildConfig.DEBUG) {
    StrictMode.setThreadPolicy(
        StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build()
    )
    StrictMode.setVmPolicy(
        StrictMode.VmPolicy.Builder()
            .detectLeakedSqlLiteObjects()
            .detectLeakedClosableObjects()
            .penaltyLog()
            .build()
    )
}

Initialize LaunchDarkly SDK via init with timeout set to zero.

LDClient.init(application, ldConfig, ldContext, 0)

Get logs saying there was a violation of StrictMode when running migrations.

Expected behavior
Access to disk happen in a background thread by default. No disk access violation happens as a result of using the LD SDK.

Logs

StrictMode policy violation; ~duration=257 ms: android.os.strictmode.DiskReadViolation
    at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1596)
    at android.app.SharedPreferencesImpl.awaitLoadedLocked(SharedPreferencesImpl.java:275)
    at android.app.SharedPreferencesImpl.getString(SharedPreferencesImpl.java:301)
    at com.launchdarkly.sdk.android.SharedPreferencesPersistentDataStore.getValue(SharedPreferencesPersistentDataStore.java:33)
    at com.launchdarkly.sdk.android.Migration.migrateWhenNeeded(Migration.java:35)
    at com.launchdarkly.sdk.android.LDClient.init(LDClient.java:134)
    at com.launchdarkly.sdk.android.LDClient.init(LDClient.java:238)

SDK version
Android Client 5.6.1

Language version, developer tools
Kotlin 2.1.0 / Android Studio /

OS/platform
Android level 30 to 35

Additional context

[tanderson-ld]

Thank you for bringing this to our attention. This has been logged internally as 1248. Is this interfering with your ability to use the SDK in your project's configuration?

[mikehc]

Thank you for bringing this to our attention. This has been logged internally as 1248. Is this interfering with your ability to use the SDK in your project's configuration?

Not a blocker, we see warnings about frames dropping because doing too much work in the UI. We are trying to fix all possible instances that might be causing this.

If we move the init call into a background thread the violation goes away, so the fix seem simple enough.

[mikehc]

Any updates on this? I see the bug tag was removed.

[tanderson-ld]

HI @mikehc , I initially put the label on thinking it might be more severe, but after your follow up, dropped it back to not a bug until I could investigate more. Spent a little more time this morning looking through the code and our documentation and agree it is a bug in that it isn't ideal.

Is it leading to dropped frames for you?

I'm not sure when we'll be able to prioritize it for fixing.

[mikehc]

@tanderson-ld I thought the issue was being dropped completely, that's why I asked for a follow up.

We believe that it is causing dropped frames but I cannot said to the point were our app is unusable. We display video in our app so any hiccups and drops can be noticeable at some point.

The alternative for us is to apply some workaround to try to guarantee that most of the work by LD SDK is done in the background. As you can imagine, we think this might be an easier fix to do directly on your side than in application code.

If you have any suggestions so we can mitigate this I'm all ears.

Thanks!