问题描述
uni-app Android App 在用户同意隐私协议后，友盟 SDK 初始化时，同一时间连续两次调用 Android ID 获取接口：
android.provider.Settings$Secure$getString
调用参数为：
android_id
两次调用堆栈完全一致，均来自友盟 SDK 内部：
com.umeng.umzid.ZIDManager
请协助确认 uni-app / DCloud 集成的友盟 SDK 是否存在重复初始化或 ZIDManager 重复采集 Android ID 的问题，以及是否有配置方式避免同一次初始化中重复读取 Android ID。
复现步骤
- 使用 HBuilderX 云打包 Android App。
- 卸载旧 App，重新安装新包。
- 首次启动 App。
- 用户点击同意隐私协议。
- 使用合规检测工具检测敏感 API 调用。
- 检测到同一时间连续两次读取 Android ID。
期望结果
用户同意隐私协议后，友盟 SDK 可以按需初始化，但同一次初始化流程中不应重复读取 Android ID。
如果该行为属于友盟 SDK 内部逻辑，请说明是否符合合规要求，以及 DCloud 当前集成版本是否可升级或规避。
实际结果
同一时间出现两条完全一致的 Android ID 读取记录：
敏感函数: android.provider.Settings$Secure$getString
函数参数: [ContentResolver, android_id]
堆栈信息:
com.umeng.commonsdk.statistics.common.DeviceConfig.getAndroidId(DeviceConfig.java:153)
java.lang.reflect.Method.invoke(Native Method)
com.umeng.umzid.d.a(Unknown Source:31)
com.umeng.umzid.ZIDManager.a(Unknown Source:14)
com.umeng.umzid.ZIDManager.b(:8)
com.umeng.umzid.ZIDManager$b.run(:1)
java.util.concurrent.Executors$RunnableAdapter.call
java.util.concurrent.FutureTask.run
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run
java.util.concurrent.ThreadPoolExecutor.runWorker
java.lang.Thread.run
1 个回复
Ask小助手 - Ask社区AI助手
根据你的描述和堆栈信息，这个重复调用 Android ID 的行为确实是由友盟 SDK 内部的
ZIDManager触发的。关于你的疑问和解决方案，我基于知识库和通用技术经验给你梳理一下：
1. 这是否属于友盟 SDK 的内部逻辑？是否符合合规要求？
是的，这属于友盟 SDK 的内部逻辑。 从堆栈
com.umeng.umzid.ZIDManager可以明确看出，这是友盟用于生成设备唯一标识（ZID）的模块在初始化时进行的操作。关于合规性，这需要分情况看：
UMConfigure.init）和隐私状态提交（UMConfigure.submitPolicyGrantResult）都严格放在了用户同意隐私协议之后执行。只要在同意后调用，行为本身是合规的。2. 是否有配置方式避免同一次初始化中重复读取 Android ID？
目前没有直接配置可以禁用
ZIDManager的第一次调用。这个重复调用是友盟 SDK 自身的一个已知行为。从 ask 社区的过往反馈来看（如 友盟组件 在 用户 同意隐私政策前 获取安卓ID），有开发者遇到过完全相同的堆栈和问题。友盟的 ZID 生成逻辑中，会通过反射的方式获取 Android ID，并且由于其内部缓存或异步检查机制，确实可能在同一时间点触发两次
Settings$Secure.getString调用。实际处理建议：
template模式的隐私弹窗，而不是自定义的。这是 DCloud 控制所有原生模块（包括友盟）初始化时机的关键。详细配置请参考 Android平台隐私与政策提示框。ZIDManager重复调用问题的官方说明或最新修复版本。总的来说，只要调用发生在用户同意之后，这个重复行为虽然不完美，但通常不会被判定为合规问题。如果你的 App 在同意前就出现了这个调用，那么一定是隐私弹窗配置或初始化时机出了问题，需要优先排查。
要回复问题请先登录或注册
公告
更多>相关问题