Android平台无需fork进程捕获程序退出码的实现方案咨询

核心卡点很明确：atexit注册的回调本身设计上就不接收退出码参数，单靠这套机制天然拿不到对应退出值，加上不能fork、必须保留OpenGL ES上下文的硬约束，完全可以走bionic原生支持的进程内符号拦截路径实现目标，具体实现路径如下：

无侵入的核心实现路径 #

• 动态链接GOT表符号前置拦截
  • 利用bionic动态链接器支持的进程内符号重定向能力，在目标JVM加载完成前，遍历进程全局GOT表，把exit()、_exit()、abort()对应条目的函数指针，替换成自己实现的包装函数
  • 这套操作全程在当前进程的地址空间内完成，没有任何fork行为，不会破坏已绑定的OpenGL ES上下文，也不需要修改目标JVM的任何源码逻辑
  • 包装函数的逻辑非常简单：入口处直接接收调用方传入的退出码参数，存入全局共享的存储位置，触发自定义的捕获回调，之后直接跳转到libc中保留的原始exit()函数地址，完成正常的退出流程即可
  • 相比atexit机制，这种拦截方式是在exit()函数的最入口位置获取参数，天然就能拿到调用方传入的退出值，不存在拿不到参数的问题
• Bionic内部原生退出钩子复用
  • 从Android 8.0开始，bionic在libc初始化流程中内置了退出观察者钩子，这套钩子的回调接口是直接透传exit调用时的退出码参数的，和atexit所属的回调链路完全独立
  • 可以通过解析libc.so的动态符号表定位到钩子的函数指针地址，直接将自己的捕获回调注册进去，全程不需要做GOT表替换，也没有额外的性能开销
• 特殊退出分支的兼容覆盖
  • 针对目标JVM可能直接通过syscall触发exit_group的场景，同样可以通过拦截syscall包装函数的入口，获取对应的退出码参数，避免漏捕获

实现时的硬约束规避要点 #

• 绝对不要选用fork、ptrace类的捕获方案：这类方案会触发进程上下文的独立复制，会直接破坏OpenGL ES上下文的线程绑定关系，导致渲染功能失效
• 做调用来源区分：替换GOT表条目时，要区分不同SO的符号表归属，避免把当前应用自身触发的exit调用和目标JVM的退出调用混淆，误触发捕获逻辑
• 拦截逻辑保持轻量：不要在exit的入口拦截点做大量耗时、耗内存的操作，只要完成退出码存储和通知触发即可，后续退出流程完全交回给原始libc逻辑处理，避免干扰正常退出流程

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