quickstart-android: FirebaseRemoteConfigFetchException when fetching Remote Config

I am having the exact same problem. This issue was closed with problems still existing it seems. Is anyone still having this problem? Has anyone figured out how to resolve it?

I’m still getting this issue as well, using 10.2.0 Always comes back with a fetch exception with no detail message. Makes no difference whether I use a cache expiration parameter or not in the fetch call.

Hi all m for anyone still facing this issue , The Remote Config library has a client-side throttle to ensure you don’t ping the service too frequently. By setting your fetchDuration to 0, you’ll hit this throttle and your library will stop making calls. You can get around this by enabling developer mode.call this function right before you call Remote config API .

func activateDebugMode() { let debugSettings = FIRRemoteConfigSettings(developerModeEnabled: true) FIRRemoteConfig.remoteConfig().configSettings = debugSettings! }

By setting developer mode to true, you’re telling Remote Config to bypass the client-side throttle. For development purposes, or testing with your 10-person team, this is fine. But if you were to launch this app to the public with your millions of adoring fans, you’re going to hit the server-side throttle pretty quickly, and Remote Config will stop working. (This is the whole reason you have a client-side throttle in the first place.) For release mode make sure you disable developer mode and set your fetchDuration to something a little more reasonable, like 43200 (that’s 12 hours to you and me).

Hope this helps !

I had the same problem. As in your code, I was calling fetch() without a parameter, but it was resolved when I passed in the cacheExpiration parameter as noted in the example:

 long cacheExpiration = 3600; // 1 hour in seconds.

        if (mFirebaseRemoteConfig.getInfo().getConfigSettings().isDeveloperModeEnabled()) {
            cacheExpiration = 0;
        }

        mFirebaseRemoteConfig.fetch(cacheExpiration)

Many Android devices on the earth are shipped without Google Play services. That’s where this issue happens. Your remote configuration could never reach these devices at present.

Firebase team should definitely make Remote Config work on wider devices, including those shipped without Google Play services. (e.g. Amazon Fire devices and most Android devices in China)

PS, Firebase Analytics, Realtime Database, Crashlytics already works without Google Play services.

I have the similar issue with 10.2.4, but without exception, just no callbacks called when fetching, the issue is only on specific device (Sony Xperia d5803 with Android 4.4.4) and 100% reproducible, it doesn’t work every time. Tried all workarounds available with delayed fetching, but nothing helped to fix the issue.

Many Android devices on the earth are shipped without Google Play Services. That’s where this issue happens.

My test devices, as mentioned above, were a Samsung, a Nexus, and a Huawei, all with Google Play Services. And so, assuming that this exception is caused by missing Google Play Services is just plain not true.

We ended up going with Google Tag Manager instead (which has its own bugs, including a tendency for thread deadlocks 😃 ) but it still works a lot better than Firebase.

Still an issue in Firebase Config 16.1. Nothing to do with throttling.

Think I have a workaround though.

My code was doing this:

firebaseRemoteConfig.activateFetched();

// Use firebaseRemoteConfig.getString  / getAllKeys / etc.

firebaseRemoteConfig.fetch().addOnCompleteListener(callback)

// callback:
if (task.isSuccessful()) {
  // Would not happen
} else {
 // Would happen
final Exception x = task.getException();
// x = FirebaseRemoteConfigException
// x.getMessage = null
}

Makes sense right?

We may already have some values, we activate and use them, and then queue up a refresh in case there is an update.

This caused FirebaseRemoteConfigException every time.

And this is the workaround - how Firebase Config wants you to do things:

firebaseRemoteConfig.fetch().addOnCompleteListener(callback)

firebaseRemoteConfig.activateFetched();

// Use firebaseRemoteConfig.getString  / getAllKeys / etc.
// Note that the fetch callback hasn't triggered yet

// callback:
if (task.isSuccessful()) {
  // Now we end up here every time
} else {
 // And this doesn't happen
final Exception x = task.getException();
}

I’m not sure if my “workaround” is actually how the API works and my older code is just wrong. I can’t quite tell if we’re supposed to / can call activateFetched “just in case” to activate “any just in case” previously fetched values.

I also can’t quite tell if activateFetched is necessary at least once per app process lifetime to activate any values fetched (and cached in storage, I presume) on previous runs.

I also don’t know if my fetch (in the “workaround” version) is actually completing before I’m calling activateFetched / getValue, so maybe I’m just getting lucky because my networking is fast.

But I hope my comment may help another developer.

It also seems to me that Firebase APIs (there are what, three methods total really?) are too fragile.

An application calling activateFetched when it’s not needed should just be a no-op and not cause the whole technology piece fall go catatonic. Anyone from Google here who wants to take this up?

Same issue with 10.2.4 and Android emulator Nexus 6 + API23.