feat(android): Support android call notification style

[dprevost-LMI]

PR introducing the new Android 12 CallStyle notification related to phone calls.

CallStyle can produce three different notifications:

• Incoming

• Ongoing

• Screening

With Verification text and icon:

Notes on the changes:

• Upgrade to androidx.core:core:1.10.0 was required to have the CallStyle inside NotificationCompat (See also this google issue about it). This update also generates the room update. Otherwise, duplicated lib errors were generated
• Inside the call style as a premier, we have to process pressActions and create a pending intent instead of behind outside of the style like the other (and be generic pressActions props)
• Unit tests and even integration test was added
• I favoured Java Enum instead of plain integer for style type & call type
• All test & lining commands were run as specified in the CONTRIBUTING.md
• All three call types were tested manually in the example app (the pictures above are proof!)

⚠️ Dependant projects might also need to update their androidx.core:core version or even their androidx.core:core-ktx to at least 1.10

⚠️ There is a known limitation where additional custom actions, as claimed in the documentation, do not currently work. See this Google issue

[CLAassistant]

All committers have signed the CLA.

[mikehardy]

Just to note I see these commits flying by in my notification queue and I'm excited to see this when you think it's ready
No rush of course, it's your effort :-)
Totally fine with dependency updates as needed of course, core is actually on 1.15 now so bumping to 1.10 is arguably not even enough (but only doing what is necessary for the PR makes sense - no need to struggle on a side project of updating it)

[dprevost-LMI]

Just to note I see these commits flying by in my notification queue

😮 I can remove the draft PR; I thought the draft would not spam, sorry

core is actually on 1.15 now so bumping to 1.10 is arguably not even enough

Yeah, I struggled since on 1.10, I had some duplicate deps errors and needed to update the rooms deps too. So yeah, I'm doing the minimal since it is not the focus, as you mentioned!

While I have your attention, I struggle with the PendingIntent creation. I reached a working point, but having them in the NotificationAndroidStyleModel.java. I want to move that into its own class at some point.
However, I must pass the NotificationModel pretty deep, which seems bad. If you have any suggestions about that, let me know

[mikehardy]

No worries about spam, it's a drop in the bucket and it's pleasing to see notificaitons about a feature PR vs yet another "I can't compile NNN because of ABC" issue comment 😅

I reached a working point, but having them in the NotificationAndroidStyleModel.java. I want to move that into its own class at some point.
However, I must pass the NotificationModel pretty deep, which seems bad. If you have any suggestions about that, let me know

I'm a fan of "tested and working" over perfect, so I lean towards something that you know works first. Second, I'm not sure what exactly would be better, passing it down the way it is now doesn't seem so bad

The only thing I can see that makes me 🤔 is the inconsistent use of constants vs "magic numbers and strings" - I love the enums at the TS level and it would be nice to see constants or enums to match at the java level (and in the TS warning, which uses the numbers again vs the call types)

In general though, looks like it is shaping up. At first I thought this was just duplication of our full screen intent style (which is targeted for this use case as well) but as soon as I looked at the APIs in use it looks like this is just me being unaware of the problem area and that the APIs have moved on (as they always seem to for notifications...) to have specific call notification type for modern android. Nice to support it

[dprevost-LMI]

For your information, I just linked my project with my PR, and the first draft is working well in a happy path scenario!
I hope to wrap this up in the upcoming weeks!

From Notifee example project it looks like this:

[mikehardy]

That's wonderful!

[dprevost-LMI]

Do I need to create a feature issue for this PR, or is the PR only OK?

[mikehardy]

