要求指南
正式版访问权限被拒的 7 个原因及应对方法
被拒通常是因为测试未达到要求，或者做了测试却没能说清楚。从人数不足、天数中断、问卷单薄、没有更新、违反政策、首次启动出错到回答与事实不符，本文按原因说明需要修正什么。
最后核对于 2026年10月7日。
被拒大多是两种情况之一
正式版访问权限申请被拒，大致有两种原因：测试没有达到要求，或者 测试做了却没能说明清楚。前者是 14 天和人数的问题，后者是调查问卷的问题。从上到下对照下面七项，大多能找到卡在哪里。
1. 参与人数不足 12 名
计算的不是列表中电子邮件地址的数量，而是真正选择加入并保持参与的账号数量。中途一旦低于 12 名，要求在那一刻就不再满足。
预防方法：预留备用人员再开始。人数刚好就开始的话，一个人退出就得从头再来。
2. 14 天没有连续进行
测几天、停几天、再接着测，这样的天数不会累加。新建或暂停测试轨道也会导致中断。
预防方法：14 天内不要改动测试轨道和测试人员列表。添加人员没问题，但要避免移除。
3. 调查问卷回答不充分
这是最常见的原因。审核由人工阅读判断，所以“测试已顺利完成”这样的回答会被视为没有依据。
预防方法：用数字写清楚确认了什么、修改了什么。各版本改了什么尤其重要。
4. 测试期间应用一次都没有更新
问卷会问您是否把测试中的收获反映到了应用中，如果只有一个版本，就没什么可写的。这不是硬性条件，但会对您不利。
预防方法：测试期间每隔 3~4 天发布一次更新，哪怕只是小改进，也能留下版本历史。
5. 应用本身违反政策
例如请求过多权限、缺少隐私权政策、内容分级不符等，因与测试无关的原因被卡住。
预防方法：在测试之外，先把应用内容 · 数据安全表单 · 隐私权政策整理好。
6. 首次启动时出现问题
虽然能安装，但在特定系统版本上立即退出，或卡在登录界面的应用，会被视为准备不足。
预防方法：在多个制造商 · 系统版本上确认首次启动是否正常，记录失败设备的日志并加以修复。
7. 调查问卷内容与事实不符
编造不存在的测试人员体验，审核人员可能会通过与其他回答的不一致发现问题。一旦出了问题，面临风险的不是应用，而是账号。
预防方法：只写实际发生的事情。没能确认的功能，如实写明没有确认更安全。
重新申请之前
- 再次确认参与人数和测试期是否确实满足要求。请参阅 14 天的计算规则。
- 重新填写调查问卷。各题回答示例请参阅 正式版访问权限调查问卷填写指南。
- 整理好测试期间发布的版本和修改内容。这是最有力的依据。
- 确认应用内容 · 数据安全表单 · 隐私权政策没有遗漏的项目。
如果正式版访问权限申请被拒，只要您在测试结束之日起 30 天内告诉我们，DUIRE 就会免费再进行一次 14 天封闭式测试。重新进行时，有时新建测试轨道会更好，我们会根据被拒原因与您一起决定。
常见问题
- 被拒后，封闭式测试要从头再来吗？
- 取决于原因。如果是调查问卷不充分而被拒，可以补充后重新申请。如果测试本身没有达到要求，就需要继续测试。
- Google 会告知被拒的原因吗？
- 审核结果会发送到账号所有者的电子邮件，应用信息中心也会显示相关说明。不过原因往往不够具体，逐项对照要求和调查问卷会更快找到问题。
- 什么时候可以重新申请？
- 重新满足要求后即可申请。与其被拒后立刻原样重新提交，不如先修正不足之处，隔几天再提交。
- 被拒后应用会被删除吗？
- 被拒的是正式版访问权限，应用不会被删除。封闭式测试轨道也会原样保留。