Remote Config doesn't pass StrictMode (disk read violation)

[mlewandowskipt]

• Firebase Component: Remote Config
• Component version: 21.4.1

Steps to reproduce:

1. Integrate Firebase Remote Config to your app
2. Turn on StrictMode with detectAll() and penaltyLog()
3. Observe logs, following violation appears:

StrictMode policy violation; ~duration=82 ms: android.os.strictmode.DiskReadViolation
  at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1674)
  at android.app.SharedPreferencesImpl.awaitLoadedLocked(SharedPreferencesImpl.java:275)
  at android.app.SharedPreferencesImpl.getLong(SharedPreferencesImpl.java:328)
  at com.google.firebase.remoteconfig.internal.ConfigMetadataClient.getFetchTimeoutInSeconds(ConfigMetadataClient.java:92)
  at com.google.firebase.remoteconfig.RemoteConfigComponent.getFrcBackendApiClient(RemoteConfigComponent.java:250)
  at com.google.firebase.remoteconfig.RemoteConfigComponent.getFetchHandler(RemoteConfigComponent.java:264)
  at com.google.firebase.remoteconfig.RemoteConfigComponent.get(RemoteConfigComponent.java:180)
  at com.google.firebase.perf.config.RemoteConfigManager.isFirebaseRemoteConfigAvailable(RemoteConfigManager.java:395)
  at com.google.firebase.perf.config.RemoteConfigManager.triggerRemoteConfigFetchIfNecessary(RemoteConfigManager.java:331)
  at com.google.firebase.perf.config.RemoteConfigManager.getRemoteConfigValue(RemoteConfigManager.java:295)
  at com.google.firebase.perf.config.RemoteConfigManager.getBoolean(RemoteConfigManager.java:207)
  at com.google.firebase.perf.config.ConfigResolver.getRemoteConfigBoolean(ConfigResolver.java:867)
  at com.google.firebase.perf.config.ConfigResolver.getIsExperimentTTIDEnabled(ConfigResolver.java:826)
  at com.google.firebase.perf.metrics.AppStartTrace.onActivityResumed(AppStartTrace.java:352)
  at android.app.Application.dispatchActivityResumed(Application.java:416)
  at android.app.Activity.dispatchActivityResumed(Activity.java:1448)
  at android.app.Activity.onResume(Activity.java:2001)
  at androidx.fragment.app.FragmentActivity.onResume(FragmentActivity.java:309)

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[argzdev]

Thanks for reaching out, @mlewandowskipt. Interestingly enough the issue is reproducible if we add the StrictMode right at the beginning e.g.

class CustomApplication: Application() {

    init {
        StrictMode.setVmPolicy(
            StrictMode.VmPolicy.Builder()
                .detectAll()
                .penaltyLog()
                .build())
        StrictMode.enableDefaults()
    }

If we add the StrictMode under the onCreate, the DiskReadViolation is not encountered. I guess this is because the read is already complete the moment it reached onCreate. That said, I'll forward these findings to our engineers and see what we can do.

[dhruvkaushal11]

Facing the same issue while doing Strict Mode Checking for our app.

[keyboardsurfer]

This issue can be verified by running the Now in Android sample app from this PR: android/nowinandroid#1050

[Mercandj]

This issue can be verified by running the Now in Android sample app from this PR: android/nowinandroid#1050

By declaring a ContentProvider with an initOrder="101" and by putting the StrictMode declaration into the ContentProvider.onCreate, you will see all the Firebase violation. Mainly DiskReadViolation.

Why use a ContentProvider?

• Because ContentProviders are created before the Application.onCreate
• Because Firebase is using internally a ContentProvider for initialization reasons
• So, to be called before the Firebase code that is using initOrder="100"

Here are the logs I got on Pixel-6a, form a cold-start, with

implementation("com.google.firebase:firebase-analytics:21.5.0")
implementation("com.google.firebase:firebase-config:21.6.0")
implementation("com.google.firebase:firebase-crashlytics:18.6.1")

strict_mode_logs.txt

[visumickey]

Based on the read of the logs, there seem to be multiple products involved in causing the DiskReadViolation. In the logs, it seems like Crashlytics is trying to access the file system in the early phase of the application launch causing this violation. Based on the last comment, it looks like this issue is happening without FIrebase performance integration. So, removing Firebase Performance from the tags and including Crashlytics to debug this further.

Separately, Firebase Performance is going to make some app startup changes to avoid initializing remote config to avoid disk reads in the early phase of app start.