react-native-notify-kit 9.6.0 → 10.0.0

package/README.md

@@ -135,10 +135,30 @@ useEffect(() => {
 }, []);
 ```
 
+## Notifee FCM Mode (NEW in 10.0.0)
+
+**Use `react-native-notify-kit` as the sole FCM display layer on both Android and iOS** — one developer API, no duplicate notifications on Android, no silent-push drops on iOS. Ship a server SDK payload, let the client handle it in one line, and scaffold the iOS Notification Service Extension with a single CLI command:
+
+```bash
+# server: build the payload
+import { buildNotifyKitPayload } from 'react-native-notify-kit/server';
+await admin.messaging().send(buildNotifyKitPayload({ token, notification: { title, body, android, ios } }));
+
+# client (Android + iOS): one line in setBackgroundMessageHandler / onMessage
+await notifee.handleFcmMessage(remoteMessage);
+
+# iOS NSE scaffold
+npx react-native-notify-kit init-nse && cd ios && pod install
+```
+
+See the full guide: **[docs/fcm-mode.md](docs/fcm-mode.md)** — covers architecture, server SDK reference, client API, NSE setup, payload schema, migration, troubleshooting, and known limitations.
+
 ## Push Notifications (Firebase)
 
 This library handles notification **display and management**. For receiving push notifications, pair it with [`@react-native-firebase/messaging`](https://rnfirebase.io/messaging/usage):
 
+> **New in 10.0.0:** for a turnkey FCM integration that handles both platforms (no duplicate on Android, APNs-reliable on iOS), use **[Notifee FCM Mode](docs/fcm-mode.md)** instead of the manual pattern below. The sections that follow still apply for basic Firebase setup (google-services plugin, permissions, APNs capability).
+
 ### Android setup
 
 1. Add Firebase dependencies to your app:
@@ -196,7 +216,22 @@ messaging().onMessage(async remoteMessage => {
 
 ## iOS Notification Service Extension
 
-To modify push notification content before display (e.g., attach images), create a Notification Service Extension:
+To modify push notification content before display (e.g., attach images), create a Notification Service Extension.
+
+### Automated setup (recommended)
+
+From your project root, with `react-native-notify-kit` installed:
+
+```bash
+npx react-native-notify-kit init-nse
+cd ios && pod install
+```
+
+The CLI scaffolds a Swift NSE target (default name: `NotifyKitNSE`), patches your Podfile, and wires `.pbxproj`. Open your `.xcworkspace` in Xcode, verify the NSE target's signing, and build. See [docs/fcm-mode.md#ios-nse-setup](docs/fcm-mode.md#ios-nse-setup) for the full CLI reference (target name, bundle suffix, `--dry-run`, `--force`).
+
+### Manual setup
+
+For Expo, monorepos with non-standard iOS paths, or heavily-customized Xcode configurations where the CLI can't patch the project cleanly:
 
 1. In Xcode: **File > New > Target > Notification Service Extension**
 2. Add to your Podfile:
@@ -234,6 +269,40 @@ To modify push notification content before display (e.g., attach images), create
 
 5. Run `cd ios && pod install`
 
+## Server SDK
+
+`react-native-notify-kit` ships a **zero-dependency server SDK** under the `/server` subpath, for building FCM HTTP v1 payloads that the client `handleFcmMessage` handler consumes. Runs in Node.js 22+ and Firebase Cloud Functions.
+
+```ts
+import { buildNotifyKitPayload } from 'react-native-notify-kit/server';
+import * as admin from 'firebase-admin';
+
+const message = buildNotifyKitPayload({
+  token: '<device FCM token>',
+  notification: {
+    id: 'order-42',
+    title: 'Your order is on the way',
+    body: 'Tap to see live tracking',
+    data: { orderId: '42' },
+    android: { channelId: 'orders', smallIcon: 'ic_notification' },
+    ios: { sound: 'default', interruptionLevel: 'timeSensitive' },
+  },
+  options: { androidPriority: 'high', ttl: 3600 },
+});
+
+await admin.messaging().send(message);
+```
+
+Full reference: [docs/fcm-mode.md#server-sdk-reference](docs/fcm-mode.md#server-sdk-reference) (types, validation rules, payload shape, FCM 4 KB limit).
+
+## CLI Tools
+
+The library ships a small CLI at `npx react-native-notify-kit`. Currently one command is available:
+
+- `npx react-native-notify-kit init-nse` — scaffolds an iOS Notification Service Extension (Swift), patches the Podfile, and wires `.pbxproj`. See [docs/fcm-mode.md#ios-nse-setup](docs/fcm-mode.md#ios-nse-setup) for options.
+
+The CLI is prepacked into the main package at publish time, so `npx react-native-notify-kit` works immediately after `yarn add react-native-notify-kit` — no separate install.
+
 ## Jest Testing
 
 Mock the native module in your Jest setup file:
@@ -263,7 +332,7 @@ This fork is a complete migration to React Native's **New Architecture**:
 - **Toolchain**: Yarn 4, Node 22+, Java 17, compileSdk/targetSdk 35
 - **Single Android module** — the original Notifee shipped a pre-compiled AAR bundled inside the npm tarball under a frozen Maven coordinate; this fork compiles the core from source as part of the React Native bridge module on every consumer build. Eliminates the `FAIL_ON_PROJECT_REPOS` issue on RN 0.74+ and the Gradle cache staleness bug that could serve outdated bytecode after `yarn upgrade`.
 - **Core notification logic (NotifeeCore) is unchanged** — the public API is fully compatible with the original Notifee
-- **30 upstream bugs fixed** — see [Bugs Fixed from Upstream Notifee](#bugs-fixed-from-upstream-notifee) below
+- **33 upstream bugs fixed** — see [Bugs Fixed from Upstream Notifee](#bugs-fixed-from-upstream-notifee) below
 - **Reliable trigger notifications** — AlarmManager is the default backend instead of WorkManager, with automatic fallback when exact alarm permission is not granted
 - **New API: `setNotificationConfig()`** — opt-out flag to prevent Notifee from intercepting iOS remote notification handlers (see [New APIs](#new-apis) below)
 - **Baseline Profile** — the library AAR ships a Baseline Profile that instructs ART to AOT-compile the foreground service notification hot path at install time, eliminating JIT penalty on first invocation
@@ -304,8 +373,21 @@ This fork fixes the following bugs that were never resolved in the original Noti
 | `getBadgeCount:` completion block never called when running in an app extension, causing JS promises to hang forever in NSE handlers | iOS | Pre-existing | 9.4.0 |
 | Notification Service Extension attachment downloads had no timeout cap (default 60-second `NSURLSession` timeout exceeds iOS's ~30-second NSE budget), causing extension process kill and notification loss on slow networks | iOS | Pre-existing | 9.4.0 |
 | `cancelTriggerNotifications()` / `createTriggerNotification()` promises resolve before Room DB write completes, causing ~3% race on cancel-then-create patterns. Also fixes a previously-undocumented reboot-recovery data-loss bug in `NotifeeAlarmManager.rescheduleNotification` and an ordering bug in `NotificationManager.doScheduledWork` | Android | [#549](https://github.com/invertase/notifee/issues/549) | 9.5.0 |
-| Scheduled trigger notifications silently lost across device reboot on OEM devices (Xiaomi MIUI, OnePlus, Huawei EMUI, Oppo ColorOS, Vivo FuntouchOS) whose vendor OS suppresses `BOOT_COMPLETED` until the user manually enables autostart. Also handles zombie non-repeating triggers whose fire time already passed (fire-once within a 24-hour grace period, then delete the Room row; delete silently beyond the grace period) and adds try/catch/finally guards to all notifee `BroadcastReceiver` async paths. | Android | [#734](https://github.com/invertase/notifee/issues/734) | Unreleased |
-| `ObjectAlreadyConsumedException` in headless task when the same `WritableMap` is reused or the `taskConfig` accessor is read twice — `TaskConfig.init` mutated the caller's map instead of copying it first. Latent in most apps but observed in production by upstream users with high-frequency headless events | Android | [#266](https://github.com/invertase/notifee/issues/266) | Unreleased |
+| Scheduled trigger notifications silently lost across device reboot on OEM devices (Xiaomi MIUI, OnePlus, Huawei EMUI, Oppo ColorOS, Vivo FuntouchOS) whose vendor OS suppresses `BOOT_COMPLETED` until the user manually enables autostart. Also handles zombie non-repeating triggers whose fire time already passed (fire-once within a 24-hour grace period, then delete the Room row; delete silently beyond the grace period) and adds try/catch/finally guards to all notifee `BroadcastReceiver` async paths. | Android | [#734](https://github.com/invertase/notifee/issues/734) | 9.6.0 |
+| `ObjectAlreadyConsumedException` in headless task when the same `WritableMap` is reused or the `taskConfig` accessor is read twice — `TaskConfig.init` mutated the caller's map instead of copying it first. Latent in most apps but observed in production by upstream users with high-frequency headless events | Android | [#266](https://github.com/invertase/notifee/issues/266) | 9.6.0 |
+| `getDisplayedNotifications()` returned no `data` field on Android, breaking iOS/Android API symmetry where iOS exposes custom keys via `parseDataFromUserInfo:` (see platform limitation note below — the fix is API parity for app-posted notifications, not a workaround for FCM background auto-display) | Android | [#393](https://github.com/invertase/notifee/issues/393) | 9.7.0 |
+
+> **Important note on `getDisplayedNotifications()` and FCM custom data on Android.**
+>
+> The 9.7.0 fix for [#393](https://github.com/invertase/notifee/issues/393) makes `getDisplayedNotifications()` expose a `data` field for notifications stored in `Notification.extras` (matching iOS shape). However, when the FCM Android SDK auto-displays a `notification`+`data` push while the app is in background or killed, custom `data` fields are placed only on the tap-action `PendingIntent` — never on `Notification.extras`. This is the FCM SDK's original design (see `CommonNotificationBuilder.createContentIntent` in [firebase-android-sdk](https://github.com/firebase/firebase-android-sdk/blob/master/firebase-messaging/src/main/java/com/google/firebase/messaging/CommonNotificationBuilder.java)) and is not workaroundable from any library — the PendingIntent's extras are sealed by Android's security model. Firebase tracks this gap in [firebase-android-sdk#2639](https://github.com/firebase/firebase-android-sdk/issues/2639) (open since 2021).
+>
+> **The fix does work** for these scenarios on Android: notifications created via `notifee.displayNotification({ data: {...} })`, FCM data-only messages handled in `onMessageReceived` followed by an explicit `displayNotification()` call, custom `FirebaseMessagingService.handleIntent` overrides that inject extras before display, and notifications from other libraries that call `NotificationCompat.Builder.addExtras(bundle)`.
+>
+> **Recommended pattern for full control over FCM push notifications on Android**: send FCM data-only messages (omit the `notification` field server-side), handle them in `onMessageReceived` (or a headless task in killed state), and render the notification yourself via `notifee.displayNotification()`. This gives full control over `data`, channel, styling, tap behavior, and is also Firebase's [official recommendation](https://firebase.blog/posts/2018/09/handle-fcm-messages-on-android/).
+>
+> **Reserved keys filtered from `data`** (custom payload keys matching these are dropped): prefixes `android.`, `google.`, `gcm.`, `fcm.` (with trailing dot — `fcmRegion`, `googleish` survive), `notifee` (no trailing dot — library's reserved namespace, `notifeeFoo` is also filtered), plus exact keys `from`, `collapse_key`, `message_type`, `message_id`, `aps`, `fcm_options`. The `fcm_options` exact-match matches iOS behavior on the Firebase analytics-label key. **Cross-platform note**: bare-`fcm` keys other than `fcm_options` (e.g. `fcmRegion`, `fcmToken`) are preserved on Android but filtered on iOS — rename server-side if you need strict parity.
+
+<!-- markdownlint-disable-line MD028 -->
 
 > **Note for apps requiring guaranteed exact alarms (alarm clocks, timers, calendars):**
 > Add `<uses-permission android:name="android.permission.USE_EXACT_ALARM" />` to your app's
@@ -675,7 +757,7 @@ The script runs the macrobenchmark test in `apps/smoke/android/baselineprofile/`
 
 ## Documentation
 
-The upstream Notifee documentation remains the best reference for the public API and platform guides used by this fork.
+The full `react-native-notify-kit` documentation is hosted on docs.page and is kept in sync with this repo. It covers the public API, platform guides, FCM Mode, the server SDK, and the `init-nse` CLI.
 
 - [Overview](https://docs.page/marcocrupi/react-native-notify-kit/react-native/overview)
 - [Reference](https://docs.page/marcocrupi/react-native-notify-kit/react-native/reference)

package/RNNotifeeCore.podspec

@@ -16,6 +16,8 @@ Pod::Spec.new do |s|
 
   s.cocoapods_version        = '>= 1.10.0'
   s.ios.deployment_target   = '15.1'
+  s.module_name            = 'RNNotifeeCore'
+  s.pod_target_xcconfig    = { 'DEFINES_MODULE' => 'YES' }
     
   if defined?($NotifeeCoreFromSources) && $NotifeeCoreFromSources == true
     # internal dev flag used by Notifee devs, ignore

package/android/src/main/java/app/notifee/core/NotificationManager.java

@@ -72,8 +72,11 @@ import com.google.common.util.concurrent.ListenableFuture;
 import com.google.common.util.concurrent.ListeningExecutorService;
 import com.google.common.util.concurrent.MoreExecutors;
 import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.HashSet;
 import java.util.List;
 import java.util.Objects;
+import java.util.Set;
 import java.util.concurrent.Callable;
 import java.util.concurrent.ExecutorService;
 import java.util.concurrent.Executors;
@@ -84,6 +87,43 @@ class NotificationManager {
   private static final String TAG = "NotificationManager";
   private static final String EXTRA_NOTIFEE_NOTIFICATION = "notifee.notification";
   private static final String EXTRA_NOTIFEE_TRIGGER = "notifee.trigger";
+
+  // Denylist for getDisplayedNotifications() data extraction — pairs with
+  // EXCLUDED_DATA_KEY_PREFIXES below. `fcm_options` is the Firebase HTTP v1
+  // `Message.fcm_options` analytics label; on iOS it is caught by the bare
+  // `hasPrefix:@"fcm"` filter in NotifeeCoreUtil.m:627, and we match that
+  // filter exactly on Android via this set so the analytics label never
+  // leaks into `notification.data`.
+  private static final Set<String> EXCLUDED_DATA_KEYS =
+      new HashSet<>(
+          Arrays.asList(
+              "from", "collapse_key", "message_type", "message_id", "aps", "fcm_options"));
+
+  // Prefixes that denote system or internal keys.
+  // - `android.`, `gcm.`, `google.`, `fcm.` include the trailing dot so
+  //   legitimate custom keys like `androidify`, `googleish`, or `fcmRegion`
+  //   survive the filter.
+  // - `notifee` is intentionally without dot: it's the library's own namespace
+  //   and we reserve it entirely (matches the internal constants
+  //   `notifee.notification` / `notifee.trigger`, plus `notifee_options` and
+  //   any future addition — mirrors iOS NotifeeCoreUtil.m:626 which uses
+  //   hasPrefix:@"notifee" for the same reason).
+  //
+  // Note: `fcm.` with the dot on Android diverges from iOS, which uses bare
+  // `hasPrefix:@"fcm"` (NotifeeCoreUtil.m:627-628). The iOS filter exists
+  // specifically to drop `fcm_options` (the Firebase HTTP v1 analytics
+  // label, documented inline in that iOS source as `// fcm_options`) — it
+  // is NOT a historical/broad match. We handle `fcm_options` via the
+  // EXCLUDED_DATA_KEYS exact-match set above, which gives us parity on the
+  // Firebase-reserved key while preserving realistic user keys like
+  // `fcmRegion` and `fcmToken` that iOS's broader filter would also drop.
+  // Apps that need strict cross-platform consistency for custom data keys
+  // should avoid names starting with `fcm` entirely (iOS drops them, Android
+  // preserves everything except the exact `fcm_options` label).
+  private static final String[] EXCLUDED_DATA_KEY_PREFIXES = {
+    "android.", "gcm.", "google.", "notifee", "fcm."
+  };
+
   private static final ExecutorService CACHED_THREAD_POOL = Executors.newCachedThreadPool();
   private static final ListeningExecutorService LISTENING_CACHED_THREAD_POOL =
       MoreExecutors.listeningDecorator(CACHED_THREAD_POOL);
