react-native-notify-kit 9.5.0 → 9.7.0

package/android/src/test/java/app/notifee/core/model/TimestampTriggerModelTest.java

@@ -2,16 +2,37 @@ package app.notifee.core.model;
 
 import static org.junit.Assert.assertEquals;
 import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertTrue;
 
 import android.os.Bundle;
+import java.util.Calendar;
+import java.util.TimeZone;
+import org.junit.After;
+import org.junit.Assume;
 import org.junit.Before;
 import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.robolectric.RobolectricTestRunner;
 
+@RunWith(RobolectricTestRunner.class)
 public class TimestampTriggerModelTest {
+  private static final long ONE_MINUTE_MS = 60L * 1000L;
+  private static final long ONE_HOUR_MS = 60L * 60L * 1000L;
+  private static final long ONE_DAY_MS = 24L * ONE_HOUR_MS;
+
+  private static final int REPEAT_FREQUENCY_HOURLY = 0;
+  private static final int REPEAT_FREQUENCY_DAILY = 1;
+  private static final int REPEAT_FREQUENCY_WEEKLY = 2;
+
   private TimestampTriggerModel mTimestampTriggerModel = null;
+  private TimeZone mOriginalTimeZone;
+  private long mNow;
 
   @Before
   public void before() {
+    mOriginalTimeZone = TimeZone.getDefault();
+    mNow = System.currentTimeMillis();
+
     Bundle trigger = new Bundle();
     Bundle triggerComponents = new Bundle();
     triggerComponents.putInt("minute", 1);
@@ -20,16 +41,18 @@ public class TimestampTriggerModelTest {
     triggerComponents.putInt("month", 12);
     triggerComponents.putInt("weekday", 3);
     triggerComponents.putInt("weekdayOrdinal", 2);
-
-    // The ISO 8601 week date of the year.
     triggerComponents.putInt("weekOfYear", 24);
-    // The week number of the months.
     triggerComponents.putInt("weekOfMonth", 2);
 
     trigger.putBundle("components", triggerComponents);
     mTimestampTriggerModel = TimestampTriggerModel.fromBundle(trigger);
   }
 
+  @After
+  public void after() {
+    TimeZone.setDefault(mOriginalTimeZone);
+  }
+
   @Test
   public void testBundleValues() {
     assertEquals(
@@ -41,4 +64,177 @@ public class TimestampTriggerModelTest {
     assertEquals(
         "with no 'repeatFrequency', delay should be 0", 0, mTimestampTriggerModel.getDelay());
   }
+
+  // Regression tests for the DAILY/WEEKLY/HOURLY rescheduling cycle. Guard the fix for
+  // upstream invertase/notifee#839 (DAILY trigger fails to re-fire from day 2 onwards on
+  // Android) and #875 (DST-safe Calendar.add for repeat frequency) against future refactors
+  // of TimestampTriggerModel.setNextTimestamp().
+
+  private TimestampTriggerModel buildRepeatingTrigger(long timestamp, int repeatFrequency) {
+    Bundle trigger = new Bundle();
+    trigger.putLong("timestamp", timestamp);
+    trigger.putInt("repeatFrequency", repeatFrequency);
+    return TimestampTriggerModel.fromBundle(trigger);
+  }
+
+  @Test
+  public void setNextTimestamp_daily_advancesToTomorrowSameWallClock() {
+    long original = mNow - ONE_MINUTE_MS;
+    TimestampTriggerModel trigger = buildRepeatingTrigger(original, REPEAT_FREQUENCY_DAILY);
+
+    Calendar originalCal = Calendar.getInstance();
+    originalCal.setTimeInMillis(original);
+    int originalHour = originalCal.get(Calendar.HOUR_OF_DAY);
+    int originalMinute = originalCal.get(Calendar.MINUTE);
+    int originalSecond = originalCal.get(Calendar.SECOND);
+
+    trigger.setNextTimestamp();
+    long next = trigger.getTimestamp();
+
+    assertTrue("next timestamp must be in the future", next > mNow);
+    assertTrue("next timestamp must be within 25h", next < mNow + 25L * ONE_HOUR_MS);
+
+    Calendar nextCal = Calendar.getInstance();
+    nextCal.setTimeInMillis(next);
+    assertEquals("wall-clock hour preserved", originalHour, nextCal.get(Calendar.HOUR_OF_DAY));
+    assertEquals("wall-clock minute preserved", originalMinute, nextCal.get(Calendar.MINUTE));
+    assertEquals("wall-clock second preserved", originalSecond, nextCal.get(Calendar.SECOND));
+  }
+
+  @Test
+  public void setNextTimestamp_daily_multipleMissedFires_skipsToFuture() {
+    // Offset by 1 minute so the original does not land exactly on a multiple of 24h from mNow.
+    // Otherwise, with a deterministic clock (e.g. Robolectric), the while-loop's `<` comparison
+    // exits precisely at `cal == now` and next equals mNow, which is not strictly in the future.
+    long original = mNow - 3L * ONE_DAY_MS - ONE_MINUTE_MS;
+    TimestampTriggerModel trigger = buildRepeatingTrigger(original, REPEAT_FREQUENCY_DAILY);
+
+    trigger.setNextTimestamp();
+    long next = trigger.getTimestamp();
+
+    assertTrue("next timestamp must be in the future after 3 missed fires", next > mNow);
+    assertTrue("next timestamp must not be more than 25h ahead", next < mNow + 25L * ONE_HOUR_MS);
+  }
+
+  @Test
+  public void setNextTimestamp_weekly_advancesOneWeek() {
+    long original = mNow - ONE_MINUTE_MS;
+    TimestampTriggerModel trigger = buildRepeatingTrigger(original, REPEAT_FREQUENCY_WEEKLY);
+
+    trigger.setNextTimestamp();
+    long next = trigger.getTimestamp();
+
+    long lower = mNow + 6L * ONE_DAY_MS + 23L * ONE_HOUR_MS;
+    long upper = mNow + 7L * ONE_DAY_MS + ONE_HOUR_MS;
+    assertTrue("weekly next timestamp must be >= now + 6d23h", next >= lower);
+    assertTrue("weekly next timestamp must be <= now + 7d1h", next <= upper);
+  }
+
+  @Test
+  public void setNextTimestamp_hourly_advancesOneHour() {
+    long original = mNow - ONE_MINUTE_MS;
+    TimestampTriggerModel trigger = buildRepeatingTrigger(original, REPEAT_FREQUENCY_HOURLY);
+
+    trigger.setNextTimestamp();
+    long next = trigger.getTimestamp();
+
+    long lower = mNow + 59L * ONE_MINUTE_MS;
+    long upper = mNow + 61L * ONE_MINUTE_MS;
+    assertTrue("hourly next timestamp must be >= now + 59m", next >= lower);
+    assertTrue("hourly next timestamp must be <= now + 61m", next <= upper);
+  }
+
+  @Test
+  public void setNextTimestamp_dailyAcrossDstSpringForward() {
+    // Europe/Rome spring-forward 2026: 2026-03-29 02:00 local jumps to 03:00 local. The 29
+    // March 2026 calendar day is 23 hours long in Europe/Rome. Using 04:30 (NOT 01:30) as
+    // the wall-clock: 04:30 on 2026-03-28 is CET (UTC+1), while 04:30 on 2026-03-29 is CEST
+    // (UTC+2). Calendar.add(DAY_OF_MONTH, 1) preserves the local 04:30 wall-clock across the
+    // boundary; a hypothetical refactor to +86_400_000 ms fixed arithmetic would drift the
+    // wall-clock to 05:30 CEST on the day after the crossing. Using 01:30 would NOT
+    // discriminate because 01:30 sits in the same UTC offset on both sides of the transition.
+    TimeZone rome = TimeZone.getTimeZone("Europe/Rome");
+    TimeZone.setDefault(rome);
+
+    Calendar start = Calendar.getInstance(rome);
+    start.clear();
+    start.set(2026, Calendar.MARCH, 28, 4, 30, 0);
+    long originalTimestamp = start.getTimeInMillis();
+
+    // Assume the current wall-clock is in the post-spring-forward / pre-fall-back window for
+    // 2026. Outside this window the while-loop inside setNextTimestamp either does not run
+    // (future-dated start) or crosses an even number of DST boundaries whose effects cancel
+    // for fixed-ms arithmetic, making the assertion non-discriminative.
+    Calendar windowStart = Calendar.getInstance(rome);
+    windowStart.clear();
+    windowStart.set(2026, Calendar.MARCH, 30, 0, 0, 0);
+    Calendar windowEnd = Calendar.getInstance(rome);
+    windowEnd.clear();
+    windowEnd.set(2026, Calendar.OCTOBER, 24, 23, 59, 59);
+    long now = System.currentTimeMillis();
+    Assume.assumeTrue(
+        "spring-forward discrimination requires current time in [2026-03-30, 2026-10-24]"
+            + " Europe/Rome",
+        now >= windowStart.getTimeInMillis() && now <= windowEnd.getTimeInMillis());
+
+    TimestampTriggerModel trigger =
+        buildRepeatingTrigger(originalTimestamp, REPEAT_FREQUENCY_DAILY);
+    trigger.setNextTimestamp();
+    long next = trigger.getTimestamp();
+
+    Calendar nextCal = Calendar.getInstance(rome);
+    nextCal.setTimeInMillis(next);
+    assertTrue("next timestamp must be >= now", next >= now);
+    assertEquals(
+        "wall-clock hour must remain 4 after crossing spring-forward",
+        4,
+        nextCal.get(Calendar.HOUR_OF_DAY));
+    assertEquals("wall-clock minute must remain 30", 30, nextCal.get(Calendar.MINUTE));
+    assertEquals("wall-clock second must remain 0", 0, nextCal.get(Calendar.SECOND));
+  }
+
+  @Test
+  public void setNextTimestamp_dailyAcrossDstFallBack() {
+    // Europe/Rome fall-back 2025: 2025-10-26 03:00 local reverts to 02:00 local. The 26
+    // October 2025 calendar day is 25 hours long. Starting at 2025-10-25 04:30 CEST (UTC+2)
+    // — the day before the fall-back — the local 04:30 wall-clock on 2025-10-26 is CET
+    // (UTC+1). Calendar.add preserves the 04:30 local wall-clock; +86_400_000 ms would drift
+    // it to 03:30 CET after the crossing.
+    TimeZone rome = TimeZone.getTimeZone("Europe/Rome");
+    TimeZone.setDefault(rome);
+
+    Calendar start = Calendar.getInstance(rome);
+    start.clear();
+    start.set(2025, Calendar.OCTOBER, 25, 4, 30, 0);
+    long originalTimestamp = start.getTimeInMillis();
+
+    // Assume the current wall-clock is in the post-fall-back-2025 / pre-spring-forward-2026
+    // window, so the setNextTimestamp loop crosses exactly one DST boundary (the fall-back)
+    // and the test remains discriminative against fixed-ms arithmetic.
+    Calendar windowStart = Calendar.getInstance(rome);
+    windowStart.clear();
+    windowStart.set(2025, Calendar.OCTOBER, 27, 0, 0, 0);
+    Calendar windowEnd = Calendar.getInstance(rome);
+    windowEnd.clear();
+    windowEnd.set(2026, Calendar.MARCH, 28, 23, 59, 59);
+    long now = System.currentTimeMillis();
+    Assume.assumeTrue(
+        "fall-back discrimination requires current time in [2025-10-27, 2026-03-28] Europe/Rome",
+        now >= windowStart.getTimeInMillis() && now <= windowEnd.getTimeInMillis());
+
+    TimestampTriggerModel trigger =
+        buildRepeatingTrigger(originalTimestamp, REPEAT_FREQUENCY_DAILY);
+    trigger.setNextTimestamp();
+    long next = trigger.getTimestamp();
+
+    Calendar nextCal = Calendar.getInstance(rome);
+    nextCal.setTimeInMillis(next);
+    assertTrue("next timestamp must be >= now", next >= now);
+    assertEquals(
+        "wall-clock hour must remain 4 after crossing fall-back",
+        4,
+        nextCal.get(Calendar.HOUR_OF_DAY));
+    assertEquals("wall-clock minute must remain 30", 30, nextCal.get(Calendar.MINUTE));
+    assertEquals("wall-clock second must remain 0", 0, nextCal.get(Calendar.SECOND));
+  }
 }

package/android/src/test/java/io/invertase/notifee/HeadlessTaskConfigTest.kt

@@ -0,0 +1,34 @@
+package io.invertase.notifee
+
+import com.facebook.react.bridge.WritableMap
+import org.junit.Test
+import org.mockito.ArgumentMatchers.anyInt
+import org.mockito.ArgumentMatchers.anyString
+import org.mockito.Mockito.mock
+import org.mockito.Mockito.never
+import org.mockito.Mockito.times
+import org.mockito.Mockito.verify
+import org.mockito.Mockito.`when`
+
+class HeadlessTaskConfigTest {
+
+    // Regression guard for invertase/notifee#266: the init block must copy the caller's
+    // WritableMap before mutating it, otherwise a later .copy() on the already-consumed map crashes.
+    @Test
+    fun taskConfig_copiesParamsBeforeMutating_keepsCallerMapPristine() {
+        val original = mock(WritableMap::class.java)
+        val copy = mock(WritableMap::class.java)
+        `when`(original.copy()).thenReturn(copy)
+
+        HeadlessTask.TaskConfig(
+            "NotifeeHeadlessJS",
+            60_000L,
+            original,
+            null,
+        )
+
+        verify(original, never()).putInt(anyString(), anyInt())
+        verify(original, times(1)).copy()
+        verify(copy, times(1)).putInt(anyString(), anyInt())
+    }
+}

package/dist/types/Notification.d.ts

@@ -32,10 +32,41 @@ export interface Notification {
      */
     body?: string | undefined;
     /**
-     * Additional data to store on the notification.
-     *
-     * Data can be used to provide additional context to your notification which can be retrieved
-     * at a later point in time (e.g. via an event).
+     * Additional data to associate with the notification.
+     *
+     * On Android, when populated by `getDisplayedNotifications()`, the `data`
+     * field reflects custom keys present in the underlying `Notification.extras`,
+     * with the following keys filtered out: prefixes `android.`, `google.`,
+     * `gcm.`, `fcm.` (with trailing dot — `fcmRegion` survives), and `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`.
+     *
+     * **Important FCM platform limitation on Android**: 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` and never on `Notification.extras`. This is FCM's design
+     * (see `CommonNotificationBuilder.createContentIntent` in the firebase-android-sdk
+     * source) and cannot be worked around from any library — the PendingIntent's
+     * extras are sealed by Android's security model. Tracked in
+     * firebase-android-sdk#2639 (open since 2021).
+     *
+     * The `data` field DOES surface custom keys for: notifications created via
+     * `notifee.displayNotification({ data })`, FCM data-only messages handled
+     * in `onMessageReceived` followed by an explicit `displayNotification()`,
+     * custom `FirebaseMessagingService.handleIntent` overrides that inject
+     * extras before display, and notifications posted by other libraries that
+     * call `NotificationCompat.Builder.addExtras(bundle)`.
+     *
+     * Recommended pattern for full control over FCM push notifications on Android:
+     * send FCM data-only messages (no `notification` field server-side), handle
+     * them in `onMessageReceived`, and render the notification via
+     * `notifee.displayNotification()`.
+     *
+     * Note: the `fcm` filter diverges from iOS, which uses a broader bare-`fcm*`
+     * prefix filter (deliberately, to catch `fcm_options`). On Android, only
+     * `fcm.` (with dot) and the exact key `fcm_options` are filtered — custom
+     * keys like `fcmRegion` are preserved on Android but filtered on iOS.
      */
     data?: {
         [key: string]: string | object | number;

package/dist/types/Notification.js.map

@@ -1 +1 @@
-{"version":3,"file":"Notification.js","sourceRoot":"","sources":["../../src/types/Notification.ts"],"names":[],"mappings":"AAAA;;GAEG;AA6SH;;;;;GAKG;AACH,MAAM,CAAN,IAAY,SA2EX;AA3ED,WAAY,SAAS;IACnB;;;;;OAKG;IACH,gDAAY,CAAA;IAEZ;;;;;;;OAOG;IACH,mDAAa,CAAA;IAEb;;;;;;OAMG;IACH,2CAAS,CAAA;IAET;;OAEG;IACH,yDAAgB,CAAA;IAEhB;;;;;;OAMG;IACH,mDAAa,CAAA;IAEb;;;;;OAKG;IACH,uDAAe,CAAA;IAEf;;;;OAIG;IACH,+DAAmB,CAAA;IAEnB;;;;OAIG;IACH,2EAAyB,CAAA;IAEzB;;OAEG;IACH,yFAAgC,CAAA;IAEhC;;;;OAIG;IACH,iEAAoB,CAAA;AACtB,CAAC,EA3EW,SAAS,KAAT,SAAS,QA2EpB;AA+ED;;;;;;GAMG;AACH,MAAM,CAAN,IAAY,mBA0BX;AA1BD,WAAY,mBAAmB;IAC7B;;;;;;;OAOG;IACH,kFAAmB,CAAA;IAEnB;;OAEG;IACH,iEAAU,CAAA;IAEV;;OAEG;IACH,yEAAc,CAAA;IAEd;;;OAGG;IACH,2EAAe,CAAA;AACjB,CAAC,EA1BW,mBAAmB,KAAnB,mBAAmB,QA0B9B"}
+{"version":3,"file":"Notification.js","sourceRoot":"","sources":["../../src/types/Notification.ts"],"names":[],"mappings":"AAAA;;GAEG;AA4UH;;;;;GAKG;AACH,MAAM,CAAN,IAAY,SA2EX;AA3ED,WAAY,SAAS;IACnB;;;;;OAKG;IACH,gDAAY,CAAA;IAEZ;;;;;;;OAOG;IACH,mDAAa,CAAA;IAEb;;;;;;OAMG;IACH,2CAAS,CAAA;IAET;;OAEG;IACH,yDAAgB,CAAA;IAEhB;;;;;;OAMG;IACH,mDAAa,CAAA;IAEb;;;;;OAKG;IACH,uDAAe,CAAA;IAEf;;;;OAIG;IACH,+DAAmB,CAAA;IAEnB;;;;OAIG;IACH,2EAAyB,CAAA;IAEzB;;OAEG;IACH,yFAAgC,CAAA;IAEhC;;;;OAIG;IACH,iEAAoB,CAAA;AACtB,CAAC,EA3EW,SAAS,KAAT,SAAS,QA2EpB;AA+ED;;;;;;GAMG;AACH,MAAM,CAAN,IAAY,mBA0BX;AA1BD,WAAY,mBAAmB;IAC7B;;;;;;;OAOG;IACH,kFAAmB,CAAA;IAEnB;;OAEG;IACH,iEAAU,CAAA;IAEV;;OAEG;IACH,yEAAc,CAAA;IAEd;;;OAGG;IACH,2EAAe,CAAA;AACjB,CAAC,EA1BW,mBAAmB,KAAnB,mBAAmB,QA0B9B"}

package/dist/version.d.ts

@@ -1 +1 @@
-export declare const version = "9.5.0";
+export declare const version = "9.7.0";

package/dist/version.js

@@ -1,3 +1,3 @@
 // Generated by genversion.
-export const version = '9.5.0';
+export const version = '9.7.0';
 //# sourceMappingURL=version.js.map

package/jest-mock.js

@@ -26,6 +26,7 @@ export const testNotification = {
   id: 'test-id',
   title: 'test-title',
   body: 'test-body',
+  data: { event: 'test_event', userId: '42' },
   android: {
     channelId: 'default',
   },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "react-native-notify-kit",
-  "version": "9.5.0",
+  "version": "9.7.0",
   "author": "Marco Crupi",
   "description": "Maintained Notifee-compatible fork for React Native — advanced local notifications for Android & iOS.",
   "main": "dist/index.js",

package/src/types/Notification.ts

@@ -46,10 +46,41 @@ export interface Notification {
   body?: string | undefined;
 
   /**
-   * Additional data to store on the notification.
-   *
-   * Data can be used to provide additional context to your notification which can be retrieved
-   * at a later point in time (e.g. via an event).
+   * Additional data to associate with the notification.
+   *
+   * On Android, when populated by `getDisplayedNotifications()`, the `data`
+   * field reflects custom keys present in the underlying `Notification.extras`,
+   * with the following keys filtered out: prefixes `android.`, `google.`,
+   * `gcm.`, `fcm.` (with trailing dot — `fcmRegion` survives), and `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`.
+   *
+   * **Important FCM platform limitation on Android**: 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` and never on `Notification.extras`. This is FCM's design
+   * (see `CommonNotificationBuilder.createContentIntent` in the firebase-android-sdk
+   * source) and cannot be worked around from any library — the PendingIntent's
+   * extras are sealed by Android's security model. Tracked in
+   * firebase-android-sdk#2639 (open since 2021).
+   *
+   * The `data` field DOES surface custom keys for: notifications created via
+   * `notifee.displayNotification({ data })`, FCM data-only messages handled
+   * in `onMessageReceived` followed by an explicit `displayNotification()`,
+   * custom `FirebaseMessagingService.handleIntent` overrides that inject
+   * extras before display, and notifications posted by other libraries that
+   * call `NotificationCompat.Builder.addExtras(bundle)`.
+   *
+   * Recommended pattern for full control over FCM push notifications on Android:
+   * send FCM data-only messages (no `notification` field server-side), handle
+   * them in `onMessageReceived`, and render the notification via
+   * `notifee.displayNotification()`.
+   *
+   * Note: the `fcm` filter diverges from iOS, which uses a broader bare-`fcm*`
+   * prefix filter (deliberately, to catch `fcm_options`). On Android, only
+   * `fcm.` (with dot) and the exact key `fcm_options` are filtered — custom
+   * keys like `fcmRegion` are preserved on Android but filtered on iOS.
    */
   data?: { [key: string]: string | object | number };
 

package/src/version.ts

@@ -1,2 +1,2 @@
 // Generated by genversion.
-export const version = '9.5.0';
+export const version = '9.7.0';