关于IOS设置了privacyRegisterMode: "manual" 和 pushRegisterMode: "manual"，个推 SDK 在用户同意隐私政策前仍然采集了 IDFV 和设备名称

欢迎到专业群（ uni-app 官方技术交流群 1 ） 咨询，群中有相关专业的管理员和群友。

根据你提供的堆栈信息和配置，你遇到的问题核心在于：privacyRegisterMode: "manual" 和 pushRegisterMode: "manual" 这两个配置主要控制的是 dcloud 自身框架层 的采集行为（如 idfa 获取），但 个推 sdk（unipush）在底层原生代码中的初始化，是由其自身控制的，并且可能在应用启动的早期阶段就触发了设备信息的采集。

从知识库和官方文档来看，可以确认以下几点：

1. privacyRegisterMode 的作用范围

根据官方文档 如何配置在用户同意隐私政策后使用IDFA 和 manifest配置，privacyRegisterMode: "manual" 的作用是：

• 阻止应用在启动时自动获取 idfa/idfv，以避免提前触发 跟踪app活动 授权提示框。
• 需要在用户同意隐私政策后，主动调用 plus.runtime.agreePrivacy() 来触发后续的 idfa 获取流程。

它主要解决的是 dcloud 框架自动采集 idfa 的问题，但 并不能完全阻止所有第三方原生 sdk（如个推）在底层自行读取 idfv 或设备名称。

2. 个推 sdk（unipush）的提前采集问题

这是已知的常见问题。从知识库的多个案例和社区反馈来看：

• 在 android 平台，官方明确要求使用 template 模式的隐私弹窗 才能有效阻止 unipush 等 sdk 在同意前的初始化，并且 custom 模式“并不能完全避免在弹出隐私提示框之前，读取设备信息” 参考文档。
• 在 ios 平台，pushRegisterMode: "manual" 的作用是延迟推送的注册，但个推 sdk 内部获取 idfv、设备名称、ip 地址、运营商等信息的逻辑，可能在 sdk 自身的初始化流程中就已执行，这个初始化时机可能早于你调用 plus.runtime.agreePrivacy() 的时机。
• 有用户反馈，即使配置了 privacyRegisterMode: "manual" 和 template 模式，个推 sdk 仍可能在同意前采集 idfv 参考 ask 社区。

3. 你抓到的堆栈分析

你抓到的堆栈中，gtsdeviceutils 获取 idfv 和设备名称，gtasynsocket 获取 ip，gtgbdutil 获取运营商，这些都是个推 sdk 内部的原生类。这说明个推 sdk 在应用进程启动后、你调用 plus.runtime.agreePrivacy() 之前，就已经执行了这些采集操作。仅通过 manifest.json 中的 manual 配置无法完全阻止这个层面的行为。

4. 可行的解决方案

要达到完全阻止的目的，需要从根源上延迟个推 sdk 的初始化，而不是仅仅延迟其注册或使用。根据现有信息和通用实践，你可以尝试以下方案：

• 方案一：使用 template 模式并严格控制初始化时机（推荐）

  1. 确保 manifest.json 中已配置 privacyRegisterMode: "manual" 和 pushRegisterMode: "manual"。
  2. 在 manifest.json 的 app 启动界面配置中，勾选 使用原生隐私政策提示框，这会使用 template 模式。template 模式会在用户点击同意前，阻塞应用界面的显示和部分初始化逻辑，这是目前官方认为最有效的阻断方式。
  3. 不要 在 app.vue 的 onlaunch 或任何应用启动早期阶段调用任何与 unipush、uni-ad、统计等相关的 api。
  4. 在用户点击同意隐私政策的回调中，首先 调用 plus.runtime.agreePrivacy()，然后 再执行 unipush 的初始化（如 uni.getpushclientid()）或其他涉及隐私的 sdk 调用。

• 方案二：自定义隐私弹窗 + 延迟初始化（需谨慎）
  如果你必须使用自定义隐私弹窗（custom 模式），那么你需要：

  1. 在应用启动后，立即显示你的自定义隐私弹窗，此时应用应处于一个极简的等待状态。
  2. 在用户点击“同意”按钮后，调用 plus.runtime.agreePrivacy()。
  3. 在此之后，再通过动态导入或条件判断的方式，去加载和执行所有会初始化第三方 sdk 的代码。但这对于像 unipush 这类在原生层就自动初始化的 sdk 来说，可能无法完全控制其初始化时机。

• 方案三：联系个推或使用插件关闭采集
  如堆栈所示，采集行为是个推 sdk 自身发起的。如果上述方案仍无法通过审核，你可能需要：

  • 查阅个推官方文档，看其 ios sdk 是否提供了在初始化前禁止采集某些信息的 api 或配置项。
  • 在 dcloud 插件市场搜索是否有针对个推隐私合规的插件，或者自行开发原生插件，在原生层延迟个推 sdk 的初始化，直到收到来自 js 层的“已同意”信号。

总结
你目前的配置是正确的，但 privacyRegisterMode: "manual" 和 pushRegisterMode: "manual" 无法完全阻止个推 sdk 在同意隐私政策前采集 idfv、设备名称等信息。要解决此问题，最直接的方案是 采用 template 模式的隐私弹窗，并严格确保所有第三方 sdk 的调用和初始化都在 plus.runtime.agreePrivacy() 之后进行。如果 template 模式仍不能解决问题，则问题出在个推 sdk 自身过早的初始化，可能需要从其 sdk 层面或通过原生插件来干预。

建议你优先尝试 方案一，并使用最新版本的 hbuilderx 进行云端打包后，重新提交检测。