Call recording causing audio service crashes and call interruptions

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

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)
`
Maybe it can help.

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.

bobbed859

de0u This problem occurs when you record the call; it’s an issue that has already been mentioned several times. It still happens with Android 16.

r134a

de0u I've did some tests, but would certainly not be comfortable calling them experiments;

Important mention before performing these tests: Phone updated to 2025092700 this morning.

This is the sequence of the test performed, all with call recording function:

Call 1

WiFi & LTE are enabled
No voice or background noise on both sides
Speaker disabled
Duration call: 10 min

No crash

Call 2

Airplane mode on, WiFi enabled
Background noise (Iphone next to tv, so pixel receiving audio)
Speaker disabled
Duration call: 10 min

No crash

Call 3

At this point i remembered that on all calls i had the crash happen while recording, i had speaker enabled.

Airplane mode on, WiFi enabled
Background noise (Iphone next to tv, so pixel receiving audio) (There where some instances the pixel would transmit some background noise aswell but not actively)
Speaker enabled
Duration call: 10 min

Audioserver crashed, call recording has full phone call lenght but audio cuts at 5:22, presumably when the crash happened.

log audioserver crash:

type: crash
osVersion: google/caiman/caiman:16/BP2A.250805.005/2025092700:user/release-keys
uid: 1041 (u:r:audioserver:s0)
cmdline: /system/bin/audioserver
processUptime: 0s

abortMessage: TimeCheck timeout for IAudioFlinger::getInputFramesLost scheduled 11:34:48.253 on thread 1082
Timeout ms 5000.00 (3000.00 + 2000.00) elapsed steady ms 5001.2031 elapsed system ms 5001.2139
HAL pids [ 997 ]
now 11:34:54.359
secondChanceCount 2
analysis [ ]
timeout [ { IAudioFlinger::getInputFramesLost scheduled 11:34:48.253 deadline :51.253 tid 1082 } ]
pending [ ]
retired [ { IAudioFlinger::getInputFramesLost scheduled 11:34:48.187 deadline :51.187 tid 1141 } { IAudioFlinger::getInputFramesLost scheduled 11:34:48.209 deadline :51.209 tid 1141 } { IAudioFlinger::getInputFramesLost scheduled 11:34:48.210 deadline :51.210 tid 1082 } { IAudioFlinger::getInputFramesLost scheduled 11:34:48.230 deadline :51.230 tid 1082 } ]
timeout(1082) 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 000000000007d1f0 /system/bin/audioserver (main.cfi+1728) (BuildId: d22c45c22044758807103c4115e2bce6)
#05 pc 000000000007450c /apex/com.android.runtime/lib64/bionic/libc.so (libc_init+124) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
]

signal: 6 (SIGABRT), code -1 (SI_QUEUE)
threadName: audioserver
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/bin/audioserver (main.cfi+1728, pc 7d1f0)
/apex/com.android.runtime/lib64/bionic/libc.so (libc_init+124, pc 7450c)

log android.hardware.audio.service-aidl.aoc crash:

type: crash
osVersion: google/caiman/caiman:16/BP2A.250805.005/2025092700: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:997_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)
/vendor/bin/hw/android.hardware.audio.service-aidl.aoc (main+1772, pc 9156c)
/apex/com.android.runtime/lib64/bionic/libc.so (libc_init+124, pc 7450c)

Call 4

Airplane mode on, WiFi enabled
Background noise (Iphone next to tv, so pixel receiving audio) (There where some instances the pixel would transmit some background noise aswell but not actively)
Speaker enabled
Duration call: 10 min

No crash

Call 5

Airplane mode on, WiFi enabled
Background noise (Iphone next to tv & pixel next to tv, so pixel receiving & transmitting audio)
Speaker enabled
Duration call: 10 min

Audioserver crashed twice, call recording has full phone call lenght but audio cuts at 5:16, presumably when the crash happened.

log audioserver crash:

type: crash
osVersion: google/caiman/caiman:16/BP2A.250805.005/2025092700:user/release-keys
uid: 1041 (u:r:audioserver:s0)
cmdline: /system/bin/audioserver
processUptime: 0s

abortMessage: TimeCheck timeout for IAudioFlinger::getInputFramesLost scheduled 12:05:18.575 on thread 1929
Timeout ms 5000.00 (3000.00 + 2000.00) elapsed steady ms 5000.6777 elapsed system ms 5000.6890
HAL pids [ 1753 ]
now 12:05:24.688
secondChanceCount 5
analysis [ ]
timeout [ { IAudioFlinger::getInputFramesLost scheduled 12:05:18.575 deadline :21.575 tid 1929 } ]
pending [ { IAudioFlinger::acquireAudioSessionId scheduled 12:05:18.678 deadline :21.678 tid 1757 } { IAudioFlinger::setParameters scheduled 12:05:18.695 deadline :21.695 tid 1931 } ]
retired [ { IAudioFlinger::setParameters scheduled 12:05:17.688 deadline :20.688 tid 1929 } { IAudioFlinger::getInputFramesLost scheduled 12:05:18.566 deadline :21.566 tid 1757 } { IAudioFlinger::newAudioUniqueId scheduled 12:05:18.675 deadline :21.675 tid 1757 } { IAudioPolicyService::getDevicesForAttributes scheduled 12:05:18.718 deadline :21.718 tid 1756 } ]
timeout(1929) callstack [
#00 pc 00000000000a4a60 /apex/com.android.runtime/lib64/bionic/libc.so (syscall+32) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#01 pc 000000000007e8b4 /apex/com.android.runtime/lib64/bionic/libc.so (futex_wait_ex(void volatile, bool, int, bool, timespec const)+148) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#02 pc 000000000008fdfc /apex/com.android.runtime/lib64/bionic/libc.so (NonPI::MutexLockWithTimeout(pthread_mutex_internal_t, bool, timespec const)+316) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#03 pc 00000000000a248c /system/lib64/libc++.so (std::1::mutex::lock()+12) (BuildId: ada37e5198285720b02f7d77fd27626c7782fe29)
#04 pc 0000000000164c20 /system/lib64/libaudiohal@aidl.so (android::StreamHalAidl::sendCommand(aidl::android::hardware::audio::core::StreamDescriptor::Command const&, aidl::android::hardware::audio::core::StreamDescriptor::Reply, bool, android::StreamHalAidl::StatePositions)+208) (BuildId: ed6e6dcb9932dd2bf80077dc1f1e3075)
#05 pc 0000000000164ac0 /system/lib64/libaudiohal@aidl.so (android::StreamHalAidl::updateCountersIfNeeded(aidl::android::hardware::audio::core::StreamDescriptor::Reply, android::StreamHalAidl::StatePositions)+208) (BuildId: ed6e6dcb9932dd2bf80077dc1f1e3075)
#06 pc 00000000001734bc /system/lib64/libaudiohal@aidl.so (android::StreamInHalAidl::getInputFramesLost(unsigned int)+188) (BuildId: ed6e6dcb9932dd2bf80077dc1f1e3075)
#07 pc 00000000001c1388 /system/bin/audioserver (android::RecordThread::getInputFramesLost() const+216) (BuildId: d22c45c22044758807103c4115e2bce6)
#08 pc 00000000000bffb4 /system/bin/audioserver (android::AudioFlinger::getInputFramesLost(int) const+164) (BuildId: d22c45c22044758807103c4115e2bce6)
#09 pc 00000000000e2510 /system/lib64/libaudioclient.so (android::AudioFlingerServerAdapter::getInputFramesLost(int, int)+144) (BuildId: 923fbe3a858ad1a8736b97356a136b56)
#10 pc 000000000003dc6c /system/lib64/audioflinger-aidl-cpp.so (android::media::BnAudioFlingerService::onTransact(unsigned int, android::Parcel const&, android::Parcel, unsigned int)+15372) (BuildId: be3360f96325d2802c14284fbf73f189)
#11 pc 00000000000c9c38 /system/bin/audioserver (android::AudioFlinger::onTransactWrapper(android::AudioFlingerServerAdapter::Delegate::TransactionCode, android::Parcel const&, unsigned int, std::1::function<int ()> const&)+856) (BuildId: d22c45c22044758807103c4115e2bce6)
#12 pc 00000000000e649c /system/lib64/libaudioclient.so (non-virtual thunk to android::AudioFlingerServerAdapter::onTransact(unsigned int, android::Parcel const&, android::Parcel, unsigned int)+172) (BuildId: 923fbe3a858ad1a8736b97356a136b56)
#13 pc 000000000004cae0 /system/lib64/libbinder.so (android::IPCThreadState::executeCommand(int)+752) (BuildId: 740e60925fa42723a8a00f259c2fd52c)
#14 pc 0000000000055858 /system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+296) (BuildId: 740e60925fa42723a8a00f259c2fd52c)
#15 pc 0000000000082cec /system/lib64/libbinder.so (android::PoolThread::threadLoop()+28) (BuildId: 740e60925fa42723a8a00f259c2fd52c)
#16 pc 000000000001956c /system/lib64/libutils.so (android::Thread::_threadLoop(void)+252) (BuildId: 8708332b97701f7d01a4f87d703335f7)
#17 pc 000000000001bdb8 /system/lib64/libutils.so (libutil_thread_trampoline(void) (.uniq.226528677032898775202282855395389835431)+24) (BuildId: 8708332b97701f7d01a4f87d703335f7)
#18 pc 000000000008e254 /apex/com.android.runtime/lib64/bionic/libc.so (pthread_start(void*)+180) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
#19 pc 000000000007f9f4 /apex/com.android.runtime/lib64/bionic/libc.so (start_thread+68) (BuildId: e688446b48f00a577c82f6e36cac2c6e)
]

signal: 6 (SIGABRT), code -1 (SI_QUEUE)
threadName: binder:1752_3
MTE: enabled

backtrace:
/apex/com.android.runtime/lib64/bionic/libc.so (syscall+32, pc a4a60)
/apex/com.android.runtime/lib64/bionic/libc.so (futex_wait_ex(void volatile, bool, int, bool, timespec const)+148, pc 7e8b4)
/apex/com.android.runtime/lib64/bionic/libc.so (NonPI::MutexLockWithTimeout(pthread_mutex_internal_t, bool, timespec const)+316, pc 8fdfc)
/system/lib64/libc++.so (std::1::mutex::lock()+12, pc a248c)
/system/lib64/libaudiohal@aidl.so (android::StreamHalAidl::sendCommand(aidl::android::hardware::audio::core::StreamDescriptor::Command const&, aidl::android::hardware::audio::core::StreamDescriptor::Reply, bool, android::StreamHalAidl::StatePositions)+208, pc 164c20)
/system/lib64/libaudiohal@aidl.so (android::StreamHalAidl::updateCountersIfNeeded(aidl::android::hardware::audio::core::StreamDescriptor::Reply, android::StreamHalAidl::StatePositions)+208, pc 164ac0)
/system/lib64/libaudiohal@aidl.so (android::StreamInHalAidl::getInputFramesLost(unsigned int)+188, pc 1734bc)
/system/bin/audioserver (android::RecordThread::getInputFramesLost() const+216, pc 1c1388)
/system/bin/audioserver (android::AudioFlinger::getInputFramesLost(int) const+164, pc bffb4)
/system/lib64/libaudioclient.so (android::AudioFlingerServerAdapter::getInputFramesLost(int, int)+144, pc e2510)
/system/lib64/audioflinger-aidl-cpp.so (android::media::BnAudioFlingerService::onTransact(unsigned int, android::Parcel const&, android::Parcel, unsigned int)+15372, pc 3dc6c)
/system/bin/audioserver (android::AudioFlinger::onTransactWrapper(android::AudioFlingerServerAdapter::Delegate::TransactionCode, android::Parcel const&, unsigned int, std::1::function<int ()> const&)+856, pc c9c38)
/system/lib64/libaudioclient.so (non-virtual thunk to android::AudioFlingerServerAdapter::onTransact(unsigned int, android::Parcel const&, android::Parcel, unsigned int)+172, pc e649c)
/system/lib64/libbinder.so (android::IPCThreadState::executeCommand(int)+752, pc 4cae0)
/system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+296, pc 55858)
/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)

log android.hardware.audio.service-aidl.aoc crash:

type: crash
osVersion: google/caiman/caiman:16/BP2A.250805.005/2025092700: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:1753_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)
/vendor/bin/hw/android.hardware.audio.service-aidl.aoc (main+1772, pc 9156c)
/apex/com.android.runtime/lib64/bionic/libc.so (libc_init+124, pc 7450c)

I'll refrain from adding the logs of the second crash here as it would make this thread gigantic, but if it might be of any use, i still have them.

Call 6

LTE on, WiFi disabled
Background noise (Iphone next to tv & pixel next to tv, so pixel receiving & transmitting audio)
Speaker enabled
Duration call: 10 min

Audioserver crashed 4 times, call recording has full phone call lenght but audio cuts at 5:48, presumably when the crash happened.

I'll refrain from adding the logs of those 4 crashes related to this call for the same reason mentioned above. I still haev them so if they might be of any use, i can provide them.

de0u with and without Wi-Fi calling

Interestingly, from 'tests' above i could trigger the crash on both WiFi-calling and cellular.

de0u and recording how far into a call crashes happen

Based on the limited tests, they all seem to happen between the 5-6 min mark if i base myself on where the audio cuts in the recording itself.

de0u Trying calls with and without recording

Unfortunately i only tested it with call recording, not without. I wanted to narrow down on how it could be reproduced. Unfortunately i don't have any more spare time to test this without call recording at the moment. Perhaps someone else can add to this based on these observations.

de0u it is always useful to have reliable directions for reproducing a problem,

While the data is certainly limited, i assume the best way to be able to reproduce would be:

Perform a call with call recording
Make sure the pixel receives audio, and transmits audio (Replicate a real conversation between 2 parties)
Enable Speaker
Have the call going for ₁₀ min

GrapheneOS Full system logs may be useful.

I've went trough my full system logs, but unfortunatly i'm not really comfortable sharing them as they seem to have many other specific data tied to them. If i had a spare barebones phone i would have tried to replicate these crashes and send those full system logs without any issue. Unfortunately i only have 1 device which is for personal use.

GrapheneOS we haven't replicated it.

I hope it can be replicated or narrowed down further by devs or the community based on the limited tests above. Perhaps another community member with a spare phone which is able to reproduce can provide full system logs.

GrapheneOS 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.

Thanks for the explanation. Certainly understandable since the current circumstances, there are higher priorities. I atleast hope i provided some value someone else can work with from here.

bobbed859

GrapheneOS What are the steps or commands to obtain full system logs, and how can we share them?

bobbed859

r134a

I made a call from my grapheneos device to another phone of mine, started recording, and after about 10 minutes the audio server crash appeared.

Then I made a second call, this time without recording, and left it ongoing for an hour and a half. There was no problem at all.

r134a

bobbed859 I personally don't recall it happening aswell on regular calls without recording, though 'not important' call usually don't reach the 10 min mark in my case.

Based on the tests i did above, based on call 4, it seems it might not be reproducable reliably. This might have a reason, but these are assumptions.
Call 3 & 4 are similar, though only call 3 invoked the crash.

On call 3 & 4 it was replicated only 1 partie was 'speaking', while the pixel was 'listening'. Though my kids where running around and being loud, so pixel might have had some audio input, but not actively.

It might be on call 3 there was enough audio input , and not on call 4. Based on call 5 & 6 which crashed several times when there was active audio input, this assumption might make sense.

It could be the issue lays there somewhere, combination of call recording, and active audio input in the pixel (perhaps combined with speaker).

Though these are very rough assumptions based on the limited data, and could even be unrelated at all. Nevertheless an interesing observation.