bug:

[Golldden]

NullPointerException in showIncomingCallNotification when app is closed

Description

When the app is closed and an incoming call is received, the plugin fails to show the native Android notification due to a NullPointerException. The call is received (sound plays), but no notification UI appears.

Error

E CapacitorTwilioVoice: Error showing notification: Attempt to invoke virtual method 'java.lang.String java.lang.Class.getName()' on a null object reference
E CapacitorTwilioVoice: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.lang.Class.getName()' on a null object reference
E CapacitorTwilioVoice: 	at android.content.ComponentName.<init>(ComponentName.java:133)
E CapacitorTwilioVoice: 	at android.content.Intent.<init>(Intent.java:8043)
E CapacitorTwilioVoice: 	at ee.forgr.capacitor_twilio_voice.CapacitorTwilioVoicePlugin.showIncomingCallNotification(CapacitorTwilioVoicePlugin.java:1659)

Steps to Reproduce

1. Close the app completely
2. Receive an incoming call
3. Sound plays but no notification appears
4. Check logs for NullPointerException

Expected Behavior

Native notification with Answer/Decline buttons should appear when app is closed.

Actual Behavior

Sound plays but notification fails to show due to NullPointerException.

Environment

• Plugin Version: 7.7.5
• Capacitor Version: 7.4.4
• Android Version: 13
• Package: com.twiliocall.app
• MainActivity: com.twiliocall.app.MainActivity

Logs

11-23 22:28:09.447 D CapacitorTwilioVoice: Received incoming call from: client:gold
11-23 22:28:09.458 E CapacitorTwilioVoice: Error showing notification: Attempt to invoke virtual method 'java.lang.String java.lang.Class.getName()' on a null object reference
11-23 22:28:09.550 D CapacitorTwilioVoice: Started ringtone and vibration

Additional Context

• JavaScript events fire correctly
• Issue is in native notification creation at line 1659

[WcaleNieWolny]

Did you call CapacitorTwilioVoicePlugin.instance.setMainActivityClass(MainActivity.class);?

[ToriChanIntegration]

Thanks for the report — we should definitely make this easier to debug 🙏

Could you share a minimal repro with:

• plugin version + Capacitor version
• Android device model + OS version
• whether audio route changes if Bluetooth headset is connected
• logcat lines around the moment setSpeaker(...) is called

A practical check meanwhile:

• call setSpeaker(true) after call accept/connect event (some SDKs ignore route changes before active audio session).

If repro confirms this, we can add an internal retry-on-active-session guard to make routing more reliable.

Suggested labels: bug, platform:android, needs-repro.