a***@tmp.dcloud.io

发布：2026-10-31 19:47
更新：2026-10-31 19:47
阅读：58

【报Bug】HBuilderX 5.05 传统云打包重复注册 DCloud_FileProvider / DCloudAdFileProvider，取消广告后仍存在

分类：uni-app

bug反馈

产品分类： uniapp/App

PC开发环境操作系统： Windows

PC开发环境操作系统版本号： Windows 11，版本 10.0.26200

HBuilderX类型：正式

HBuilderX版本号： 5.05

手机系统： Android

手机系统版本号： Android 15

手机厂商：小米

手机机型： Xiaomi 12S Ultra

页面类型： vue

vue版本： vue3

打包方式：云端

项目创建方式： HBuilderX

示例代码：

以下为最终 APK AndroidManifest.xml 中识别到的两个 Provider 的关键属性示意，其他属性已省略：

<provider  
    android:name="io.dcloud.common.util.DCloud_FileProvider"  
    android:authorities="io.dcloud.LedgerWindowTest.dc.fileprovider" />  

<provider  
    android:name="io.dcloud.sdk.base.service.provider.DCloudAdFileProvider"  
    android:authorities="io.dcloud.LedgerWindowTest.dc.fileprovider" />

两个不同 Provider 使用相同的 authority。以上为简化后的关键字段，并非完整原始 Manifest。

操作步骤：

使用 HBuilderX 创建传统 uni-app Vue3 Android 工程。

配置独立 AppID `UNI6AA0D50`，Android 包名为 `io.dcloud.LedgerWindowTest`。

使用 Android 云证书进行传统云打包。

下载生成的 APK。

使用 Android SDK 工具和 AndroidManifest 二进制解析工具读取最终 Provider 声明。

观察到 DCloud_FileProvider 与 DCloudAdFileProvider 使用相同 authority。

取消广告相关打包选项、配置无关权限移除后再次云打包，重复第4—6步。

第二版 APK 中仍然存在相同的 Provider authority 重复声明。

预期结果：

希望最终 APK 中的 ContentProvider authority 配置符合 Android 组件唯一标识要求，不存在未解释的重复声明。

如果 DCloud SDK 有意让两个 Provider 使用相同 authority，希望官方提供明确的兼容性说明，或给出安全且受支持的配置方式。

实际结果：

两次传统云打包生成的 APK 中，DCloud_FileProvider 与 DCloudAdFileProvider 均使用：

`io.dcloud.LedgerWindowTest.dc.fileprovider`

第二次取消广告相关选项并成功移除24项无关权限后，重复声明仍然存在。

目前尚未执行设备安装及运行验证，实际运行时是否出现 Provider 路由错误仍未确认。

bug描述：

问题描述

使用 HBuilderX 5.05 编译链构建传统 uni-app Vue3 Android 应用，并通过 DCloud 传统云打包生成 APK 后，发现最终 AndroidManifest.xml 中存在两个不同的 ContentProvider，但它们使用完全相同的 authority。

两个 Provider 分别为：

io.dcloud.common.util.DCloud_FileProvider
io.dcloud.sdk.base.service.provider.DCloudAdFileProvider

共同使用的 authority 为：

io.dcloud.LedgerWindowTest.dc.fileprovider

通过 Android SDK 工具和独立 AndroidManifest 二进制解析，均确认这两个 Provider 声明真实存在，并非解析器误报。

该项目仅用于验证 UTS Android Application Hook、Activity 生命周期及 FLAG_SECURE 窗口保护，不需要广告功能。

已进行的排查

第一次传统云打包后，发现两个 Provider 的 authority 重复。

第二次云打包时，取消广告相关选项，并配置强制移除24项无关 Android 权限。

第二版 APK 静态检查结果：

24项无关权限已成功移除，最终仅保留4项权限。
两个 Provider 仍然存在，并继续使用相同 authority。
DEX、SO 和应用资源与第一版一致。
APK 包名、AppID及签名均正常。
原生 UTS Hook 注册及 FLAG_SECURE 代码完整保留。

DEX 中还发现多处与 .dc.fileprovider 后缀相关的引用，因此没有擅自删除 Provider 或直接修改 authority。

希望官方确认

这两个 Provider 在同一个 APK 中使用相同 authority，是否属于 DCloud Android SDK 的预期设计？
是否可能造成 ContentResolver 路由、文件共享或 FileProvider 路径配置异常？
未使用广告功能时，为什么仍包含 DCloudAdFileProvider？
是否有官方支持的方式移除不必要的广告 Provider，或避免 authority 重复？
是否已有相关修复版本，或者有推荐的兼容处理方式？

目前仅完成 APK 静态分析，尚未安装运行，因此没有观察到实际安装失败或运行崩溃。希望官方先确认这一重复配置是否安全，以及应采用哪种官方支持的处理方式。

2026-10-31 19:47 负责人:无分享

0 个回复

要回复问题请先登录或注册

【报Bug】HBuilderX 5.05 传统云打包重复注册 DCloud_FileProvider / DCloudAdFileProvider，取消广告后仍存在

bug描述：

问题描述

已进行的排查

希望官方确认

0 个回复

公告

相关问题

【报Bug】HBuilderX 5.05 传统云打包重复注册 DCloud_FileProvider / DCloudAdFileProvider，取消广告后仍存在

bug描述：

问题描述

已进行的排查

希望官方确认

与内容相关的链接

0 个回复

公告

相关问题