1. 政策原文只有一句原则。Google Play「Malware（恶意软件）」政策开篇即写明：「Our Malware policy is simple, the Android ecosystem including the Google Play store, and user devices should be free from malicious behaviors (for example, malware).」——Android 生态（含 Google Play 商店）与用户设备必须免于恶意行为。恶意代码的定义被刻意写宽：「Malware is any code that could put a user, a user's data, or a device at risk. Malware includes, but is not limited to, Potentially Harmful Applications (PHAs), binaries, or framework modifications, consisting of categories such as trojans, phishing, and spyware apps, and we are continuously updating and adding new categories.」真正决定绝大多数执法结果的，是紧接着的适用范围句：「The requirements of this policy also apply to any third party code (for example, an SDK) that you include in your app」——你集成进应用里的任何第三方代码（例如 SDK）同样受本政策约束（https://support.google.com/googleplay/android-developer/answer/9888380）。
2. Google 用来判定的六个目标。政策列出使代码构成恶意的六种目标：破坏用户设备完整性；取得设备控制权；「enable remote-controlled operations for an attacker to access, use, or otherwise exploit an infected device」（开放远程受控操作，供攻击者访问、使用或以其他方式利用被感染设备）；「transmit personal data or credentials off the device without adequate disclosure and consent」（在披露与同意不足的情况下把个人数据或凭据传出设备）；「disseminate spam or commands from the infected device to affect other devices or networks」（从被感染设备对外散布垃圾信息或指令）；以及欺诈用户。六条是并集：命中任意一条即成立，不需要全部满足。
3. 「我们不是故意的」不是抗辩理由。政策原文：「An app, binary, or framework modification can be potentially harmful, and therefore can generate malicious behavior, even if it wasn't intended to be harmful... what is harmful to one Android device might not pose a risk at all to another Android device. For example, a device running the latest version of Android is not affected by harmful apps which use deprecated APIs to perform malicious behavior but a device that is still running a very early version of Android might be at risk.」实务含义：主观意图不构成抗辩，「只影响老设备」也不构成抗辩；把 minSdk / targetSdk 长期压在旧版本上，恰恰扩大了可被标记的风险面。
4. Play Protect 实际比对的是哪些类别。Google Play Protect 的 Malware 页面逐条列出分类：backdoors（后门）、billing fraud（短信/通话/话费欺诈）、stalkerware（跟踪监控软件）、denial of service、hostile downloaders、non-Android threats、phishing、elevated privilege abuse、ransomware、rooting、spam、spyware、trojans、uncommon apps、riskware（https://developers.google.com/android/play-protect/phacategories）。其中最容易被「完全无恶意意图」的应用踩中的是后门判定：「A necessary condition for any code to be classified as a backdoor is that it enables behavior that would place the code into one of the other malware categories if executed automatically. For example, if an app allows dynamic code loading and the dynamically loaded code is extracting text messages, it will be classified as a backdoor malware. However, if an app allows arbitrary code execution and we don't have any reason to believe that this code execution was added to perform a malicious behaviour then the app will be treated as having a vulnerability, rather than being backdoor malware, and the developer will be asked to patch it.」读成规则就是：动态代码加载只有在「拉取的载荷可证明无害」时才能过关；一旦 DCL 与读取短信等敏感数据并存，即判为后门。
5. 第三方 SDK 的责任在你，不在 SDK 供应商。Malware 页面的 Do/Don't 明确列出 SDK 拖垮应用的四种情形：「Ensure third-party SDKs don't collect and/or exfiltrate user data without policy-compliant functionality and/or adequate notice or consent (Spyware)」、「Use third-party SDKs that perform Denial of Service attacks or act as a Hostile Downloader」、「Use third-party SDKs that collect and transmit personal data for monitoring without proper user disclosure and consent (i.e. stalkerware)」、「Integrate code that abuses elevated privileges to compromise system integrity, roots devices without explicit user consent and awareness, or employs maskware techniques to evade detection of malicious behavior」；同页还提醒：「All apps must also comply with all Google Play Developer Program Policies, including user and device data policies such as Mobile Unwanted Software, User Data, Permissions and APIs that Access Sensitive Information, and SDK Requirements」。
6. 2024 年新增、专治「看起来干净」应用的那一条。Google「Mobile Unwanted Software」政策现已写明：「Do not request or deceive users into turning off device security protections such as Google Play Protect. For example, you must not offer additional app features or rewards to users in exchange for turning off Google Play Protect」（https://support.google.com/googleplay/android-developer/answer/9970222），该条由 2024 年 4 月 3 日政策公告引入（https://support.google.com/googleplay/android-developer/answer/14594990）。任何引导页、帮助文档或 SDK 授权流程里出现「关闭 Play Protect 才能正常使用」「关掉它解锁功能/给奖励」，都是直接违规；而恶意软件属于「重复或严重违规将危及开发者账号本身、而不只是下架一个包」的政策集。
7. 执法的实际形态。Google 开发者政策中心写明：「Because Malware is potentially harmful to users, apps containing Malware are strictly prohibited from Google Play」（https://play.google/developer-content-policy/）。下架后果会传导到用户设备：「If your app has been removed or suspended from Google Play, its users may receive a push notification from Google Play Protect informing them of this change and giving them the option to remove the app from their device」（https://support.google.com/googleplay/android-developer/answer/2477981）。两个机制必须记住：其一，警告不等于结束——「Warnings don't impact the standing of your Google Play Developer account. However, your app will be removed after the number of days found in the initial warning email」，且「If your app has been suspended after receiving a warning, an appeal is required」；其二，重新提交必须把每条轨道都清干净——要「upload the modified, policy-compliant app bundle across all tracks, and deactivate the non-compliant app bundle(s)」，否则「if you fail to deactivate the non-compliant app bundle(s), your attempt to resubmit your app will fail, and live versions of your app bundle(s) may be removed from Google Play」；申诉额度有限——「You may submit one appeal per app removal, suspension, or other enforcement action」，所以第一次申诉就必须一次讲全。
8. Play Protect 警告：五类可申诉，一类不可申诉。Google 的开发者指引逐条解释了用户会看到的每一类警告：「App blocked to protect your device」在来自浏览器、通讯软件、文件管理器等互联网侧载来源的 APK 声明 RECEIVE_SMS、READ_SMS、NOTIFICATION_LISTENER 或 ACCESSIBILITY 时触发，原因是「these permissions are frequently abused for financial fraud」，可申诉；「Harmful App Blocked」表示被识别为 PHA 或不受欢迎软件，可申诉；「Deceptive Accessibility Tool Warning」只在「you declare isAccessibilityTool="true" when your app isn't used to assist users with disabilities」时出现，可申诉；「Android App Compatibility Too Low Warning」只在「the app's targetSdkVersion is more than 2 versions lower than the current Android API level」时出现，靠升级 target 消除而不是靠申诉。唯一的例外是未知应用扫描弹窗（「Play Protect hasn't seen this app before」／「This app is unknown to Play Protect. To protect yourself and others, send it to Google for a security check.」），Google 的说明是：「For users, sending (one time or always) this application to Google Play Protect to scan for potential malware will make this notification go away. Appeals are not relevant and won't remove this message.」——这类弹窗不能靠申诉消除，出路是让 Play Protect 认识这个应用（走 Play 商店分发并检查设备认证状态），而不是反复提交申诉（https://developers.google.com/android/play-protect/warning-dev-guidance）。
9. 「干净」应用实际被标记的入口。实务上集中在五种：(a) 动态或延迟代码加载，且拉取的载荷触及消息、通讯录或设备标识符；(b) 非辅助类应用把无障碍服务声明为 isAccessibilityTool="true"；(c) 侧载分发渠道叠加短信／通知监听／无障碍权限组合；(d) 为变现或统计引入的 SDK 偷偷外传标识符、注入混淆代码或充当恶意下载器；(e) targetSdk 落后当前平台两个 API 以上。
10. 发布前自检清单。逐个体检第三方 SDK 的域名与网络行为，而不是只看名字；只申请最小必要权限，用 SMS Retriever 或 User Consent API 替代 READ_SMS 做短信验证；绝不内置隐藏的远程控制能力，也不混淆远程执行端点；被标记的漏洞立即修补；targetSdk 保持最新；绝不引导用户关闭 Play Protect；并确保 Play Console 声明、APK 实际行为与商店文案三者一致——Play Protect 会把申报用途与构建体的真实行为做比对。本站相关阅读：《短信与通话记录（SMS & Call Log）敏感权限声明》一篇（https://kapps.store/zh/faq/sms-and-call-log-permissions-declaration-handler-eligibility-permitted-and-excep.html）与《Restricted Permissions Declaration on Google Play——高风险权限表单的正确填写》（https://kapps.store/faq/restricted-permissions-declaration-on-google-play-completing-the-high-risk-permi.html）。