element-hq
Version 1.6.24 - App Crashes when Phone Locked and an incoming call comes in
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.
- Lock Pixel 8 Pro - Call from another device (Pixel 7A or Pixel 9)
- Pixel 8 Pro rings for a millisecond
- 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
Same issue on Nokia (Android One phone, Android 14) and Elements installed from Play store.
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?
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 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.
@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?
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.
@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.
@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
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.
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.
Alright, the PR has been created. Let me know if you have any feedback @bmarty : https://github.com/element-hq/element-android/pull/8989
@christianrowlands, I am truly grateful that you are working on this. Thank you so much
I believe we can close this issue as the PR has been merged (I don't have permission to close this issue). The next release will contain the fix!
Hello, first of all thank you very much for supporting and following up on this, I really appreciate the effort you have made. Having said that, I would like to tell you that I downloaded the modified version to solve the bug, and the incidence of the problem has decreased a lot, but after a period of inactivity, which can be 2 hours or 24 hours, the problem reappears: the phone is blocked with the data network, it does not receive the call notification, when I turn on the screen it starts to give a half tone and the app crashes, returning to version 1.6.18 of the app, the calls work perfectly, but the images that are sent between chats do not appear, the image is sent but is not seen when receiving it. Could you help me?
@infryt404 , the image problem you are seeing is due to authenticated media -- the old version doesn't have it so it can't see images from newer versions. The new versions can see images from the older version.
@infryt404 , I will try to reproduce that issue. I never tested incoming calls after 2 hours of the phone being idle. I will let it sit for several hours and then try calling it to see if I can reproduce that scenario.
Out of curiosity, have you seen this problem @ToddCrimson ?
@AdamMajer thank you very much for your response. In this case, I am using the same version on all my devices, version 1.6.18, and that is where I have the problem with the images.
@christianrowlands You know I was originally using Samsung A55 devices, and this is where those issues start to appear after idle times, but I have a pixel 7 and after a few settings in background processes and notification priorities, the issue no longer appears.
Well, it might be a problem with just that device, or maybe the specific version of Android it is running.