2021年，我国正式颁布并实施《个人信息保护法》，并与《数据安全法》、《网络安全法》和《刑法》中相关条款共同组成了个人信息保护法律体系。

为了推进个人信息保护工作，国家有关部委陆续出台《常见类型移动互联网应用程序必要个人信息范围规定》、《关于开展纵深推进APP侵害用户权益专项整治行动的通知》、《移动互联网应用程序个人信息保护管理规定（征求意见稿）》等监管要求，并持续开展各类个人信息权益保护专项治理行动，取得了显著的成效。

将至网络高度重视数据安全和个人信息保护工作，参照最新法律法规、政策及标准的规定，不断规范和提升我们的数据保护策略。

为了帮助使用将至SDK的开发者和运营者(以下简称"您")更好地落实移动终端个人信息保护相关事宜，避免因涉及第三方相关业务实践而违反相关法律法规、政策及标准的规定，特编写《将至SDK应用合规指南》供您参考。

为免歧义，本《指南》中的“合规要求”、“注意事项”等内容，均为将至网络基于自身对国家相关法律法规、政策及标准的理解而起草，仅作为参考内容向您提供，不构成也不应被视为对任何法律法规、 政策及标准的有权解释、法律意见或法律建议，亦不构成将至网络对外的任何承诺与保证。

一. 开发者个人信息保护的合规要求

1、您应确保您所开发或运营的APP有《隐私政策》

隐私政策（或命名为个人信息保护政策等类似名称），是说明 APP的个人信息收集和使用情况，获得用户的合法授权以及保护用户个人信息主体权利的重要文档。

1）您可以参考《GB/T 35273-2020 信息安全技术 个人信息安全规范》，该文件对您理解个人信息保护要求和隐私政策编写具有重要的参考价值。

2）您应在《隐私政策》中逐一明示您嵌入的第三方SDK名称、提供方、第三方SDK所收集使用个人信息的目的、方式和范围，以及所提供的数据安全保护措施。

2、APP 的隐私政策中应披露将至SDK的哪些内容

您应在《隐私政策》中“个人信息共享”条款部分或"第三方SDK情况说明”中告知终端用户消息游戏相关功能/服务由将至SDK提供，参考将至SDK隐私政策内容列明收集、使用的用户个人信息类型、目的和用途，并显示将至SDK的隐私政策链接。

将至SDK提供以下告知文案示例供您参考执行：

为向您提供良好的游戏服务，我们集成了将至SDK，相关信息具体如下：

SDK名称	将至SDK
开发者名称	广州市将至网络科技有限公司
使用目的	提供游戏账号登录、支付、角色上报
共享的个人信息类型	设备标识【OAID、加密的Android ID、IMEI号(针对安卓P及之前)】、设备信息(设备厂商、型号、归属地、运营商名称等)、软件相关信息(Android系统和SDK版本号、Android ID、游戏服务版本号)、第三方账号信息（用于实现登录账号）、游戏的ID、游戏包名、游戏版本号、游戏商品名称、商品金额】
可能调用的权限	访问网络状态、获取设备信息、写入设备存储
隐私政策链接	https://open.coming.cool/SDK/doc/privacy-policy.html

3、APP隐私政策的展示方案

您应遵从国家相关法律法规、政策及标准的要求，对APP隐私政策进行展示，包括但不限于：

1）隐私政策应单独成文，而不是用户协议或其他文件的一 部分。

2）APP首次运行时应通过弹窗等明显方式提示终端用户阅读隐私政策。

3）您应当保证隐私政策的易访问性。终端用户进入 APP主功能界面后，通过 4 次以内的点击或滑动，就能够访问到隐私政策。

4）隐私政策应由终端用户自主选择是否同意，不应以默认勾选同意的方式或是欺骗诱导的方式取得终 端用户授权。

5）按照近日工业和信息化部《关于开展信息通信服务感知提升行动的通知》，您还应建立个人信息清单和与第三方共享个人信息清单，并在APP二级菜单中展示，方便用户查询。

4、如果APP用户不希望其个人信息被处理和使用，应当如何处理？

