Call recording causing audio service crashes and call interruptions

ThisOldGuy

I kept getting notifications that audio server and hardware audio service keeps crashing after one of this months updates.

Yesterday I realized that it is impacting my phone calls (primarily used in secondary profiles). I use speakerphone 100% of the time.

What other information can I give to unravel this issue?

`type: crash
userType: full.secondary
osVersion: google/komodo/komodo:16/BP2A.250705.008/2025071900:user/release-keys
uid: 1041 (u:r:hal_audio_default:s0)
cmdline: /vendor/bin/hw/android.hardware.audio.service-aidl.aoc
processUptime: 0s

signal: 35 (<debuggerd signal>), code -1 (SI_QUEUE), senderUid 1041
threadName: binder:28629_2
MTE: enabled

`type: crash
userType: full.secondary
osVersion: google/komodo/komodo:16/BP2A.250705.008/2025071900:user/release-keys
uid: 1041 (u:r:audioserver:s0)
cmdline: /system/bin/audioserver
processUptime: 0s

abortMessage: TimeCheck timeout for IAudioFlinger::getInputFramesLost scheduled 22:01:35.875 on thread 28633
Timeout ms 5000.00 (3000.00 + 2000.00) elapsed steady ms 5001.7471 elapsed system ms 5001.7578
HAL pids [ 28629 ]
now 22:01:41.950
secondChanceCount 1
analysis [ ]
timeout [ { IAudioFlinger::getInputFramesLost scheduled 22:01:35.875 deadline :38.875 tid 28633 } ]
pending [ ]
retired [ { IAudioFlinger::getInputFramesLost scheduled 22:01:35.788 deadline :38.788 tid 28752 } { IAudioFlinger::getInputFramesLost scheduled 22:01:35.809 deadline :38.809 tid 28752 } { IAudioFlinger::getInputFramesLost scheduled 22:01:35.831 deadline :38.831 tid 28752 } { IAudioFlinger::getInputFramesLost scheduled 22:01:35.831 deadline :38.831 tid 28633 } ]
timeout(28633) callstack [
#00 pc 00000000000e980c /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+12) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#01 pc 00000000000885d0 /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+160) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#02 pc 0000000000051248 /system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+216) (BuildId: 227bfd6b656603710e305006a6b61d7a)
#03 pc 00000000000557c8 /system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+152) (BuildId: 227bfd6b656603710e305006a6b61d7a)
#04 pc 0000000000084dcc /system/lib64/libbinder.so (android::PoolThread::threadLoop()+28) (BuildId: 227bfd6b656603710e305006a6b61d7a)
#05 pc 000000000001956c /system/lib64/libutils.so (android::Thread::_threadLoop(void)+252) (BuildId: 8708332b97701f7d01a4f87d703335f7)
#06 pc 000000000001bdb8 /system/lib64/libutils.so (libutil_thread_trampoline(void) (.uniq.226528677032898775202282855395389835431)+24) (BuildId: 8708332b97701f7d01a4f87d703335f7)
#07 pc 000000000008e254 /apex/com.android.runtime/lib64/bionic/libc.so (pthread_start(void*)+180) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#08 pc 000000000007f9f4 /apex/com.android.runtime/lib64/bionic/libc.so (start_thread+68) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
]

signal: 6 (SIGABRT), code -1 (SI_QUEUE)
threadName: binder:28628_2
MTE: enabled

