最近测试报了个偶现问题，在一同耳机切换和通话测试后，soundrecorder app播放录音文件时没有声音，通话也无法听到对方的声音，而正常的music音频能够播放.

问题发现后，抓取了对应的logcat的log, 一直在排查可疑的点，下面的Log是第一个怀疑的点，后面仔细想想，这个很明显是当播放无声后，手动调节音量键的log，当然setVolumeCurveIndex设置failed也给了个audiopolicy这个排查的方向.

06-28 16:16:37.712  9843 10368 D APM_AudioPolicyManager: setVolumeCurveIndex: wrong index 15 min=-1 max=-1
06-28 16:16:37.712  9843 10368 E APM_AudioPolicyManager: setVolumeIndexForAttributes failed to set curve index for group 7 device 0x2
06-28 16:16:37.712  1628  2141 E AudioSystem-JNI: Command failed for android_media_AudioSystem_setStreamVolumeIndex: -22
06-28 16:16:37.714  9843 10368 D APM_AudioPolicyManager: setVolumeCurveIndex: wrong index 15 min=-1 max=-1

强制做了个测试，直接在设置音量的接口处，现象是播放什么资源都无声

status_t AudioPolicyManager::setVolumeCurveIndex(int index,
                                                 audio_devices_t device,
                                                 IVolumeCurves &volumeCurves)
{
    // VOICE_CALL stream has minVolumeIndex > 0  but can be muted directly by an
    // app that has MODIFY_PHONE_STATE permission.
    bool hasVoice = hasVoiceStream(volumeCurves.getStreamTypes());
    ALOGD("%s: print volume index %d min=%d max=%d", __FUNCTION__, index,
        volumeCurves.getVolumeIndexMin(), volumeCurves.getVolumeIndexMax());
    // If this code can reproduce issue
    // index = -1;
    // If this code can reproduce issue 
    if (((index < volumeCurves.getVolumeIndexMin()) && !(hasVoice && index == 0)) ||
            (index > volumeCurves.getVolumeIndexMax())) {
        ALOGD("%s: wrong index %d min=%d max=%d", __FUNCTION__, index,
              volumeCurves.getVolumeIndexMin(), volumeCurves.getVolumeIndexMax());
        return BAD_VALUE;
    }
    if (!audio_is_output_device(device)) {
        return BAD_VALUE;
    }

    // Force max volume if stream cannot be muted
    if (!volumeCurves.canBeMuted()) index = volumeCurves.getVolumeIndexMax();

    ALOGD("%s setVolumeCurveIndex device %08x, index %d", __FUNCTION__ , device, index);
    volumeCurves.addCurrentVolumeIndex(device, index);
    return NO_ERROR;
}

一直无果。。。

后面开始继续追踪公司自己的logger本地app保存的Log，一直想通过log复原现场，看看之前的log有什么蛛丝马迹，直到看到下面的Log，原来是audio hal层的服务crash掉了

