如何解决SMS发送时出现的RESULT_ERROR_LIMIT_EXCEEDED错误？

我之前维护短信类应用时正好碰到过这个API 27新增的坑，官方文档确实说得太笼统，网上资料也少。结合当时的排查和解决经验，给你几个实际可行的方向：

1. 先确认应用权限与队列基础状态 #

• 首先检查你的应用是否是默认短信应用：非默认应用的系统短信队列上限会低很多，你可以通过Telephony.Sms.getDefaultSmsPackage()来验证。如果不是默认应用，要么引导用户设置，要么调整发送策略适配更严格的限制。
• 查看当前待发送短信队列：通过ContentResolver查询content://sms/outbox，统计待发送的短信数量。原生系统的队列阈值一般在30-50条左右，不同厂商可能有调整，如果已经接近这个数，就得暂停新的发送请求。

2. 优化发送节奏，避免批量压入 #

这个错误大多是短时间内批量丢太多请求给系统导致的，你可以这么调整：

• 给发送请求加时间间隔：比如每1-2秒发送一条，不要一次性把几十条短信都丢给SmsManager；
• 自己实现本地任务队列：把要发送的短信先存在本地数据库，然后用定时器或WorkManager控制发送节奏，每次只向系统队列推送一条，成功后再推下一条；
• 长短信用sendMultipartTextMessage()，但同样要控制发送频率，不要批量触发。

3. 错误回调里做智能重试 #

当收到RESULT_ERROR_LIMIT_EXCEEDED时，别直接放弃：

• 在PendingIntent的回调中捕获这个错误码；
• 把失败的任务加入重试队列，用指数退避策略重试（比如第一次等5秒，第二次10秒，上限设为1分钟），避免短时间内重复请求触发限制；
• 重试前先查询系统队列状态，确认有剩余空间再发送。

4. 适配厂商定制系统 #

国内厂商大多会修改原生系统的短信队列限制，有的甚至把非默认应用的上限压到10条以内：

• 在主流品牌设备上做测试，记录触发错误的具体阈值；
• 针对限制严格的厂商，要么降低发送频率，要么弹窗引导用户将应用设为默认短信应用（默认应用的队列限制会宽松很多）。

5. 扒系统日志找细节 #

有时候系统会在Logcat里输出更具体的限制信息，比如“sms queue size exceeded 40”这类提示。你可以过滤SmsManager、Telephony相关的日志，说不定能找到厂商自定义的阈值，帮你更精准地调整策略。

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