Crash with Acrobits Softphone system dialer integration ON

[MrKingMichael]

If "Use system dialer integration" is ON in Acrobits Softphone, once a SIP call is active BCR will repeatedly spam a push notification (see screenshot below) and crash. The title of the push is "Failed to record call" and its body text is "Attempt to invoke virtual method 'int android.telephony.SubscriptionInfo.getSimSlotIndex()' on a null object reference". This happens regardless of whether call recording is ON in Acrobits Softphone.

I use a Pixel 5 rooted with Magisk, build 14 (UP1A.231105.001.B2).

[MrKingMichael]

It seems that Acrobits Softphone achieves this integration by adding a new calling account as you can see below. Hope this helps.

[chenxiaolong]

Thanks for the report. I don't have an account with a SIP provider, but I think this should be a pretty easy fix.

Can you give this test build a try? (includes the fix in #516) BCR-1.61.r7.g3107a9c-release.zip

[MrKingMichael]

Thank you for your quick response and work. I tested the build you provided and while BCR no longer crashes or spams pushes, the final recording file is 2 seconds long without any audio. I cannot find any logs to attach. It's not a big issue for me since the app Acrobits Softphone allows you to record calls anyway, but IMO this still needs a fix for any app which might make use of this. If you need anything else please let me know.

[chenxiaolong]

Great, thanks for testing! If you long press the version number in BCR, it'll enable debug mode. Once enabled, on the next call, BCR will save the log file to the output directory. Could you give that a try and upload that log file?

[MrKingMichael]

Thanks, I attached the log below. Don't know if it helps but the test call was 6 seconds long. Please let me know if you need anything else.

20240315_012238.617+0200_out_13840_Vodafone.log.txt

[chenxiaolong]

Don't know if it helps but the test call was 6 seconds long

Yep, that's definitely helpful. I can see that ~6.8 seconds elapsed between the time that Android reported the call was active and when it was disconnecting. Acrobits Softphone's integration with Android's telephony system appears to be working well.

03-15 01:22:41.733 31933 31933 D RecorderInCallService: onStateChanged: Call [id: TC@4, state: ACTIVE, details: [id: TC@4, state: ACTIVE, pa: ComponentInfo{cz.acrobits.softphone.alien/cz.acrobits.softphone.telecom.ConnectionService}, ***, UserHandle{0}, hdl: ***, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_HOLD CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE], props: [Properties:]]], 4
...
03-15 01:22:48.613 31933 31933 D RecorderInCallService: onStateChanged: Call [id: TC@4, state: DISCONNECTING, details: [id: TC@4, state: DISCONNECTING, pa: ComponentInfo{cz.acrobits.softphone.alien/cz.acrobits.softphone.telecom.ConnectionService}, ***, UserHandle{0}, hdl: ***, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_HOLD CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE], props: [Properties: PROPERTY_VOIP_AUDIO_MODE]]], 10

However, Android only sent 1.6 seconds of audio to BCR:

03-15 01:22:48.629 31933 32344 D RecorderThread/60: Input complete: Total: 74496 frames (1.6s), Encoded: 74496 frames (1.6s), Sample rate: 48000, Channel count: 1, Buffer frames: 3840, Buffer overruns: 0, Was ever paused: false, Was ever holding: false

If you open the recording in something like Audacity and the file truly has no sound (vs. very quiet noise), then I suspect this might be a device limitation. It might not allow both Acrobits Softphone and BCR to access the audio at the same time.

[MrKingMichael]

I made a test call again that was 12 seconds long and the output file was 5 seconds long but again, pure silence. I played with call recording off and on in the Acrobits Softphone app, changed the file format in BCR, same result. I opened it in an audio editor and tried to amplify it but it remains completely silent. I attach the log just in case.

20240315_015815.87+0200_out_13840_Vodafone.log.txt

[chenxiaolong]

Thanks for checking. Looks like the same thing (Android only provided 5.8 seconds of audio to BCR):

