[firebase-messaging] IOException: Invalid argument for the given fid

[jparkrr]

• Firebase Component: firebase-messaging
• Component version: 24.0.1

Describe the problem

Steps to reproduce:

For some users, attempting to get the token returns this error:

Fetching the token failed: java.util.concurrent.ExecutionException: java.io.IOException: Invalid argument for the given fid.

Here's a related issue that shows a full stack trace: #6914

Relevant Code:

FirebaseMessaging.getInstance().token
        .addOnCompleteListener { task ->
          if (!task.isSuccessful) {
            val exception = task.exception
            promise.reject(REGISTRATION_FAIL_CODE, "Fetching the token failed: ${exception?.message ?: "unknown"}", exception)
            return@addOnCompleteListener
          }
         // ...
        }

Note: I am using this through a library called expo-notifications, so you can see all the code here: https://github.com/expo/expo/blob/c46aeff68ecf6747d792b530482f2c88111cff39/packages/expo-notifications/android/src/main/java/expo/modules/notifications/tokens/PushTokenModule.kt#L51

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[Ali1Ammar]

flutter app had same issus

          Fatal Exception: io.flutter.plugins.firebase.crashlytics.FlutterError: [firebase_messaging/unknown] java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: Invalid argument for the given fid.
       at StandardMethodCodec.decodeEnvelope(message_codecs.dart:652)
       at MethodChannel._invokeMethod(platform_channel.dart:370)
       at MethodChannel.invokeMapMethod(platform_channel.dart:570)
       at MethodChannelFirebaseMessaging.getToken(method_channel_messaging.dart:248)

[kodebach]

We're seeing the same issue. The issue was (almost) gone during May, but it's occurred more often in the last two weeks. This completely breaks our app for new users, since it relies upon functioning push messages. Existing users seem unaffected, existing FCM tokens still work.

We're currently using com.google.firebase:firebase-messaging version 24.1.1 directly.

[lehcar09]

Hi folks! thank you for reaching out. I tried reproducing the issue, however, I did not encounter the same error. According to our engineers,

This registration error was returned because there were app instances in different devices using the same Firebase Installation ID (FID) to register FCM tokens. This happens generally because one app instance's firebase data was copied to an app instance in a different device.

This error is expected because of a recent change in FCM backend. FCM doesn't allow multiple devices to share the same FID because it will cause unpredicatble messasge delivery behaviors.

One solution is reinstall the app on the device that received this error. It will trigger a new FID to be generated.

With that, I'll be closing this issue now. For further investigation, it would be best to reach out to the Firebase support channel instead. We'd need access to your project settings (including projectID, SHA-1 etc) to troubleshoot this type of issue.

Thanks!

[kodebach]

I was able to reproduce this on a device where the app was never installed before. A reinstall solved the issue on that device, but users have reported reinstalling does not solve the issue for them. At the moment my only explanation right now is that the FCM server is giving out duplicate IDs and then rejecting apps.

I have also contacted support and so far have not gotten any additional infos beyond the quote in #7025 (comment)

[jparkrr]

@lehcar09 thank you for the response.

But I have some concerns. As we are not the end user, we cannot reinstall the app.

Are you saying that this library doesn't support the basic Android feature "Set up & restore", where the app data will be copied to a new device (presumably along with the FID)? This seems like a big oversight.

I would appreciate if you could check with the engineers on how this common scenario should be handled, it doesn't seem specific to our app.

[manuelkasper]

I also have users reporting that reinstalling the app does not solve the issue. The common denominator seems to be Android 15, but that may also be a coincidence.

[kodebach]

I'm now able to consistently reproduce the issue by restoring a backup to two different emulators simultaneously. So this seems to be an issue with the dataExtractionRules/fullBackupContent settings of our app.

For the next update, we now added the following exclude rules:

        <exclude
            domain="sharedpref"
            path="com.google.android.gms.appid.xml" />
        <exclude
            domain="sharedpref"
            path="com.google.android.gms.measurement.prefs.xml" />

Plus one extra rule, which I'll explain below

EDIT: We're also automatically deleting FIDs after the update, see below #7025 (comment)

Strangely enough, however, the only hint I found that any backup rules may be necessary is buried here https://developer.android.com/identity/data/autobackup?hl=en#xml-include-exclude. AFAICT the Firebase documentation itself doesn't mention backup content anywhere. There is also no definitive list of which files need to excluded from backups.

IMO this is a severe bug in the com.google.firebase:firebase-messaging library. Why do I say that? Because of the extra rule we had to add:

        <!-- See com.google.firebase.installations.local.PersistedInstallation.getDataFile() for how file name is constructed -->
        <exclude
            domain="file"
            path="PersistedInstallation.W0RFRkFVTFRd+MTo0....JlZmJm.json" />

Note: I obfuscated the filename, because it contains the mobilesdk_app_id specific to your Firebase project.

firebase-android-sdk/firebase-installations/src/main/java/com/google/firebase/installations/local/PersistedInstallation.java

