这确实是一个在使用android studio调试时非常折磨人的问题。你遇到的这种“程序无响应”（ANR）弹窗，本质上是系统的 Activity Manager Service (AMS) 在通过 InputDispatcher 监控主线程的反馈。当你挂载调试器（Attach Debugger）并命中断点时，主线程会被挂起，导致它无法处理输入事件或通过屏障同步，从而触发系统的超时惩罚机制。
要从根本上让系统“无视”你的调试卡顿，可以尝试以下几种方案：
1. 开发者选项中的“选择待调试应用”
这是 Android 系统原生提供的调试握手机制，能够通知 AMS 延长或取消对该进程的 ANR 检测。
- 前往 设置 -> 开发者选项。
- 点击 选择待调试应用 (Select debug app)，选择你正在开发的程序。
- 勾选 等待调试器 (Wait for debugger)。
- 效果： 这样当你启动应用时，它会停留在“Waiting For Debugger”对话框，系统会自动放宽对该进程的监控，极大程度上减少调试期间的弹窗干扰。
2. 通过 ADB 修改系统全局设置
如果你正在处理 AOSP 级别的开发，可以直接通过命令关闭全局的 ANR 弹窗，防止 AppNotRespondingDialog 弹出。
关闭所有 ANR 弹窗（弹窗不会显示，但后台仍可能记录 ANR）
adb shell settings put global show_annoying_app_ops_notifications 0
在某些 ROM 中，可以使用以下命令禁用所有错误弹窗
adb shell settings put global hide_error_dialogs
3. AOSP 源码层面的“手术”
既然你在处理系统级开发，可以直接干掉 ActivityManagerService.java 中的相关逻辑。
- 在源码中找到 appNotResponding 方法。
- 在方法入口处增加逻辑判断：如果 ProcessRecord.isDebugging() 为真，则直接 return。
- 这样无论你断点多久，系统都会认为该进程处于“豁免状态”。
4. 针对 Input 超时的优化
如果是由于输入事件堆积导致的弹窗，可以临时调大系统的超时阈值。在 AOSP 源码或通过修改 build.prop（如果允许）：
- 修改 ro.input.dispatchtimeout（通常默认为 5000ms）。
- 将其改为一个巨大的数值（如 60000ms），为你的断点调试争取更多时间。
建议：
优先使用方法 1，因为它不会破坏系统的稳定性。如果你正在进行频繁的内核或 Framework 调试，方法 2 和 3 会让你耳根清净许多。