backtrace:
/apex/com.android.runtime/lib64/bionic/libc.so (ioctl+12, pc e980c)
/apex/com.android.runtime/lib64/bionic/libc.so (ioctl+160, pc 885d0)
/system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+216, pc 51248)
/system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+152, pc 557c8)
/system/lib64/libbinder.so (android::PoolThread::threadLoop()+28, pc 84dcc)
/system/lib64/libutils.so (android::Thread::_threadLoop(void)+252, pc 1956c)
/system/lib64/libutils.so (libutil_thread_trampoline(void) (.uniq.226528677032898775202282855395389835431)+24, pc 1bdb8)
/apex/com.android.runtime/lib64/bionic/libc.so (pthread_start(void*)+180, pc 8e254)
/apex/com.android.runtime/lib64/bionic/libc.so (start_thread+68, pc 7f9f4)`

ThisOldGuy

Anyone?

de0u

ThisOldGuy With people in multiple timezones around the world, sometimes it can take some hours for a response to show up. It could easily be a couple of days before a specialist can look at a crash dump, especially given weekends and/or holidays.

de0u

ThisOldGuy You could post the crash dumps as an issue on the GrapheneOS issue tracker. If you pursue that, please try to provide as much information as possible, including your carrier. Also, does this happen only on speakerphone? How many minutes into a call?

ThisOldGuy

de0u
I did not realize anyone could post to issue tracker thank you!
I can include my carrier but unfortunately I cannot test on regular phone. It happens consistently during the call, I haven't noticed a timing pattern though. I do have wifi enabled but I'm not sure how to check if it's a wifi call or not. My phone gets hot with calls when wifi is disabled but I can try and test.
Usually it drops sound for a few seconds. Longer calls will die, but it may be coincidental and unrelated.

Thank you for your help, if you can think of anything else I can add I will.

Side: I usually bump 10ish hours later when there is likely user timezone change for issues that have evidence.

de0u

ThisOldGuy I did not realize anyone could post to issue tracker thank you!

I can include my carrier but unfortunately I cannot test on regular phone. It happens consistently during the call, I haven't noticed a timing pattern though. [...] Longer calls will die, but it may be coincidental and unrelated.

Since (at least so far) I don't think there are a lot of similar reports, having some way to reproduce the problem may be a critical ingredient. So I think it's worthwhile to include as many details as possible. Sometimes timing can be a big clue, so you might want to try to firm this up by keeping a log of how phone calls work. Maybe for a few days, log on a piece of paper the start time of each call (and whether it's incoming or outgoing) and then log the times of any disruptions and whether or not there is a crash report.

de0u

ThisOldGuy I usually bump 10ish hours later when there is likely user timezone change for issues that have evidence.

I guess that might make sense if the GrapheneOS community had paid "customer service representatives" with organized shifts. But the situation is very different from that. And it is genuinely true that many readers are not in a position to comment on any individual post. Some GrapheneOS users literally do not have a SIM/eSIM, and all of their "calls" are via Signal/Molly. Some users don't make "voice calls" of any type for days or weeks. Some users almost never use speakerphone.

Meanwhile, lots of users are at least a little bit interrupted / poked by a thread popping up to the top of the list. Some people might unfollow a thread if it seems irrelevant to them, but thread topics often shift radically.

I guess I'm saying that for this forum I think a 10-hour bump is very unlikely to get more attention (or more-active attention), and at least a little likely to put a bunch of people off. I think this is particularly likely on weekends. If somebody doesn't see a post on Friday, and then some time on Saturday or Sunday or Monday sees a post followed essentially immediately by a bump, I don't think that's likely to increase the perceived urgency of the issue. That said, I don't speak for the GrapheneOS project, and this is only my opinion.

ThisOldGuy

de0u
Valid points. However people rarely scroll back on new posts for multiple days and posts can't be deleted if empty just hidden.

The only calls I make on sim are insurance related and random. The issue is now resolved and I won't likely make calls again for months. But your thoughts above made me realize I dont have this issue on Molly calls I think.

x-pve

It happened to me 2 times, no impact on phone call; I don!t do phone calls very often. I!ll post logs if it will happed again.

ThisOldGuy

x-pve
Ah thank you! Yes, I rarely make calls except the last couple weeks and the longer the call the worse it was.
Do you use handset, speaker or headset?

de0u

ThisOldGuy Valid points. However people rarely scroll back on new posts for multiple days [...]

Offhand I suspect that claim might not be based on a survey of members of this forum.

Regardless, for this particular issue, I am quite certain that the first person to respond saw the original post and the bump at the same time, more than 10 hours after the original post.

x-pve

Just caught it - I made a call, but nothing happened - quiet, call not answered. I repeated the call and all OK. But I sav a notification about audioserver crash:
`type: crash
flags: bootloader unlocked, dev options enabled
osVersion: google/komodo/komodo:16/BP2A.250805.005/2025080600:user/release-keys
uid: 1041 (u:r:audioserver:s0)
cmdline: /system/bin/audioserver
processUptime: 0s

