端侧 AI 推理的数据本地闭环：Android Scoped Storage 与 Linux 权限隔离

随着端侧大模型（如 Gemma-2B、Phi-3、MiniCPM）与轻量化向量引擎的发展，越来越多的 AI 功能开始在手机与嵌入式设备上本地运行。端侧 AI 最大的卖点在于“隐私安全与数据零上云”——用户的私人相册、聊天记录、健康数据与本地知识库完全留在设备内。

然而，在操作系统底层，将数据真正“锁”在本地并高效供给推理引擎，面临着严峻的系统级挑战：Android 严格的分区存储（Scoped Storage）、Linux 内核的 UID/GID 沙箱、SELinux 强制访问控制，以及底层 C++ 推理引擎对文件句柄的直接访问需求，彼此之间存在复杂的机制冲突。

一、Android 存储沙箱与底层推理引擎的矛盾

在传统 Linux 或早期的 Android 系统中，C/C++ 编写的推理引擎（如 llama.cpp、ONNX Runtime、NCNN）通常直接调用标准 POSIX API 访问文件：

// 传统 POSIX 文件打开方式（在现代 Android 上受阻）
FILE* fp = fopen("/sdcard/Documents/my_private_notes.pdf", "rb");
int fd = open("/sdcard/Models/gemma-2b-q4.gguf", O_RDONLY);

但在 Android 10+（API 29+）引入 Scoped Storage（分区存储）后，应用对外部共享存储的绝对文件路径访问权限被彻底剥离：

[用户私人文件 (外部存储 MediaStore / SAF 授权)]
                       │
                       ▼ (ContentProvider / DocumentFile)
            [Java / Kotlin 应用层]
                       │
                 (获取 FileDescriptor)
                       │
                       ▼ JNI 传递 int fd
            [C++ 原生推理引擎 (llama.cpp / ONNX)]
                       │
                       ▼ (fdopen / mmap)
          [Linux 内核 VFS 虚拟文件系统]

1.1 为什么不能把用户数据先拷贝到私有目录？

很多开发者为了图省事，先在 Java 层把外部文件读取并拷贝到 /data/user/0/com.app.ai/cache/，再让 C++ 引擎读取。

对于几百 KB 的纯文本这尚可接受，但对于端侧 AI 场景（如对几 GB 的离线视频做多模态特征提取，或加载 2GB 的量化模型）：

• 频繁的文件复制会导致 I/O 吞吐减半、设备发热严重；
• 手机物理 Flash 寿命（P/E Cycle）被剧烈消耗；
• 内存与存储瞬时翻倍，极易触发系统的 LowMemoryKiller（LMK）。

二、基于文件描述符（FD）的零拷贝跨层传递实战

要实现既合规又高性能的数据闭环，必须打通 “Java 层获取 SAF 授权 FileDescriptor ──► JNI 透传 ──► 底层 C++ 执行 mmap 零拷贝映射” 的管道。

2.1 Java/Kotlin 层获取安全句柄

// Android 端：通过 SAF (Storage Access Framework) 打开用户授权的文件
val contentResolver = context.contentResolver
val uri = userSelectedDocumentUri // content://com.android.providers.media.documents/...

contentResolver.openFileDescriptor(uri, "r")?.use { pfd ->
    val rawFd = pfd.detachFd() // 脱离管理，将原始 Linux 文件描述符交给底层
    NativeAIInference.loadUserDataByFd(rawFd)
}

2.2 底层 C++ 基于 FD 的 mmap 内存映射

底层推理引擎接收到 fd 后，无需知道物理文件路径，直接通过 mmap 将文件映射到虚拟内存空间：

#include <jni.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <android/log.h>

extern "C" JNIEXPORT jboolean JNICALL
Java_com_app_ai_NativeAIInference_loadUserDataByFd(JNIEnv* env, jobject thiz, jint fd) {
    if (fd < 0) {
        return JNI_FALSE;
    }

    struct stat sb;
    if (fstat(fd, &sb) == -1) {
        close(fd);
        return JNI_FALSE;
    }

    size_t file_size = sb.st_size;

    // 零拷贝虚拟内存映射（PROT_READ 确保只读安全）
    void* mapped_data = mmap(nullptr, file_size, PROT_READ, MAP_SHARED, fd, 0);
    if (mapped_data == MAP_FAILED) {
        close(fd);
        return JNI_FALSE;
    }

    // 告知内核预读模式，提升推理批处理顺序读取性能
    madvise(mapped_data, file_size, MADV_SEQUENTIAL);

    // 将 mapped_data 指针与 file_size 传递给本地 Tokenizer 或推理管道
    // 执行完推理后记得 munmap 与 close(fd)
    
    // ... 执行本地特征提取与推理 ...

    munmap(mapped_data, file_size);
    close(fd);
    return JNI_TRUE;
}

三、Linux 沙箱与本地数据安全闭环保障

除了文件访问接口的适配，端侧本地数据的静态落盘安全依赖操作系统的多重隔离机制：

+-------------------------------------------------------------+
| Android App 沙箱 (Linux UID: u0_a185)                        |
|                                                             |
|   /data/data/com.app.ai/databases/                          |
|   ├── user_vectors.db (SQLite-vec + SQLCipher 加密)         |
|   └── chat_history.db (由 Android KeyStore 派生 AES 密钥)    |
|                                                             |
|   DAC (自主访问控制): 仅属主 UID 可读写 (权限 0700)          |
|   MAC (SELinux): u:r:untrusted_app:s0:c185,c256 进程域隔离  |
+-------------------------------------------------------------+

1. Linux UID/GID 进程级 DAC 隔离：Android 为每个安装的应用分配唯一的 Linux UID。即使设备上存在恶意第三方 App，也无法读取当前 App 私有目录下的任何 SQLite 数据库或缓存文件。
2. SELinux 强制访问控制（MAC）：即便应用内部出现 Native 代码注入漏洞，SELinux 的 untrusted_app 策略也能严格限制该进程无法执行未经允许的系统调用或访问未经授权的设备驱动节点。
3. 硬件级密钥派生（Hardware-backed Keystore）：本地向量库（如 SQLite-vec）的敏感文本内容采用 AES-256-GCM 加密，加密密钥由 Android Keystore 依托 TEE（可信执行环境）或 StrongBox 硬件生成并保护，杜绝内存 Dump 攻击。

实现真正的端侧 AI 本地闭环，不能仅停留在“把模型打包进 App”的表面，必须深刻理解移动操作系统的存储框架与内核安全边界，在零拷贝极致性能与严苛隐私防御之间建立稳固的系统工程基石。