AppErrorsTracking多进程与多用户异常捕获ProcessRecord深度解析【免费下载链接】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 异常捕获模块它从系统框架层全方位捕获任意应用的多进程、多用户崩溃信息连原生层堆栈都能记录下来让抓不到异常成为过去式。很多开发者都遇到过这样的难题App 明明闪退了国内 ROM 却把系统 FC 对话框直接删掉或者崩溃发生在:push、:remote这样的子进程里普通的异常监听工具要么漏报要么把崩溃张冠李戴到错误的进程上。这篇文章就带你深入 AppErrorsTracking 的核心——ProcessRecord看看它是怎么把多进程、多用户场景下的每一次崩溃都精准捕获下来的。为什么多进程与多用户场景这么难抓异常 在深入源码之前先理解两个 Android 特性带来的挑战场景说明抓异常的难点多进程一个 App 可同时运行多个进程如主进程、:push推送进程崩溃发生在哪个进程哪个进程崩溃才值得弹窗提醒多用户/工作资料同一 App 可在用户 0、用户 10工作资料等身份下各跑一个实例崩溃归属于哪个用户重新打开 App该打开哪个用户的实例Thread.UncaughtExceptionHandler这类应用层方案只能处理当前进程的异常且部分 App如 QQ自己注册了处理器后系统就再也拿不到崩溃信息。而 AppErrorsTracking 的做法是注入系统框架在系统真正处理崩溃的地方出手性能更好、覆盖更全面。核心原理ProcessRecord 是系统的进程身份证Android 的 ActivityManagerServiceAMS为每个运行中的进程维护一个ProcessRecord对象它是系统内部对进程的完整描述——相当于每个进程的身份证。AppErrorsTracking 要做的就是从这张身份证上读出所有关键信息。在框架钩子实现文件module-app/src/main/java/com/fankes/apperrorstracking/hook/entity/FrameworkHooker.kt中模块通过反射声明了多个框架类的引用第 69~88 行框架类用途com.android.server.am.AppErrors崩溃处理入口钩子就挂在它的方法上com.android.server.am.ProcessRecord进程身份证pid、userId、进程名的来源com.android.server.am.AppErrorDialog$Data崩溃对话框数据包含是否重复崩溃标志com.android.server.am.ProcessRecord$ErrorDialogControllerAPI 30 拆出为ErrorDialogController控制原生崩溃对话框的显示注意这里用了候选类名的写法新版本 Android 把PackageList、ErrorDialogController从内部类拆成了独立类模块会同时尝试两个名字保证跨版本兼容。钩住崩溃入口不同 Android 版本的两个挂点FrameworkHooker.kt的onHook()第 411 行起根据系统版本选择不同的钩子方法Android 12API 31以上钩住AppErrors.handleAppCrashLSPB第 457~459 行第一个参数就是ProcessRecord实例Android 12 以下钩住AppErrors.handleShowAppErrorUi第 476~478 行再从AppErrorDialog$Data的proc字段里取出ProcessRecord拿到实例后模块用统一的AppErrorsProcessData封装类第 102 行起对ProcessRecord做容错反射读取同一个字段在不同系统版本上名字可能不同比如进程 ID 在新旧版本上分别是mPid和pid第 139~144 行模块会依次尝试mPid → pid // 进程 ID userId // 用户 ID info // ApplicationInfo含包名 processName // 进程名 pkgList / getPkgList // 该进程承载的包列表这种多名字轮询 失败即降级的读取方式正是模块能从 Android 7.0 一路兼容到最新系统的秘诀。四个关键标志位读懂崩溃的身份 从ProcessRecord读出原始值后模块进一步推导出四个标志位AppErrorsProcessData第 182~216 行它们决定了崩溃如何处理标志位判定逻辑含义isActualApp包列表大小 1 且ApplicationInfo非空这是能直接启动的 App而非框架/共享进程isMainProcesspackageName processName崩溃发生在主进程子进程名如com.xx:push则不相等isBackgroundProcess通过UserController.getCurrentProfileIds比对当前用户崩溃发生在后台如工作资料的实例崩溃isRepeatingCrash读取AppErrorDialog$Data的repeating字段App 是否在短时间内重复崩溃这几个标志位直接驱动了界面上按钮的显隐。在崩溃对话框实现module-app/src/main/java/com/fankes/apperrorstracking/ui/activity/errors/AppErrorsDisplayActivity.kt中当packageName ! processName时对话框会额外显示一行崩溃进程名第 77、81 行让你一眼看出是子进程崩了重新打开按钮只在主进程崩溃时才出现FrameworkHooker.kt第 361~364 行因为子进程本来就不该由用户手动重启多用户崩溃连工作资料的实例都逃不掉 这是很多异常工具忽略的场景。模块从ProcessRecord的userId字段第 150~154 行识别崩溃归属的用户对话框标题带上用户身份非 0 用户的崩溃标题会显示为应用名 (用户 10)这样的形式第 329~333 行日志区分用户记录崩溃时日志会附加--user $userId和--pid $pid第 394~398 行多用户同时崩溃也不会混淆重新打开精准到用户AppErrorsDisplayActivity调用FrameworkTool.openAppUsedFramework时同时传入packageName和userId第 88 行等价于系统的--user参数确保重启的是崩溃的那个用户实例多进程策略崩溃弹窗也可以按需过滤 ️子进程推送、下载、统计等频繁崩溃每次都弹个对话框反而打扰。模块在module-app/src/main/java/com/fankes/apperrorstracking/data/ConfigData.kt中提供了两个开关配置项代码位置效果isEnableOnlyShowErrorsInFront第 167 行只在前景显示错误后台进程崩溃isBackgroundProcess true不再弹窗FrameworkHooker.kt第 371 行isEnableOnlyShowErrorsInMain第 177 行只监视主进程非主进程崩溃被过滤FrameworkHooker.kt第 373 行过滤只影响提醒方式——所有进程的崩溃数据依旧会被完整记录进异常历史随时可以回看做到不打扰与不遗漏兼得。动手实践3 步复现一个多进程崩溃 ️项目内置了演示应用可以直观看到子进程崩溃被捕获的效果1️⃣克隆仓库git clone https://gitcode.com/gh_mirrors/ap/AppErrorsTracking2️⃣查看演示应用的多进程配置demo-app/src/main/AndroidManifest.xml中注册了一个名为MultiProcessActivity的 Activity并通过android:process:multi_process指定它运行在独立子进程中。3️⃣触发子进程崩溃运行演示应用点击多进程异常按钮实现见demo-app/src/main/java/com/fankes/apperrorsdemo/ui/activity/MainActivity.kt第 46~57 行——它会启动子进程 Activity等待 600 毫秒后抛出一个错误。此时 AppErrorsTracking 弹出的对话框里会显示崩溃进程为com.fankes.apperrorsdemo:multi_process直观证明子进程的崩溃同样逃不过系统的捕获。小结这套方案好在哪 ✨系统级捕获注入AppErrors崩溃处理链路绕过 App 自定义异常处理器多进程、多用户、原生层堆栈一网打尽ProcessRecord 深度解析一次反射读取 pid、userId、进程名、包列表推导出主进程、后台、重复崩溃等关键身份人性化过滤前景/主进程双开关让开发者只关心真正重要的崩溃历史数据却完整保留对于没有电脑、无法 ADB 调试的场景AppErrorsTracking 让每一次多进程、多用户的崩溃都留下清晰的身份证这正是它给 Android 开发者带来的最佳排障体验。【免费下载链接】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多进程与多用户异常捕获：ProcessRecord深度解析
AppErrorsTracking多进程与多用户异常捕获ProcessRecord深度解析【免费下载链接】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 异常捕获模块它从系统框架层全方位捕获任意应用的多进程、多用户崩溃信息连原生层堆栈都能记录下来让抓不到异常成为过去式。很多开发者都遇到过这样的难题App 明明闪退了国内 ROM 却把系统 FC 对话框直接删掉或者崩溃发生在:push、:remote这样的子进程里普通的异常监听工具要么漏报要么把崩溃张冠李戴到错误的进程上。这篇文章就带你深入 AppErrorsTracking 的核心——ProcessRecord看看它是怎么把多进程、多用户场景下的每一次崩溃都精准捕获下来的。为什么多进程与多用户场景这么难抓异常 在深入源码之前先理解两个 Android 特性带来的挑战场景说明抓异常的难点多进程一个 App 可同时运行多个进程如主进程、:push推送进程崩溃发生在哪个进程哪个进程崩溃才值得弹窗提醒多用户/工作资料同一 App 可在用户 0、用户 10工作资料等身份下各跑一个实例崩溃归属于哪个用户重新打开 App该打开哪个用户的实例Thread.UncaughtExceptionHandler这类应用层方案只能处理当前进程的异常且部分 App如 QQ自己注册了处理器后系统就再也拿不到崩溃信息。而 AppErrorsTracking 的做法是注入系统框架在系统真正处理崩溃的地方出手性能更好、覆盖更全面。核心原理ProcessRecord 是系统的进程身份证Android 的 ActivityManagerServiceAMS为每个运行中的进程维护一个ProcessRecord对象它是系统内部对进程的完整描述——相当于每个进程的身份证。AppErrorsTracking 要做的就是从这张身份证上读出所有关键信息。在框架钩子实现文件module-app/src/main/java/com/fankes/apperrorstracking/hook/entity/FrameworkHooker.kt中模块通过反射声明了多个框架类的引用第 69~88 行框架类用途com.android.server.am.AppErrors崩溃处理入口钩子就挂在它的方法上com.android.server.am.ProcessRecord进程身份证pid、userId、进程名的来源com.android.server.am.AppErrorDialog$Data崩溃对话框数据包含是否重复崩溃标志com.android.server.am.ProcessRecord$ErrorDialogControllerAPI 30 拆出为ErrorDialogController控制原生崩溃对话框的显示注意这里用了候选类名的写法新版本 Android 把PackageList、ErrorDialogController从内部类拆成了独立类模块会同时尝试两个名字保证跨版本兼容。钩住崩溃入口不同 Android 版本的两个挂点FrameworkHooker.kt的onHook()第 411 行起根据系统版本选择不同的钩子方法Android 12API 31以上钩住AppErrors.handleAppCrashLSPB第 457~459 行第一个参数就是ProcessRecord实例Android 12 以下钩住AppErrors.handleShowAppErrorUi第 476~478 行再从AppErrorDialog$Data的proc字段里取出ProcessRecord拿到实例后模块用统一的AppErrorsProcessData封装类第 102 行起对ProcessRecord做容错反射读取同一个字段在不同系统版本上名字可能不同比如进程 ID 在新旧版本上分别是mPid和pid第 139~144 行模块会依次尝试mPid → pid // 进程 ID userId // 用户 ID info // ApplicationInfo含包名 processName // 进程名 pkgList / getPkgList // 该进程承载的包列表这种多名字轮询 失败即降级的读取方式正是模块能从 Android 7.0 一路兼容到最新系统的秘诀。四个关键标志位读懂崩溃的身份 从ProcessRecord读出原始值后模块进一步推导出四个标志位AppErrorsProcessData第 182~216 行它们决定了崩溃如何处理标志位判定逻辑含义isActualApp包列表大小 1 且ApplicationInfo非空这是能直接启动的 App而非框架/共享进程isMainProcesspackageName processName崩溃发生在主进程子进程名如com.xx:push则不相等isBackgroundProcess通过UserController.getCurrentProfileIds比对当前用户崩溃发生在后台如工作资料的实例崩溃isRepeatingCrash读取AppErrorDialog$Data的repeating字段App 是否在短时间内重复崩溃这几个标志位直接驱动了界面上按钮的显隐。在崩溃对话框实现module-app/src/main/java/com/fankes/apperrorstracking/ui/activity/errors/AppErrorsDisplayActivity.kt中当packageName ! processName时对话框会额外显示一行崩溃进程名第 77、81 行让你一眼看出是子进程崩了重新打开按钮只在主进程崩溃时才出现FrameworkHooker.kt第 361~364 行因为子进程本来就不该由用户手动重启多用户崩溃连工作资料的实例都逃不掉 这是很多异常工具忽略的场景。模块从ProcessRecord的userId字段第 150~154 行识别崩溃归属的用户对话框标题带上用户身份非 0 用户的崩溃标题会显示为应用名 (用户 10)这样的形式第 329~333 行日志区分用户记录崩溃时日志会附加--user $userId和--pid $pid第 394~398 行多用户同时崩溃也不会混淆重新打开精准到用户AppErrorsDisplayActivity调用FrameworkTool.openAppUsedFramework时同时传入packageName和userId第 88 行等价于系统的--user参数确保重启的是崩溃的那个用户实例多进程策略崩溃弹窗也可以按需过滤 ️子进程推送、下载、统计等频繁崩溃每次都弹个对话框反而打扰。模块在module-app/src/main/java/com/fankes/apperrorstracking/data/ConfigData.kt中提供了两个开关配置项代码位置效果isEnableOnlyShowErrorsInFront第 167 行只在前景显示错误后台进程崩溃isBackgroundProcess true不再弹窗FrameworkHooker.kt第 371 行isEnableOnlyShowErrorsInMain第 177 行只监视主进程非主进程崩溃被过滤FrameworkHooker.kt第 373 行过滤只影响提醒方式——所有进程的崩溃数据依旧会被完整记录进异常历史随时可以回看做到不打扰与不遗漏兼得。动手实践3 步复现一个多进程崩溃 ️项目内置了演示应用可以直观看到子进程崩溃被捕获的效果1️⃣克隆仓库git clone https://gitcode.com/gh_mirrors/ap/AppErrorsTracking2️⃣查看演示应用的多进程配置demo-app/src/main/AndroidManifest.xml中注册了一个名为MultiProcessActivity的 Activity并通过android:process:multi_process指定它运行在独立子进程中。3️⃣触发子进程崩溃运行演示应用点击多进程异常按钮实现见demo-app/src/main/java/com/fankes/apperrorsdemo/ui/activity/MainActivity.kt第 46~57 行——它会启动子进程 Activity等待 600 毫秒后抛出一个错误。此时 AppErrorsTracking 弹出的对话框里会显示崩溃进程为com.fankes.apperrorsdemo:multi_process直观证明子进程的崩溃同样逃不过系统的捕获。小结这套方案好在哪 ✨系统级捕获注入AppErrors崩溃处理链路绕过 App 自定义异常处理器多进程、多用户、原生层堆栈一网打尽ProcessRecord 深度解析一次反射读取 pid、userId、进程名、包列表推导出主进程、后台、重复崩溃等关键身份人性化过滤前景/主进程双开关让开发者只关心真正重要的崩溃历史数据却完整保留对于没有电脑、无法 ADB 调试的场景AppErrorsTracking 让每一次多进程、多用户的崩溃都留下清晰的身份证这正是它给 Android 开发者带来的最佳排障体验。【免费下载链接】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），仅供参考