abortMessage: TimeCheck timeout for IAudioFlinger::getInputFramesLost scheduled 07:57:33.147 on thread 8497
Timeout ms 5000.00 (3000.00 + 2000.00) elapsed steady ms 5000.5972 elapsed system ms 5000.6069
HAL pids [ 819 ]
now 07:57:39.233
secondChanceCount 1
analysis [ ]
timeout [ { IAudioFlinger::getInputFramesLost scheduled 07:57:33.147 deadline :36.147 tid 8497 } ]
pending [ ]
retired [ { IAudioFlinger::getInputFramesLost scheduled 07:57:33.108 deadline :36.108 tid 8497 } { IAudioFlinger::getInputFramesLost scheduled 07:57:33.109 deadline :36.109 tid 15467 } { IAudioFlinger::getInputFramesLost scheduled 07:57:33.128 deadline :36.128 tid 15467 } { IAudioFlinger::getInputFramesLost scheduled 07:57:33.146 deadline :36.146 tid 15467 } ]
timeout(8497) callstack [
#00 pc 00000000000e980c /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+12) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#01 pc 00000000000885d0 /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+160) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#02 pc 0000000000051248 /system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+216) (BuildId: 227bfd6b656603710e305006a6b61d7a)
#03 pc 00000000000557c8 /system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+152) (BuildId: 227bfd6b656603710e305006a6b61d7a)
#04 pc 0000000000084dcc /system/lib64/libbinder.so (android::PoolThread::threadLoop()+28) (BuildId: 227bfd6b656603710e305006a6b61d7a)
#05 pc 000000000001956c /system/lib64/libutils.so (android::Thread::_threadLoop(void)+252) (BuildId: 8708332b97701f7d01a4f87d703335f7)
#06 pc 000000000001bdb8 /system/lib64/libutils.so (libutil_thread_trampoline(void) (.uniq.226528677032898775202282855395389835431)+24) (BuildId: 8708332b97701f7d01a4f87d703335f7)
#07 pc 000000000008e254 /apex/com.android.runtime/lib64/bionic/libc.so (pthread_start(void*)+180) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#08 pc 000000000007f9f4 /apex/com.android.runtime/lib64/bionic/libc.so (start_thread+68) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
]

signal: 6 (SIGABRT), code -1 (SI_QUEUE)
threadName: binder:898_7
MTE: enabled

bobbed859

Same issue here again; it’s really annoying when it happens in the middle of a call.

type: crash
flags: dev options enabled
osVersion: google/husky/husky:16/BP2A.250805.005/2025091900:user/release-keys
uid: 1041 (u:r:audioserver:s0)
cmdline: /system/bin/audioserver
processUptime: 0s

abortMessage: TimeCheck timeout for IAudioFlinger::getInputFramesLost scheduled 18:22:13.431 on thread 4752
Timeout ms 5000.00 (3000.00 + 2000.00) elapsed steady ms 5002.1235 elapsed system ms 5002.1382
HAL pids [ 900 ]
now 18:22:19.605
secondChanceCount 3
analysis [ ]
timeout [ { IAudioFlinger::getInputFramesLost scheduled 18:22:13.431 deadline :16.431 tid 4752 } ]
pending [ ]
retired [ { IAudioFlinger::getInputFramesLost scheduled 18:22:13.385 deadline :16.385 tid 4752 } { IAudioFlinger::getInputFramesLost scheduled 18:22:13.406 deadline :16.406 tid 4752 } { IAudioFlinger::getInputFramesLost scheduled 18:22:13.427 deadline :16.427 tid 4752 } { IAudioFlinger::getInputFramesLost scheduled 18:22:13.430 deadline :16.430 tid 2288 } ]
timeout(4752) callstack [
#00 pc 00000000000e980c /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+12) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#01 pc 00000000000885d0 /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+160) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#02 pc 0000000000051248 /system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+216) (BuildId: 740e60925fa42723a8a00f259c2fd52c)
#03 pc 00000000000557c8 /system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+152) (BuildId: 740e60925fa42723a8a00f259c2fd52c)
#04 pc 0000000000082cec /system/lib64/libbinder.so (android::PoolThread::threadLoop()+28) (BuildId: 740e60925fa42723a8a00f259c2fd52c)
#05 pc 000000000001956c /system/lib64/libutils.so (android::Thread::_threadLoop(void)+252) (BuildId: 8708332b97701f7d01a4f87d703335f7)
#06 pc 000000000001bdb8 /system/lib64/libutils.so (libutil_thread_trampoline(void) (.uniq.226528677032898775202282855395389835431)+24) (BuildId: 8708332b97701f7d01a4f87d703335f7)
#07 pc 000000000008e254 /apex/com.android.runtime/lib64/bionic/libc.so (pthread_start(void*)+180) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#08 pc 000000000007f9f4 /apex/com.android.runtime/lib64/bionic/libc.so (start_thread+68) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
]

