Fix SlimeVR server from not working reliably on Quest standalone

[swax]

The SlimeVR server running on Android is at risk of being killed when running in the background and/or when under memory pressure. This is especially bad on the Quest as playing a game requires a lot of memory and it doesn't take long for Android to kill the SlimeVR server if it is running the background.

According to the docs, processes with foreground services are less likely to be killed by Android, for example a music player running in the background. We can start a foreground service using startForegroundService, one of the stipulations being that the service must also show a persistent notification as well. An importance level of 'low' keeps the notification out of the way, only in the alerts tray.

Tested on Quest with server running in background:

• Verified the current SlimeVR server is killed after a period of time
• Verified with the new build the server remains running for over an hour, in high pop worlds, with all avatars on (high memory pressure)

Notes:
There isn't a way to shutdown the SlimeVR server from within the GUI afaik. This is an issue on Quest as there isn't a way to manually kill apps. The only way to kill the server on Quest is to restart the device (afaik).

What the alert looks like on Quest, it only shows up in the notifications dialog, not in the game

[ButterscotchV]

I finally got around to getting this on my phone, I don't see the notification show up, does it not have permission? Is there supposed to be a notification on phones? For context, this is on Android 14, I know Quest is on an older version.

[swax]

Hrm, so the app now starts a foreground task, and foreground tasks are required to have a persistent notification that can't be dismissed. With it set to a low priority notification it should be in the notification manager, but not pop up over any active applications. Is there like a notification tray, or filters on the tray you can double check?

The permissions should be fine, I added the foreground service permission for this change. If we updated the build to Android 14 then we would also want to add the FOREGROUND_SERVICE_CONNECTED_DEVICE permission and call startForeground() with FOREGROUND_SERVICE_TYPE_CONNECTED_DEVICE, but for now Android 14 shouldn't care about that if the app is built for Android 12.

I just found this note here: https://developer.android.com/develop/background-work/services/foreground-services
"Note: Devices that run Android 12 (API level 31) or higher provide a streamlined experience for short-running foreground services. On these devices, the system waits 10 seconds before showing the notification associated with a foreground service." So maybe wait a minute and check again?

These persistent notifications are also dismissible in Android 13 and above, so maybe with it being low priority it was auto dismissed somehow? This is the least likely possibility.

[ButterscotchV]

For context this is a Pixel 8 running Android 14, it doesn't show up where persistent apps usually do (it makes a section for "Silent" notifications), it shouldn't be dismissed and if I re-open it would show up again. I can see it's running in the background for now but I assume it will be killed eventually.

[swax]

I pasted the changelog into ChatGPT o1 and asked it for ideas of wtf is going on, and it tipped me off to this permission POST_NOTIFICATIONS that is new in Android 13. Luckily not a hallucination, I read over the docs and there's a bunch of notes in there about how older apps are treated, there's a good chance this is what's preventing the notification from getting through. It even mentions you still need to create a notification for foregrounds services:

Note: Apps don't need to request the POST_NOTIFICATIONS permission in order to launch a foreground service. However, apps must include a notification when they start a foreground service, just as they do on previous versions of Android.

It does say that Android 14 should ask the user for notification permissions the first time an older app tries to create one, but it doesn't sound like that happened for you. Maybe there's an entry in some centralized notification settings somewhere it could be flipped on? Not critical for the notification to show up as that's how it works now, though useful I think for the user to know there's a server running in the background. More importantly though is that the foreground service is running which the notification would help us confirm at least.