3.1 发现机制#

系统怎么知道这个 APK 是驱动？不是随便装个 APK 就能冒充的

1. 元数据声明 三星发布的 Samsung Game Driver.apk，在其 AndroidManifest.xml 里必须包含特定的 <meta-data> 标签：

// 示例
    <meta-data android:name="android.graphics.driver.build_time" value="Chongxi & CEPATO" />
    <meta-data android:name="com.android.graphics.driver.library" value="libGLESv2_adreno.so" />

这个 com.android.graphics.driver.library 是关键，它让系统知道他是货真价实的库

2. Game Driver Service：
   Android 系统启动时，GraphicsEnvironment会扫描所有已安装的应用。它会寻找包名符合规则（如 com.samsung.gamedriver.sm8250）且带有上述元数据的 App

一旦找到，它会把这个 APK 的路径（/data/app/~~.../base.apk!/lib/arm64-v8a/）缓存到系统服务里，标记为 Available Driver Provider

3.2 注入#

当你在启动 codm 时，进程刚 Zygote Fork，加载图形库的流程如下：

游戏进程首先加载的是系统的 /system/lib64/libEGL.so 和 /system/lib64/libvulkan.so

这只是个 Wrapper/Stub，里面全是空函数或者转发逻辑，真正的驱动还没加载

在 AOSP 源码的 Loader.cpp 中，有一个关键函数 Loader::openDriver。它会向 GraphicsEnvironment 发起查询：

这个叫血战孤儿院的，有没有被指定使用‘Game Driver’？

如果确实启用了，Linker 会创建一个独立的 Native Namespace

• 一般情况下 Linker 去 /vendor/lib64/egl 找 libGLESv2_adreno.so
• 现在系统会调用 android_create_namespace，并把 LD_LIBRARY_PATH 强行指向 解压目录/data/app/...

这意味着，游戏进程在这个独立的命名空间里，它以为它加载的是系统库，实际上 Linker 给它塞的是 APK 里的 .so

3.3 握握手#

APK 只能更新用户层面 (UMD)，也就是运行在 User Space 的 OpenGL/Vulkan 实现库。但硬件是运行在 Kernel Space 的，也就是内核 KMD

在这台手机上

• KMD: 是编译进 boot.img 里的 kgsl 模块。它暴露的设备节点通常是 /dev/kgsl-3d0
• UMD: 就是 APK 里那几个 .so

怎么通讯？IOCTL

当你用 APK 更新了驱动，新的 UMD 会打开 /dev/kgsl-3d0，通过 ioctl 系统调用发送命令流给内核

这里有个大问题就是 ABI 稳定性

APK 里的新驱动（UMD）必须得向下兼容老旧的内核驱动（KMD）
如果高通在新的 UMD 里用了一个新的 ioctl 命令，但你的内核是 3 年前的，根本不认识这个指令，驱动初始化就会失败

这就是为什么三星 / 高通不能无限制地给 S20 这个机子推送最新的驱动 APK。APK 里的 UMD 版本，必须跟你的内核 KMD 版本握手成功才能跑

3.4 SELinux#

Android 的 SELinux 极其严格。普通 app 是没有权限去加载另一个 App 私有目录下的 .so 文件的

为了让这个 APK 驱动能跑，Google 在 Android 10 的 SELinux 策略里开了一个白名单

• 定义了一个新的域 gamedriver_file
• 允许 appdomain（普通应用进程）对标记为 gamedriver_file 的文件执行 map 和 execute 操作

所以，那个驱动 APK 安装后，系统会自动给它的 .so 文件打上特殊的 SELinux 标签，否则 Linker 加载时会被直接 Permission Denied

这就是为什么说 S20 的模块化是教科书级别的

它在不刷机、不 Root、不修改系统分区的前提下，通过 Linker Namespace 和 SELinux 策略，实现了核心渲染逻辑的热替换。这在以前绝对做不到