Version 1.6.24 - App Crashes when Phone Locked and an incoming call comes in

[ToddCrimson]

Steps to reproduce

We updated today to latest version 1.6.24. Note we tried this on Four of our phones (Two Pixel 8 Pro, Pixel 7A, Pixel 9). All Failed. We tried with Background Sync and with NTFY push server. We built the app from your code to test it. Same issue. If phones are locked, and a call comes in, you hear the bell for a millisecond, and it goes quiet.

1. Lock Pixel 8 Pro - Call from another device (Pixel 7A or Pixel 9)
2. Pixel 8 Pro rings for a millisecond
3. Unlock the Pixel 8 Pro, open app, it shows app crashed.

NOTE: We use the F-Droid version, as your GPLAY version does not have Background Sync option.

Outcome

What did you expect?

Call to continue to ring, and being able to answer

What happened instead?

Call rings for a millisecond or less. Unlocking the phone, and starting the app reveals that app crashed.

Your phone model

Pixel 8 Pro, Pixel 7 A, Pixel 9

Operating system version

Android 14 and 15

Application version and app store

Element version 1.6.24 from F-Droid

Homeserver

Latest Synapse private server

Will you send logs?

Yes

Are you willing to provide a PR?

Yes

[AdamMajer]

Same issue on Nokia (Android One phone, Android 14) and Elements installed from Play store.

[ToddCrimson]

Update: We switched back to version 1.6.18 the above problem went away.
Out of curiosity, we updated again, the problem came back.
So we are now running 1.6.18, confirming that 1.6.24 while fixed the microphone issue, has introduced other regression.

Caveat: Ver 1.6.18 doesn't do well when on Synapse Matrix server you have media requiring authentication. So we had to turn it off in vars.yml using matrix_synapse_enable_authenticated_media: false. We will wait until bug fixes come for the latest version.

Please let me know if we can help any way to support fixing of this problem?

[atuctuc]

i experience the same. since i updated element from 1.6.20 to 1.6.24, every incomming call crashes element. the appears on two android phones, on both the same. i use f-droid version with unified push

[ToddCrimson]

i experience the same. since i updated element from 1.6.20 to 1.6.24, every incomming call crashes element. the appears on two android phones, on both the same. i use f-droid version with unified push

I would suggest switching back to 1.6.18 from F-Droid store.
This is the direct link to the Android Phone version - https://f-droid.org/repo/im.vector.app_40106182.apk
Version 1.6.18 (40106182) - Added on Jul 06, 2024 -- arm64-v8a

PS: 1.6.20 has the issue with Microphone access revoking if you are on a call, and you switch to another app (putting element in background) or lock your screen.

[foegra]

Same here, on Xiaomi 12 with 1.6.26, app from Google play

[ToddCrimson]

@bmarty , if it is ok to tag you here please and just request roughly if this has a path and time to resolution, and if there is any help I can provide troubleshooting?

[takashikumagai]

I am experiencing a similar issue with 1.6.24 on my Pixel 7a. Not sure if it is the same problem though. Could anyone provide more details on how exactly the app crashes?

In my case, the crash is related to MicrophoneAccessService and the error originates from JitsiMeetSDK. Please refer to this log.
If I keep the microphone permission denied to Element app, the crash does not ocurr.
If the app is granted microphone access permission, however, it crashes the moment it tries to use the microphone device upon receiving a call.

[ToddCrimson]

@takashikumagai, I'd suggest to tag and reach out directly to all the devs here. None of them seem to respond to any of the latest messages about app crashes, non-usability of apps. I understand that it is not easy and everyone is busy, but its common courtesy to at the very least reply with the intent.

[takashikumagai]

@bmarty @BillCarsonFr @christianrowlands @ganfra @ouchadam

Could you please have a look at this crash bug?

I am experiencing a similar issue with 1.6.24 on my Pixel 7a. Not sure if it is the same problem though. Could anyone provide more details on how exactly the app crashes?

In my case, the crash is related to MicrophoneAccessService and the error originates from JitsiMeetSDK. Please refer to this log. If I keep the microphone permission denied to Element app, the crash does not ocurr. If the app is granted microphone access permission, however, it crashes the moment it tries to use the microphone device upon receiving a call.

Also, if there is any suggestion from the log, anything I should investigate further, etc. please don't hesitate to reach out. I'd appreciate any guidance or update on this.

and thank you so much @ToddCrimson for the advice

[christianrowlands]

I took a glance at this issue, and I was able to reproduce it as described in this thread. The devices must be running Android 14+, and the microphone permission must be granted to the Element Android app. If you set the Microphone Permission to "Ask every time" then the call rings through, and the user is prompted to grant the permission.

Trying to hunt down the root cause of the issue, I found this blurb from the Android documentation linked here:

"Note: The RECORD_AUDIO runtime permission is subject to while-in-use restrictions. For this reason, you cannot create a microphone foreground service while your app is in the background and you cannot launch a microphone foreground service from a BOOT_COMPLETED receiver, with a few exceptions. For more information, see Restrictions on starting foreground services that need while-in-use permissions."

I am poking around the documentation to see if there is a workaround for this, which there has to be since other apps are able to receive incoming calls while the screen is locked.

[christianrowlands]

Interestingly enough, I was able to fix this bug by commenting out these three lines of code found here:

Timber.tag(loggerTag.value).v("Starting microphone foreground service")
val intent = Intent(this, MicrophoneAccessService::class.java)
ContextCompat.startForegroundService(this, intent)

Basically, by not starting the MicrophoneAccessService at all, we prevent the problem since we are not accessing the microphone from the background. Instead, we access the microphone once the user clicks the "Answer" button, which means we are not accessing it from the background, but instead based on a user action (clicking on the answer button, which is a foreground action).

My only concern is all the edge case scenarios. I am unsure why the line of code ContextCompat.startForegroundService(this, intent) is needed from the VectorCallActivity. I will throw up a PR and see if @bmarty has any thoughts.