Android应用libstagefright.so库ACodec相关native崩溃定位咨询

崩溃堆栈跟踪信息：

backtrace:
#00  pc 00000000000b24a4  /system/lib/libstagefright.so (android::DataConverter::convert(android::spandroid::MediaCodecBuffer const&, android::spandroid::MediaCodecBuffer&)+27)
#00  pc 000000000009d14b  /system/lib/libstagefright.so (android::ACodec::BaseState::onOMXFillBufferDone(unsigned int, unsigned int, unsigned int, unsigned int, long long, int)+594)
#00  pc 000000000009ca8f  /system/lib/libstagefright.so (android::ACodec::BaseState::onOMXMessage(android::spandroid::AMessage const&)+274)
#00  pc 000000000000fc0b  /system/lib/libstagefright_foundation.so (android::AHierarchicalStateMachine::handleMessage(android::spandroid::AMessage const&)+58)
#00  pc 000000000009c887  /system/lib/libstagefright.so (android::ACodec::BaseState::onOMXMessageList(android::spandroid::AMessage const&)+106)
#00  pc 000000000009c4e1  /system/lib/libstagefright.so (android::ACodec::BaseState::onMessageReceived(android::spandroid::AMessage const&)+460)
#00  pc 000000000000fc0b  /system/lib/libstagefright_foundation.so (android::AHierarchicalStateMachine::handleMessage(android::spandroid::AMessage const&)+58)
#00  pc 00000000000fa85  /system/lib/libstagefright_foundation.so (android::AHandler::deliverMessage(android::spandroid::AMessage const&)+24)
#00  pc 0000000000011f91  /system/lib/libstagefright_foundation.so (android::AMessage::deliver()+60)
#00  pc 00000000000106eb  /system/lib/libstagefright_foundation.so (android::ALooper::loop()+470)
#00  pc 000000000000d32b  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+270)
#00  pc 000000000006e919  /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+80)
#00  pc 0000000000047ba3  /system/lib/libc.so (__pthread_start(void*)+22)
#00  pc 000000000001b067  /system/lib/libc.so (__start_thread+32)

该崩溃是Android多媒体框架libstagefright层的硬编解码环节抛出的native崩溃，崩溃触发点在音视频数据格式转换逻辑中，以下是具体定位方法：

1. 圈定关联业务范围 #

• 先提取Google Play Console中该崩溃的附加属性：统计崩溃集中的Android系统版本、设备厂商、CPU架构，先确认是否是特定ROM的已知系统漏洞，减少不必要的业务排查成本
• 梳理App内所有使用音视频能力的场景：包括视频播放、直播推流、视频录制/剪辑、实时音视频通话、短视频加工等依赖MediaCodec、ExoPlayer、ijkplayer等多媒体框架的功能，该崩溃和这类业务100%强关联

2. 补充采集关联调用栈 #

系统原生的native崩溃栈不会自带Java层调用链，需要手动补充采集逻辑来关联业务代码：

• 在App自定义Application中注册全局Native崩溃捕获逻辑，捕获崩溃时同步dump当前前台Activity名称、Java层完整调用栈、用户近期操作埋点记录
• 给所有多媒体组件的生命周期（初始化、启动、暂停、释放）增加专属埋点，崩溃后可通过埋点序列匹配到具体的多媒体实例和对应业务场景
• 针对崩溃集中的机型/系统版本做定向灰度测试，复现问题时通过Android Studio Profiler工具关联native堆栈和上层Java调用关系

3. 常见根因排查方向 #

从崩溃点DataConverter::convert方法可以判断，是系统底层转换音视频数据格式时访问了非法内存，常见触发原因如下：

• 上层给MediaCodec传入了非法的编解码参数，比如错误的色彩格式、不匹配的分辨率参数，导致底层数据转换时内存越界
• 上层提前释放了音视频缓冲区，但系统底层仍在访问对应内存地址，触发野指针异常
• 特定系统版本的ROM存在底层bug，比如安卓8.0部分厂商定制ROM中libstagefright的已知漏洞，这类问题无需修改业务代码，可通过系统版本白名单规避

4. 快速验证方案 #

如果暂时无法定位到具体业务代码，可以先做灰度验证缩小范围：

• 针对崩溃集中的系统版本，临时强制开启音视频软解码，禁用硬件编解码，观察崩溃率是否下降
• 检查所有MediaCodec相关逻辑，确认缓冲区生命周期管理是否正确，不要在编解码仍在运行时提前释放输入/输出缓冲区

内容的提问来源于stack exchange，提问作者John