简介：本资源是一套完整的Android平台声波通信实现方案，面向移动开发初学者与物联网通信技术实践者，解决设备间无需网络、基于音频信号进行短距离数据传输的核心问题，适用于近场身份识别、离线信息交换等轻量级场景。压缩包共33个文件，含11个Java源码文件（涵盖音频采集、调制解码、信道处理等核心逻辑）、5个XML布局与配置文件、9个PNG图标资源、2个VSD设计图（展示通信流程与模块关系），以及jar依赖库、项目配置文件和说明文档，整体体积仅684KB，结构精简便于快速理解与二次开发。已有191人下载学习，资源包含可直接运行的Demo工程，目录组织规范，覆盖src主逻辑、res资源、libs依赖、AndroidManifest清单及.gitignore等标准Android项目要素，还提供proguard混淆配置与lint检查支持，适合边学边练、调试分析与通信协议原理验证。
1. 声波通信不是玄学：一个无需网络、不依赖蓝牙的离线数据通道，实测3米内稳定传文本/指令
你有没有遇到过这种场景：两台没联网的Android设备，要快速传一段WiFi密码、一个设备ID，或者给教室里的几十台平板同步下发一条重启指令？插U盘太慢，开热点又耗电，蓝牙配对在批量场景下像在走迷宫。这个「Android声波通信源码」项目，就是为这类“离线最后一公里”问题而生的——它把手机扬声器变成发射端，麦克风变成接收端，用20kHz以下人耳可听/不可听的声波频段，完成0.5~3米内的点对点数据传输。核心不是炫技，而是落地：它不依赖任何外部服务、不申请敏感权限（仅需录音和音频播放）、APK体积压到800KB以内，且已适配Android 8.0~14。某高校实验室用它做无网环境下的传感器组网调试，A同学在展会现场靠它让观众手机“听”一声就自动跳转到指定H5页面。这不是玩具级Demo，而是一套经过真实弱网、嘈杂教室、不同机型混用场景验证的轻量级通信协议栈。
2. 架构与技术选型：为什么选FSK+曼彻斯特编码，而不是直接FFT或MQTT over Audio
2.1 整体分层设计：从物理层到应用层的四层收敛
这个项目没有堆砌高大上的名词，而是严格按嵌入式通信思维分层：
- 物理层（Audio I/O）：绕过Android AudioTrack/AudioRecord的高延迟缓冲区，直接使用OpenSL ES进行毫秒级音频采样控制（采样率固定44.1kHz，16bit PCM），确保发送/接收时序可控；
- 链路层（Modulation/Demodulation）：采用FSK（频移键控）调制，用1200Hz代表0，1800Hz代表1，载波间隔600Hz——这个值是实测平衡抗噪性与解调速度的结果：再窄易受环境谐波干扰，再宽则降低码率；
- 帧结构层（Frame Protocol）：每帧含前导码（8个1200Hz周期）、起始位、8位数据、2位校验（XOR+奇偶）、结束位，总长128ms，支持最大16字节有效载荷；
- 应用层（API封装）：提供
SoundTransmitter.send(byte[])和SoundReceiver.setCallback(OnDataReceived)两个极简接口，上层业务完全不用碰信号处理逻辑。
提示：所有音频处理均在C++层完成（
libsoundcomm.so），Java层只做生命周期管理和回调分发。这是为了规避Android ART虚拟机GC导致的音频中断抖动——某次在Pixel 4上跑纯Java FFT解调，误码率高达37%，换成OpenSL后压到0.8%以下。
2.2 关键技术决策背后的血泪经验
为什么不用FFT做频谱分析？
初版确实用过FFT滑动窗检测频点，但发现教室空调低频噪声（约60Hz及其倍频）会严重污染1200Hz附近频带，导致虚警。改用Goertzel算法（一种针对单频点优化的DFT变种）后，计算量降为FFT的1/20，且对邻频干扰抑制提升4倍——代码里goertzel_detect()函数就是干这事的。
为什么校验只用XOR+奇偶，不用CRC？
CRC需要至少16位校验码，会吃掉宝贵帧长。实测中，单字节数据+2位校验的误判率已低于10⁻⁵（在信噪比≥20dB时），而加CRC会让帧长超限，被迫降速。我们宁可多发几次重传，也不牺牲实时性。
为什么限定3米？
不是技术做不到，而是物理规律：44.1kHz采样下，1800Hz正弦波每周期仅24.5个采样点，超过3米后空气衰减+多径反射会导致相位模糊，解调失败率陡增。项目里MAX_DISTANCE_METERS = 3是写死的常量，不是拍脑袋。
2.3 目录结构直击重点：删掉所有非必要文件后的精简骨架
app/ ├── src/main/ │ ├── java/com/example/soundcomm/ │ │ ├── SoundTransmitter.java // 发送控制器：配置频率、启动播放 │ │ ├── SoundReceiver.java // 接收控制器：注册回调、启动录音 │ │ └── callback/OnDataReceived.java // 应用层数据回调接口 │ ├── jni/ │ │ ├── soundcomm.cpp // OpenSL初始化、音频流绑定主逻辑 │ │ ├── fsk_modulator.cpp // FSK调制：输入byte[] → 输出PCM short[] │ │ ├── fsk_demodulator.cpp // FSK解调：输入PCM → 输出bit流 → 组帧 │ │ └── goertzel.cpp // Goertzel算法实现（核心！） │ └── res/ // 仅含基础布局和权限声明 └── CMakeLists.txt // 明确指定编译为armeabi-v7a/arm64-v8a双架构注意：没有assets/目录（不放预录音频），没有libs/（所有so动态生成），build.gradle里禁用ProGuard混淆——因为信号处理函数名若被混淆，JNI调用直接崩溃。
3. 运行实操：从零编译到真机验证的完整链路
3.1 环境准备：NDK版本与Gradle的精准匹配
这个项目对NDK版本极其敏感。实测只有NDK r21e能稳定编译通过，更高版本（如r23+）因OpenSL头文件路径变更导致#include <SLES/OpenSLES.h>报错。Gradle插件必须用4.2.2（对应Android Gradle Plugin 4.2.2），更高版本会强制启用R8导致JNI符号丢失。
# 正确配置（gradle.properties） android.useDeprecatedNdk=true ndk.dir=/path/to/android-ndk-r21e注意：
android.useDeprecatedNdk=true这行不能省！它是让Gradle回退到旧NDK构建流程的关键开关。漏掉这行，你会卡在CMake Error: Could not find cmake executable——因为新版NDK已移除独立cmake二进制。
3.2 编译命令与so生成验证
进入项目根目录，执行：
./gradlew clean assembleDebug成功后检查app/build/intermediates/merged_native_libs/debug/out/lib/目录，应存在：
arm64-v8a/libsoundcomm.so（约320KB）armeabi-v7a/libsoundcomm.so（约290KB）
验证so是否真能加载（adb shell）：
adb shell "cd /data/local/tmp && mkdir test && cd test && cp /sdcard/Download/app-debug.apk . && unzip app-debug.apk lib/arm64-v8a/libsoundcomm.so" adb shell "cd /data/local/tmp/test && LD_LIBRARY_PATH=. ./libsoundcomm.so"如果输出SoundComm initialized OK，说明so无ABI兼容性问题。
3.3 真机调试三步法：避开90%的无声/收不到坑
第一步：确认硬件通路
在SoundTransmitter.java的start()方法末尾插入：
Log.d("SoundComm", "AudioTrack state: " + audioTrack.getState() + ", playState: " + audioTrack.getPlayState());运行后看logcat：必须同时出现STATE_INITIALIZED和PLAYSTATE_PLAYING。若只有前者，说明音频焦点被抢占（比如微信语音后台占着）。
第二步：监听接收端原始音频流
修改fsk_demodulator.cpp中的onAudioBufferReceived()，在goertzel_detect()前加：
// 将接收到的PCM数据实时dump到SD卡（仅DEBUG） static int dump_counter = 0; if (dump_counter++ < 10) { FILE* f = fopen("/sdcard/sound_dump.raw", "ab"); if (f) { fwrite(buffer, 1, bytes, f); fclose(f); } }用Audacity打开sound_dump.raw（Import → Raw Data，Format=16-bit PCM，Rate=44100），看是否有清晰的1200Hz/1800Hz交替波形。没有？说明麦克风没采集到——去系统设置关掉“降噪”和“AI语音增强”。
第三步：帧同步验证
在fsk_demodulator.cpp的帧解析循环里加日志：
LOGD("Frame sync: preamble=%d, data_len=%d, checksum_ok=%d", has_preamble, data_len, checksum_ok);正常通信时，应看到连续的preamble=1, data_len=8, checksum_ok=1。若preamble=0居多，说明前导码长度不够或环境噪声太大——此时需调大PREAMBLE_CYCLES（默认8）到12。
4. 避坑指南：那些让你怀疑人生却只需改一行代码的问题
4.1 现象：发送端有声音，接收端log显示“no preamble detected”，但Audacity里波形很干净
原因：Android 10+默认开启AUDIO_SOURCE_VOICE_RECOGNITION，该模式会强制启用AGC（自动增益控制）和高通滤波，把1200Hz以下成分削掉。
解决：在SoundReceiver.java初始化AudioRecord时，显式指定MediaRecorder.AudioSource.MIC而非默认源：
audioRecord = new AudioRecord( MediaRecorder.AudioSource.MIC, // 必须写死这个！ SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSize );4.2 现象：同一台手机，用耳机孔播放能收到，外放却收不到
原因：手机外放扬声器频响范围通常为300Hz~15kHz，1800Hz虽在范围内，但谐波失真严重，导致接收端Goertzel检测出两个峰（1200Hz和1800Hz同时强）。
解决：在fsk_modulator.cpp中，将载波频率微调为1250Hz/1750Hz（差值仍为500Hz），并同步修改goertzel.cpp中的目标频率：
// goertzel.cpp 第42行 const float TARGET_FREQS[2] = {1250.0f, 1750.0f}; // 原为{1200.0f, 1800.0f}4.3 现象：小米/OPPO手机上接收成功率不足30%，华为/三星却达95%
原因：小米等厂商在AudioRecord底层做了深度定制，对短时音频（<100ms）有丢帧保护机制，而本项目单帧仅128ms，触发了保护。
解决：在SoundReceiver.java的start()方法中，启动录音前插入100ms静音缓冲：
// 在audioRecord.startRecording()前加 short[] silence = new short[SAMPLE_RATE / 10]; // 100ms静音 audioRecord.read(silence, 0, silence.length); // 强制消耗掉初始脏数据 audioRecord.startRecording();4.4 现象：发送中文字符串“你好”，接收端变成乱码“浣”
原因：Java层String.getBytes()默认用UTF-16编码，而C++层按字节流处理，未做编码转换。
解决：统一强制用UTF-8：
// 发送端 byte[] payload = "你好".getBytes(StandardCharsets.UTF_8); // 接收端回调里 String received = new String(dataBytes, StandardCharsets.UTF_8);4.5 现象：App切到后台后接收立即停止
原因：Android 8.0+对后台Service有严格限制，SoundReceiver若用Service实现会被系统杀掉。
解决：改用前台Service + Notification（最低要求）：
// 在SoundReceiver.start()中 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { startForeground(1, new NotificationCompat.Builder(this, "sound") .setContentTitle("声波通信运行中").build()); }5. 二次开发实战：如何把文本传输升级为指令控制+状态反馈闭环
5.1 指令协议扩展：从“发数据”到“发命令+等响应”
原项目只支持单向发送，但实际场景常需双向交互。比如：手机A发送CMD:REBOOT给设备B，B执行后返回ACK:OK。我们只需在帧结构层扩展，不碰物理层和调制层。
步骤1：定义新帧类型
在fsk_demodulator.cpp顶部添加枚举：
typedef enum { FRAME_TYPE_DATA = 0, FRAME_TYPE_CMD = 1, // 新增：指令帧 FRAME_TYPE_ACK = 2 // 新增：确认帧 } frame_type_t;步骤2：修改帧解析逻辑
在parse_frame()函数中，读取第0位bit后判断类型：
uint8_t frame_type = (data_bits[0] << 1) | data_bits[1]; // 取前2bit if (frame_type == FRAME_TYPE_CMD) { // 解析CMD:xxx格式，提取命令名和参数 char cmd_buf[32]; memcpy(cmd_buf, &data_bits[2], 14); // 命令体占14bit（约7字符） cmd_buf[14] = '\0'; handle_command(cmd_buf); // 调用业务逻辑 }步骤3：实现ACK自动回复
在handle_command()中，当收到CMD:REBOOT时：
void handle_command(char* cmd) { if (strcmp(cmd, "REBOOT") == 0) { // 执行重启逻辑（此处省略） // 然后立即发ACK uint8_t ack_frame[16] = {0}; ack_frame[0] = (FRAME_TYPE_ACK << 6) | 0x3F; // 类型+填充 memcpy(&ack_frame[1], "OK", 2); transmitter_send(ack_frame, 16); // 复用现有发送函数 } }5.2 状态反馈可视化：在UI层加实时信噪比指示器
用户需要知道当前通信质量。我们在Java层加一个SNRMonitor类，利用接收端原始PCM数据计算信噪比：
public class SNRMonitor { private static final int WINDOW_SIZE = 1024; private double[] window = new double[WINDOW_SIZE]; private int ptr = 0; public void updateSample(short sample) { window[ptr] = Math.abs(sample); ptr = (ptr + 1) % WINDOW_SIZE; } public double getSNR() { // 计算窗口内RMS值（信号强度） double signal_rms = 0; for (double v : window) signal_rms += v * v; signal_rms = Math.sqrt(signal_rms / WINDOW_SIZE); // 估算噪声基底（取最小10%样本的均值） double[] sorted = Arrays.copyOf(window, window.length); Arrays.sort(sorted); double noise_floor = 0; for (int i = 0; i < sorted.length / 10; i++) { noise_floor += sorted[i]; } noise_floor /= (sorted.length / 10); return signal_rms > noise_floor ? 20 * Math.log10(signal_rms / noise_floor) : 0; } }在Activity中每200ms更新一次UI：
new Handler(Looper.getMainLooper()).postDelayed(new Runnable() { @Override public void run() { double snr = snrMonitor.getSNR(); snrBar.setProgress((int) Math.min(100, snr)); // 进度条映射0-100 snrText.setText(String.format("SNR: %.1fdB", snr)); handler.postDelayed(this, 200); } }, 200);5.3 性能压测技巧：用自动化脚本模拟百台设备并发
想验证大规模部署效果？别手动点一百次。写个Python脚本，用ADB批量控制：
import subprocess import time DEVICES = ["0123456789ABCDEF", "FEDCBA9876543210"] # 设备序列号 def send_cmd(device_id, cmd): subprocess.run([ "adb", "-s", device_id, "shell", "am broadcast -a com.example.soundcomm.SEND_CMD --es data '{}'".format(cmd) ]) # 同时向所有设备发指令 for dev in DEVICES: send_cmd(dev, "REBOOT") # 3秒后检查日志 time.sleep(3) for dev in DEVICES: result = subprocess.run([ "adb", "-s", dev, "logcat", "-t", "10", "SoundComm:D" ], capture_output=True, text=True) print(f"{dev}: {result.stdout[-200:]}")关键点：用am broadcast而非adb shell input keyevent，避免触控事件排队阻塞。
从那以后我每次做跨设备通信项目，都强制走一遍“静音缓冲→AGC关闭→SNR监控”三板斧。不是怕出错，而是知道哪些坑踩过一次就足够疼。希望帮到你。
本文还有配套的精品资源，点击获取
