Android: Fullscreen notification bypasses lockscreen and presents entire app (Incoming Calls)

[ice-cap0]

Hi everyone and thanks to the authors for open-sourcing and maintaining this

Use case: Incoming Call on Lock Screen.

After this exact sequence
1- killing the app
2- awakening it with server-sent high importance notification below
3- dismissing the notification
4- locking the screen
5- resending the same notification

The notification bypasses lockscreen and just opens the app on top of it, every time, without entering passcode, with full access to the app (but not past the lock screen). Seems like a big footgun.

Is this a bug or a feature ?

More generally: Is it possible today with notifee to get basic Incoming Call notifications going? With similar behavior users expect: turns on lock screen, occupies it full screen and displays/vibrates/rings until interacted with.

mainComponent sounds like a good lead but it isn't quite clear in the docs what it can or cannot do (props? navigate back to main app?)

const displayCallNotificationAndroid = async ({
  callId,
  callerName,
  hasVideo,
}: {
  callId: string;
  callerName: string;
  hasVideo: boolean;
}) => {
  console.log('📞 📥  displayCallNotificationAndroid: ', callId);

  const channelId = await notifee.createChannel({
    id: 'nugget-calls',
    name: 'nugget-calls',
    importance: AndroidImportance.HIGH,
  });

  const dnr = await notifee.displayNotification({
    title: callerName,
    body: `is calling you on ${hasVideo ? 'video' : 'voice'}...`,
    id: callId,
    android: {
      channelId,
      smallIcon: 'ic_launcher_round',
      color: '#dedede',
      category: AndroidCategory.CALL,
      importance: AndroidImportance.HIGH,
      fullScreenAction: {
        id: 'default',
      },
      actions: [
        {
          title: 'Decline',
          pressAction: {
            id: 'decline-call',
          },
        },
        {
          title: 'Answer',
          pressAction: {
            id: 'answer-call',
          },
        },
      ],
      lightUpScreen: true,
      // asForegroundService: true,
      colorized: true,
    },
  });
  console.log('🔭 displayNotification result: ', dnr);
};

Samsung s10e 
Android 12
compileSdkVersion = 31
"react-native": "^0.68.0",
"@react-native-firebase/app": "^13.0.1",
"@react-native-firebase/messaging": "^13.0.1",
"@notifee/react-native": "^5.4.1",

Thanks!

[ice-cap0]

Not sure what kind of work this would entail, but an Incoming Call UI as described above would fill a massive, gaping void in the ecosystem. Basically all calling apps need this, and there is no credible js-only solution

Even react-native-callkeep does not solve this, as the native call UI on Android doesn't work on all devices (?). It is left for us to build:

When showIncomingCallUi is fired, you must show an incoming call UI. This would be a high priority notification

Sounds like notifee is on the cusp of filling that void, but 1- launchActivity requires writing native and 2- docs are unclear wrt purpose/behavior/usage of mainComponent (as mentioned above)

If this is just a docs issue, and mainComponent actually addresses this use case, I will 100% be making a PR to the docs if someone can explain to me how it is used.

Otherwise I guess this is a Feature Request :)

Community packages proving the pain point/blind spot

https://github.com/bharathselva28/react-native-incoming-call-android
https://github.com/linhvovan29546/react-native-full-screen-notification-incoming-call
https://github.com/bkdev98/react-native-incoming-call#readme

[mikehardy]

This is vague, my apologies in advance, but I believe some people are using notifee to handle incoming calls. How it interacts with the lock screen, I'm not sure.

Is this the gap you are talking about?

The notification bypasses lockscreen and just opens the app on top of it, every time, without entering passcode, with full access to the app (but not past the lock screen). Seems like a big footgun.

Is there anything else? I think it is either a docs issue, or perhaps a minor missing bit where we can grant some indication of whether the screen is locked or not so you can handle navigation differently in the "received a call on a locked phone" case, similar to people handling navigation differently in the "app is open but user is not logged in" case, with different navigation sets

[ice-cap0]

Hm did not think of that, since it's still just the app being presented, you could just use getInitialNotification to route navigation on mount. We would then be missing like you mentioned an un/locked flag, but also a means to close the fullscreened notification/app to go back to the lockscreen.

However I still think that's a foot gun. I may be totally wrong but I don't think it's expected behavior that a full screen notification just opens your app passed the lock screen.

An actual fullscreen notification UI element, with the same semantics as all other notifications would be much more intuitive imho wrt separation of concerns. In fact that's pretty much what the wording in the docs seems to indicate, that notifee has a physical/native "full screen notification"

You may want to display a full-screen notification for time-sensitive, urgent notifications. For example, an ongoing alarm or an incoming call.
Full-screen actions have the same properties as press actions

Is there such a thing or are we in fact talking about the actions on the non-fullscreen, heads-up state of the fullscreen notification (that android renders if device is open)? Because the only fullscreen I get, is the app itself when it bypasses device lock, which obviously doesn't have any of the notifee press actions.

Also what does mainComponent do?

[ice-cap0]