@@ -866,6 +906,8 @@ class NotificationManager {
                 notificationBundle.putString("subtitle", subtitle.toString());
               }
 
+              notificationBundle.putBundle("data", extractDataFromExtras(extras));
+
               Bundle androidBundle = new Bundle();
               if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
                 androidBundle.putString("channelId", original.getChannelId());
@@ -894,6 +936,62 @@ class NotificationManager {
         });
   }
 
+  /**
+   * Builds a {@link Bundle} of custom data keys from a {@link StatusBarNotification} extras bundle,
+   * filtering out Android system keys, FCM/Firebase internals, and Notifee-reserved keys via {@link
+   * #shouldIncludeInData(String)}. Mirrors iOS {@code parseDataFromUserInfo:} in {@code
+   * NotifeeCoreUtil.m} on the Firebase-reserved keys ({@code fcm_options}, {@code gcm.*}, {@code
+   * google.*}, {@code aps}, etc.), with a deliberate divergence: Android uses {@code fcm.} (with
+   * dot) plus an exact-match on {@code fcm_options} to preserve realistic user keys like {@code
+   * fcmRegion} and {@code fcmToken} that iOS's broader bare-{@code fcm} prefix would also drop. See
+   * {@link #EXCLUDED_DATA_KEY_PREFIXES} and {@link #EXCLUDED_DATA_KEYS} for the full rationale.
+   *
+   * <p>Values are coerced to {@code String} via {@code toString()}. FCM {@code data} payloads are
+   * {@code Map<String, String>} by contract, so the coercion is a no-op in practice; the defensive
+   * {@code toString()} call only matters for the rare non-String extra that might survive the
+   * denylist (e.g. a numeric value added via {@code Bundle.putInt}).
+   *
+   * <p>Always returns a non-null {@code Bundle} (possibly empty) so that JS consumers can
+   * dereference {@code notification.data.foo} without null-checking {@code data} itself — matching
+   * iOS, which always returns a dictionary.
+   */
+  static Bundle extractDataFromExtras(Bundle extras) {
+    Bundle dataBundle = new Bundle();
+    if (extras == null) {
+      return dataBundle;
+    }
+    for (String key : extras.keySet()) {
+      if (!shouldIncludeInData(key)) {
+        continue;
+      }
+      Object value = extras.get(key);
+      if (value != null) {
+        dataBundle.putString(key, value.toString());
+      }
+    }
+    return dataBundle;
+  }
+
+  /**
+   * Pure denylist predicate used by {@link #extractDataFromExtras(Bundle)}. Extracted for direct
+   * unit testing without having to construct a {@link Bundle}. See the {@link
+   * #EXCLUDED_DATA_KEY_PREFIXES} docs for the reasoning behind each prefix choice.
+   */
+  static boolean shouldIncludeInData(String key) {
+    if (key == null) {
+      return false;
+    }
+    if (EXCLUDED_DATA_KEYS.contains(key)) {
+      return false;
+    }
+    for (String prefix : EXCLUDED_DATA_KEY_PREFIXES) {
+      if (key.startsWith(prefix)) {
+        return false;
+      }
+    }
+    return true;
+  }
+
   static void getTriggerNotifications(MethodCallResult<List<Bundle>> result) {
     WorkDataRepository workDataRepository = new WorkDataRepository(getApplicationContext());
 

package/android/src/test/java/app/notifee/core/GetDisplayedNotificationsDataTest.java

@@ -0,0 +1,242 @@
+package app.notifee.core;
+
+/*
+ * Copyright (c) 2016-present Invertase Limited & Contributors
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this library except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertNotNull;
+import static org.junit.Assert.assertTrue;
+
+import android.os.Bundle;
+import java.util.Arrays;
+import java.util.HashSet;
+import java.util.Set;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.robolectric.RobolectricTestRunner;
+
+/**
+ * Unit tests for {@link NotificationManager#shouldIncludeInData(String)} and {@link
+ * NotificationManager#extractDataFromExtras(android.os.Bundle)} — the denylist filter and
+ * bundle-to-bundle helper added for upstream invertase/notifee#393.
+ *
+ * <p>The end-to-end {@code getDisplayedNotifications()} path is intentionally not exercised here
+ * because it depends on {@code android.app.NotificationManager.getActiveNotifications()}, which
+ * would require a system service mock. Extracting the pure predicate and the extras iteration into
+ * helper methods lets these tests run under Robolectric with a real {@link Bundle} implementation
+ * and no system service at all.
+ */
+@RunWith(RobolectricTestRunner.class)
+public class GetDisplayedNotificationsDataTest {
+
+  // -------- shouldIncludeInData (pure predicate) --------
+
+  @Test
+  public void shouldIncludeInData_plainKey_returnsTrue() {
+    assertTrue(NotificationManager.shouldIncludeInData("event"));
+    assertTrue(NotificationManager.shouldIncludeInData("userId"));
+    assertTrue(NotificationManager.shouldIncludeInData("conversation_id"));
+  }
+
+  @Test
+  public void shouldIncludeInData_androidPrefix_returnsFalse() {
+    assertFalse(NotificationManager.shouldIncludeInData("android.title"));
+    assertFalse(NotificationManager.shouldIncludeInData("android.text"));
+  }
+
+  @Test
+  public void shouldIncludeInData_androidLookalike_returnsTrue() {
+    // The `android.` prefix intentionally includes the dot, so custom keys that
+    // merely begin with the substring `android` are not accidentally filtered.
+    assertTrue(NotificationManager.shouldIncludeInData("androidify"));
+    assertTrue(NotificationManager.shouldIncludeInData("androidish"));
+  }
+
+  @Test
+  public void shouldIncludeInData_googlePrefix_returnsFalse() {
+    assertFalse(NotificationManager.shouldIncludeInData("google.sent_time"));
+    assertFalse(NotificationManager.shouldIncludeInData("google.delivered_priority"));
+  }
+
+  @Test
+  public void shouldIncludeInData_googleLookalike_returnsTrue() {
+    // Same reasoning as androidLookalike — `google.` with dot keeps the filter precise.
+    assertTrue(NotificationManager.shouldIncludeInData("googleish"));
+    assertTrue(NotificationManager.shouldIncludeInData("googlebot"));
+  }
+
+  @Test
+  public void shouldIncludeInData_gcmPrefix_returnsFalse() {
+    assertFalse(NotificationManager.shouldIncludeInData("gcm.notification.foo"));
+    assertFalse(NotificationManager.shouldIncludeInData("gcm.n.e"));
+  }
+
+  @Test
+  public void shouldIncludeInData_notifeePrefix_returnsFalse() {
+    // "notifee.notification" and "notifee.trigger" are the current internal
+    // constants (EXTRA_NOTIFEE_NOTIFICATION / EXTRA_NOTIFEE_TRIGGER). They
+    // are caught by the no-dot `notifee` prefix.
+    assertFalse(NotificationManager.shouldIncludeInData("notifee.notification"));
+    assertFalse(NotificationManager.shouldIncludeInData("notifee.trigger"));
+
+    // `notifee` is INTENTIONALLY kept without the dot: the library reserves
+    // its own namespace entirely, so `notifeeFoo` is also filtered. This
+    // differs from `fcm.` (with dot, see below): for `notifee` the whole
+    // prefix is library-owned and can collide with future internal constants,
+    // whereas `fcm` is a third-party namespace where we prefer to let
+    // realistic user keys like `fcmRegion` or `fcmToken` survive.
+    assertFalse(NotificationManager.shouldIncludeInData("notifeeFoo"));
+  }
+
+  @Test
+  public void shouldIncludeInData_fcmDottedPrefix_returnsFalse() {
+    // `fcm.` uses the trailing dot so realistic user custom keys (fcmRegion,
+    // fcmToken, fcmlike) can round-trip through `data`. This diverges from
+    // iOS parseDataFromUserInfo:, which uses bare `[key hasPrefix:@"fcm"]`
+    // specifically to catch `fcm_options` (see the `// fcm_options` marker
+    // at NotifeeCoreUtil.m:627-628 and the dedicated
+    // shouldIncludeInData_fcmOptionsExactKey_returnsFalse test above). Both
+    // platforms drop `fcm_options`; Android additionally preserves bare-fcm
+    // user keys (fcmRegion, fcmToken, …) that iOS drops as collateral.
+    assertFalse(NotificationManager.shouldIncludeInData("fcm.notification"));
+    assertFalse(NotificationManager.shouldIncludeInData("fcm.foo"));
+  }
+
+  @Test
+  public void shouldIncludeInData_fcmLookalike_returnsTrue() {
+    // These survive the Android filter. They would NOT survive the iOS
+    // filter, which is an accepted cross-platform divergence in favor of
+    // preserving realistic user data on Android. Note: `fcm_options` is a
+    // deliberate EXCEPTION to this rule — see the dedicated test
+    // shouldIncludeInData_fcmOptionsExactKey_returnsFalse below.
+    assertTrue(NotificationManager.shouldIncludeInData("fcm"));
+    assertTrue(NotificationManager.shouldIncludeInData("fcmlike"));
+    assertTrue(NotificationManager.shouldIncludeInData("fcmRegion"));
+    assertTrue(NotificationManager.shouldIncludeInData("fcmToken"));
+  }
+
+  @Test
+  public void shouldIncludeInData_fcmOptionsExactKey_returnsFalse() {
+    // `fcm_options` is the Firebase HTTP v1 Message.fcm_options analytics
+    // label. On iOS it is caught by the bare `[key hasPrefix:@"fcm"]` filter
+    // in NotifeeCoreUtil.m:627-628, which has an inline `// fcm_options`
+    // comment documenting that the whole reason the iOS prefix is bare (not
+    // dotted) is specifically to drop this key. On Android we switched the
+    // prefix to `fcm.` (with dot) so realistic user keys like `fcmRegion`
+    // can survive — but that alone would leak `fcm_options`. This test
+    // guards the exact-match entry in EXCLUDED_DATA_KEYS that restores
+    // parity with iOS for the one Firebase-reserved bare-`fcm` key.
+    assertFalse(NotificationManager.shouldIncludeInData("fcm_options"));
+  }
+
+  @Test
+  public void shouldIncludeInData_exactKeyBlocklist_returnsFalse() {
+    assertFalse(NotificationManager.shouldIncludeInData("from"));
+    assertFalse(NotificationManager.shouldIncludeInData("collapse_key"));
+    assertFalse(NotificationManager.shouldIncludeInData("message_type"));
+    assertFalse(NotificationManager.shouldIncludeInData("message_id"));
+    assertFalse(NotificationManager.shouldIncludeInData("aps"));
+  }
+
+  @Test
+  public void shouldIncludeInData_nullKey_returnsFalse() {
+    assertFalse(NotificationManager.shouldIncludeInData(null));
+  }
+
+  // -------- extractDataFromExtras (bundle → bundle) --------
+
+  @Test
+  public void extractDataFromExtras_nullExtras_returnsEmptyBundle() {
+    Bundle result = NotificationManager.extractDataFromExtras(null);
+    assertNotNull(result);
+    assertEquals(0, result.size());
+  }
+
+  @Test
+  public void extractDataFromExtras_emptyExtras_returnsEmptyBundle() {
+    Bundle result = NotificationManager.extractDataFromExtras(new Bundle());
+    assertNotNull(result);
+    assertEquals(0, result.size());
+  }
+
+  @Test
+  public void extractDataFromExtras_mixedKeys_returnsOnlyCustomKeys() {
+    Bundle extras = new Bundle();
+
+    // Custom keys that should survive the filter.
+    extras.putString("event", "chat_msg");
+    extras.putString("userId", "42");
+
+    // System keys that must be dropped.
+    extras.putString("android.title", "Hello");
+    extras.putString("android.text", "Body");
+    extras.putString("google.sent_time", "123456");
+    extras.putString("gcm.notification.e", "1");
+    extras.putString("from", "12345");
+    extras.putString("collapse_key", "do_not_collapse");
+    extras.putString("message_id", "msg-abc");
+    extras.putString("notifee.notification", "internal");
+    extras.putString("fcm.foo", "reserved-dotted");
+
+    // Custom key matching the iOS-divergent survivor pattern: `fcmRegion`
+    // must appear in the result on Android, even though iOS would drop it.
+    extras.putString("fcmRegion", "eu-west-1");
+
+    // Non-String value to verify toString() coercion for the rare survivor.
+    extras.putInt("count", 5);
+
+    Bundle result = NotificationManager.extractDataFromExtras(extras);
+    assertNotNull(result);
+
+    Set<String> expected = new HashSet<>(Arrays.asList("event", "userId", "fcmRegion", "count"));
+    assertEquals(expected, result.keySet());
+    assertEquals("chat_msg", result.getString("event"));
+    assertEquals("42", result.getString("userId"));
+    assertEquals("eu-west-1", result.getString("fcmRegion"));
+    assertEquals("5", result.getString("count"));
+  }
+
+  @Test
+  public void extractDataFromExtras_onlySystemKeys_returnsEmptyBundle() {
+    Bundle extras = new Bundle();
+    extras.putString("android.title", "Hello");
+    extras.putString("google.sent_time", "123");
+    extras.putString("gcm.notification.foo", "bar");
+    extras.putString("notifee.trigger", "internal");
+    extras.putString("from", "12345");
+    extras.putString("fcm.options", "reserved-dotted");
+    // Firebase analytics label — exact-match filtered for iOS parity,
+    // see shouldIncludeInData_fcmOptionsExactKey_returnsFalse.
+    extras.putString("fcm_options", "{\"analytics_label\":\"foo\"}");
+
+    Bundle result = NotificationManager.extractDataFromExtras(extras);
+    assertNotNull(result);
+    assertEquals(0, result.size());
+  }
+
+  @Test
+  public void extractDataFromExtras_nullValueForCustomKey_isSkipped() {
+    Bundle extras = new Bundle();
+    extras.putString("event", "chat_msg");
+    extras.putString("nullable", null);
+
+    Bundle result = NotificationManager.extractDataFromExtras(extras);
+    assertNotNull(result);
+    assertEquals(1, result.size());
+    assertEquals("chat_msg", result.getString("event"));
+  }
+}

package/cli/bin/react-native-notify-kit

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+require('../dist/cli.js');