signal: 6 (SIGABRT), code -1 (SI_QUEUE)
threadName: binder:965_B
MTE: enabled

backtrace:
/apex/com.android.runtime/lib64/bionic/libc.so (ioctl+12, pc e980c)
/apex/com.android.runtime/lib64/bionic/libc.so (ioctl+160, pc 885d0)
/system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+216, pc 51248)
/system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+152, pc 557c8)
/system/lib64/libbinder.so (android::PoolThread::threadLoop()+28, pc 82cec)
/system/lib64/libutils.so (android::Thread::_threadLoop(void)+252, pc 1956c)
/system/lib64/libutils.so (libutil_thread_trampoline(void) (.uniq.226528677032898775202282855395389835431)+24, pc 1bdb8)
/apex/com.android.runtime/lib64/bionic/libc.so (pthread_start(void*)+180, pc 8e254)
/apex/com.android.runtime/lib64/bionic/libc.so (start_thread+68, pc 7f9f4)

ThisOldGuy

Sometimes toggling the hold button on-off gets me sound on a call again.
There's an open github issue that's for the audio server but I'm not sure if exactly identical.

GrapheneOS

Are you using call recording?

r134a

GrapheneOS I recently have encountered several call recordings to crash audio server. I wanted to open an issue on github but it seemed this issue is already known as there was one open issue regarding this with the tag priority-high assigned.

de0u

r134a If the newest report in the GitHub issue is from before Android 16, it might be helpful for one person to post a recent crash dump to demonstrate that it's still an issue.

r134a

I've initially stumbled upon this similar issue: https://github.com/GrapheneOS/os-issue-tracker/issues/6209, which then pointed to duplicate of https://github.com/GrapheneOS/os-issue-tracker/issues/5145, which got assigned 'priority-high' 2 days ago, so i assumed the issue is known and being worked on, if not i'm glad to provide the crash dumps in a day or 2 when i'm back home, hopefully earlier. Please let me know if i should, thanks.

de0u

r134a I think it's ok to hold off on adding to the comment thread for a week or two.

GrapheneOS

r134a It's not being worked on since no useful logs were provided and we haven't replicated it. The crash reports which have been provided aren't useful. Full system logs may be useful. We don't have much time to work on it right now. Currently, priority-high does not mean something will be worked on soon, only priority-max does.

r134a

de0u Not sure if (still) relevant in any way,
But i could provide some 'context'. In the last 2'isch weeks i had some calls which would certainly have some value when recorded, in case. The timeframe might not actually be relevant as the weeks before i didn't had to use call recording.

Consistently these times when i actually recorded audioserver crashed, never ever happened outside these specific circumstances.

Interestingly, i went through my last 4 recorded calls, and 3 of them are complete. The one that is incomplete has the lenghth of the full duration of the call, but only with audio presumably till the crash happened at 5 min 59 sec mark.

Reading paragraph above i get the impression my mind is playing tricks on me, but i'm pretty sure those last 4 recorded calls i had audioserver crashing more then the 1 incomplete recording might suggest.

I wanted to add perhaps another point, as it seems it certainly doesn't crash instanty, if there perhaps could be an indication of when it happens, say at the _6min mark, but isn't really possible with the above data. If it happens again i might pay specific attention to it and perhaps add here, if it might be of any value at all.

Perhaps zero value aswell, but all those call recordings where performed with WiFi-calling specifically. But i've not tested it on cellular.

de0u

r134a To me this all sounds useful. When time permits, I think it would be great if you could do some experiments (with a formal log). Trying calls with and without recording, and with and without Wi-Fi calling, and recording how far into a call crashes happen, could be useful. When a developer is working on something like this, it is always useful to have reliable directions for reproducing a problem, and also useful to know if a "nearby" scenario reliably does not reproduce the problem.