当前位置：首页 > news >正文

System 应用访问 Vendor 库的详细方案

news 来源：原创 2025/5/25 13:12:10

文章目录

- - 系统签名 (System Signature)
  - 自定义 SELinux 策略 (Custom SELinux Policy)
  - 使用 VNDK (Vendor Native Development Kit)

本文首发地址：https://h89.cn/archives/367.html

system 应用访问 vendor 库的方案有以下几种：系统签名、自定义 SELinux 策略和使用 VNDK。

好的，我们来详细介绍一下前面提到的三种主要的 system 应用访问 vendor 库的方案：系统签名、自定义 SELinux 策略和使用 VNDK。

系统签名 (System Signature)

原理：

在 Android 系统中，应用程序可以使用不同的证书进行签名。系统签名是指使用与构建 Android 操作系统时相同的密钥对应用程序进行签名。拥有系统签名的应用程序被视为受信任的系统组件，因此通常会被授予比普通第三方应用更高的权限。这些权限可以包括访问受保护的系统资源、调用特权 API，以及在某些情况下，绕过一些针对普通应用的隔离限制，例如访问 vendor 分区的库。

详细配置方法：

要在编译 system 应用时使用系统签名，您需要在 Android 源码环境下进行操作，并修改应用的构建配置文件。

Android.mk (旧的构建系统):

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional  # 或 user/release 等
LOCAL_SRC_FILES := $(call all-subdir-java-files) # 应用的 Java 源代码
LOCAL_PACKAGE_NAME := YourSystemApp # 你的应用包名
LOCAL_CERTIFICATE := platform       # 指定使用平台签名
LOCAL_PRIVILEGED_MODULE := true    # 将应用标记为特权应用 (通常与系统签名一起使用，授予更多权限)
# 可选的其他配置，如依赖的库等
include $(BUILD_PACKAGE)

LOCAL_CERTIFICATE := platform 是关键指令，它指示构建系统使用平台签名密钥对该应用进行签名。
LOCAL_PRIVILEGED_MODULE := true 通常与系统签名一起使用，将应用安装到 /system/priv-app 目录下，使其能够访问特权权限。

Android.bp (Soong 构建系统 - 较新的 Android 版本):

android_app {
    name: "YourSystemApp",             # 应用模块名
    srcs: ["src/**/*.java"],           # 应用的 Java 源代码
    platform_apis: true,             # 允许访问平台私有 API (如果需要)
    certificate: "platform",          # 指定使用平台签名
    privileged: true,                # 标记为特权应用
    system_ext_specific: true,       # 如果应用属于 system_ext 分区
    product_specific: true,          # 如果应用属于 product 分区
    // vendor_specific: true,         # 注意：system 应用通常不应直接属于 vendor 分区
    // ... 其他依赖和配置
}

certificate: "platform" 指示使用平台签名。
privileged: true 同样用于标记为特权应用。
system_ext_specific: true 和 product_specific: true 用于指定应用构建到哪个分区，system 应用通常会位于 system 或 system_ext 分区。

优点：

符合 Android 安全模型： 系统签名是 Android 区分受信任系统组件和普通应用的主要机制。
权限授予： 拥有系统签名的应用通常会被自动授予许多系统级权限，这可能包括访问某些 vendor 库所需的权限。
相对简单： 相较于自定义 SELinux 策略，配置系统签名通常更直接。

缺点：

需要源码环境： 必须在 Android 源码环境下编译应用才能使用平台签名。
密钥管理： 系统签名密钥是高度敏感的，必须妥善保管。泄露会导致严重的安全风险。
过度授权风险： 拥有系统签名的应用权限较高，如果应用存在安全漏洞，可能会对系统造成更大的影响。
不适用于第三方应用： 这种方法仅适用于作为系统镜像一部分构建的应用，不适用于普通的第三方开发者。

自定义 SELinux 策略 (Custom SELinux Policy)

原理：

SELinux 是 Android 的强制访问控制 (MAC) 系统，它通过安全策略规则来限制进程对系统资源的访问。每个进程和文件都有一个安全上下文（Security Context），SELinux 策略定义了不同安全上下文之间的交互规则。默认情况下，system 应用的上下文和 vendor 库的上下文可能不允许直接访问。通过自定义 SELinux 策略，可以显式地允许特定的 system 应用访问特定的 vendor 库。

详细配置方法：

