[RK3568][Android12.0]--- 深入解析预置APK的三种模式与实现原理

张开发
2026/4/16 15:02:14 15 分钟阅读

分享文章

[RK3568][Android12.0]--- 深入解析预置APK的三种模式与实现原理
1. RK3568 Android12预置APK的核心机制在RK3568平台上开发Android12系统时预置第三方APK是个高频需求。Rockchip官方提供了三种预置模式每种模式对应不同的使用场景和系统行为。我第一次接触这个功能时发现官方文档只有简单说明实际开发中踩了不少坑。今天我就结合源码带大家彻底搞懂这三种模式的差异。预置APK的本质是将应用程序提前集成到系统镜像中使其在设备首次开机时就自动安装。与普通安装方式相比预置APK具有两个显著优势一是避免用户手动安装的繁琐操作二是可以控制应用的卸载权限。根据业务需求不同Rockchip设计了三种预置目录preinstall不可卸载的预置应用preinstall_del可卸载但恢复出厂能自动恢复的预置应用preinstall_del_forever可卸载且恢复出厂不会恢复的预置应用这三种模式在底层实现上有本质区别。preinstall目录下的APK会被打包到system分区而preinstall_del和preinstall_del_forever则会被打包到odm分区。这种分区设计直接决定了应用的恢复特性——system分区在恢复出厂时不会被清除而odm分区则可能被重置。2. 三种预置模式的配置方法2.1 基础目录结构要在RK3568上预置APK首先需要在设备目录下创建对应的预置文件夹。以rk3568设备为例目录结构通常如下device/rockchip/rk3568/ ├── preinstall/ # 不可卸载的预置APK ├── preinstall_del/ # 可卸载可恢复的预置APK └── preinstall_del_forever/ # 可卸载不恢复的预置APK实际操作中只需要将APK文件放入对应目录即可。例如要预置一个不可卸载的系统工具APKcp MySystemTool.apk device/rockchip/rk3568/preinstall/2.2 Makefile配置原理预置功能的实现核心在device/rockchip/common/modules/preinstall.mk文件中。这个makefile会调用auto_generator.py脚本为每个预置目录生成编译规则$(shell python device/rockchip/common/auto_generator.py \ $(TARGET_DEVICE_DIR) preinstall bundled_persist-app $(TARGET_ARCH)) $(shell python device/rockchip/common/auto_generator.py \ $(TARGET_DEVICE_DIR) preinstall_del bundled_uninstall_back-app $(TARGET_ARCH)) $(shell python device/rockchip/common/auto_generator.py \ $(TARGET_DEVICE_DIR) preinstall_del_forever bundled_uninstall_gone-app $(TARGET_ARCH))脚本会根据预置目录中的APK文件自动生成Android.mk和preinstall.mk。例如对于preinstall目录下的APK生成的Android.mk会包含如下关键配置LOCAL_MODULE_PATH : $(TARGET_OUT)/preinstall LOCAL_CERTIFICATE : PRESIGNED LOCAL_DEX_PREOPT : false这些配置决定了APK的安装路径、签名方式和优化策略。值得注意的是三种预置模式生成的模块路径不同预置类型安装路径恢复特性preinstall/system/preinstall不可卸载preinstall_del/odm/bundled_uninstall_back-app可卸载恢复出厂可恢复preinstall_del_forever/odm/bundled_uninstall_gone-app可卸载恢复出厂不恢复3. 预置APK的安装流程解析3.1 系统启动时的扫描安装当Android系统启动时PackageManagerService会扫描预置目录并安装APK。关键代码在frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java中private void preinstallThirdPartyAPK(PackageParser2 packageParser, ExecutorService executorService, int scanFlags) { preinstallPrebundledpersist(packageParser, executorService, scanFlags); preinstallPrebundledUninstallBack(packageParser, executorService, scanFlags); preinstallPrebundledUninstallGone(packageParser, executorService, scanFlags); }这三个方法分别处理三种预置模式。以preinstallPrebundledpersist为例它会扫描BUNDLED_PERSIST_DIR目录private void preinstallPrebundledpersist(PackageParser2 packageParser, ExecutorService executorService, int scanFlags) { scanDirTracedLI(new File(BUNDLED_PERSIST_DIR), mDefParseFlags | ParsingPackageUtils.PARSE_IS_SYSTEM_DIR, scanFlags | SCAN_AS_PREINSTALL | SCAN_AS_SYSTEM, 0, packageParser, executorService); }扫描过程中系统会为每个APK创建Package对象并将其添加到已安装包列表。关键区别在于scanFlags参数SCAN_AS_SYSTEM标记为系统应用SCAN_AS_PREINSTALL标记为预置应用SCAN_AS_PREBUNDLED_DIR标记为可卸载的预置应用3.2 可卸载APK的特殊处理对于preinstall_del和preinstall_del_forever目录下的APK系统会有额外的处理逻辑。在scanDirLI方法中可以看到如下关键代码if (scanDir.getAbsolutePath().contains(BUNDLED_UNINSTALL_GONE_DIR)) { if (!readDeleteFile(list)) { Log.e(TAG, read data failed); return; } }这段代码会检查是否有标记为已删除的预置应用。如果是preinstall_del_forever目录下的APK且已被用户卸载系统会跳过安装。而对于preinstall_del目录下的APK即使用户卸载恢复出厂设置后仍会重新安装。4. 实战经验与常见问题4.1 签名问题处理在实际项目中最常见的坑是签名问题。如果预置的APK没有正确签名会出现如下错误W PackageManager: Failed to scan /odm/bundled_persist-app/autotest: No APK Signature Scheme v2 signature in package解决方法是在Android.mk中添加PRESIGNED标记LOCAL_CERTIFICATE : PRESIGNED如果是系统特权应用则需要使用平台签名LOCAL_CERTIFICATE : platform4.2 桌面图标不显示问题有时预置的APK已经安装成功但在桌面看不到图标。这通常是因为APK没有默认的LAUNCHER Activity。解决方法有两种修改APK的AndroidManifest.xml添加LAUNCHER入口在预置时强制显示添加如下配置LOCAL_REPLACE_PREBUILT_APK_INSTALLED : $(LOCAL_PATH)/$(LOCAL_MODULE).apk4.3 预置APK的升级策略预置APK的升级需要特别注意版本兼容性。如果用户从应用商店升级了预置应用恢复出厂设置后会出现版本回退。建议在代码中做如下判断try { PackageInfo preinstallInfo getPackageManager() .getPackageInfo(com.example.app, PackageManager.GET_META_DATA); if (preinstallInfo ! null) { // 检查是否是预置版本 ApplicationInfo appInfo preinstallInfo.applicationInfo; if ((appInfo.flags ApplicationInfo.FLAG_SYSTEM) ! 0) { // 处理预置版本的特殊逻辑 } } } catch (PackageManager.NameNotFoundException e) { // 应用未安装 }5. 三种预置模式的深度对比5.1 技术实现差异通过分析源码我整理出三种预置模式的关键技术差异特性preinstallpreinstall_delpreinstall_del_forever存储分区systemodmodm卸载权限不可卸载可卸载可卸载恢复出厂行为保留恢复不恢复安装后是否删除源文件否是是适用场景系统核心功能厂商定制应用临时推广应用5.2 性能影响评估不同预置方式对系统性能也有影响。经过实测发现preinstall模式的APK会参与系统dex优化首次开机时间较长但运行效率高preinstall_del模式的APK在恢复出厂时需要重新安装会增加恢复时间preinstall_del_forever模式的APK如果被卸载会永久释放存储空间在资源紧张的设备上建议将非核心应用放在preinstall_del目录以减小system分区占用。5.3 最佳实践建议根据项目经验我总结出以下预置原则系统必需组件如设置、相机使用preinstall模式厂商定制应用如音乐、视频使用preinstall_del模式临时预装或推广应用使用preinstall_del_forever模式单个APK体积建议控制在20MB以内过大会影响系统镜像生成速度预置前务必测试APK在低内存设备上的运行表现在RK3568平台上还需要特别注意存储分区的大小配置。如果预置应用过多可能导致system或odm分区溢出。可以通过调整BoardConfig.mk中的分区大小参数来解决BOARD_SYSTEMIMAGE_PARTITION_SIZE : 2147483648 # system分区2GB BOARD_ODMIMAGE_PARTITION_SIZE : 536870912 # odm分区512MB

更多文章