how is this handled for SIP softphones that can run persistently in the background, in a direct SIP or SIP-over-TLS connection to a server? for instance:

https://play.google.com/store/apps/details?id=org.linphone&h...

that's just a random example I thought of since I use it, but I can also think of a lot of other Android apps that I'm fairly sure aren't using any client-server communications mediated through google firebase, yet they continue to function while backgrounded on android 10 and 11.

I'm not sure how Linphone is doing it but all the apps I used that required to run in the background were required to show a notification at all time.

This is a terrible UX, my notification center is useless because I always have those apps in there (KDEConnect and Syncthing for example)

Just FYI, you can set those notifications to be ‘silent’ (not displayed on the top) and to collapse into a thin line each—in the system's notification settings. The apps still keep running, however I haven't figured out whether this change affects the frequency with which the background service is called by the system, and thus synchronization delays.

Don't forget that turning off the screen can wildly affect service behavior even for foreground services, and these effects vary across vendors:

https://developer.android.com/training/monitoring-device-sta...

Linphone does show a persistent notification while running and registered to a server.

VoIP has always been treated a bit differently to regular apps on both platforms. I vaguely remember about 10 years ago both iOS and Android had special permissions specifically for VoIP apps to run in the background.

On iOS that's pretty much all been removed. The access gateway has to send an APNS notifications when there is an inbound call.

Android has it's own SIP stack. It's even exposed in the standard Android phone dialler from Google. In the settings for that app look under "calling accounts".

https://developer.android.com/guide/topics/connectivity/sip

I haven't looked, but I'm sure just like Firebase, services get a special exemption to receive SIP notifications.

The Android SIP stack is pretty crummy. Last I tried to use it there was no support for TLS registration (leaving your calls unencrypted, barebacking the web) or for push notifications.

Linphone, Zoiper, etc can show a badge in your notifications menu/top bar at all times and get semi-reliable access to run in the background, but expect to miss 5% to 20% of all incoming calls. Firebase push notifications are mandatory if you care about battery life or reliable inbound calling :c

> leaving your calls unencrypted, barebacking the web

btw. most of the time only the session is unencrypted, not the media. when sip uses sips it will encrypt both the session and the media. but the latter is pretty uncommon and most often you wil see unencrypted session and an encrypted rtp stream. this is still the default, even deutsche telekom does it like that by default, even in their commerical offerings like "cloud pbx", because you would need to pay extra for the encrypted session.

and btw. sip over tls mostly means that the call is encrypted, but the sip messages aren't.

Firebase push messages are best effort an by no means guaranteed. You will still miss calls/notifications, even high priority ones.

I'm still looking for a guaranteed push service/library.

> It's even exposed in the standard Android phone dialler from Google.

If I recall correctly Samsung modifies the standard android dialler to disable this functionality. Or at last they did in the S5 that I used.