Is your feature request related to a problem? Please describe.
Talk's incoming-call UI (CallNotificationActivity) is entirely custom-drawn by the app, outside Android's Telecom framework. A code search of this repo turns up zero references to ConnectionService or TelecomManager anywhere in talk-android. By contrast, apps like Signal, WhatsApp, and Google Meet register as a self-managed ConnectionService/PhoneAccount, which gets them guaranteed native incoming-call UI independent of the app's own full-screen-intent/notification-channel setup, correct interaction with Do Not Disturb "allow calls from" exceptions (a custom channel's bypassDnd flag is easy to get wrong or have silently reset), and native call-log entry plus Bluetooth/car head-unit integration shared with the rest of the OS.
I ran into this while debugging intermittent missed Talk calls on a GrapheneOS phone. Full-screen intent permission, battery optimization, Doze whitelisting, and notification channel importance were all already correctly configured, and the app rang reliably in every test I could run, including a forced deep-Doze test, so the custom call UI is mostly fine but has less of a safety net than Telecom integration would provide for edge cases I couldn't reproduce on demand.
Describe the solution you'd like
Adopt Android's self-managed ConnectionService API (PhoneAccount plus ConnectionService) for Talk calls, the same approach Signal uses, so incoming/outgoing Talk calls are treated as first-class calls by the OS instead of a custom notification-driven UI.
Describe alternatives you've considered
Continuing to tune the current custom call-notification path (full-screen intent, notification channel importance, battery whitelisting). This works when correctly configured, but is more fragile than OS-level Telecom integration and easier to silently break via unrelated OS/app updates or user settings changes.
Additional context
Happy to help test on GrapheneOS if this is picked up.
Is your feature request related to a problem? Please describe.
Talk's incoming-call UI (CallNotificationActivity) is entirely custom-drawn by the app, outside Android's Telecom framework. A code search of this repo turns up zero references to ConnectionService or TelecomManager anywhere in talk-android. By contrast, apps like Signal, WhatsApp, and Google Meet register as a self-managed ConnectionService/PhoneAccount, which gets them guaranteed native incoming-call UI independent of the app's own full-screen-intent/notification-channel setup, correct interaction with Do Not Disturb "allow calls from" exceptions (a custom channel's bypassDnd flag is easy to get wrong or have silently reset), and native call-log entry plus Bluetooth/car head-unit integration shared with the rest of the OS.
I ran into this while debugging intermittent missed Talk calls on a GrapheneOS phone. Full-screen intent permission, battery optimization, Doze whitelisting, and notification channel importance were all already correctly configured, and the app rang reliably in every test I could run, including a forced deep-Doze test, so the custom call UI is mostly fine but has less of a safety net than Telecom integration would provide for edge cases I couldn't reproduce on demand.
Describe the solution you'd like
Adopt Android's self-managed ConnectionService API (PhoneAccount plus ConnectionService) for Talk calls, the same approach Signal uses, so incoming/outgoing Talk calls are treated as first-class calls by the OS instead of a custom notification-driven UI.
Describe alternatives you've considered
Continuing to tune the current custom call-notification path (full-screen intent, notification channel importance, battery whitelisting). This works when correctly configured, but is more fragile than OS-level Telecom integration and easier to silently break via unrelated OS/app updates or user settings changes.
Additional context
Happy to help test on GrapheneOS if this is picked up.