请您充分了解，根据相关法律法规，终端用户对其个人信息的处理享有知情权、决定权、限制处理权、拒绝权、更正删除权等多方面权利。用户可以通过提交请求撤销同意，包括收集、使用和/或披露掌握或控制的用户的个人信息。根据用户所使用的具体服务，可以通过访问 http://www.coming.cool - 联系我们，通过电话联系客服处理。我们将会在您做出请求后的合理时间内处理您的请求，并且会根据您的请求，在此后不再收集、使用和/或披露您的个人信息

二. 您在使用将至产品及服务时应注意什么？

1、不可在用户未同意状态下收集MAC、IMEI、IMSI、SSID、APP LIST、IP、GPS、WiFi-Name

用户点击“同意”前，APP不能和云端有任何数据交互(隐私政策的网页除外)，APP或SDK不能对设备进行任何数据读取（如imei、mac等），SDK必须做延迟初始化配置。用户同意《隐私政策》后再初始化SDK采集数据，用户打开游戏后，应立即以弹窗形式展示隐私政策。

将至网络SDK请接入最新版本，并按照Demo进行接入，其它SDK在用户点击“同意”前，不要做初始化配置，用户点击“同意”前的任何数据读取行为都不符合规范，日志分析方法见下文< 驳回日志分析方法 >

2、隐私政策需用户手动同意

勾选方式展示隐私政策，不可默认勾选

弹框方式展示隐私政策，需要有明显的拒绝按钮

3、通讯录/短信/录音/相机/XXX等权限申请

需要在使用时向用户申请，不能首次打开时申请

4、用户拒绝权限申请时，可以正常运行游戏

驳回日志分析方法

注：日志结构可能会与下文不完全一致，但思路相同，均为通过调用栈定位不合规的接口调用。

用户同意《隐私政策》前采集数据被驳回并设置debug模式时，可打开用户日志，打开后如图：

1. 格式化日志

tag包含MAC、IMEI、IMSI、SSID、APP LIST、IP、GPS、WiFi-Name的需要进行修改

2. 查看调用栈

对stackMsg的内容进行分析

java.lang.Exception

at comui.security.privacy.PrivacyUtil.addLog(PrivacyUtil.java:66)//测试机log，可忽略

at comui.security.privacy.PrivacyUtil.addLog(PrivacyUtil.java:53) //测试机log，可忽略

at android.telephony.TelephonyManager.getDeviceId(TelephonyManager.java:1630) //此处为调用IMEI的Android api

at com.coming.ad.common.util.AndroidUtils.getIMEI(SourceFile:14)

//通过包名可认为直接调用者是广告SDK

at com.coming.ad.common.util.AndroidUtils.getHashedIMEI(SourceFile:1)

at a.d.a.a.i.d.d.a(SourceFile:27)

at com.coming.ad.common.network.g$a.run(SourceFile:1)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:462)

at java.util.concurrent.FutureTask.run(FutureTask.java:266)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)

at java.lang.Thread.run(Thread.java:919)

3. 延迟初始化

在用户同意《隐私政策》后调用广告SDK的初始化方法

三. 常见问题合规指引

1、隐私政策不合规

情景一：缺少隐私弹窗或设置为默认勾选

典型案例：

游戏首次打开后展示主动勾选完成的隐私政策，或直接进入游戏，属于隐私政策不合规

指导意见：

游戏需要在第一界面展示清晰的隐私政策，包括通过弹窗、文本链接等主动形式提示用户阅读隐私政策

隐私政策以单独成文的形式发布，而不是作为用户协议、用户说明等文件中的一部分存在

情景二： 隐私政策缺少拒绝按钮

典型案例：

用户在阅读完隐私协议内容后可以同意进入游戏同样也需要有拒绝并退出游戏的按钮

指导建议：

在首次运行、用户注册时，必须提供用户主动同意的选择方式，如提供同意/不同意按钮，不能是“我知道了”“好的”等无法清晰表达用户同意的词语

隐私政策文本文字显示方式（字号、颜色、行间距等）不会造成阅读困难，清晰说明各项业务功能及所收集个人信息类型、个人信息处理规则及用户权益保障

参考案例

常见问题

Q：隐私协议弹窗一定要有复选框吗

A：不是必须有复选框，但是必须不能默认勾选

Q：我的隐私协议明确的展示“同意/不同意”文案，为什么不合规