Turns out getInitialNotification returns null when the app is loaded as a fullscreen notification (it doesn't return itself). Resorted to passing a flag in data to loop thru getDisplayedNotifications.

The solution is def the one you mentioned, to

grant some indication of whether the screen is locked or not

[alexander01202]

Hello. I am having a problem using this fullscreen notification. I have set mine but it just shows up as a normal notification. I have properly edited my androidManifest.xml and it shows... But it still doesn't send a full screen notification... This is my code:

const channelId = await notifee.createChannel({
      id: 'default',
      name: 'Default Channel',
    });
    notifee.displayNotification({
        // title: 'Notification Title',
        body: 'Full-screen notification',
        android: {
            channelId,
          // Recommended to set a category
          category: AndroidCategory.CALL,
          // Recommended to set importance to high
          importance: AndroidImportance.HIGH,
          fullScreenAction: {
            id: 'default',
          },
        },
    });

Please is there anything I'm doing wrong?

[ice-cap0]

AFAICT android only displays it fullscreen when the phone is locked/closed

[mikehardy]

That's my experience with whatsapp at least as well - only fullscreen if locked/closed

[ice-cap0]

mikehardy, would the lockscreen check be something that you guys would consider integrating into notifee? It's really the only piece missing for the Incoming Call feature if we use this approach

If so, is there perhaps a means to place a bounty on this feature to speed things up?

I'd also be willing to try my hand at writing the native module myself but I've never written Android. If you don't think the feature itself is all that complicated, I may just give it a shot 😄 along with a nice PR to the docs

[alexander01202]

So are you saying I can only do fullscreen while listening for background notification and displaying it using notifee?

[mikehardy]

So are you saying I can only do fullscreen while listening for background notification and displaying it using notifee?

Careful with the terms! "notification" is easily confused as the term is overloaded. Let's use:

"FCM" / "Cloud Message" - this is a block of JSON from a server to the device, could contain anything
"notification" (or "notification FCM") - this is an FCM *that contains a notification block"
"mixed content message" - this is an FCM with notification and data block
"data-only message" - this is an FCM with no notification block, just data.

That's important because you have to be able to speak accurately/precisely in order to test and offer advice on delivery reliability expectations.

In this case I think you mean a data-only message? If that's the case then yes, I think you are right (though @shawarmaz has more recent testing here...) and it should be reliable on android. But not iOS, you'll need a notification extension handler there and to use a "notification FCM"

You can see how if you say "background notification" it's confusing, is that data-only? Does it have a notification block? The answers to those questions could go either way and would result in maybe unreliable advice for iOS

[mikehardy]

mikehardy, would the lockscreen check be something that you guys would consider integrating into notifee? It's really the only piece missing for the Incoming Call feature if we use this approach

Absolutely, that's really useful in combination with intentional / intended support for this use case

If so, is there perhaps a means to place a bounty on this feature to speed things up?

Not sure that would actually help, I think we're all about 300% utilized at the moment 😆 - along with you I'm sure

I'd also be willing to try my hand at writing the native module myself but I've never written Android. If you don't think the feature itself is all that complicated, I may just give it a shot smile along with a nice PR to the docs

It looks trivial as a bit of code - https://stackoverflow.com/a/8668648/9910298

The hard part will be to implement it well here. I think this belongs in the core library as a feature really, then with react-native wrapping it.

@helenaford if you could wave a wand and say: "drop a boolean method right here in android/.... and then call it from right here in packages/react-native/... where would you put them?

[alexander01202]

@mikehardy does notifee listen for onesignal notifications? I am using onesignal to send notifications and I can't see any way in the docs to handle to onesignal notifications. Or does the docs still apply when using onesignal? Do you understand what I'm saying?

[mikehardy]

This still feels like imprecise language, so I am not sure I understand.

OneSignal documents their setup as requiring a Firebase FCM setup step for Android:
https://documentation.onesignal.com/docs/mobile-sdk-setup#android
(and APNS push certificate on iOS)

Technically, it's important to understand that each vendor (android/google, iOS/apple, android/huawei) has one way to send cloud messages to a device. And everyone else just funnels into that.

For Android, that's FCM. For iOS that's APNS. For Huawei it's HMS (or whatever they call it now, important part is that it's one way)

So here's the thing - it doesn't matter what vendor you are using to generate the cloud message. In the end they will be sending a message that follows the format of the system cloud messaging service. For Android that's FCM

At that point, you can refer back to my definitions above, or read the google upstream docs on FCM.

Now, does Notifee listen for those? Notifee listens for local on-device notification events. So anything that posts an actual user-visible notification should trigger a notifee event. Notifee does not listen for cloud messages then. Just the notifications that may be triggered by them, if that makes sense? It's the second step / side effect of sending a cloud message with a notification block

@react-native-firebase/messaging listens for the actual incoming cloud message, and if it's a data-only message, you'll get the background handler called.

Hopefully that all makes sense

[helenaford]

@shawarmaz if I'm following correctly, you only want a limited view of the app if the device is locked? What is the proposed solution in regard to:

mikehardy, would the lockscreen check be something that you guys would consider integrating into notifee? It's really the only piece missing for the Incoming Call feature if we use this approach

Would this be a API endpoint like notifee.isLocked() ? (cc @mikehardy )

I think you could use a different activity or mainComponent to achieve your overall goal of only showing a limited view of your app when someone rings.