fix(messaging, android): prevent OOM by limiting stored notifications

[sean5940]

Description

This PR addresses an OutOfMemoryError (OOM) crash on Android caused by ReactNativeFirebaseMessagingStoreImpl storing up to 100 notifications in SharedPreferences.

When a device receives many notifications with large payloads, the SharedPreferences file grows significantly. Since SharedPreferences loads the entire file into memory, this can exceed the heap size on some devices, leading to a crash.

Related Issue:
Closes #8770

Changes

1. Reduced Default Limit: The default MAX_SIZE_NOTIFICATIONS has been reduced from 100 to 20.

   • Reasoning: getInitialNotification typically only needs the single notification that launched the app. A buffer of 20 is sufficient for most use cases while significantly reducing memory pressure.

2. Configurable Limit: Added support for configuring the limit via AndroidManifest.xml.

   • Developers can now set rn_firebase_messaging_max_stored_notifications in their AndroidManifest.xml to adjust this limit without forking the library.

   <meta-data
     android:name="rn_firebase_messaging_max_stored_notifications"
     android:value="50" />

3. Safety Cap: Added a hard cap of 100 to the configurable limit.

   • Even if a developer sets the value higher in the manifest, it will be capped at 100 to prevent re-introducing the OOM risk.

4. Aggressive Cleanup: Changed the cleanup logic from an if statement to a while loop.

   • Reasoning: If a user already has >20 notifications stored (e.g., 100 from the previous version), the previous logic only removed one old notification per new message. The while loop ensures the storage is immediately drained down to the limit upon receiving the next message.

Verification

• Verified locally that getInitialNotification still functions correctly with the reduced limit.
• Verified that the limit is correctly read from AndroidManifest.xml.
• Verified that the safety cap prevents values > 100.
• Verified that the while loop correctly cleans up excess notifications.

Stack Trace (Reference)

java.lang.OutOfMemoryError: Failed to allocate a 24 byte allocation with 425280 free bytes and 415KB until OOM...
    at android.app.SharedPreferencesImpl$EditorImpl.commitToMemory(SharedPreferencesImpl.java:539)
    at io.invertase.firebase.messaging.ReactNativeFirebaseMessagingStoreImpl.storeFirebaseMessage(ReactNativeFirebaseMessagingStoreImpl.java:43)

[vercel]

@sean5940 is attempting to deploy a commit to the Invertase Team on Vercel.

A member of the Team first needs to authorize it.

[CLAassistant]

All committers have signed the CLA.

[mikehardy]

I mentioned in more detail in specific comments but a summary:

1- I really like the idea of making the serialized notification count configurable

But, I believe strongly this should use our existing code though, and if you want to make existing boot-crash-loop devices recoverable you'll need to add error handling to that common code

2- I do not believe we should change the default, we should avoid a potentially breaking change

3- I like the trim-until-we-are-the-value vs one-at-a-time change

I think there's the core of something that can go in here if you work through the info I put out for item 1 here in this list

[mikehardy]

I don't believe changing this is a good idea - not for 100% technical reasons - 100 may not be practical for every case - you obviously have an OOM so this is critical to address somehow - but this feature has existed for 5 years (ref: sean5940@a7cafc9) and you are the first report of a problem.

So while 100 may be impractical sometimes, it's once in 5 years out of maybe tens of thousands of apps and millions and millions of users.

Weigh that versus even the slim possibility of some app relying on this behavior (or some unknown amount less than 100 and greater than 20) and that implies this would be a breaking change.

I don't think a fix here is worth a breaking change given it has existed for 5 years without any other issues.

So I am a "no" on changing this constant

[sean5940]

Updated to maintain a maximum value of 100, based on comments
41ca8ef

[sean5940]

@mikehardy

@Override
  public void storeFirebaseMessage(RemoteMessage remoteMessage) {
    try {
      String remoteMessageString =
          reactToJSON(remoteMessageToWritableMap(remoteMessage)).toString();
      //      Log.d("storeFirebaseMessage", remoteMessageString);
      UniversalFirebasePreferences preferences = UniversalFirebasePreferences.getSharedInstance();
      preferences.setStringValue(remoteMessage.getMessageId(), remoteMessageString);
      // save new notification id
      String notifications = preferences.getStringValue(S_KEY_ALL_NOTIFICATION_IDS, "");
      notifications += remoteMessage.getMessageId() + DELIMITER; // append to last

      // check and remove old notifications message
      List<String> allNotificationList = convertToArray(notifications);
      if (allNotificationList.size() > MAX_SIZE_NOTIFICATIONS) {
        String firstRemoteMessageId = allNotificationList.get(0);
        preferences.remove(firstRemoteMessageId); // ------ here
        notifications = removeRemoteMessage(firstRemoteMessageId, notifications);
      }
      preferences.setStringValue(S_KEY_ALL_NOTIFICATION_IDS, notifications);
    } catch (JSONException e) {
      e.printStackTrace();
    }
  }

While preferences.remove(firstRemoteMessageId) is invoked when the notification list exceeds MAX_SIZE_NOTIFICATIONS, the editor never calls apply()/commit().
As a result, the entry stored under remoteMessage.getMessageId() is never actually removed from io.invertase.firebase.xml, so the file keeps growing.
Once the XML becomes large enough, calling preferences.setStringValue(S_KEY_ALL_NOTIFICATION_IDS, notifications) can trigger OOM because the entire SharedPreferences file must be loaded into memory before the update.
Is this understanding correct?