06-28 15:12:49.237 I/crash_dump64( 9835): obtaining output fd from tombstoned, type: kDebuggerdTombstone
06-28 15:12:49.238 I/tombstoned(  619): received crash request for pid 2140
06-28 15:12:49.239 I/crash_dump64( 9835): performing dump of process 855 (target tid = 2140)
06-28 15:12:49.243 F/DEBUG   ( 9835): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-28 15:12:49.243 F/DEBUG   ( 9835): Build fingerprint: 'xxx/xxx-1/xxx:11/RKQ1.210107.001/218.02.08.0036:user/release-keys'
06-28 15:12:49.243 F/DEBUG   ( 9835): Revision: 'sm6115'
06-28 15:12:49.243 F/DEBUG   ( 9835): ABI: 'arm64'
06-28 15:12:49.243 F/DEBUG   ( 9835): Timestamp: 2021-06-28 15:12:49+0800
06-28 15:12:49.243 F/DEBUG   ( 9835): pid: 855, tid: 2140, name: TimeCheckThread  >>> /system/bin/audioserver <<<
06-28 15:12:49.243 F/DEBUG   ( 9835): uid: 1041
06-28 15:12:49.243 F/DEBUG   ( 9835): signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
06-28 15:12:49.243 F/DEBUG   ( 9835): Abort message: 'TimeCheck timeout for IAudioPolicyService command 4'
06-28 15:12:49.244 F/DEBUG   ( 9835):     x0  0000000000000000  x1  000000000000085c  x2  0000000000000006  x3  0000006f079cc550
06-28 15:12:49.244 F/DEBUG   ( 9835):     x4  fefefefefefefeff  x5  fefefefefefefeff  x6  fefefefefefefeff  x7  7f7f7f7f7f7f7f7f
06-28 15:12:49.244 F/DEBUG   ( 9835):     x8  00000000000000f0  x9  5a898500ae1f6d58  x10 0000000000000000  x11 ffffffc0ffffffdf
06-28 15:12:49.244 F/DEBUG   ( 9835):     x12 0000000000000001  x13 0000000000000034  x14 0000000000000008  x15 ffffffffffffffff
06-28 15:12:49.244 F/DEBUG   ( 9835):     x16 000000720ef45c80  x17 000000720ef27b70  x18 0000006f069ae000  x19 0000000000000357
06-28 15:12:49.244 F/DEBUG   ( 9835):     x20 000000000000085c  x21 00000000ffffffff  x22 0000000000000000  x23 b400006f2d521fb4
06-28 15:12:49.244 F/DEBUG   ( 9835):     x24 b400006f2d521fb4  x25 0000006f079cccc0  x26 0000006f079ccff8  x27 00000000000fc000
06-28 15:12:49.244 F/DEBUG   ( 9835):     x28 0000006f078d4000  x29 0000006f079cc5d0
06-28 15:12:49.244 F/DEBUG   ( 9835):     lr  000000720eedb3e0  sp  0000006f079cc530  pc  000000720eedb40c  pst 0000000000000000
06-28 15:12:49.258 F/DEBUG   ( 9835): backtrace:
06-28 15:12:49.258 F/DEBUG   ( 9835):       #00 pc 000000000004e40c  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: 8d77279a411c99f8bc6edb79c76340fb)
06-28 15:12:49.258 F/DEBUG   ( 9835):       #01 pc 00000000000062b0  /system/lib64/liblog.so (__android_log_default_aborter+12) (BuildId: 53286795d97fe56c1e70dca740895c84)
06-28 15:12:49.258 F/DEBUG   ( 9835):       #02 pc 0000000000006e18  /system/lib64/liblog.so (__android_log_assert+336) (BuildId: 53286795d97fe56c1e70dca740895c84)
06-28 15:12:49.258 F/DEBUG   ( 9835):       #03 pc 000000000002f330  /system/lib64/libmediautils.so (android::TimeCheck::TimeCheckThread::threadLoop()+1072) (BuildId: be679853f80e27fd3e135454bc78757d)
06-28 15:12:49.258 F/DEBUG   ( 9835):       #04 pc 0000000000015594  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+460) (BuildId: 4e69b93bf70ed592f0029dbd1097529e)
06-28 15:12:49.258 F/DEBUG   ( 9835):       #05 pc 0000000000014d90  /system/lib64/libutils.so (thread_data_t::trampoline(thread_data_t const*)+412) (BuildId: 4e69b93bf70ed592f0029dbd1097529e)
06-28 15:12:49.258 F/DEBUG   ( 9835):       #06 pc 00000000000b0048  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64) (BuildId: 8d77279a411c99f8bc6edb79c76340fb)
06-28 15:12:49.258 F/DEBUG   ( 9835):       #07 pc 00000000000503c8  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 8d77279a411c99f8bc6edb79c76340fb)
06-28 15:12:49.654 W/NativeCrashListener( 1628): Couldn't find ProcessRecord for pid 855
06-28 15:12:49.655 E/tombstoned(  619): Tombstone written to: /data/tombstones/tombstone_01

/hardware/interfaces / audio/common/all-versions/default/service/service.cpp

int main(int /* argc */, char* /* argv */ []) {
    //play record file has no sound(occur once)
    /**
     *  audio: Ignore SIGPIPE in the default audio HAL wrapper
     *  It could happen that a service process receives a SIGPIPE
     *  while providing a dump due unexpected pipe closure on
     *  the other side. This should not lead to a service
     *  termination. Ignoring SIGPIPE is a normal practice for
     *  system services.
     *  merge patch from google
     * */
    signal(SIGPIPE, SIG_IGN);

#ifdef ARCH_ARM_32
    android::hardware::ProcessState::initWithMmapSize(getHWBinderMmapSize());
#endif
    ::android::ProcessState::initWithDriver("/dev/vndbinder");
    // start a threadpool for vndbinder interactions
    ::android::ProcessState::self()->startThreadPool();

    const int32_t defaultValue = -1;
    int32_t value =
        property_get_int32("persist.vendor.audio.service.hwbinder.size_kbyte", defaultValue);
    if (value != defaultValue) {
        ALOGD("Configuring hwbinder with mmap size %d KBytes", value);
        ProcessState::initWithMmapSize(static_cast<size_t>(value) * 1024);
    }
    configureRpcThreadpool(16, true /*callerWillJoin*/);

    // Automatic formatting tries to compact the lines, making them less readable
    // clang-format off

在默认音频 HAL 包装器中忽略 SIGPIPE 可能发生服务进程收到 SIGPIPE
同时由于意外的管道关闭而提供转储，另一边这不应该导致服务终止.忽略 SIGPIPE 是正常做法

从这个bug的解决上，日后需要注意的点是两个方面：

1. audio播放无声问题，我们第一点需要想到的是尽可能的去dump audio_policy;

2.之前忽略log的crash，因为此问题是audioserver的crash，我们手动重启audio hal server即恢复了，这说明signal杀进程影响了audio hal service的启动，另外一个是，后续如果发现log中有crash发现，最先想到的是尽量把E/tombstoned(  619): Tombstone written to: /data/tombstones/tombstone_01导出