A：注意文案的颜色、大小等，不能带有诱导性质

Q：隐私协议什么时候进行展示

A：游戏需要在第一界面展示清晰的隐私政策，包括通过弹窗、文本链接等主动形式提示用户阅读隐私政策

2、频繁索要权限

重点关注APP安装、运行和使用相关功能时，非服务所必需或无合理应用场景下，用户拒绝相关授权申请后，应用自动退出或关闭的行为。重点关注短时长、高频次，在用户 明确拒绝权限申请后，频繁弹窗、反复申请与当前服务场景无关权限的行为。重点关注未及时明确告知用户索取权限的目的和用途，提前 申请超出其业务功能等权限的行为。

合规指引：

APP运行时，向用户索取电话、通讯录、定位、短信、录音、相机、存储、日历等权限，用户拒绝授权后，APP不应退出或关闭。

APP运行时，向用户索取电话、通讯录、定位、短信、录音、相机、存储、日历等权限，用户拒绝授权后，APP不应循环弹窗申请权限，使用户无法继续使用。

用户注册登录时，APP向用户索取电话、通讯录、定位、短信、录音、相机、存储、日历等权限，用户拒绝授权后，APP不应无法正常注册或登录。

APP运行时，在用户明确拒绝通讯录、定位、短信、录音、相机、日历等权限申请后，不应向用户频繁弹窗申请与当前服务场景无关的权限，影响用户正常使用。

APP在用户明确拒绝通讯录、定位、短信、录音、相机、日历等权限申请后，重新运行时，APP不应向用户频繁弹窗申请开启与当前服务场景无关的权限，影响用户正常使用。

APP首次打开或运行中，未见使用权限对应的相关功能或服务时，不应提前向用户弹窗申请开启通讯录、定位、短信、录音、相机、日历等权限。

APP未见提供相关业务功能或服务，不应申请通讯录、定位、短信、录音、相机、日历等权限

情景一：强制索权

主要表现为必须同意授予权限，否则无法使用应用。

典型案例：

游戏类应用需申请通讯录权限获取游戏好友，首次申请权限时用户拒绝，应用需保证游戏基础功能可使用，且不得访问联系人。当用户再次使用到需联系人的场景时，才可弹出申请通信录权限。

指导建议：

不管用户拒绝哪种权限，均需提供基本功能，不得直接退出应用。若用户明确拒绝某功能必要权限后，需当用户再次触达相关功能场景时弹框供用户选择是否开启。

情景二：频繁索权

主要表现为在用户拒绝权限后，重新打开App或进入相应界面，都会再次向用户索要或频繁以弹窗等形式提示用户授权相关权限，干扰用户正常使用，属于一种变相的强制索权。

典型案例：

用户拒绝权限申请后多次弹出与当前服务场景无关权限申请弹窗

指导建议：

同情形一中案例，需掌握合适时机弹出，不得影响其他功能可用，两次权限申请时间间隔48小时

情景三：过度索权 向用户索取非必要权限

主要表现为仅以提供附加功能、个性化服务、提升用户体验等为由收集某些个人信息/系统权限（此类信息并非实现App基本功能所必要），同时将该类信息与实现App基本功能所必要的信息相捆绑，要求用户一并同意，用户不同意则无法使用App基本功能或所有功能。

典型案例：

如天气应用主要功能是为用户提供天气情况，主要用到的权限为定位权限，不应获取权限摄像头权限、联系人权限。

指导建议：

针对应用软件使用场景和功能，确定应用软件申请哪些对应的敏感权限，不应申请与应用业务功能无关的其他权限。

3、不给权限不让用

情形一：强制索权

主要表现为必须同意授予权限，否则无法使用应用。

典型案例：

游戏类应用需申请通讯录权限获取游戏好友，首次申请权限时用户拒绝，应用需保证游戏基础功能可使用，且不得访问联系人。当用户再次使用到需联系人的场景时，才可弹出申请通信录权限。

指导建议：

不管用户拒绝哪种权限，均需提供基本功能，不得直接退出应用。若用户明确拒绝某功能必要权限后，需当用户再次触达相关功能场景时弹框供用户选择是否开启。

4、未经许可读取个人信息

情景一：征得用户同意前，收集“IMEI”、“MAC”、“软件安装列表”等信息