2025-11-25.10.53.27.mov

[mikehardy]

@sean5940 your analysis appears correct, regardless of the other feedback I gave, your conversion of the "if" to a "while", and adding an apply() there is an immediate bug fix. I will post a PR and release it independently of this here so that it not blocked and the fix can be out with no delay

[mikehardy]

@sean5940 I can merge and release the PR quickly, but review always helps. If you could take a look?

• fix(messaging, android): properly remove stored remote messages to avoid OOM #8776

I would still like to pursue the idea of making the storage limit configurable here, and working through the idea of OOM recovery by catching an OOM error. Although I think the 5th commit in my PR - "purge old messages before storing new" may actually recover people sufficiently,.

[mikehardy]

This was mostly superceded by #8776 which I wanted to get out as soon as possible because it was in "crash fix" territory

The remaining part of this is the configurable maximum message parameter - what do you think @sean5940 is it still worth it to implement that, or do you want to see if #8776 clears out the problem?

[sean5940]

This was mostly superceded by #8776 which I wanted to get out as soon as possible because it was in "crash fix" territory

The remaining part of this is the configurable maximum message parameter - what do you think @sean5940 is it still worth it to implement that, or do you want to see if #8776 clears out the problem?

@mikehardy

One concern I have is that the shared preferences file is already extremely large, which significantly increases the risk of OOM errors. I’m exploring ways to deal with this — do you have any suggestions on how we might mitigate the issue?

For example, if we assume a situation where the XML file manages only 100 IDs while several thousand FCM messages are stored, the cleanup process can operate only on those 100 known IDs. As a result, any data associated with IDs outside that range cannot be deleted.

I’m not seeing a clear way to address this at the library level. In this situation, would it make sense for the app to check the file size in Application.onCreate() and delete it when it becomes abnormally large?

[mikehardy]

🤔

do you have any suggestions on how we might mitigate the issue

Don't send huge data chunks in your messages, have the data in some other location and send unambiguous references to it, for fetch after getting the notification? But that's a design issue and not really your question

For example, if we assume a situation where the XML file manages only 100 IDs while several thousand FCM messages are stored, the cleanup process can operate only on those 100 known IDs. As a result, any data associated with IDs outside that range cannot be deleted.

Ah, but if you mean that somehow the "accounting" (that is, the assumption in the code that each and every actual message stored has an id stored as well, with no ids for messages that don't exist and no messages without an id entry) is broken then I can see what you mean and we would need some sort of cleanup process.

Indeed, this is the easiest to understand representation of the logic that is currently deployed it is after my refactor for clarity but before any logic changes from the PR I just merged

react-native-firebase/packages/messaging/android/src/main/java/io/invertase/firebase/messaging/ReactNativeFirebaseMessagingStoreImpl.java

Lines 31 to 43 in 2ca86df

	preferences.setStringValue(remoteMessage.getMessageId(), remoteMessageString);
	// save new notification id
	String notificationIds = preferences.getStringValue(S_KEY_ALL_NOTIFICATION_IDS, "");
	notificationIds += remoteMessage.getMessageId() + DELIMITER; // append to last
	// check and remove old notifications message
	List<String> allNotificationList = convertToArray(notificationIds);
	if (allNotificationList.size() > MAX_SIZE_NOTIFICATIONS) {
	String firstRemoteMessageId = allNotificationList.get(0);
	preferences.remove(firstRemoteMessageId);
	notificationIds = removeRemoteMessageId(firstRemoteMessageId, notificationIds);
	}
	preferences.setStringValue(S_KEY_ALL_NOTIFICATION_IDS, notificationIds);

So,

1- store the message as messageId + contents key/value pair
2- then store the messageId list
3- then purge one old message if there are more than the limit

We can assume that 1 may work, and 2 may fail which would lead to an "accounting" failure and an orphaned message yes.

I believe a combination of getAll() on the SharedPreferences, followed by a search for keys that are a) in the known pattern of firebase message ids* and b) are not in the list of messageIds would allow for cleaning old messages. Similarly if there is an id but no related message, that id could be removed from the list, though that is less likely since the messages are stored first.

However, the * is important - perhaps you are sending messages from some other source?

Judging from your recording above, a regex like (untested...) ^\d\:\d{16}%\d{17}$ should be a good match for message ids so you assert that a particular SharedPreferences key is a message (assuming you test that and make sure I got it correct...)

Then you can do a look up in the notificationIds list, and if it is not there, remove().apply() on it.
There is a note in the API docs for getAll() to be careful with how you treat the Map that is returned, so you will likely want to just use it to get all the keys for storage into an fresh intermediate variable as one step, for direct key-by-key processing as a second pass.

This would be a positive change in my opinion, if you implemented it I would be happy to merge it. If you didn't I would probably implement it myself but with a considerable delay - it could be weeks

[mikehardy]

Thanks for the config change - nice to give people control over this one
As mentioned I don't think a clamp is a positive move but that's an easy change

And if you wanted to implement an all-messageIds-iterator in a separate method like preenMessageStorage or similar then call it before storing a new message, I'd be open to that

[sean5940]

@mikehardy
I've addressed all the review feedback in commit d91c462.

Key changes:

• Renamed the config key to messaging_max_stored_notifications for consistency with other messaging configs
• Removed all clamping logic (no min/max restrictions) so developers have full control
• Added logging to show the final setting value and where it came from (SharedPreferences/firebase.json/AndroidManifest/default)
• Updated the schema description to warn about risks without restricting choices
• Kept the default value at 100