Lines 83 to 99 in f08e0c7

	private File getDataFile() {
	if (dataFile == null) {
	synchronized (this) {
	if (dataFile == null) {
	// Different FirebaseApp in the same Android application should have the same application
	// context and same dir path
	dataFile =
	new File(
	firebaseApp.getApplicationContext().getFilesDir(),
	SETTINGS_FILE_NAME_PREFIX + "." + firebaseApp.getPersistenceKey() + ".json");
	}
	}
	}
	return dataFile;
	}

firebase-android-sdk/firebase-common/src/main/java/com/google/firebase/FirebaseApp.java

Lines 518 to 529 in f08e0c7

	/**
	* Use this key to store data per FirebaseApp.
	*
	* @hide
	*/
	@KeepForSdk
	public String getPersistenceKey() {
	return encodeUrlSafeNoPadding(getName().getBytes(Charset.defaultCharset()))
	+ "+"
	+ encodeUrlSafeNoPadding(
	getOptions().getApplicationId().getBytes(Charset.defaultCharset()));
	}

Again: IMO this is a severe bug in the com.google.firebase:firebase-messaging library. Why? If the file cannot be backed up and restored it should not be in appContext.getFilesDir() but in appContext.getNoBackupFilesDir() to avoid exactly this issue.

At the very least the FCM documentation should be updated, including an explanation of how the filename is generated.

The common denominator seems to be Android 15, but that may also be a coincidence.

We've seen the issue on Android 14 and Android 12 as well.

IIUC the bug was caused by a server-side change and this file can no longer be moved between devices. There may be a good reason for this change. But in that case, there should have been a new version of the FCM client library which moves this file into the no_backup directory and followed by a long deprecation period and ample warnings in release notes, etc..

[kodebach]

I also have users reporting that reinstalling the app does not solve the issue.

My current assumption for this is, that either Google Play Store or the OS itself is restoring a cloud backup when reinstalling the app, or the manufacturer-specific Android variant has a feature to uninstall an app without removing app data and that also causes issues somehow.

We will instruct our users to use the "Clear storage" feature in the system settings app, which removes all app data and therefore ensures an actual fresh install.

[lehcar09]

Hi @kodebach, thank you for sharing your investigation findings. I was able to encounter the error after restoring the app backup on another emulator. And, this is expected because FCM doesn't allow multiple devices to share the same FID.

I tried uninstalling the app from emulator-1 before restoring the app on another emulator-2 and I was able to generate the token without any issue. On cases where re-installing the app did not resolve the issue, it's possible, that the app data was not removed.

To clarify, according to our Eng. the server-side change did not cause this issue. In the past, registrations of devices sharing the same FID were invalidated by FCM backend implicitly. After this change, we return an error explicitly in this case.

[kodebach]

In addition to the exclusion rules for future backups, we are also going to update the app, so that it will detect the java.io.IOException: Invalid argument for the given fid error and delete it's FID. We haven't tested yet, whether calling deleteToken is necessary as well. That should fix the issue without requiring re-installation or deletion of app data. Though it will still require an app update.

This was suggested by Firebase support upon recommendation from their engineering team.

They also suggested using the Admin SDK to delete the FID, but that would only work if the server can get the FID before or when this error occurs, which is not case for us. But it might work for someone else.

according to our Eng. the server-side change did not cause this issue. In the past, registrations of devices sharing the same FID were invalidated by FCM backend implicitly. After this change, we return an error explicitly in this case.

IIUC previously the server silently assigned a new FID and FCM token. After the change, the FCM SDK an error is returned to the app instead, but nobody was told about this new error, or that we may need to handle it. To me that is a bug in the FCM SDK.

(If previously FCM would just silently stop working on one or both of the devices with the duplicate FID, then I agree it's actually bugfix and not a new bug. But app developers should still have been told about the new error.)

To be clear the docs for getToken() do not mention that the returned Task could fail with an exception that the needs to handle. Normally, when no exceptions are documented, it means you should just let it crash, because you can't do anything about it anyways. Also unless there was a change in the last two days, [this] is still one only place that mentions that FCM files need manual backup exclusions.

My main issue here is that this major (potentially breaking) change was not announced anywhere despite its major impact considering the widespread use of FCM.

On top of that there is of course the fact, that this whole fiasco was completely avoidable, if the FCM SDK had stored it's PersistedInstallation file in the no_backup directory where it belongs. So if anything the FCM SDK is not following the documented rules for Android development.

PS. @lehcar09 nothing against you personally, I assume you were and are following internal guidelines re closing of issues and referral to support. I'm just trying to point out that this seems like systemic failure for the Firebase team and you should internally re-evaluate how you could avoid issues like this in the future.

EDIT to add: I hope it is clear to your engineering team the error message Invalid argument for the given fid is now essentially part of the public API and changing it would be a(nother) breaking change. Changing the error message will cause this exact issue again in any app that now fixes the duplicate FID issue by detecting this error. (cf. Hyrum's Law)