1. 从一次线上事故说起为什么我们需要监听用户的操作行为去年我们团队负责维护一个在线教育类的App主打一对一视频授课。产品经理提了个需求要求记录下老师端和学生端的课堂互动数据用于后续的教学质量分析。起初我们只记录了常规的发言、白板操作和课件翻页。直到某天一个家长投诉说孩子上课时偷偷用手机录屏把老师讲解的付费课程内容录下来分享给了同学造成了内容泄露。我们排查后台日志发现除了常规的点击事件对这种“录屏”行为完全没有任何感知。这件事给我们敲了警钟。在移动应用开发中尤其是涉及版权内容、隐私数据或敏感操作如金融交易、在线考试的场景仅仅监听UI交互是远远不够的。用户的截屏、录屏、投屏操作往往发生在系统层面应用默认是“失明”的。但这些行为背后可能意味着内容分享、信息泄露甚至作弊风险。比如金融App里用户截屏保存了交易密码在线考试App里学生录屏记录考题或者像我们遇到的版权课程被非法录制传播。所以“监听”这些行为不是为了窥探用户隐私而是应用在特定业务场景下进行自我保护的必备能力。它让应用从被动响应变为主动感知能够在关键行为发生时及时做出反应例如在用户截屏时弹出水印警告、在检测到录屏时模糊敏感界面、在投屏开始时切换至安全演示模式。这不仅是功能需求更是安全与风控的重要一环。今天我就结合在Android平台上的多次实践系统性地拆解一下如何实现对这些系统级用户行为的监听。你会发现虽然Android没有提供直接的“截屏监听”API但通过组合不同的系统机制和巧妙的“旁路”监听我们完全可以构建出一套可靠的行为感知体系。我会从原理、实现、避坑到实战优化手把手带你走通整个流程。2. 监听截屏没有API那就创造“条件”Android系统本身并没有一个名为onScreenshotTaken()的官方回调。用户按下“电源键音量减”或三指下滑时这个动作是由系统服务MediaProjection相关服务直接处理的应用进程无从知晓。但是我们可以利用一个间接但非常有效的信号媒体库的文件变化。当用户截屏时系统最终会将一张PNG或JPEG图片保存到设备的公共图片目录下通常是Pictures/Screenshots/或DCIM/Screenshots/。我们的监听思路就从监听这个目录的文件新增事件开始。2.1 核心原理利用ContentObserver监听媒体库Android提供了ContentObserver类用于观察指定Uri内容URI指向的数据变化。媒体库的变更可以通过MediaStore.Images.Media.EXTERNAL_CONTENT_URI这个Uri来观察。它的工作流程是这样的用户截屏。系统媒体扫描服务MediaScanner将新图片文件的信息插入到MediaStore数据库中。数据库的插入操作会触发一个内容变更通知。我们注册的ContentObserver接收到这个通知。我们在回调中查询最新插入的媒体文件通过分析其路径、文件名等特征判断它是否是一次截屏。2.2 实现步骤与代码详解首先我们需要在AndroidManifest.xml中声明必要的权限。注意从Android 10 (API 29) 开始访问外部存储的权限模型发生了重大变化。!-- 对于 Android 9 (API 28) 及以下 -- uses-permission android:nameandroid.permission.READ_EXTERNAL_STORAGE / !-- 对于 Android 10 (API 29) 及以上如果需要访问其他应用的文件可能需要 -- uses-permission android:nameandroid.permission.READ_MEDIA_IMAGES / !-- 或者如果应用只访问自己创建的文件或媒体文件使用媒体库权限 -- !-- 在Android 13需要动态申请 READ_MEDIA_IMAGES --接下来在您的Activity或Service中注册ContentObserver。class ScreenshotDetector(private val context: Context) { private var contentObserver: ContentObserver? null fun startWatching() { if (contentObserver ! null) { return // 避免重复注册 } contentObserver object : ContentObserver(Handler(Looper.getMainLooper())) { override fun onChange(selfChange: Boolean, uri: Uri?) { super.onChange(selfChange, uri) // 当媒体库变化时触发 detectScreenshot(uri) } } // 注册观察者监听外部存储的图片数据变化 context.contentResolver.registerContentObserver( MediaStore.Images.Media.EXTERNAL_CONTENT_URI, true, // 监听其所有后代URI的变化 contentObserver!! ) } fun stopWatching() { contentObserver?.let { context.contentResolver.unregisterContentObserver(it) contentObserver null } } private fun detectScreenshot(uri: Uri?) { // 为了避免频繁触发可以加一个简单的防抖 // 这里我们直接查询最新的图片 val projection arrayOf( MediaStore.Images.Media.DATA, // 文件路径 MediaStore.Images.Media.DATE_ADDED, // 添加时间 MediaStore.Images.Media.DISPLAY_NAME // 文件名 ) val sortOrder ${MediaStore.Images.Media.DATE_ADDED} DESC val cursor context.contentResolver.query( MediaStore.Images.Media.EXTERNAL_CONTENT_URI, projection, null, null, sortOrder ) cursor?.use { if (it.moveToFirst()) { val path it.getString(it.getColumnIndexOrThrow(MediaStore.Images.Media.DATA)) val dateAdded it.getLong(it.getColumnIndexOrThrow(MediaStore.Images.Media.DATE_ADDED)) val fileName it.getString(it.getColumnIndexOrThrow(MediaStore.Images.Media.DISPLAY_NAME)) // 关键判断逻辑 if (isScreenshot(path, fileName, dateAdded)) { // 确认是截屏触发业务逻辑 onScreenshotDetected(path) } } } } private fun isScreenshot(path: String?, fileName: String?, dateAdded: Long): Boolean { if (path.isNullOrEmpty() || fileName.isNullOrEmpty()) { return false } // 1. 路径判断是否包含“Screenshots”目录 val isInScreenshotDir path.contains(Screenshots, ignoreCase true) // 2. 文件名判断是否以“Screenshot”或“截屏”等开头 val isScreenshotName fileName.startsWith(Screenshot_, ignoreCase true) || fileName.startsWith(截屏_, ignoreCase true) || fileName.startsWith(IMG_, ignoreCase true) // 有些厂商格式 // 3. 时间判断文件是否是在最近几秒内创建的防止处理历史图片 val currentTime System.currentTimeMillis() / 1000 val timeDiff currentTime - dateAdded val isRecent timeDiff 5 // 假设5秒内为新文件 // 综合判断在截图目录下且文件名符合特征并且是最近创建的 return (isInScreenshotDir || isScreenshotName) isRecent } // 回调接口用于通知业务层 var onScreenshotListener: ((String) - Unit)? null private fun onScreenshotDetected(imagePath: String) { onScreenshotListener?.invoke(imagePath) // 例如弹出Toast记录日志上传路径等 Log.d(ScreenshotDetector, Screenshot detected: $imagePath) Toast.makeText(context, 检测到截屏操作, Toast.LENGTH_SHORT).show() } }2.3 避坑指南与实战心得性能与防抖ContentObserver的onChange可能会被频繁调用不仅仅是截屏任何图片的增删改都可能触发。因此在detectScreenshot方法中一定要加入时间戳判断isRecent只处理最近几秒内新增的文件否则应用可能会被不必要的查询拖慢。更精细的做法可以记录上一次处理的时间戳进行节流。厂商兼容性不同手机厂商小米、华为、OPPO、vivo等的截屏保存路径和文件名规则可能不同。Pictures/Screenshots/是Android标准建议但有些厂商会保存在DCIM/Screenshots/甚至自定义目录。文件名也可能不是Screenshot_开头。最稳妥的办法是收集主流机型的特征做一个兼容性列表或者放宽路径判断条件主要依赖“最近创建”和“是图片”这两个核心特征。Android 11 的权限与作用域在Android 11及以上即使拥有READ_EXTERNAL_STORAGE权限应用默认也只能访问媒体库中的图片、视频和音频文件而不能直接通过文件路径File API访问。我们上面使用的是MediaStoreAPI 查询这是被允许的。但如果你需要读取这个图片文件的具体二进制数据去做水印分析等可能需要使用MediaStore的openInputStream方法或者申请所有文件访问权限MANAGE_EXTERNAL_STORAGE但后者上架Google Play审核非常严格非必要不申请。后台监听如果需要在应用退到后台时依然能监听截屏你需要将ScreenshotDetector放在一个Service中并注册ContentObserver。同时要注意Android的后台限制避免服务被系统杀死。可以考虑使用ForegroundService前台服务并给用户一个合理的通知。注意纯粹依赖ContentObserver在应用被杀死后是无法工作的。真正的“全局”监听需要更复杂的方案这超出了普通应用的需求范围也涉及更多的系统权限和功耗问题。3. 监听录屏与投屏借助MediaProjection的“副作用”录屏和投屏在技术原理上是一回事它们都依赖于Android的MediaProjectionAPI。这个API允许应用捕获屏幕内容生成一个视频流。录屏是将这个流编码保存为本地文件而投屏是将这个流通过网络传输到其他显示设备。因此监听录屏/投屏的核心就是监听MediaProjection服务的启动。幸运的是Android 5.0 (API 21) 引入了一个系统服务MediaProjectionManager我们可以通过它来间接感知。3.1 核心原理监听MediaProjectionManager的Callback当用户发起录屏或投屏时例如点击系统快捷设置中的“屏幕录制”或“投射”按钮系统会通过MediaProjectionManager创建一个虚拟的“投影会话”。这个会话在创建和销毁时会发送全局广播。我们的应用可以注册一个回调Callback来监听这些会话的生命周期事件。关键点这个回调监听的是整个设备上所有MediaProjection会话的状态而不仅仅是当前应用的。这意味着我们能知道用户是否正在对任何界面包括我们的应用、桌面或其他应用进行录屏或投屏。3.2 实现步骤与代码详解首先你需要获取MediaProjectionManager的实例。class ScreenCaptureDetector(private val context: Context) { private lateinit var mediaProjectionManager: MediaProjectionManager private var callback: MediaProjectionManager.Callback? null fun startWatching() { mediaProjectionManager context.getSystemService(Context.MEDIA_PROJECTION_SERVICE) as MediaProjectionManager callback object : MediaProjectionManager.Callback() { override fun onStart(sessionInfo: MediaProjectionInfo) { super.onStart(sessionInfo) // 有录屏/投屏会话开始了 onCaptureStarted(sessionInfo) } override fun onStop(sessionInfo: MediaProjectionInfo) { super.onStop(sessionInfo) // 录屏/投屏会话结束了 onCaptureStopped(sessionInfo) } } // 注册回调 mediaProjectionManager.addCallback(callback!!, Handler(Looper.getMainLooper())) } fun stopWatching() { callback?.let { mediaProjectionManager.removeCallback(it) callback null } } private fun onCaptureStarted(sessionInfo: MediaProjectionInfo) { // 这里可以获取到 sessionInfo里面包含发起录屏/投屏的包名等信息 val packageName sessionInfo.packageName Log.d(ScreenCaptureDetector, Screen capture started by: $packageName) // 判断是否是对我们自己的应用进行录屏 val isCapturingOurApp packageName ! null packageName ! context.packageName // 通常系统录屏工具的包名是 com.android.systemui 或厂商定制包名 // 第三方录屏App则有各自的包名 // 触发业务逻辑例如隐藏敏感信息切换界面到安全模式 onCaptureStateChanged(true, packageName) } private fun onCaptureStopped(sessionInfo: MediaProjectionInfo) { Log.d(ScreenCaptureDetector, Screen capture stopped.) // 触发业务逻辑恢复正常界面 onCaptureStateChanged(false, null) } // 回调接口 var onCaptureStateChangeListener: ((isCapturing: Boolean, capturerPackage: String?) - Unit)? null private fun onCaptureStateChanged(isCapturing: Boolean, packageName: String?) { onCaptureStateChangeListener?.invoke(isCapturing, packageName) if (isCapturing) { Toast.makeText(context, 检测到屏幕正在被捕获录屏/投屏, Toast.LENGTH_LONG).show() } else { Toast.makeText(context, 屏幕捕获已停止, Toast.LENGTH_SHORT).show() } } }3.3 避坑指南与实战心得API 级别限制MediaProjectionManager.Callback是在 Android API 级别 21 (Lollipop) 引入的这意味着在 Android 5.0 以下的设备上无法使用此方法。对于需要支持更低版本的应用这个功能点只能放弃或寻找其他非标准的替代方案通常不可靠。无法区分录屏与投屏这个回调只告诉我们“屏幕捕获开始了”但无法区分用户是在录屏还是投屏。对于业务来说有时需要不同的处理策略例如投屏时可能切换到演讲者视图录屏时则打上防盗水印。一个折中的办法是结合sessionInfo.packageName进行猜测系统自带的投屏功能包名、知名录屏App的包名等。但这并不完全准确。及时注册与注销这个回调需要尽早注册比如在Application的onCreate或主Activity的onCreate中。同时在不需要的时候如应用销毁一定要记得调用removeCallback注销避免内存泄漏。前台服务通知如果你希望在应用处于后台时也能收到回调同样需要将ScreenCaptureDetector放在一个Service中。但请注意MediaProjectionManager.Callback本身是绑定到系统服务的即使你的应用进程被杀死系统服务端的回调可能依然存在但你的应用进程无法接收。因此后台监听依然是一个挑战依赖于进程保活机制而这在Android高版本上受到严格限制。用户感知与体验检测到录屏/投屏后直接粗暴地退出应用或黑屏会伤害用户体验。更好的做法是进行“柔性处理”例如在金融App的密码输入界面检测到录屏时自动清空密码框并弹出提示“为保障账户安全已暂停输入”在教育App的付费视频播放界面检测到录屏时在视频上方叠加一个半透明的版权警告水印。这既达到了保护目的又没有中断用户的核心操作。4. 高级话题组合拳与边界情况处理在实际项目中单一监听手段往往不够用。我们需要根据业务场景将上述方法组合起来并处理各种边界情况。4.1 组合监听策略一个健壮的监听系统应该包含以下层次前台主动监听在应用内同时注册ContentObserver监听截屏和MediaProjectionManager.Callback监听录屏/投屏。这是最直接有效的方式。关键界面强化监听在支付页面、考题展示页面、版权视频播放页面等敏感界面除了上述监听还可以增加周期性检查。例如每隔1秒通过MediaProjectionManager.getActiveProjectionInfo()检查当前是否有活跃的投影会话。这可以作为一种补偿机制防止回调因某些原因丢失。后台兜底策略谨慎使用对于安全要求极高的应用如某些企业级应用可以考虑使用ForegroundService结合上述监听器实现后台持续监控。但必须向用户明确说明该服务的目的并提供关闭选项否则很可能违反平台政策并被用户卸载。4.2 处理“三指下滑”等快捷截屏很多国产Android ROM支持“三指下滑截屏”等手势。从监听原理上讲这和我们之前说的“电源键音量减”没有区别最终都会生成图片文件并触发MediaStore更新。因此ContentObserver方案同样有效。关键在于你的isScreenshot判断函数能否准确识别出这些截图文件。实践表明只要路径或文件名特征匹配并且文件是最近创建的就能被捕获。4.3 应对“录屏时静音”或“仅内部录音”有些录屏App提供“仅录制系统声音”或“不录制麦克风”的选项。我们的MediaProjectionManager.Callback监听的是图像捕获的会话与音频通道无关。因此无论用户选择录制哪种音频只要他在捕获屏幕图像我们就能检测到。如果业务上需要区分是否在录制声音目前没有公开的API可以做到。4.4 无障碍服务AccessibilityService的另类思路这是一个非常规但强大的方法。通过无障碍服务应用可以监听到全局的窗口变化和用户操作。理论上可以监听“屏幕截图”这个系统通知的弹出或者分析窗口内容的变化来推断截屏行为。但是我强烈不建议将无障碍服务用于此目的。原因如下用户体验极差需要引导用户到系统设置中手动开启一个听起来很吓人的“无障碍服务”转化率极低且容易被用户视为恶意软件。权限过高无障碍服务能获取的信息太多涉及严重隐私不符合最小权限原则。稳定性差不同厂商系统对无障碍服务的限制和实现差异巨大兼容性是个噩梦。政策风险Google Play 对于滥用无障碍服务的应用审核非常严格很可能被下架。因此除非是面向特定封闭场景的系统级应用否则请优先使用标准的ContentObserver和MediaProjectionManager.Callback方案。5. 实战案例为在线考试App集成防作弊监听让我们以一个在线考试App的场景将上面的知识串联起来设计一个完整的解决方案。需求考生在答题过程中禁止截屏、录屏和投屏。一旦检测到此类行为立即在后台记录作弊事件并在前端模糊当前试题弹出严重警告。架构设计创建一个核心监听服务ExamProtectionService继承自Service并在onCreate中初始化ScreenshotDetector和ScreenCaptureDetector。使用前台服务为了让服务在后台持续运行即使考生切到桌面将其设置为前台服务并显示一个常驻通知说明“考试保护服务运行中”。在考试Activity中绑定服务通过bindService获取服务实例并注册监听回调。定义回调接口服务中定义onCheatingDetected(type: CheatingType)接口其中CheatingType可以是SCREENSHOT,SCREEN_CAPTURE。处理检测事件当ScreenshotDetector回调时服务调用onCheatingDetected(CheatingType.SCREENSHOT)。当ScreenCaptureDetector的onStart回调时服务调用onCheatingDetected(CheatingType.SCREEN_CAPTURE)。Activity中的响应收到作弊事件后立即执行以下操作通过网络向服务器上报作弊事件考生ID、时间、作弊类型。使用WindowManager在当前窗口上叠加一个半透明的模糊遮罩层覆盖试题区域。弹出一个模态对话框警告考生行为已被记录并可能影响成绩。关键代码片段Service部分class ExamProtectionService : Service() { private lateinit var screenshotDetector: ScreenshotDetector private lateinit var screenCaptureDetector: ScreenCaptureDetector private var listener: ICheatingListener? null override fun onCreate() { super.onCreate() // 启动前台服务 startForegroundService() screenshotDetector ScreenshotDetector(this) screenshotDetector.onScreenshotListener { imagePath - Log.w(ExamProtection, Screenshot detected: $imagePath) listener?.onCheatingDetected(CheatingType.SCREENSHOT) } screenshotDetector.startWatching() screenCaptureDetector ScreenCaptureDetector(this) screenCaptureDetector.onCaptureStateChangeListener { isCapturing, pkgName - if (isCapturing) { Log.w(ExamProtection, Screen capture started by: $pkgName) listener?.onCheatingDetected(CheatingType.SCREEN_CAPTURE) } } screenCaptureDetector.startWatching() } private fun startForegroundService() { val channelId exam_protection_channel if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { val channel NotificationChannel( channelId, 考试监控, NotificationManager.IMPORTANCE_LOW ).apply { description 保障考试公平进行 } (getSystemService(NOTIFICATION_SERVICE) as NotificationManager) .createNotificationChannel(channel) } val notification NotificationCompat.Builder(this, channelId) .setContentTitle(在线考试) .setContentText(考试保护服务运行中) .setSmallIcon(R.drawable.ic_exam) .setPriority(NotificationCompat.PRIORITY_LOW) .build() startForeground(1, notification) } // ... 其他Service生命周期方法Binder实现等 }注意事项电量与性能长时间运行前台服务、持续监听媒体库和投影服务会带来额外的电量消耗。必须在用户体验和安全需求之间取得平衡。可以在考试开始前启动服务考试结束后立即停止。反绕过技术上的监听无法100%防止作弊。有经验的用户可能使用物理设备另一部手机对着屏幕拍摄或者使用root后的设备安装模块来隐藏录屏行为。因此防作弊是一个综合体系技术监听只是其中一环还需要结合题目乱序、限时作答、人脸识别等多项措施。法律与隐私在应用启动时必须通过清晰的用户协议和隐私政策告知用户考试期间会进行屏幕操作监控及其目的并获得用户的明确同意。这是合规的基本要求。监听用户的截屏、录屏和投屏行为是一个在特定领域非常有价值的技术点。它没有想象中那么神秘其核心在于理解Android系统处理这些操作的底层机制并找到合法的、有效的“监听点”。通过ContentObserver和MediaProjectionManager.Callback这两大工具我们已经可以覆盖绝大多数场景。剩下的就是根据自己产品的具体业务逻辑设计出合理、合规且用户体验良好的响应策略了。
Android应用如何监听截屏、录屏与投屏操作：原理、实现与实战
发布时间：2026/7/31 6:35:13
1. 从一次线上事故说起为什么我们需要监听用户的操作行为去年我们团队负责维护一个在线教育类的App主打一对一视频授课。产品经理提了个需求要求记录下老师端和学生端的课堂互动数据用于后续的教学质量分析。起初我们只记录了常规的发言、白板操作和课件翻页。直到某天一个家长投诉说孩子上课时偷偷用手机录屏把老师讲解的付费课程内容录下来分享给了同学造成了内容泄露。我们排查后台日志发现除了常规的点击事件对这种“录屏”行为完全没有任何感知。这件事给我们敲了警钟。在移动应用开发中尤其是涉及版权内容、隐私数据或敏感操作如金融交易、在线考试的场景仅仅监听UI交互是远远不够的。用户的截屏、录屏、投屏操作往往发生在系统层面应用默认是“失明”的。但这些行为背后可能意味着内容分享、信息泄露甚至作弊风险。比如金融App里用户截屏保存了交易密码在线考试App里学生录屏记录考题或者像我们遇到的版权课程被非法录制传播。所以“监听”这些行为不是为了窥探用户隐私而是应用在特定业务场景下进行自我保护的必备能力。它让应用从被动响应变为主动感知能够在关键行为发生时及时做出反应例如在用户截屏时弹出水印警告、在检测到录屏时模糊敏感界面、在投屏开始时切换至安全演示模式。这不仅是功能需求更是安全与风控的重要一环。今天我就结合在Android平台上的多次实践系统性地拆解一下如何实现对这些系统级用户行为的监听。你会发现虽然Android没有提供直接的“截屏监听”API但通过组合不同的系统机制和巧妙的“旁路”监听我们完全可以构建出一套可靠的行为感知体系。我会从原理、实现、避坑到实战优化手把手带你走通整个流程。2. 监听截屏没有API那就创造“条件”Android系统本身并没有一个名为onScreenshotTaken()的官方回调。用户按下“电源键音量减”或三指下滑时这个动作是由系统服务MediaProjection相关服务直接处理的应用进程无从知晓。但是我们可以利用一个间接但非常有效的信号媒体库的文件变化。当用户截屏时系统最终会将一张PNG或JPEG图片保存到设备的公共图片目录下通常是Pictures/Screenshots/或DCIM/Screenshots/。我们的监听思路就从监听这个目录的文件新增事件开始。2.1 核心原理利用ContentObserver监听媒体库Android提供了ContentObserver类用于观察指定Uri内容URI指向的数据变化。媒体库的变更可以通过MediaStore.Images.Media.EXTERNAL_CONTENT_URI这个Uri来观察。它的工作流程是这样的用户截屏。系统媒体扫描服务MediaScanner将新图片文件的信息插入到MediaStore数据库中。数据库的插入操作会触发一个内容变更通知。我们注册的ContentObserver接收到这个通知。我们在回调中查询最新插入的媒体文件通过分析其路径、文件名等特征判断它是否是一次截屏。2.2 实现步骤与代码详解首先我们需要在AndroidManifest.xml中声明必要的权限。注意从Android 10 (API 29) 开始访问外部存储的权限模型发生了重大变化。!-- 对于 Android 9 (API 28) 及以下 -- uses-permission android:nameandroid.permission.READ_EXTERNAL_STORAGE / !-- 对于 Android 10 (API 29) 及以上如果需要访问其他应用的文件可能需要 -- uses-permission android:nameandroid.permission.READ_MEDIA_IMAGES / !-- 或者如果应用只访问自己创建的文件或媒体文件使用媒体库权限 -- !-- 在Android 13需要动态申请 READ_MEDIA_IMAGES --接下来在您的Activity或Service中注册ContentObserver。class ScreenshotDetector(private val context: Context) { private var contentObserver: ContentObserver? null fun startWatching() { if (contentObserver ! null) { return // 避免重复注册 } contentObserver object : ContentObserver(Handler(Looper.getMainLooper())) { override fun onChange(selfChange: Boolean, uri: Uri?) { super.onChange(selfChange, uri) // 当媒体库变化时触发 detectScreenshot(uri) } } // 注册观察者监听外部存储的图片数据变化 context.contentResolver.registerContentObserver( MediaStore.Images.Media.EXTERNAL_CONTENT_URI, true, // 监听其所有后代URI的变化 contentObserver!! ) } fun stopWatching() { contentObserver?.let { context.contentResolver.unregisterContentObserver(it) contentObserver null } } private fun detectScreenshot(uri: Uri?) { // 为了避免频繁触发可以加一个简单的防抖 // 这里我们直接查询最新的图片 val projection arrayOf( MediaStore.Images.Media.DATA, // 文件路径 MediaStore.Images.Media.DATE_ADDED, // 添加时间 MediaStore.Images.Media.DISPLAY_NAME // 文件名 ) val sortOrder ${MediaStore.Images.Media.DATE_ADDED} DESC val cursor context.contentResolver.query( MediaStore.Images.Media.EXTERNAL_CONTENT_URI, projection, null, null, sortOrder ) cursor?.use { if (it.moveToFirst()) { val path it.getString(it.getColumnIndexOrThrow(MediaStore.Images.Media.DATA)) val dateAdded it.getLong(it.getColumnIndexOrThrow(MediaStore.Images.Media.DATE_ADDED)) val fileName it.getString(it.getColumnIndexOrThrow(MediaStore.Images.Media.DISPLAY_NAME)) // 关键判断逻辑 if (isScreenshot(path, fileName, dateAdded)) { // 确认是截屏触发业务逻辑 onScreenshotDetected(path) } } } } private fun isScreenshot(path: String?, fileName: String?, dateAdded: Long): Boolean { if (path.isNullOrEmpty() || fileName.isNullOrEmpty()) { return false } // 1. 路径判断是否包含“Screenshots”目录 val isInScreenshotDir path.contains(Screenshots, ignoreCase true) // 2. 文件名判断是否以“Screenshot”或“截屏”等开头 val isScreenshotName fileName.startsWith(Screenshot_, ignoreCase true) || fileName.startsWith(截屏_, ignoreCase true) || fileName.startsWith(IMG_, ignoreCase true) // 有些厂商格式 // 3. 时间判断文件是否是在最近几秒内创建的防止处理历史图片 val currentTime System.currentTimeMillis() / 1000 val timeDiff currentTime - dateAdded val isRecent timeDiff 5 // 假设5秒内为新文件 // 综合判断在截图目录下且文件名符合特征并且是最近创建的 return (isInScreenshotDir || isScreenshotName) isRecent } // 回调接口用于通知业务层 var onScreenshotListener: ((String) - Unit)? null private fun onScreenshotDetected(imagePath: String) { onScreenshotListener?.invoke(imagePath) // 例如弹出Toast记录日志上传路径等 Log.d(ScreenshotDetector, Screenshot detected: $imagePath) Toast.makeText(context, 检测到截屏操作, Toast.LENGTH_SHORT).show() } }2.3 避坑指南与实战心得性能与防抖ContentObserver的onChange可能会被频繁调用不仅仅是截屏任何图片的增删改都可能触发。因此在detectScreenshot方法中一定要加入时间戳判断isRecent只处理最近几秒内新增的文件否则应用可能会被不必要的查询拖慢。更精细的做法可以记录上一次处理的时间戳进行节流。厂商兼容性不同手机厂商小米、华为、OPPO、vivo等的截屏保存路径和文件名规则可能不同。Pictures/Screenshots/是Android标准建议但有些厂商会保存在DCIM/Screenshots/甚至自定义目录。文件名也可能不是Screenshot_开头。最稳妥的办法是收集主流机型的特征做一个兼容性列表或者放宽路径判断条件主要依赖“最近创建”和“是图片”这两个核心特征。Android 11 的权限与作用域在Android 11及以上即使拥有READ_EXTERNAL_STORAGE权限应用默认也只能访问媒体库中的图片、视频和音频文件而不能直接通过文件路径File API访问。我们上面使用的是MediaStoreAPI 查询这是被允许的。但如果你需要读取这个图片文件的具体二进制数据去做水印分析等可能需要使用MediaStore的openInputStream方法或者申请所有文件访问权限MANAGE_EXTERNAL_STORAGE但后者上架Google Play审核非常严格非必要不申请。后台监听如果需要在应用退到后台时依然能监听截屏你需要将ScreenshotDetector放在一个Service中并注册ContentObserver。同时要注意Android的后台限制避免服务被系统杀死。可以考虑使用ForegroundService前台服务并给用户一个合理的通知。注意纯粹依赖ContentObserver在应用被杀死后是无法工作的。真正的“全局”监听需要更复杂的方案这超出了普通应用的需求范围也涉及更多的系统权限和功耗问题。3. 监听录屏与投屏借助MediaProjection的“副作用”录屏和投屏在技术原理上是一回事它们都依赖于Android的MediaProjectionAPI。这个API允许应用捕获屏幕内容生成一个视频流。录屏是将这个流编码保存为本地文件而投屏是将这个流通过网络传输到其他显示设备。因此监听录屏/投屏的核心就是监听MediaProjection服务的启动。幸运的是Android 5.0 (API 21) 引入了一个系统服务MediaProjectionManager我们可以通过它来间接感知。3.1 核心原理监听MediaProjectionManager的Callback当用户发起录屏或投屏时例如点击系统快捷设置中的“屏幕录制”或“投射”按钮系统会通过MediaProjectionManager创建一个虚拟的“投影会话”。这个会话在创建和销毁时会发送全局广播。我们的应用可以注册一个回调Callback来监听这些会话的生命周期事件。关键点这个回调监听的是整个设备上所有MediaProjection会话的状态而不仅仅是当前应用的。这意味着我们能知道用户是否正在对任何界面包括我们的应用、桌面或其他应用进行录屏或投屏。3.2 实现步骤与代码详解首先你需要获取MediaProjectionManager的实例。class ScreenCaptureDetector(private val context: Context) { private lateinit var mediaProjectionManager: MediaProjectionManager private var callback: MediaProjectionManager.Callback? null fun startWatching() { mediaProjectionManager context.getSystemService(Context.MEDIA_PROJECTION_SERVICE) as MediaProjectionManager callback object : MediaProjectionManager.Callback() { override fun onStart(sessionInfo: MediaProjectionInfo) { super.onStart(sessionInfo) // 有录屏/投屏会话开始了 onCaptureStarted(sessionInfo) } override fun onStop(sessionInfo: MediaProjectionInfo) { super.onStop(sessionInfo) // 录屏/投屏会话结束了 onCaptureStopped(sessionInfo) } } // 注册回调 mediaProjectionManager.addCallback(callback!!, Handler(Looper.getMainLooper())) } fun stopWatching() { callback?.let { mediaProjectionManager.removeCallback(it) callback null } } private fun onCaptureStarted(sessionInfo: MediaProjectionInfo) { // 这里可以获取到 sessionInfo里面包含发起录屏/投屏的包名等信息 val packageName sessionInfo.packageName Log.d(ScreenCaptureDetector, Screen capture started by: $packageName) // 判断是否是对我们自己的应用进行录屏 val isCapturingOurApp packageName ! null packageName ! context.packageName // 通常系统录屏工具的包名是 com.android.systemui 或厂商定制包名 // 第三方录屏App则有各自的包名 // 触发业务逻辑例如隐藏敏感信息切换界面到安全模式 onCaptureStateChanged(true, packageName) } private fun onCaptureStopped(sessionInfo: MediaProjectionInfo) { Log.d(ScreenCaptureDetector, Screen capture stopped.) // 触发业务逻辑恢复正常界面 onCaptureStateChanged(false, null) } // 回调接口 var onCaptureStateChangeListener: ((isCapturing: Boolean, capturerPackage: String?) - Unit)? null private fun onCaptureStateChanged(isCapturing: Boolean, packageName: String?) { onCaptureStateChangeListener?.invoke(isCapturing, packageName) if (isCapturing) { Toast.makeText(context, 检测到屏幕正在被捕获录屏/投屏, Toast.LENGTH_LONG).show() } else { Toast.makeText(context, 屏幕捕获已停止, Toast.LENGTH_SHORT).show() } } }3.3 避坑指南与实战心得API 级别限制MediaProjectionManager.Callback是在 Android API 级别 21 (Lollipop) 引入的这意味着在 Android 5.0 以下的设备上无法使用此方法。对于需要支持更低版本的应用这个功能点只能放弃或寻找其他非标准的替代方案通常不可靠。无法区分录屏与投屏这个回调只告诉我们“屏幕捕获开始了”但无法区分用户是在录屏还是投屏。对于业务来说有时需要不同的处理策略例如投屏时可能切换到演讲者视图录屏时则打上防盗水印。一个折中的办法是结合sessionInfo.packageName进行猜测系统自带的投屏功能包名、知名录屏App的包名等。但这并不完全准确。及时注册与注销这个回调需要尽早注册比如在Application的onCreate或主Activity的onCreate中。同时在不需要的时候如应用销毁一定要记得调用removeCallback注销避免内存泄漏。前台服务通知如果你希望在应用处于后台时也能收到回调同样需要将ScreenCaptureDetector放在一个Service中。但请注意MediaProjectionManager.Callback本身是绑定到系统服务的即使你的应用进程被杀死系统服务端的回调可能依然存在但你的应用进程无法接收。因此后台监听依然是一个挑战依赖于进程保活机制而这在Android高版本上受到严格限制。用户感知与体验检测到录屏/投屏后直接粗暴地退出应用或黑屏会伤害用户体验。更好的做法是进行“柔性处理”例如在金融App的密码输入界面检测到录屏时自动清空密码框并弹出提示“为保障账户安全已暂停输入”在教育App的付费视频播放界面检测到录屏时在视频上方叠加一个半透明的版权警告水印。这既达到了保护目的又没有中断用户的核心操作。4. 高级话题组合拳与边界情况处理在实际项目中单一监听手段往往不够用。我们需要根据业务场景将上述方法组合起来并处理各种边界情况。4.1 组合监听策略一个健壮的监听系统应该包含以下层次前台主动监听在应用内同时注册ContentObserver监听截屏和MediaProjectionManager.Callback监听录屏/投屏。这是最直接有效的方式。关键界面强化监听在支付页面、考题展示页面、版权视频播放页面等敏感界面除了上述监听还可以增加周期性检查。例如每隔1秒通过MediaProjectionManager.getActiveProjectionInfo()检查当前是否有活跃的投影会话。这可以作为一种补偿机制防止回调因某些原因丢失。后台兜底策略谨慎使用对于安全要求极高的应用如某些企业级应用可以考虑使用ForegroundService结合上述监听器实现后台持续监控。但必须向用户明确说明该服务的目的并提供关闭选项否则很可能违反平台政策并被用户卸载。4.2 处理“三指下滑”等快捷截屏很多国产Android ROM支持“三指下滑截屏”等手势。从监听原理上讲这和我们之前说的“电源键音量减”没有区别最终都会生成图片文件并触发MediaStore更新。因此ContentObserver方案同样有效。关键在于你的isScreenshot判断函数能否准确识别出这些截图文件。实践表明只要路径或文件名特征匹配并且文件是最近创建的就能被捕获。4.3 应对“录屏时静音”或“仅内部录音”有些录屏App提供“仅录制系统声音”或“不录制麦克风”的选项。我们的MediaProjectionManager.Callback监听的是图像捕获的会话与音频通道无关。因此无论用户选择录制哪种音频只要他在捕获屏幕图像我们就能检测到。如果业务上需要区分是否在录制声音目前没有公开的API可以做到。4.4 无障碍服务AccessibilityService的另类思路这是一个非常规但强大的方法。通过无障碍服务应用可以监听到全局的窗口变化和用户操作。理论上可以监听“屏幕截图”这个系统通知的弹出或者分析窗口内容的变化来推断截屏行为。但是我强烈不建议将无障碍服务用于此目的。原因如下用户体验极差需要引导用户到系统设置中手动开启一个听起来很吓人的“无障碍服务”转化率极低且容易被用户视为恶意软件。权限过高无障碍服务能获取的信息太多涉及严重隐私不符合最小权限原则。稳定性差不同厂商系统对无障碍服务的限制和实现差异巨大兼容性是个噩梦。政策风险Google Play 对于滥用无障碍服务的应用审核非常严格很可能被下架。因此除非是面向特定封闭场景的系统级应用否则请优先使用标准的ContentObserver和MediaProjectionManager.Callback方案。5. 实战案例为在线考试App集成防作弊监听让我们以一个在线考试App的场景将上面的知识串联起来设计一个完整的解决方案。需求考生在答题过程中禁止截屏、录屏和投屏。一旦检测到此类行为立即在后台记录作弊事件并在前端模糊当前试题弹出严重警告。架构设计创建一个核心监听服务ExamProtectionService继承自Service并在onCreate中初始化ScreenshotDetector和ScreenCaptureDetector。使用前台服务为了让服务在后台持续运行即使考生切到桌面将其设置为前台服务并显示一个常驻通知说明“考试保护服务运行中”。在考试Activity中绑定服务通过bindService获取服务实例并注册监听回调。定义回调接口服务中定义onCheatingDetected(type: CheatingType)接口其中CheatingType可以是SCREENSHOT,SCREEN_CAPTURE。处理检测事件当ScreenshotDetector回调时服务调用onCheatingDetected(CheatingType.SCREENSHOT)。当ScreenCaptureDetector的onStart回调时服务调用onCheatingDetected(CheatingType.SCREEN_CAPTURE)。Activity中的响应收到作弊事件后立即执行以下操作通过网络向服务器上报作弊事件考生ID、时间、作弊类型。使用WindowManager在当前窗口上叠加一个半透明的模糊遮罩层覆盖试题区域。弹出一个模态对话框警告考生行为已被记录并可能影响成绩。关键代码片段Service部分class ExamProtectionService : Service() { private lateinit var screenshotDetector: ScreenshotDetector private lateinit var screenCaptureDetector: ScreenCaptureDetector private var listener: ICheatingListener? null override fun onCreate() { super.onCreate() // 启动前台服务 startForegroundService() screenshotDetector ScreenshotDetector(this) screenshotDetector.onScreenshotListener { imagePath - Log.w(ExamProtection, Screenshot detected: $imagePath) listener?.onCheatingDetected(CheatingType.SCREENSHOT) } screenshotDetector.startWatching() screenCaptureDetector ScreenCaptureDetector(this) screenCaptureDetector.onCaptureStateChangeListener { isCapturing, pkgName - if (isCapturing) { Log.w(ExamProtection, Screen capture started by: $pkgName) listener?.onCheatingDetected(CheatingType.SCREEN_CAPTURE) } } screenCaptureDetector.startWatching() } private fun startForegroundService() { val channelId exam_protection_channel if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { val channel NotificationChannel( channelId, 考试监控, NotificationManager.IMPORTANCE_LOW ).apply { description 保障考试公平进行 } (getSystemService(NOTIFICATION_SERVICE) as NotificationManager) .createNotificationChannel(channel) } val notification NotificationCompat.Builder(this, channelId) .setContentTitle(在线考试) .setContentText(考试保护服务运行中) .setSmallIcon(R.drawable.ic_exam) .setPriority(NotificationCompat.PRIORITY_LOW) .build() startForeground(1, notification) } // ... 其他Service生命周期方法Binder实现等 }注意事项电量与性能长时间运行前台服务、持续监听媒体库和投影服务会带来额外的电量消耗。必须在用户体验和安全需求之间取得平衡。可以在考试开始前启动服务考试结束后立即停止。反绕过技术上的监听无法100%防止作弊。有经验的用户可能使用物理设备另一部手机对着屏幕拍摄或者使用root后的设备安装模块来隐藏录屏行为。因此防作弊是一个综合体系技术监听只是其中一环还需要结合题目乱序、限时作答、人脸识别等多项措施。法律与隐私在应用启动时必须通过清晰的用户协议和隐私政策告知用户考试期间会进行屏幕操作监控及其目的并获得用户的明确同意。这是合规的基本要求。监听用户的截屏、录屏和投屏行为是一个在特定领域非常有价值的技术点。它没有想象中那么神秘其核心在于理解Android系统处理这些操作的底层机制并找到合法的、有效的“监听点”。通过ContentObserver和MediaProjectionManager.Callback这两大工具我们已经可以覆盖绝大多数场景。剩下的就是根据自己产品的具体业务逻辑设计出合理、合规且用户体验良好的响应策略了。
