嘿，这个问题问到点子上了——Android后台运行时的无障碍功能确实有不少系统层面的限制，毕竟Google一直把用户隐私和系统稳定性放在首位。我结合实际开发踩过的坑，整理了这些核心限制和具体局限：

一、进程存活与资源调度限制 #

• 进程易被回收：当应用进入后台后，系统会根据内存压力动态调整进程优先级，如果无障碍服务所在的进程没有绑定前台服务（startForegroundService()），大概率会被系统杀掉。尤其是Android 8.0（API 26）及以上版本，后台进程的存活门槛大幅提高，进程一死，无障碍服务直接停摆。
• 资源被节流：后台状态下，系统会限制无障碍服务的CPU、内存使用频率。比如你想实时监听其他应用的UI变化，这类高频操作会被系统限流，要么响应延迟，要么直接触发不了事件。

二、界面交互与敏感操作限制 #

• 后台UI无法操作：无障碍服务只能对前台应用的UI组件进行操作，后台应用的界面会被系统挂起，控件节点根本获取不到，更别说模拟点击、输入了。而且后台状态下，无障碍服务也没法主动启动其他应用的Activity，除非用户最近和你的应用有过交互，且你挂了前台服务。
• 敏感操作被拦截：涉及用户隐私的操作，比如模拟输入密码、调用相机/麦克风，哪怕你的无障碍服务有全权限，后台状态下也会被系统直接拦截——这是Google防止恶意应用滥用权限的硬规则。
• 通知栏操作受限：Android 10（API 29）及以上，后台无障碍服务不能直接操作其他应用的通知栏（比如清除通知、点击跳转），必须有用户主动交互的前提才行。

三、API调用的功能局限 #

• 实时UI事件接收失效：像AccessibilityEvent.TYPE_VIEW_CLICKED、TYPE_VIEW_TEXT_CHANGED这类实时UI事件，只有当目标应用处于前台时，无障碍服务才能收到。后台应用的UI变化，系统不会把事件推给你的服务。
• 全局系统操作失效：调用performGlobalAction(GLOBAL_ACTION_BACK)这类全局操作时，后台状态下经常会失效，尤其是系统锁屏、前台是系统级应用（比如设置、启动器）的时候。
• 控件节点获取受限：AccessibilityNodeInfo的遍历功能在后台被严格限制，你只能获取当前前台应用的控件树，连自身应用的后台控件节点都拿不到。

四、版本差异带来的额外限制 #

• Android 11+自动重置权限：如果用户长时间没和你的应用交互，后台的无障碍服务权限会被系统自动重置，得让用户手动重新授权才行。
• Android 12+启动限制：后台应用不能通过代码自动唤起无障碍设置页面请求授权了，只能引导用户手动进入设置开启服务，进一步提高了权限获取的门槛。

这些限制本质上都是为了保护用户隐私和系统稳定性，要是你有特定场景想绕开这些限制，最常用的办法就是让应用保持前台服务状态，或者引导用户频繁交互来提升进程优先级。

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