安卓 APP 通话记录与录音上传踩坑记录
内容提要
开发安卓通话录音上传功能需结合Java原生插件、自定义基座和真机调试。流程包括：申请通话与文件权限，读取系统通话记录，扫描本地录音文件，按号码和时间匹配，调用接口判断可否上传，上传文件后提交业务数据并缓存状态。仅靠前端权限无法稳定实现。
延伸解读
为什么纯前端方案难以稳定实现
文章指出，通话录音上传涉及监听通话状态、获取系统通话记录、扫描本地录音文件、读取受限目录以及处理厂商差异等能力，这些通常无法通过纯前端 API 稳定完成。即使申请了权限，在真机环境下也不一定能拿到数据。因此需要编写 Android 原生插件，通过 Java 调用系统能力，再暴露给前端使用。
自定义基座与真机调试的必要性
本地 H5 或普通运行环境无法测试完整链路。文章强调，必须将原生插件打包进自定义基座，并在真机上运行，否则很多原生能力不会生效。调试时需要查看真机日志，这是验证功能是否正常的关键步骤。没有自定义基座，整个流程无法走通。
权限申请中的常见陷阱
权限只是前置条件，不代表一定能拿到数据。文章提到，不同 Android 版本的权限策略不同，部分权限需要跳转系统设置页手动开启，例如所有文件访问权限不是普通弹窗权限。此外，厂商系统可能将权限入口放在不同位置，增加了适配难度。
匹配与状态管理的关键点
通话记录和录音文件需要自行匹配，不能只靠单一字段，最好结合号码和时间窗口判断。上传前需调用后端接口确认是否允许上传，上传文件后还需提交业务数据。最后要记录本地状态（未上传、已上传、上传失败、不可上传），并保存唯一标识（如手机号+通话时间+通话类型）以避免重复上传。
Q&A
开发安卓通话录音上传功能，为什么只申请权限不够？
因为通话录音相关能力很多不是纯前端 API 能稳定解决的，尤其包括监听通话状态、获取系统通话记录、扫描本地录音文件、读取部分受限目录、处理 Android 厂商差异。通常需要结合原生 Java 能力、打包自定义基座、真机调试来完成。
实现通话录音上传需要哪些关键步骤？
大致流程是：编写 Android 原生插件、配置 manifest 权限、打包自定义基座、安装到真机、前端调用原生插件能力、查看真机日志。运行时申请权限，读取系统通话记录，扫描本地录音文件，匹配通话和录音，调用接口判断是否可上传，上传录音文件，提交录音业务数据，缓存上传状态。
通话记录和录音文件如何匹配？
常见匹配依据包括手机号、通话开始时间、通话时长、录音文件名、录音文件修改时间。一般不能只靠单一字段，最好结合号码和时间窗口来判断。
上传录音文件后就算完成业务提交了吗？
不是。先把本地录音文件上传到文件服务，拿到文件地址或文件 ID，这一步只代表文件上传成功，不代表业务录音提交成功。还需要调用业务接口提交录音信息，通常包括手机号、通话类型、通话时长、通话唯一标识、录音文件地址、后端查询接口返回的业务字段。
如何避免同一条通话录音重复上传？
最后要记录本地状态，常见状态有未上传、已上传、上传失败、不可上传。同时建议保存唯一标识，例如手机号+通话时间+通话类型，用于判断同一条通话是否已经处理过。
为什么必须使用自定义基座和真机调试？
因为本地 H5 或普通运行环境无法测试完整链路。需要把原生插件打进自定义基座，然后在真机上运行。没有自定义基座，很多原生能力不会生效。
