#8964 Fix app crash on incoming call when running Android 14+

[christianrowlands]

Type of change

• Feature
• Bugfix
• Technical
• Other :

Content

I removed the call to start the MicrophoneAccessService on Android 14+.

Motivation and context

This change is in response to this GitHub Issue: #8964

When running on Android 14+, if you have the microphone permission granted to the app, incoming calls while the app is in the background causes the app to crash, and the incoming call to not come through. The Android documentation for that is here: https://developer.android.com/develop/background-work/services/fgs/service-types#microphone

and here: https://developer.android.com/develop/background-work/services/fgs/restrictions-bg-start#wiu-restrictions

Tests

I tested by making a call to a device running Android 14 and my changes while the device is locked, as well as unlocked with the app open.

Tested devices

• Physical
• Emulator
• OS version(s): Android 14

Checklist

• [ - ] Changes has been tested on an Android device or Android emulator with API 21
• [ - ] UI change has been tested on both light and dark themes
• [ - ] Accessibility has been taken into account. See https://github.com/element-hq/element-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request includes a new file under ./changelog.d. See https://github.com/element-hq/element-android/blob/develop/CONTRIBUTING.md#changelog
• [ - ] Pull request includes screenshots or videos if containing UI changes
• Pull request includes a sign off
• You've made a self review of your PR
• [ - ] If you have modified the screen flow, or added new screens to the application, you have updated the test UiAllScreensSanityTest.allScreensTest()

Signed-off-by: Christian Rowlands <craxiomdev [at] gmail.com>

[bmarty]

Thanks for the fix.
This code has been added in #8914 in order to fix a problem when the app is "backgrounded".

Maybe the service still need to be started, but later?

[bmarty]

Yes, but in this block the app is in the foreground (since isAppInForeground() returned true), or am I misreading something?

[christianrowlands]

I assumed that too, but when I added logging it indicated the app is in the foreground. I am guessing this is the case because by the time this code is reached the app has been brought to the foreground with an incoming call UI, but because this was not triggered by a user action, it does not matter if the app is in the foreground. Maybe my comment is not the clearest. The app not only needs to be in the foreground, but it must have gotten there via a user interaction (or another exemption path).

As for my comment about creating the microphone foreground service while your app is in the background, it depends on how the activity was triggered. A user interaction with the foreground such as clicking on a UI button or on a notification will allow the microphone to be accessed. However, if the chain is triggered entirely from the background then the exception will occur.

I believe this approach works because now the app does not use the microphone permission until the "answer" button is clicked, which is a user interaction with the UI.

See the documentation here: https://developer.android.com/develop/background-work/services/fgs/restrictions-bg-start#background-start-restriction-exemptions

And the relevant section:

The user performs an action on a UI element related to your app. For example, they might interact with a bubble, notification, widget, or activity.

[christianrowlands]

I think you are right. The service likely still needs to be started, but later. I will see if there is a later point that we can start it (has to be after the user clicks the answer button).

[christianrowlands]

@bmarty , I took another stab at this fix. Because the VectorCallActivity is paused and resumed before the incoming call has been answered, my approach is to only start the MicrophoneAccessService if the call has already been answered.