03-15 01:58:31.259 28029 29121 D RecorderThread/63: Input complete: Total: 92928 frames (5.8s), Encoded: 92928 frames (5.8s), Sample rate: 16000, Channel count: 1, Buffer frames: 1280, Buffer overruns: 0, Was ever paused: false, Was ever holding: false

I don't think anything can be done to work around this limitation. Since you mentioned the SIP app allows you to record, I'd suggest going that route.

[MrKingMichael]

Sorry for getting back to you so late. In that case I'd think letting the user know that recording is not possible is a better idea instead of dumping a useless file to their storage.

[chenxiaolong]

Yeah, agreed. I don't think it's possible to detect beforehand, but it should be relatively easy to have BCR auto-delete the file at the end if it's pure silence. Warning the user is also a good idea. I'll make it a separate notification channel so people can completely hide the notification if desired.

If you wouldn't mind, could you make a recording with BCR set to either the FLAC or WAV formats and upload that? I'd like to check if the pure silence is all 0's, all 0x7fff's, all 0xffff's, or something else.

[MrKingMichael]

have BCR auto-delete the file at the end if it's pure silence.

It's a good idea in general and I definitely think it should be implemented, but perhaps for this very issue you could simply check if getActiveSubcriptionInfo() returns null, and in that case make BCR only display a single notification that warns the user it is not possible to record and do nothing else. That way we can skip several hurdles, such as unnecessarily trying to record audio that is ultimately unusable, store it, check if the final file has actual, usable audio, and then delete it in the end. I think it makes everything a little more efficient.

Regardless, since you asked for it I uploaded a recording that is 17 seconds long. I could not upload it on GitHub due to it being an unsupported file type (.WAV) so I uploaded it on my MEGA.

https://mega.nz/file/ZsBxxCII#sYq-PAmN_a3VUC7rkMMPO-kc4n6upiPcOIBYNYf6VLk

Don't think I ever mentioned it but thanks for your time, attention and overall work you've done for this project. Everything you've done so far is greatly appreciated.

[chenxiaolong]

Thanks for the upload and glad you like BCR!

I don't think checking that getActiveSubcriptionInfo() returns null will work because some devices will return that for regular phone calls (especially older dual-SIM devices). However, along that line of thinking, at the beginning of the call, it should be possible to check which app is associated with the call. For regular phone calls, it'll always be:

com.android.phone/com.android.services.telephony.TelephonyConnectionService

Anything else should be a third party app (like cz.acrobits.softphone.alien/cz.acrobits.softphone.telecom.ConnectionService).

I'll probably implement this first and then add the silence detection.

[chenxiaolong]

518 (test build: BCR-1.61.r11.g4a1b822-release.zip) adds a new setting for controlling whether calls from these apps are recorded. A call is treated as a regular phone call if the associated app is com.android.phone. Otherwise, it's a call from an external app. This should (hopefully) work on every device. com.android.phone is a system component that Google does not allow OEMs to rename.

The option is disabled by default to avoid producing useless recordings.

I'll work on silence detection later this week.

[MrKingMichael]

Thank you very much, I gave your test build a spin and it works perfectly for me. Should I close this?

[chenxiaolong]

Thanks for testing once again. Would you mind doing one final test for the silence detection (#519)? BCR-1.61.r13.gfe9e544-release.zip

You'll have to enable the option to record telecom-integrated apps. At the end of the call, BCR should show a notification saying the recording was deleted because the audio was completely silent.

[MrKingMichael]

My pleasure, thanks for the build. It works flawlessly, exactly as you described. The notification showed up right after the phone call and the final file was gone. Attached you'll find the log, for reference.

20240320_042042.497+0200_out_13840_Vodafone.log.txt

[chenxiaolong]

Appreciate it! I think that should be everything for this issue then.

All of these changes will be included in the upcoming 1.62 release. In the meantime, feel free to continue using the test builds. They're built exactly the same way as the official releases.