确定安全上下文 (Security Contexts):
- 使用 adb shell ps -Z | grep <your_system_app_process_name> 查找你的 system 应用进程的 SELinux 上下文。输出类似于 u:r:system_app:s0:cxxx,cxxx <PID> <UID> ... <your_system_app_process_name>，你需要记录 u:r:system_app:s0 部分（实际名称可能不同）。
- 使用 adb shell ls -Z <path_to_vendor_library> 查找 vendor 库文件的 SELinux 上下文。输出类似于 -rwxr-xr-x u:object_r:vendor_lib_file:s0 <user> <group> ... <path_to_vendor_library>，你需要记录 u:object_r:vendor_lib_file:s0 部分（实际名称和类型可能不同）。
编写 SELinux 策略规则 (.te 文件):
- 在 Android 源码的设备特定 SELinux 策略目录中 (device/[manufacturer]/[device]/sepolicy 或其子目录，例如 system 或创建一个新的 vendor_access 目录），创建一个或修改 .te 文件。例如，创建一个名为 system_app.te 的文件（如果你的策略是针对特定的 system 应用）。
- 添加 allow 规则，允许 system 应用域 (system_app 在这里是示例，替换为你的实际域) 访问 vendor 库文件类型 (vendor_lib_file 在这里是示例，替换为你的实际类型) 的特定操作：
```
typeattribute system_app appdomain; # 如果你的应用域还没有类型属性，可以添加

# 允许 system_app 域读取 vendor_lib_file 类型的文件
allow system_app vendor_lib_file:file { read open getattr map };

# 如果 vendor 库需要执行（例如，是可执行文件），可能需要 execute 权限
allow system_app vendor_lib_file:file execute;

# 如果 vendor 库是 vendor 服务，可能需要允许 Binder 通信
# 假设 vendor 服务的类型是 vendor_service
allow system_app vendor_service:binder { call transfer };
```
- 你可能还需要添加 type 定义（如果 vendor_lib_file 不是已知的类型）或 typeattribute 关联。
配置 Android.bp 或 Android.mk 以包含你的策略文件:
- 在设备特定的 sepolicy 目录下的 Android.bp 或 Android.mk 文件中，确保你的 .te 文件被包含在编译过程中。
- Android.bp 示例 (通常在 device/[manufacturer]/[device]/sepolicy/Android.bp):
```
sepolicy_compile_dirs = [
    "system",
    "vendor",
    "private",
    // ... 其他目录
]

sepolicy_rules = [
    "system_app.te",
    // ... 其他 .te 文件
]
```
编译和部署 SELinux 策略:
- 在 Android 源码根目录下编译 SELinux 策略：
```
make sepolicy -j$(nproc)
```
- 编译成功的 sepolicy 文件通常位于 out/target/product/[device]/root/sepolicy 或 out/target/product/[device]/system/etc/selinux/plat_sepolicy.cil。
- 将新的 sepolicy 文件刷入设备。这通常需要重新刷写系统镜像。

优点：

细粒度控制： 可以精确控制哪些 system 应用可以访问哪些 vendor 资源以及如何访问。
安全性： 如果配置正确，SELinux 可以增强系统的安全性。

缺点：

复杂性： SELinux 策略的编写和调试非常复杂，需要深入理解 SELinux 的概念和语法。
维护困难： 随着系统和应用的变化，SELinux 策略可能需要更新和维护。
潜在风险： 配置错误的 SELinux 策略可能导致系统崩溃、功能异常或安全漏洞。
设备依赖： SELinux 策略通常是设备特定的。

使用 VNDK (Vendor Native Development Kit)

原理：

Project Treble 架构引入了 VNDK，旨在为 system 和 vendor 分区之间的原生库提供稳定的接口。VNDK 包含了一组可以在这两个分区之间安全共享的库。system 应用应该尽可能地链接到 VNDK 提供的库，而不是直接依赖 vendor 分区的私有库。

详细配置方法：

vendor 模块构建为 VNDK 库:
- 在 vendor 模块的 Android.bp 文件中，需要将其标记为 VNDK 库。这通常通过设置 vendor: true 和指定 vndk: { ... } 属性来实现。例如：
```
cc_library_shared {
    name: "vendor.example.mylib",
    srcs: ["src/mylib.c"],
    vendor: true,
    vndk: {
        enabled: true,
        support_system_process: true, # 如果需要 system 进程访问
    },
    // ... 其他配置
}
```
- enabled: true 表明这是一个 VNDK 库。
- support_system_process: true 表明 system 进程可以链接到这个 VNDK 库。

system 应用链接到 VNDK 库:

在 system 应用的 Android.bp 文件中，需要链接到相应的 VNDK 库。这通常通过在 shared_libs 属性中指定 VNDK 库的名称（通常带有 vndk- 前缀或特定的命名约定）。

android_app {
    name: "YourSystemApp",
    srcs: ["src/**/*.java"],
    // ... 其他配置
    native_libs: [
        "libexample.so", // 如果你的应用直接使用了 .so 文件
    ],
    shared_libs: [
        "vndk-vendor.example.mylib", // 链接到 VNDK 版本的库
        // ... 其他共享库
    ],
    // ...
}

cc_binary { // 如果你的 system 应用包含原生代码
    name: "your_system_native_binary",
    srcs: ["src/main.c"],
    shared_libs: [
        "vndk-vendor.example.mylib",
        // ... 其他共享库
    ],
    // ...
}

构建系统会自动处理 VNDK 库的链接和依赖关系。

优点：

架构规范： 符合 Android 的模块化和分区架构设计。
接口稳定： VNDK 旨在提供 system 和 vendor 之间更稳定的接口，减少因 vendor 分区更新导致 system 应用不兼容的风险。
安全性： VNDK 库经过精心设计，可以在不同安全域之间安全地共享。

缺点：

VNDK 覆盖有限： 并非所有的 vendor 库都有对应的 VNDK 版本。设备制造商需要投入精力将 vendor 库适配为 VNDK 库。
适配工作： 如果 system 应用需要的功能在 VNDK 中没有直接对应的库，可能需要设备制造商进行额外的适配和开发工作。
版本兼容性： 需要注意 VNDK 的版本兼容性，system 和 vendor 分区需要使用兼容的 VNDK 版本。

总结：

这三种方案各有优缺点，选择哪种取决于具体的场景、需求和 Android 系统的版本。在现代 Android 系统中，系统签名 是 system 应用获取必要权限的常用方法，而 VNDK 是推荐的跨分区库依赖的架构方案。自定义 SELinux 策略 作为一种更细粒度的权限控制手段，通常在需要更精确的安全管理时使用，但其复杂性也更高。

以上内容来自豆包方案 + Gemini 总结，仅供参考。