PR only is just fine - no need for administrivia like an issue just to close it, if there is a PR in flight already

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.81%. Comparing base (ae2953b) to head (1817d5e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1134      +/-   ##
==========================================
+ Coverage   77.08%   77.81%   +0.74%     
==========================================
  Files          32       32              
  Lines        1727     1771      +44     
  Branches      556      592      +36     
==========================================
+ Hits         1331     1378      +47     
+ Misses        395      340      -55     
- Partials        1       53      +52     

[dprevost-LMI]

Hey there, I was wondering if I could help with anything regarding the next steps on that PR. Thanks!

[mikehardy]

Sorry for the slow pace - progress here is happening it's just not visible (yet)

One of the biggest barriers to testing all-things-Notifee is that so much of it is in response to cloud messaging, and that necessarily requires a firebase project setup, an apple development account with messaging certs and keys setup and connected and everything, and that hadn't been done except for "borrowing" personal accounts for temporary / local unshareable one-off testing.

I'm nearly done with the process of having it set up in a permanent + general way, to unblock all testing, which then unblocks all this new feature + and foreground/background event-handling issue backlog

[dprevost-LMI]

Great, thanks for the info. Your astonishing work and dedication are just amazing! Thanks again @mikehardy

[dprevost-LMI]

Rebased! Ready again!

[wilkinson4]

Playing around with this locally, and I'm noticing that the heads up notification is visible for 5ish seconds, then disappears into the notification drawer. Am I missing something?

[wilkinson4]

Playing around with this locally, and I'm noticing that the heads up notification is visible for 5ish seconds, then disappears into the notification drawer. Am I missing something?

After adding the fullScreenAction property with just an id: default key/value that changed the behavior of the notification

[hevi08]

@mikehardy could you please merge this PR ? Thanks

[dprevost-LMI]

Support for the verification text and icon was also added in 4798fdc

[Irfanwani]

Any updates on this PR?

[Irfanwani]

I tried using this PR (built the package locally from your fork). Call type notification is not having any effect, no buttons are shown.
Are there any other changes required to make it work.
(As per the code, it doesn't see so, but in case i am missing something here)

[Irfanwani]

btw, here is my implmentation:

 const channelId = await notifee.createChannel({
      id: 'call-channel',
      name: 'Call Notifications',
      importance: AndroidImportance.HIGH,
      visibility: AndroidVisibility.PUBLIC,
      sound: 'ringtone',
    });

    await notifee.displayNotification({
      // title: `${payload.name}`,
      // body: `${payload.number}`,
      id: 'call_notification',
      android: {
        channelId,
        smallIcon: 'ic_small_icon',
        category: AndroidCategory.CALL,
        importance: AndroidImportance.HIGH,
        visibility: AndroidVisibility.PUBLIC,
        loopSound: true,
        ongoing: true,
        autoCancel: false,
        sound: 'ringtone',
        style: {
          type: AndroidStyle.CALL,
          person: { name: "John Doe" },
          callTypeActions: {
            callType: AndroidCallType.INCOMING,
            answerAction: {
              pressAction: {
                id: 'accept',
                launchActivity: 'default',
              },
            },
            declineAction: {
              pressAction: {
                id: 'reject',
              },
            },
          },
          verification: { text: payload.number },
        },
        asForegroundService: true,
        foregroundServiceTypes: [
          AndroidForegroundServiceType.FOREGROUND_SERVICE_TYPE_CONNECTED_DEVICE,
        ],
        lightUpScreen: true,
        pressAction: {
          id: 'default',
        },
        fullScreenAction: {
          id: 'default',
          launchActivity: 'default',
        },
      },
    });

[Irfanwani]

Seems the package is not having the updated code from PR.

[Irfanwani]

@dprevost-LMI I am not able to use your fork. Can you please provide steps on how to use it in a react native app. I tried manually building but once used in the app, the app was failing to build.
Also, this repo (your fork) cannot be directly installed via npm.

[dprevost-LMI]

@dprevost-LMI I am not able to use your fork. Can you please provide steps on how to use it in a react native app. I tried manually building but once used in the app, the app was failing to build. Also, this repo (your fork) cannot be directly installed via npm.

It was not meant to be used as a release package, but to be merged. Unfortunately, this one will need to be figured out without me 😉

[Irfanwani]

FInally, packed it locally and used in my app. Working now. Thanks for this great work.
I was about to start building this on my own (and that was definitely going to take a lot of time as i don't have much knowledge about native development).

Thanks for saving me a lot of time.