AppErrorsTracking工作原理揭秘为何系统级注入比UncaughtExceptionHandler更强大【免费下载链接】AppErrorsTrackingAdded more features to apps crash dialog, fixed custom rom deleted dialog, the best experience to Android developer.项目地址: https://gitcode.com/gh_mirrors/ap/AppErrorsTrackingAppErrorsTracking 是一款专为 Android 开发者打造的 Xposed 崩溃捕获模块它通过系统级框架注入全方位捕获任意应用的异常含 Native 崩溃并完全取代系统原生 FC 对话框。如果你曾在没有电脑、无法使用 ADB 的场景下苦于定位闪退问题这篇文章将带你彻底搞懂它的底层原理以及为什么它比传统的UncaughtExceptionHandler异常监听强大得多。一、先搞懂UncaughtExceptionHandler 的三大局限Thread.UncaughtExceptionHandler是 Android 开发者最熟悉的异常捕获方式——在Application中注册一个处理器未捕获的异常就会回调到它。听起来很完美但它有几个天然短板局限说明 只抓 Java/Kotlin 异常Native 层C/C崩溃的堆栈它完全无能为力 可被应用截胡应用自己再注册一次 Handler 后你的监听永远收不到异常QQ、微信等大厂应用普遍如此⚙️ 注册即负担必须在每个目标进程中注册监听产生额外开销且依赖应用主动执行初始化代码对于调试来说漏掉的正是最关键的崩溃——Native Crash 往往是线上最难复现的问题。二、核心原理向系统框架注入捕获逻辑AppErrorsTracking 走的是完全不同的路线它不碰应用的代码而是直接注入 Android 系统框架system_server。整个入口非常简洁见 HookEntry.ktoverride fun onHook() encase { loadSystem { ConfigData.init(this) loadHooker(FrameworkHooker) } }loadSystem表示 Hook 代码运行在系统框架进程中。核心逻辑全部在 FrameworkHooker.kt 中它做了三件关键的事1️⃣ 干掉原生错误对话框很多定制 ROM 删除了崩溃对话框FC Dialog模块反过来利用 Hook 彻底接管原生ErrorDialogController拦截showCrashDialogs让系统自己的崩溃弹窗静默失效对AppErrorDialog的onCreate/onStart调用cancel()兜底取消任何残留的原生对话框。2️⃣ 在崩溃处理链路上旁听模块 Hook 了系统处理应用崩溃的两个核心方法随 Android 版本自动适配AppErrors.handleAppCrashLSPBAndroid 13AppErrors.handleShowAppErrorUi低版本handleAppCrashInActivityController—— 从ApplicationErrorReport.CrashInfo中取出异常类名、异常消息、抛出位置类名/文件名/方法名/行号和完整堆栈整理进 AppErrorsInfoBean.kt 定义的统一数据结构并标记isNativeCrash字段——这就是 UncaughtExceptionHandler 永远做不到的 Native 层堆栈捕获。3️⃣ 用自定义对话框取代原生 UI捕获到崩溃后模块拉起自己的崩溃对话框 AppErrorsDisplayActivity.kt提供查看详情、重新打开应用、忽略直到解锁/重启等操作异常记录通过 FrameworkTool.kt 中的数据通道与框架进程双向通信持久保存到重启前。三、一张图看懂两种方案的区别UncaughtExceptionHandler: 应用进程内注册 → 只收 Java 异常 → 可被应用覆盖 AppErrorsTracking: 系统框架内注入 → 收全部崩溃(含 Native) → 应用无法绕过对比维度UncaughtExceptionHandlerAppErrorsTracking系统级注入捕获范围仅 Java/Kotlin 异常Java 异常 Native Crash 堆栈多进程应用每个进程都要注册系统统一记录自动区分进程是否可被应用屏蔽是自定义 Handler 后失效否系统先于应用感知性能开销需额外注册监听无额外注册直接复用系统崩溃链路崩溃后操作基本只能上报日志复制/分享/导出堆栈、重开应用、忽略管理四、如何快速体验捕获效果项目内置了一个演示应用 demo-app一键触发各种崩溃类型Java 侧RuntimeException、IllegalStateException、NullPointerException见 Channel.ktNative 侧通过 JNI 抛出 C 异常见 demo_app.cpp多进程崩溃启动子进程后在独立线程中抛错验证多进程记录能力见 MainActivity.kt⚠️注意事项系统级捕获的前提是应用没有自己处理该异常。如果应用如 QQ用自定义UncaughtExceptionHandler兜底了异常模块就无法判断它是否真正闪退——这是系统级方案唯一的盲区详情可参考 README-zh-CN.md 中的说明。五、总结AppErrorsTracking 的价值在于它站在系统崩溃处理链路的源头做捕获而不是在应用进程内设卡。这带来了三个质变——捕获范围覆盖 Native 层、应用无法绕过、零额外注册开销。对于开发者而言它是在无法连接电脑时的救命稻草对普通用户它的异常历史记录功能通知栏磁贴一键进入也能帮助你把完整的崩溃信息反馈给开发者。如果你已经 Root 并使用了 LSPosed最低支持 Android 7.0这个模块值得装进你的工具箱。【免费下载链接】AppErrorsTrackingAdded more features to apps crash dialog, fixed custom rom deleted dialog, the best experience to Android developer.项目地址: https://gitcode.com/gh_mirrors/ap/AppErrorsTracking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AppErrorsTracking工作原理揭秘：为何系统级注入比UncaughtExceptionHandler更强大
AppErrorsTracking工作原理揭秘为何系统级注入比UncaughtExceptionHandler更强大【免费下载链接】AppErrorsTrackingAdded more features to apps crash dialog, fixed custom rom deleted dialog, the best experience to Android developer.项目地址: https://gitcode.com/gh_mirrors/ap/AppErrorsTrackingAppErrorsTracking 是一款专为 Android 开发者打造的 Xposed 崩溃捕获模块它通过系统级框架注入全方位捕获任意应用的异常含 Native 崩溃并完全取代系统原生 FC 对话框。如果你曾在没有电脑、无法使用 ADB 的场景下苦于定位闪退问题这篇文章将带你彻底搞懂它的底层原理以及为什么它比传统的UncaughtExceptionHandler异常监听强大得多。一、先搞懂UncaughtExceptionHandler 的三大局限Thread.UncaughtExceptionHandler是 Android 开发者最熟悉的异常捕获方式——在Application中注册一个处理器未捕获的异常就会回调到它。听起来很完美但它有几个天然短板局限说明 只抓 Java/Kotlin 异常Native 层C/C崩溃的堆栈它完全无能为力 可被应用截胡应用自己再注册一次 Handler 后你的监听永远收不到异常QQ、微信等大厂应用普遍如此⚙️ 注册即负担必须在每个目标进程中注册监听产生额外开销且依赖应用主动执行初始化代码对于调试来说漏掉的正是最关键的崩溃——Native Crash 往往是线上最难复现的问题。二、核心原理向系统框架注入捕获逻辑AppErrorsTracking 走的是完全不同的路线它不碰应用的代码而是直接注入 Android 系统框架system_server。整个入口非常简洁见 HookEntry.ktoverride fun onHook() encase { loadSystem { ConfigData.init(this) loadHooker(FrameworkHooker) } }loadSystem表示 Hook 代码运行在系统框架进程中。核心逻辑全部在 FrameworkHooker.kt 中它做了三件关键的事1️⃣ 干掉原生错误对话框很多定制 ROM 删除了崩溃对话框FC Dialog模块反过来利用 Hook 彻底接管原生ErrorDialogController拦截showCrashDialogs让系统自己的崩溃弹窗静默失效对AppErrorDialog的onCreate/onStart调用cancel()兜底取消任何残留的原生对话框。2️⃣ 在崩溃处理链路上旁听模块 Hook 了系统处理应用崩溃的两个核心方法随 Android 版本自动适配AppErrors.handleAppCrashLSPBAndroid 13AppErrors.handleShowAppErrorUi低版本handleAppCrashInActivityController—— 从ApplicationErrorReport.CrashInfo中取出异常类名、异常消息、抛出位置类名/文件名/方法名/行号和完整堆栈整理进 AppErrorsInfoBean.kt 定义的统一数据结构并标记isNativeCrash字段——这就是 UncaughtExceptionHandler 永远做不到的 Native 层堆栈捕获。3️⃣ 用自定义对话框取代原生 UI捕获到崩溃后模块拉起自己的崩溃对话框 AppErrorsDisplayActivity.kt提供查看详情、重新打开应用、忽略直到解锁/重启等操作异常记录通过 FrameworkTool.kt 中的数据通道与框架进程双向通信持久保存到重启前。三、一张图看懂两种方案的区别UncaughtExceptionHandler: 应用进程内注册 → 只收 Java 异常 → 可被应用覆盖 AppErrorsTracking: 系统框架内注入 → 收全部崩溃(含 Native) → 应用无法绕过对比维度UncaughtExceptionHandlerAppErrorsTracking系统级注入捕获范围仅 Java/Kotlin 异常Java 异常 Native Crash 堆栈多进程应用每个进程都要注册系统统一记录自动区分进程是否可被应用屏蔽是自定义 Handler 后失效否系统先于应用感知性能开销需额外注册监听无额外注册直接复用系统崩溃链路崩溃后操作基本只能上报日志复制/分享/导出堆栈、重开应用、忽略管理四、如何快速体验捕获效果项目内置了一个演示应用 demo-app一键触发各种崩溃类型Java 侧RuntimeException、IllegalStateException、NullPointerException见 Channel.ktNative 侧通过 JNI 抛出 C 异常见 demo_app.cpp多进程崩溃启动子进程后在独立线程中抛错验证多进程记录能力见 MainActivity.kt⚠️注意事项系统级捕获的前提是应用没有自己处理该异常。如果应用如 QQ用自定义UncaughtExceptionHandler兜底了异常模块就无法判断它是否真正闪退——这是系统级方案唯一的盲区详情可参考 README-zh-CN.md 中的说明。五、总结AppErrorsTracking 的价值在于它站在系统崩溃处理链路的源头做捕获而不是在应用进程内设卡。这带来了三个质变——捕获范围覆盖 Native 层、应用无法绕过、零额外注册开销。对于开发者而言它是在无法连接电脑时的救命稻草对普通用户它的异常历史记录功能通知栏磁贴一键进入也能帮助你把完整的崩溃信息反馈给开发者。如果你已经 Root 并使用了 LSPosed最低支持 Android 7.0这个模块值得装进你的工具箱。【免费下载链接】AppErrorsTrackingAdded more features to apps crash dialog, fixed custom rom deleted dialog, the best experience to Android developer.项目地址: https://gitcode.com/gh_mirrors/ap/AppErrorsTracking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考