★ FEATURED ARTICLE 简介这是一份面向Android开发者的手机验证码获取客户端示例项目PhoneNumberVerifyDemo资源包。项目聚焦客户端实现涉及短信权限申请、界面搭建、网络请求、验证码广播监听、倒计时更新、验证核对及错误处理等完整环节适合需要实现注册、登录或找回密码验证码功能的开发者参考。资源包为RAR压缩格式共51个文件体积约1.39MB包含4个Java源码、16个class编译文件、11个xml布局与配置文件、9个png界面图标、2个jar依赖库以及可直接安装的apk便于对照学习与二次开发。目前已有719人学习下载。需注意示例仅覆盖客户端侧真实项目还需自行搭建服务端或接入第三方短信服务同时应遵循HTTPS与隐私保护等最佳实践整体上手门槛较低适合初中级开发者快速理解验证码获取的典型实现流程。1. Android手机验证码的获取从短信通道到自动化输入的完整链路验证码获取这件事表面上是个权限问题实际上是一条完整信号链短信中心 → 运营商网关 → 基站 → Android系统 → 应用层。大多数开发者卡在最后两环——明明短信到了手机App却拿不到内容或者拿到了却识别不出来。这背后是Android系统对短信权限的一再收紧以及厂商ROM对通知机制的各种改造。这篇文章聚焦一个实操场景在自己开发的应用或自动化测试脚本中自动获取Android设备收到的验证码短信并完成提取与后续输入。它适合三类读者做App自动化测试的工程师、开发自动登录/注册流程的客户端开发、以及做账号体系验证工具的技术爱好者。我会把三条获取路径的原理、完整代码、权限配置和兼容性坑全部拆开讲。先说结论Android 8.0API 26之后读取短信的权限被系统对话框拦截传统方案基本失效目前最可靠、兼容性最好的是基于通知栏监听的方案。下面从原理开始一步步落地。2. 三条获取路径的原理与选型为什么通知监听成了最后的赢家2.1 短信广播、通知监听、无障碍服务可靠性与代价的三角权衡Android上获取验证码常见路径有三条。第一条是注册广播接收器监听android.provider.Telephony.SMS_RECEIVED这是Android 4.4到7.1时代的标准做法——系统收到短信后会发出一条有序广播App在Manifest里声明权限和过滤器就能在后台被唤醒。但这条路在Android 8.0之后走不通了系统要求动态注册广播且READ_SMS权限被归入敏感权限组用户一旦拒绝应用直接收不到短信广播连“已到达但被拦截”的状态都无法感知。第二条是通知栏监听核心组件是NotificationListenerService。思路很直接验证码短信到达后系统一定会弹出通知通知里包含发信人和文本内容。应用不直接碰短信而是“看到”系统已经渲染好的通知从中提取文本。这条路的关键优势在于不需要READ_SMS权限用户只需要在系统设置里给应用开一个“通知使用权”而且这个授权入口是系统级的不受运行时权限弹窗影响。第三条是无障碍服务AccessibilityService。它能读取当前屏幕上显示的所有文本理论上可以拿到任何应用的验证码输入框内容甚至能直接模拟点击。但代价很高需要用户开启无障碍开关且这类应用在应用市场上架时容易被审核重点盯防——自动化操作能力太强容易触碰用户隐私红线。对大多数场景来说用无障碍拿验证码属于“杀鸡用牛刀”而且风险远大于收益。下表是三条路径的完整对比路径所需权限用户操作成本系统兼容性主要风险短信广播READ_SMS 广播接收器运行时弹窗授权Android 7.1及以下稳定8.0失效权限被拒后完全无感知通知栏监听通知使用权系统设置里手动开启Android 4.3全兼容厂商ROM可能延迟通知回调无障碍服务无障碍开关系统设置里手动开启Android 4.3全兼容上架风险高操作权限过大2.2 Android 8.0权限分区后的信号链变化为什么广播方案集体翻车理解Android 8.0的权限模型变化是选型的关键。8.0之前SMS_RECEIVED是signature|dangerous级别的权限——系统应用和用户授权应用都能收到广播。8.0之后Google将短信权限与打电话权限并入“特殊权限组”同时禁止静态注册的隐式广播接收器接收非系统发来的广播。这意味着即使你在Manifest里写死了SMS_RECEIVED的接收器系统也不会在短信到达时唤醒你的进程。另一个被忽视的变化是Android 8.0对通知渠道Notification Channel的引入让通知监听服务拿到的Notification对象里多了一个getChannelId()字段。不同App的验证码通知走不同的渠道你在解析时如果没做渠道过滤很容易把支付类App的营销通知也识别成验证码短信导致提取错误。这个坑在后面代码部分会专门处理。常见做法是在目标设备上同时保留两条路径以通知监听为主以短信广播为兼容Android 7.1及以下设备的兜底。这样既覆盖了新老系统又不会因为系统版本差异丢掉验证码。不过这个组合会让代码复杂度上一个台阶下文先给出主干方案再讲兜底怎么加。3. 基于通知监听的验证码获取从权限申请到文本提取的完整实现3.1 最小可行工程Manifest配置与通知使用权申请先搭一个最小工程。新建一个Android项目包名按你自己的域名来这里用com.example.autocode作为示例。第一步是注册NotificationListenerService的子类并在Manifest里声明权限和服务。uses-permission android:nameandroid.permission.INTERNET / application service android:name.SmsListenerService android:exportedfalse android:label验证码监听服务 android:permissionandroid.permission.BIND_NOTIFICATION_LISTENER_SERVICE intent-filter action android:nameandroid.service.notification.NotificationListenerService / /intent-filter /service /application关键在android:permission属性——系统要求通知监听服务必须声明BIND_NOTIFICATION_LISTENER_SERVICE权限否则服务无法被系统绑定。exported设为false是因为服务只接受系统内部绑定外部应用不直接调它。Manifest配好后还需要在运行时代用户申请“通知使用权”。这个入口不能直接弹窗只能跳转到系统设置页。// MainActivity.java —— 跳转通知使用权设置页 if (!isNotificationListenerEnabled(this)) { Intent intent new Intent(android.settings.ACTION_NOTIFICATION_LISTENER_SETTINGS); // 注意部分国产ROM使用不同的Action需要做厂商适配 startActivity(intent); } else { // 服务已在运行直接开始监听 Log.d(AutoCode, notification listener already enabled); } // 检查当前应用是否已获取通知使用权 public static boolean isNotificationListenerEnabled(Context context) { String enabledListeners Settings.Secure.getString( context.getContentResolver(), enabled_notification_listeners ); return enabledListeners ! null enabledListeners.contains(context.getPackageName()); }enabled_notification_listeners是一个逗号分隔的字符串格式是组件包名/服务类全名。如果你的服务类名或者包名改了这里就会检查失败这是一个很容易忽视的配置一致性坑。3.2 服务端接收通知从onNotificationPosted回调到过滤验证码短信核心逻辑在NotificationListenerService的onNotificationPosted回调。系统每弹出一条通知这个方法就会被调用传入一个StatusBarNotification对象里面包含了包名、通知文本和时间戳。我们要做的就是从文本中筛出验证码短信。public class SmsListenerService extends NotificationListenerService { private static final String TAG AutoCode; Override public void onNotificationPosted(StatusBarNotification sbn) { // sbn.getPackageName() 拿到的是发送通知的App包名 // 短信应用通常为 com.android.mms 或厂商短信包名 String packageName sbn.getPackageName(); // 只处理短信类通知避免被无关通知刷屏 if (!isSmsPackage(packageName)) { return; } Notification notification sbn.getNotification(); if (notification null || notification.extras null) { return; } CharSequence title notification.extras.getCharSequence(Notification.EXTRA_TITLE); CharSequence text notification.extras.getCharSequence(Notification.EXTRA_TEXT); if (title null || text null) { return; } String fullText title text; String code extractVerifyCode(fullText); if (code ! null) { // 验证码已提取传回上层业务逻辑 Log.d(TAG, captured code: code); // 回调到MainActivity或者广播出去 Intent broadcast new Intent(com.example.autocode.CODE_CAPTURED); broadcast.putExtra(code, code); broadcast.putExtra(source, packageName); sendBroadcast(broadcast); } } Override public void onNotificationRemoved(StatusBarNotification sbn) { // 通知被用户划掉或自动消失时会走到这里 // 如果验证码还没被消费可以在这里做补偿处理 Log.d(TAG, notification removed: sbn.getPackageName()); } }这里的isSmsPackage需要维护一份短信应用包名列表不同厂商差异很大。常见做法是在应用启动时从Telephony.Sms.Intents里拿到默认短信应用包名再额外匹配几个常见包名如com.android.mms、com.android.message以及各厂商的短信应用。最简单的方案是凡是包名含sms、mms、message关键字的都视为短信通知宁可多收不要漏收。extras.getCharSequence(Notification.EXTRA_TEXT)拿到的是通知的正文文本。验证码短信在系统解析后正文里通常包含“验证码”或英文code字样且会有一段纯数字或字母数字混合。正文可能为空但EXTRA_TITLE通常有内容。把两者拼接后做正则匹配能提高命中率。3.3 验证码提取正则设计与优先级规则提取验证码是整个流程最玄学的一环——不同短信模板千差万别有的写“您的验证码是123456”有的写“验证码AB12CD10分钟内有效”还有的干脆没有“验证码”三个字只有一段数字。设计正则时先按优先级从高到低做多级匹配。public static String extractVerifyCode(String text) { if (text null || text.isEmpty()) { return null; } // 优先匹配“验证码”关键词后的连续数字 // 覆盖格式化符号如冒号、空格、短横线 Matcher m1 Pattern.compile((?:验证码|code|vcode|动态码)[^0-9]{0,5}([0-9]{4,8}), Pattern.CASE_INSENSITIVE).matcher(text); if (m1.find()) { return m1.group(1); } // 次优先匹配纯数字且长度在4-8位之间 Matcher m2 Pattern.compile((?![0-9])([0-9]{4,8})(?![0-9])).matcher(text); if (m2.find()) { return m2.group(1); } // 兜底英文字母数字组合常见于包含大小写的验证码 Matcher m3 Pattern.compile((?![A-Za-z0-9])([A-Za-z0-9]{4,8})(?![A-Za-z0-9])).matcher(text); if (m3.find()) { return m3.group(1); } return null; }参数设计上验证码长度限制在4到8位能覆盖国内绝大多数场景——银行验证码多为6位纯数字登录验证码多为4位或6位。如果你需要支持国际短信长度上限可以放宽到10位但误匹配率会同步上升。{0,5}表示关键词和验证码之间最多允许5个非数字字符覆盖中文冒号、英文冒号、空格、短信模板里常见的“为”“是”等连接词。一个重要细节第二条纯数字匹配规则里的(?![0-9])和(?![0-9])是负向断言用于确保匹配到的数字不是更长数字的一部分。比如短信里有“订单号12345678验证码1234”第一条规则已经优先命中“验证码1234”第二条规则不会误取订单号。但如果没有第一条规则第二条会先匹配到“12345678”而不是“1234”这就是优先级设计的价值。4. 版本兼容与厂商适配从Android 4.4到鸿蒙的差异化处理4.1 不同系统版本下通知对象的字段差异通知监听方案在Android 4.3以上都能跑但不同版本对Notification对象的字段处理有明显差异。Android 5.0API 21之前通知文本可能没有EXTRA_TEXT字段只有EXTRA_TITLE和EXTRA_TEXT_LINES。Android 5.0之后EXTRA_TEXT_LINES被删掉文本统一放EXTRA_TEXT。如果你的服务要覆盖老设备需要在取文本时做双字段回退。CharSequence text notification.extras.getCharSequence(Notification.EXTRA_TEXT); if (text null) { // Android 4.x 的兜底从文本行数组拼接 CharSequence[] lines notification.extras.getCharSequenceArray( Notification.EXTRA_TEXT_LINES ); if (lines ! null lines.length 0) { StringBuilder sb new StringBuilder(); for (CharSequence line : lines) { sb.append(line).append( ); } text sb.toString(); } }Android 8.0引入通知渠道后短信通知的getChannelId()通常是“短信”或“消息”这类渠道名。你可以根据渠道ID做一次过滤避免把外卖、快递类通知混入验证码识别——但要注意部分App会把所有通知放在同一个系统默认渠道misc里渠道过滤反而会漏所以厂家适配要谨慎。我一般会把渠道过滤做成可配置项默认关闭遇到误报再打开。4.2 国产ROM通知延迟与自启动限制的处理国产ROM某厂商的EMUI、MIUI、ColorOS等对后台进程有严格的限制策略。即使通知监听服务已经开启ROM可能延迟onNotificationPosted回调严重时拖延数秒甚至完全不回调。这通常不是你的代码问题而是ROM的“智能休眠”将应用进程挂起了。常规解法是引导用户在ROM的“自启动管理”中允许应用后台运行并开启“锁屏后保持运行”。部分ROM还要求用户在“通知使用权”之外额外授予“后台弹出界面”或“悬浮窗”权限。面对这类问题我一般会在首次启动配置页展示一份适配清单引导用户按ROM类型做设置。虽然这一步不能百分之百解决所有延迟问题但不做的话华为和部分系统上回调解体延迟会非常严重。4.3 多卡设备与双卡短信的归属识别双卡双待设备上短信可能同时到达两张卡系统会为每张卡各发一条通知。StatusBarNotification里没有直接的卡槽信息但从通知文本能够感知到——部分双卡短信的文本或标题会携带卡1/卡2标识。如果需要将验证码关联到具体号码常见做法是配合TelephonyManager读取本机号码来辅助判断或者使用运营商推送的短信中心号码前缀做区分。如果不需要区分卡槽建议在isSmsPackage判定时放行所有短信通知后续通过验证码本身去完成业务匹配。多数自动化登录场景只关心验证码内容本身不需要关心是哪张卡接收的。只有你在做多账号体系时才有必要引入卡槽识别逻辑。5. 避坑通知监听落地过程中的四个典型问题5.1 通知使用权开启后依然收不到回调现象应用内已跳转设置页并开启通知使用权但onNotificationPosted始终不触发。原因绝大多数情况下问题出在Manifest里android:name指向的服务类与enabled_notification_listeners字符串里的类名不匹配。应用升级后包名或类名变更系统还保留旧的服务组件记录新服务无法被绑定。解决先到设置里关闭通知使用权再重新开启让系统重新绑定同时检查Settings.Secure.getString(...)返回的字符串确认里面包含你当前的服务类全名。注意enabled_notification_listeners里保存的是包名/类名的完整路径如果你的服务类嵌套在内部类中路径里会用$符号而非.这点在日志排查时要留意。5.2 验证码提取成功但包含多余字符现象正则返回123456后面跟了一个空格或句点或者返回了前导的“为”字。原因短信模板在验证码后面跟着“10分钟内有效”等文案正则中的([0-9]{4,8})捕获组把数字捕获后后置文本没有完全消费掉提取逻辑如果做了trim()仍有可能把全角字符带进来。解决提取后统一做清理——去除首尾非字母数字字符同时把全角数字转成半角。// 清理捕获到的验证码 String cleaned code.replaceAll(^[^0-9A-Za-z]|[^0-9A-Za-z]$, ); // 全角转半角处理中文输入法下的数字格式 cleaned cleaned.replace(, 0).replace(, 1);这个清理放在返回前统一执行比在每个正则分支里单独处理要省事得多。验证码中包含英文字母时建议统一转为大写因为多数业务系统校验时不区分大小写但你本地做匹配或回填时统一格式会更稳。5.3 onNotificationPosted回调在主线程导致ANR现象日志里看到Input dispatching timed out或者服务出现TransactionTooLargeException。原因NotificationListenerService的回调默认运行在应用的主线程binder线程池的子类也受主线程调度影响。如果你在回调里做了网络请求、数据库写入或复杂正则会阻塞系统与应用的binder通信——系统会认为你的应用无响应杀掉进程并重试绑定。而且StatusBarNotification对象在跨进程传递时受Binder事务大小限制约1MB如果通知文本被塞入了大量图片或长文本回调时可能直接抛异常。解决回调里只做最基本的字段提取和文本拼接然后通过Handler切到工作线程做正则匹配和业务分发或者干脆统一放到一个单线程的Executor中处理。private final ExecutorService executor Executors.newSingleThreadExecutor(); Override public void onNotificationPosted(StatusBarNotification sbn) { executor.execute(() - { try { // 原文本提取与验证码匹配逻辑放到这里 } catch (Exception e) { Log.e(TAG, process notification failed, e); } }); }5.4 通知被系统收纳到“其他通知”导致提取不到现象验证码短信到达后前台没有弹横幅onNotificationPosted里收到的通知文本为空只有系统提示一条“通知已收纳”的系统消息。原因Android 8.0的用户可以主动将某个App的通知渠道设为“静默收纳”。短信App的通知被收纳后系统仍会调用onNotificationPosted但Notification对象的visibility和文本字段可能被剥掉只剩标题。解决无法直接强制取消用户的收纳行为但可以在onNotificationPosted里检测到notification.visibility Notification.VISIBILITY_PUBLIC且EXTRA_TEXT为空时尝试读取EXTRA_BIG_TEXT大视图文本。部分系统会把完整内容放在大视图里。如果大视图也为空只能降级为短信广播兜底方案并在界面上提示用户关闭该App的收纳设置。6. 进阶验证码提取后的时序协调与失败重试机制拿到验证码只是第一步真正决定方案好不好用的是验证码提取后的时序控制。常见的失败场景是验证码广播发出去了但目标输入界面还没加载完毕验证码已经过时或者验证码被提取了两次同一段码被重复消费。我通常在代码捕获到验证码之后立即做三件事打时间戳、写入本地存储SharedPreferences或文件、通过广播分发给业务层。时间戳是核心——验证码的有效期通常是60到120秒业务层消费时必须判断System.currentTimeMillis() - timestamp 120000一旦超时就丢弃避免把过期验证码提交到服务器导致登录失败。失败重试方面建议做一个环形缓冲区保存最近10条验证码记录。如果第一条验证码提交后服务器返回“验证码错误”业务层可以从缓冲区里取第二条重试。但要注意不能无限重试最多重试2次否则会把用户的风险操作次数推高触发风控。缓冲区在应用进程被杀后要持久化——用文件存储验证码 时间戳 来源包名三要素启动时重新加载。验证码正则可以再加一条白名单过滤很多平台会发送两条验证码——一条是注册验证码一条是找回密码验证码内容格式一致但语义不同。如果你的应用场景只处理登录验证码需要在短信文本里二次匹配关键词比如“登录”或“注册”再决定是否消费。我实际遇到过的情况是自动登录场景中误消费了注册验证码导致账号创建流程中断——这个问题在文档里几乎没人提但踩上一次就够你加班到深夜。回填的逻辑也可以做个更顺手的封装验证码提取后若目标App具备无障碍服务可以直接把验证码内容填充到焦点输入框如果没有无障碍权限就退化为复制到剪贴板并弹出悬浮提示由用户手动粘贴。这样既保证了自动化程度也留了人工兜底。我的习惯是默认退化到剪贴板方案只有用户明确开启无障碍后才启用自动填充——既能减少权限风险也避免在不支持的ROM上做无谓的重试。最后说一个经验通知监听的适配工作里最花时间的不是代码而是ROM行为观察。我在某图像处理Demo项目里集成这套方案时花了整整两天排查某两款手机上收不到回调的问题最后发现是ROM的电池优化把服务进程冻结了——设置里加一个“不优化”开关就全好了。这类问题无法靠代码彻底解决只能靠配置引导。建议你在发布前准备一份按机型归类的适配表单把遇到的ROM问题、设置项路径和复现步骤都记下来团队协作时能省掉大量重复沟通。希望这些记录能帮你少走一段弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
