无需Google Play实现类Play Feature Delivery的模块化应用动态功能更新咨询

一、可行技术路线选型 #

你提到的几个调研方向可以优先聚焦以下两个成熟路径，避免不必要的踩坑：

1. 自研AAB分发+动态加载方案（最贴合你的需求） #

AAB格式本身开源，你已经能通过bundletool生成APK Set，这个方向可以直接复用AAB的模块化逻辑，不需要改动现有AAB打包流程：

• 服务端侧：
  • 把bundletool生成的所有设备适配维度的split APK、feature module APK按设备架构、屏幕密度、语言维度做索引存储
  • 客户端请求时，根据上报的设备信息返回对应需要的base APK补丁、新增feature模块的对应APK分片
• 客户端侧：
  • 下载完对应的APK分片集合后，用Android系统的PackageInstaller API做免用户手动确认的分片安装（Android 5.0以上原生支持split APK安装，注意要提前申请REQUEST_INSTALL_PACKAGES权限）
  • 功能模块安装完成后，用PackageManager查询组件信息，直接通过隐式Intent或者反射调用模块内的功能，不需要重启应用

2. 动态加载框架方案（轻量需求可选） #

如果不需要完全对齐AAB的模块化规范，可以用业内成熟的开源动态化框架，已经有大量落地案例：

• 若你需要的是功能模块的按需加载，优先用Tinker、AndFix这类热修复框架的插件化扩展能力，或者直接用RePlugin、VirtualAPK这类成熟插件化框架，不需要自己处理字节码反射的兼容性问题
• Evolve这类方案确实存在较大安全风险，且对新系统版本的适配性差，生产环境不建议直接使用

二、关于Play Core库的使用说明 #

Play Core库本身依赖Google Play服务运行，没有Google Play的环境下无法直接使用它的Feature Delivery相关接口，你可以基于bundletool的能力自己封装一套类似的客户端API，逻辑和Play Core对齐即可：

• 封装请求模块接口，传入模块名后向你的服务端拉取对应APK分片
• 封装下载进度回调、安装状态回调，和原有Play Core的调用逻辑保持一致，减少业务侧的改造量

三、落地注意事项 #

• 所有分发的APK分片必须和主包使用同一签名，否则系统会直接拒绝安装
• Android 8.0以上需要动态申请未知来源应用安装权限，Android 13以上对安装权限的管控更严格，需要做好权限引导和异常情况的降级处理
• 所有下载的模块都要做签名校验，避免被篡改引发安全问题

内容的提问来源于stack exchange，提问作者Jakkins