典型案例：

APP或SDK收集用户信息前，未在隐私政策中明示收集。

指导建议：

在隐私政策中清晰明示APP收集设备MAC地址、软件安装列表等个人信息的目的方式范围，不要使用“等”模糊或者有多意性的表述；

针对第三方SDK，需核查APP中是否嵌入了会收集个人信息的SDK；如有嵌入，需确认隐私政策中逐一列出了SDK收集的个人信息类型、目的及展示隐私链接。

典型案例：

在隐私政策中已明示，但在征得用户同意前开始收集“MAC地址”“IMEI”等个人信息。

指导建议：

1. 检查代码逻辑，是否存在“设备MAC地址、应用列表、IMEI、IMSI”信息读取的代码，若无，则不违规；若有，进行步骤2检查；

2. 检查代码逻辑，在用户未点击同意隐私政策的情况下，读取“设备MAC地址、应用列表、IMEI、IMSI”信息的代码是否会被执行，若被执行，则违规；若不被执行，则不违规；

3. 检查代码逻辑，在用户拒绝同意隐私政策后，读取设备MAC地址的代码是否会被执行，若被执行，则违规；若不被执行，则不违规。

Q：“APP首次运行，用户同意隐私政策前，存在私自收集/使用设备IMEI 、IMSI等设备标识等行为”是否意味OAID等设备标识都默认不能采集了？

A：整改通知，依据的是工信部164号文等规相关法规和执行依据，请按照整改通知中明确的要求整改；强调的是收集前需要“用户同意隐私政策”；OAID在获得“用户同意”后，是可收集的

Q：APP没有主动收集用户信息，为什么会检测出收集行为？

A：不单是APP，很有可能是不规范接入的第三方SDK导致问题；网游SDK要在Application.onCreate中调用初始化方法，需要在 用户同意隐私弹窗后，再进行调用onUserAgreed方法，才可保证不提前获取信息；广告SDK要在用户同意隐私弹窗后才能调用初始化，才可保证不提前获取信息

5、未经许可发送个人信息

重点关注APP、SDK未向用户告知且未经用户同意，私自使用个人信息，将用户个人信息用于其提供服务之外的目的，特别是私自向其他应用或服务器发送、共享用户个人信息的行为。

合规指引：

未明示共享：APP未向用户明示个人信息处理的目的、方式和范围，不应将IMEI、IMSI、设备MAC地址、软件安装列表、位置、联系人、通话记录、日历、短信、本机电话号码、图片、音视频等个人信息发送给第三方SDK等产品或服务；

未同意共享：APP以个人信息处理规则弹窗等形式向用户明示共享给第三方的行为，未经用户同意，不应将IMEI、IMSI、设备MAC地址、软件安装列表、位置、联系人、通话记录、日历、短信、本机电话号码、图片、音视频等个人信息发送给第三方SDK等产品或服务；

明示共享不清晰：APP以个人信息处理规则弹窗等形式向用户明示个人信息处理的目的、方式和范围，未清晰明示共享的第三方身份、目的及个人信息类型，用户同意后，不应将IMEI、IMSI、设备MAC地址、软件安装列表、位置、联系人、通话记录、日历、短信、本机电话号码、图片、音视频等个人信息发送给第三方SDK等产品或服务；

服务器端共享：APP未向用户告知且未经用户同意，不应将设备识别信息、商品浏览记录、搜索使用习惯、软件安装列表等个人信息传输至APP服务器后，向第三方产品或服务提供其收集的个人信息。

情景一：隐私政策中有明示共享第三方，但在用户同意前，违规将个人信息数据共享给第三方使用

指导建议：

人工查看APP隐私政策声明的收集使用规则是否明确列出其将收集的个人信息类型（如imei信息、设备MAC地址、软件安装列表等）共享给第三方公司；

检查代码逻辑，在用户未点击同意隐私政策的情况下，存在将imei信息、设备MAC地址、软件安装列表等传参给XXX第三方公司的接口的代码，若被执行，则违规；若不被执行，则不违规。

情景二：向第三方提供信息前，隐私政策中未进行明示共享第三方或使用第三方SDK

指导建议：

以表格形式罗列第三方SDK并说明其用途及所属公司、隐私说明页。