Android 14→15内置可执行程序：从“野路子”到“正规军”的进化

 

 

一、先看两组代码的直观区别

 

Android 14 方案（PRODUCT_COPY_FILES）：

 

核心逻辑：直接把文件从源码目录拷贝到系统分区（如/system/bin），像“复制粘贴” 一样简单。

 

 

Android 15 方案（PRODUCT_PACKAGES）：

 

核心逻辑：先通过Android.bp 定义“模块”（如 canconfig 是一个预构建可执行程序模块），再把模块名加入打包清单，由构建系统统一管理。

终端路径：

二、为什么 Android 15 要 “淘汰” 直接拷贝？

 

这不是“功能删减”，而是 Android 系统安全、构建效率、硬件适配三重进化 的必然结果：

 

 

1. 安全升级：从“放养” 到 “强监管”

 

•Android 14 时代：直接拷贝文件，系统不会校验“这个程序能不能在设备上运行”（比如 x86 程序拷贝到 ARM 设备），也不管 “程序有没有危险权限”（比如偷偷读写系统文件）。

 

 

•Android 15 时代：强制要求模块化声明，构建系统会自动检查：

 

 

◦ 架构兼容性：程序必须是设备支持的架构（如 RK3576 的 arm64）；

 

 

◦ 权限合法性：通过 SELinux 上下文配置，限制程序能做什么（比如只允许访问串口）；

 

 

◦ 依赖完整性：如果程序依赖其他库（如libcan.so），必须明确声明，否则编译报错。

 

 

2. 构建系统进化：Soong 取代传统 Make

 

Android 15 全面拥抱 Soong 构建系统（用Android.bp 替代Android.mk），它像“智能管家”：

 

 

•传统方式（PRODUCT_COPY_FILES）：只管拷贝，不管“程序是否能运行”“依赖是否完整”，出问题全靠开发者人肉排查；

 

 

•模块方式（PRODUCT_PACKAGES）：通过cc_prebuilt_binary 等规则，自动处理权限、依赖、架构 问题，甚至能帮你发现“程序是 x86 格式，设备是 arm64” 这种低级错误。

 

 

3. 硬件适配：瑞芯微等芯片厂商的倒逼

 

以瑞芯微 RK3576 为例：

 

 

•芯片的ISP、串口、摄像头 等硬件，对驱动和工具的依赖管理要求更严格；

 

 

•直接拷贝的程序，可能因“没加载依赖库”“权限不够” 导致硬件功能失效；

 

 

•模块化声明能强制关联驱动、库、权限，确保硬件功能正常工作。

 

 

三、开发者必须注意的 3 个核心点

 

1. 必须学会写Android.bp（模块声明）

 

以cansend 为例，需在同级目录创建Android.bp：

 

 

cc_prebuilt_binary {           name: "cansend",          // 模块名，必须和 PRODUCT_PACKAGES 里的名字一致           srcs: ["cansend"],       // 可执行程序的路径           installable: true,       // 允许安装到系统分区           file_contexts: "cansend_contexts", // SELinux 上下文配置           target: {               android_arm64: { enabled: true }, // 只编译到 arm64 架构           },       }

•关键作用：告诉构建系统“这个程序是谁、能装在哪、该有什么权限”。

 

 

 

2. SELinux 配置是 “必答题”

 

Android 15 的 SELinux 会 严格拦截未授权操作，必须为程序配置上下文：

 

 

# cansend_contexts 文件内容       /system/bin/cansend usystem_file:s0

•若程序要访问串口（如/dev/ttyS8），还需额外添加 SELinux 策略（如 allow cansend serial_device:chr_file write;），否则会报avc: denied 错误。

 

 

3. 动态库依赖要“明明白白”

 

如果cansend 依赖libcan.so，不能只拷贝cansend，还需：

 

 

1.用cc_prebuilt_library_shared 声明libcan.so 模块；

 

 

2.在cansend 的Android.bp 中通过shared_libs 关联：

 

 

shared_libs: ["libcan"],

•否则设备运行时会报错cannot load library: libcan.so。

 

 

四、实战建议：从 Android 14 迁移到 15 的步骤

 

1.整理可执行程序：把canconfig、candump 等程序放到统一目录（如device/rockchip/cantools）。

 

 

2.为每个程序写Android.bp：按模块规则声明，配置架构、权限、SELinux。

 

 

3.修改PRODUCT_PACKAGES：替换原来的文件路径，改为模块名。

 

 

4.编译验证：

 

 

系统配置: export LC_ALL=C source javaenv.sh source build/envsetup.sh       export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export PATH=$JAVA_HOME/bin:$PATH export PATH=$ANDROID_BUILD_TOP/prebuilts/clang/host/linux-x86/clang-r487747c/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/lib/tools.jar lunch rk3576_u-ap4a-userdebug   一键编译:   ./build.sh -AUCKu -d rk3576-evb1-v10 -J 16

若报错，优先检查架构是否匹配、SELinux 策略是否缺失、依赖是否声明。

 

 

结语：系统越严，开发越规范

 

Android 15 对可执行程序的 “模块化” 要求，本质是 系统安全和开发效率的双向奔赴：

 

 

•对用户：避免非法程序破坏系统；

 

 

•对开发者：减少“运行时崩溃” 的 Debug 成本。

 

 

跟上这个变化，你会发现：曾经的“野路子” 虽然快，但 “正规军” 的方式更稳、更可持续。

 

 

（觉得有用？欢迎转发给需要适配 Android 15 的同行～）

---