Google Play Guidelines Update

Google is expanding its Families Policy Requirements to ban developers of anonymous chat apps from targeting children. Previously there was no explicit call-out for anonymous chat as a prohibited category in child-directed contexts. If your app offers anonymous chat features and targets children or a mixed audience that includes children, you will need to restructure your app's targeting or remove the anonymous chat functionality to remain compliant.

The rule requiring all apps to post a privacy policy link in the Play Console designated field and within the app itself has been removed from this section. This was one of the most fundamental and broadly enforced requirements, and its absence here is significant. Developers must verify whether this requirement has moved to another policy document, as privacy policy links remain a standard store listing field and likely still required.

This is a newly stated explicit prohibition on selling personal and sensitive user data, added directly to Developer Program Policy. While data monetization practices were previously governed by privacy and ads policies, this statement elevates the prohibition to a top-level policy rule. Apps that monetize user data through data brokers, data marketplaces, or direct sale arrangements are now in clear violation. Developers should review any data monetization arrangements and ensure they do not constitute a sale of user data.

This addition places child safety policy compliance as a named, explicit requirement within the Developer Program Policy. While child safety rules existed elsewhere in Google Play policies, elevating it here signals stricter enforcement at the program level. Any app that enables, facilitates, or fails to prevent child exploitation or inappropriate child-directed content is now in violation of this top-level rule. Developers of any app that could reach or be used by minors should thoroughly review Google's child safety policies.

This new addition makes it an explicit Developer Program Policy requirement — not just a Families policy requirement — that child-directed apps comply with the Google Play Families policy, specifically calling out its data handling provisions. Developers who target children must ensure their data practices, third-party SDKs, and content meet Families policy standards. Non-compliance now creates a dual policy violation: both Families policy and the broader Developer Program Policy. If your app is rated for or targeted at children, a Families policy compliance audit is now essential.

This addition formally states that apps must allow users to delete their accounts, aligning with the account deletion requirement Google has been rolling out in Play Console. Previously this was communicated as a Play Console policy and deadline, but it is now stated as a Developer Program Policy rule. Apps that create user accounts must provide a clear in-app path to account and associated data deletion. Developers who have not yet implemented account deletion functionality risk policy violations and potential removal.

Google has published the full policy text for prominent disclosure requirements, targeting cases where an app's data collection or sharing would not be reasonably expected by users — particularly background data collection when the app is not in active use. The policy mandates an explicit in-app disclosure (not just a privacy policy link) detailing data access, collection, use, and sharing. Any app collecting data in the background or in ways users wouldn't anticipate must implement this disclosure or face rejection.

Google has introduced a dedicated policy summary covering restrictions on apps that access financial data, contact data, or persistent identifiers. This signals a new or formalized category of enforcement targeting these specific sensitive data types. Developers whose apps interact with any of these data categories should review the full policy details to ensure their data handling practices are compliant.

Google has introduced an explicit requirement that child-directed apps use only SDKs that have been approved for use in apps targeting children. Previously, SDK selection may have been governed by broader Families Policy rules, but this is now a direct stated requirement. Developers of child-directed apps must audit all third-party SDKs they integrate and remove or replace any that are not on Google's approved list, or risk rejection.

Google now explicitly restricts the practice of linking persistent device or user identifiers to other data categories, permitting it only for specific telephony or enterprise device management purposes. Apps doing this must also provide clear disclosures to users. Developers who associate advertising IDs, device IDs, or similar persistent identifiers with behavioral or personal data outside these permitted use cases will need to change their data practices to remain compliant.

A new headline rule states that apps targeting children must not incorporate SDKs that lack explicit approval for child-directed environments. This is a significant addition for developers in the family or kids app space who may be using third-party SDKs for analytics, ads, or features. Using a non-approved SDK—even unintentionally—can now result in policy violations and rejection. Developers should audit all third-party SDKs in children's apps against Google's approved SDK list.

This is the detailed counterpart to the headline rule at index 55, making it explicit that the prohibition on unapproved SDKs applies to all apps in the children's category regardless of the SDK's purpose. Even SDKs used for crash reporting, analytics, or feature flags must be approved if the app targets children. Developers should not assume a general-purpose SDK is compliant just because it lacks advertising features. A full SDK review against Google's approved list is now essential before submitting or updating children's apps.

Google Play is formally introducing a Data Safety section policy that requires developers to fully disclose what user data their app collects, how it is used, and how it is shared. This is a new overarching policy framework, not just a UI feature. All developers must now treat the Data Safety section as a binding compliance obligation, not an optional form. Failure to accurately complete it can result in policy violations.

A new Don't rule explicitly bans any attempt to obscure or hide data collection and usage practices from users. While deceptive data practices were implicitly prohibited before, this makes the prohibition explicit and enforceable as a named policy violation. Apps that use technical or UX patterns to downplay data collection (e.g., burying disclosures or using vague language) are now clearly in scope. This could be grounds for rejection or removal.

Google has introduced an explicitly titled Privacy Policy Policy section in the Developer Program Policy, formally requiring all apps to have a comprehensive privacy policy that is accessible both within the app and linked in the Play Console. While a privacy policy has long been expected, codifying this as a named policy section signals stronger enforcement. Developers without a linked, in-app-accessible policy are now clearly out of compliance.

Google requires that any app allowing users to create an account must also provide a straightforward, easy-to-find mechanism for deleting that account. This formalizes and strengthens the account deletion requirement on Google Play. The deletion option must be prominently accessible, not hidden or hard to locate. Apps lacking this feature face rejection or removal.

Google now explicitly states that upon account deletion, all associated user data must be permanently and fully deleted. Retaining any user data after account deletion — beyond what is legally required — is a policy violation. Developers must ensure their backend systems and data pipelines fully purge user records and not just mark them inactive. This requirement applies unless legal or regulatory obligations mandate retention, which must be disclosed.

This requirement reinforces that deleting an account must trigger deletion of all data tied to that account across all systems. Developers cannot retain user-linked data in ancillary databases, analytics stores, or backup systems after deletion. This goes beyond just the primary account record and encompasses all associated data. Apps should audit their entire data infrastructure to ensure full compliance.

Google has introduced a named Account Deletion Requirement Policy, formally establishing that any app allowing users to create an account must provide a clear in-app option to delete it. This consolidates and elevates earlier account deletion guidance into a distinct, enforceable policy with its own summary. Developers whose apps include account creation flows must ensure a compliant deletion path is in place or face rejection. This is one of the most significant user data control requirements added to the Developer Program Policy.

Developers are explicitly forbidden from using the App Set ID for personalized advertising or ad measurement purposes. This draws a hard line distinguishing the App Set ID from advertising identifiers like the Advertising ID (GAID). Apps that attempt to repurpose the App Set ID for ad targeting or measurement pipelines will be in violation of policy. Ad tech developers in particular need to ensure their SDKs and integrations do not misuse this identifier.

The policy prohibits linking the App Set ID to any Android identifiers or personal and sensitive user data for advertising purposes. This prevents developers from using the App Set ID as a bridge to reconnect advertising profiles or fingerprint users indirectly. Developers building data pipelines or working with ad networks must ensure the App Set ID is kept isolated from advertising data flows. Violations of this rule could result in app removal.

This is a newly added policy section with no prior equivalent in the Developer Program Policy. Apps that handle personal data from users in the EEA, UK, or Switzerland must now comply with applicable privacy and data protection laws in those regions. This is a significant addition for any developer whose app collects or processes data from European users, as non-compliance becomes an explicit policy violation.

The full policy specifies that any developer accessing, using, or processing personal information sourced from Google that originates in the EEA, UK, or Switzerland must comply with all applicable privacy, data security, and data protection laws. Data use must be limited to purposes consistent with the consent obtained from users. This applies specifically to Google-provided data, meaning developers building on Google APIs or services that surface EU user data are directly in scope.

The new policy's Don't list makes clear that ignoring privacy laws is itself a Google Play policy violation, not just a legal risk. This means Google can take enforcement action — including app removal — based on privacy law non-compliance, independent of any regulatory action. Developers with European users should treat GDPR and equivalent laws as Play policy requirements.

The Don't list explicitly prohibits accessing or processing personal data for unconsented purposes. This mirrors the GDPR's purpose limitation principle but now carries Google Play enforcement weight. Developers using EU user data for analytics, advertising, or other secondary uses must ensure each use case is covered by informed user consent.

A new requirement explicitly states that apps designed for children must use SDKs that have been approved by Google Play. Previously, children's app SDK requirements may have been addressed elsewhere or less directly. Developers building apps for kids — or apps with mixed audiences — need to audit all third-party SDKs for Play approval status or risk rejection under this policy.

Apps that associate persistent identifiers (such as device IDs) with other user data are now explicitly limited to specific telephony or enterprise device management purposes. Developers must also provide clear disclosures to users when doing so. Any app outside these use cases that links persistent identifiers to additional data categories must rethink its data architecture to remain compliant and avoid rejection.

This new rule explicitly requires that when a user requests account deletion, all associated user data must be fully deleted rather than the account being frozen, deactivated, or soft-deleted. This is a significant operational requirement: developers need to ensure their backend systems can perform genuine data deletion on request. Apps that only disable accounts without purging data will be non-compliant.

Google now explicitly prohibits retaining user data after account deletion. When a user deletes their account, all associated data must be permanently removed — not archived, anonymized in a reversible way, or retained beyond any legally required minimum period. Developers using backend databases, analytics platforms, or third-party services must ensure those systems also purge user data upon deletion requests.

Google has added an explicit requirement that account deletion results in the deletion of all data associated with that account, not just the account credentials themselves. This extends to profile data, usage history, content, and any data held by integrated third-party services. Developers should audit their entire data lifecycle to confirm that a deletion request propagates correctly to all storage systems and partners.

A new rule forbids developers from selling or transferring user data without first meeting all applicable legal and policy requirements under the EU-U.S., UK, and Swiss Data Privacy Frameworks. While data sale restrictions existed in other parts of Google's policies, this explicitly anchors the prohibition within the Data Privacy Framework context. Developers who share data with third parties, data brokers, or acquirers must verify full compliance before any such transaction. Non-compliance could result in app removal or account termination.

Google Play has added an explicit prohibition on distributing content associated with predatory behavior, illegal themes, or bestiality. This formalizes and expands existing inappropriate content rules with specific named categories. Developers distributing any user-generated or curated content must ensure their moderation systems can detect and block these content types to avoid app removal.

Google Play now restricts the distribution of sexual content to apps that function as book or video catalog apps. Apps in other categories — such as games, utilities, or social apps — are no longer permitted to distribute sexual content regardless of age gating or other controls. Developers outside the book/video catalog category must remove any sexual content to remain compliant.

Google Play now explicitly bans apps from promoting services that could be interpreted as soliciting sexual acts or that involve non-consensual sexual content. This affects apps in dating, social, or adult entertainment categories that may feature ambiguous promotional language or services. Developers should carefully review any service descriptions, calls-to-action, or in-app promotions to eliminate any such interpretations.

Google has added a formal policy statement explicitly prohibiting apps that promote violence or incite hatred against individuals or groups based on a broad list of protected characteristics, including race, religion, gender identity, caste, immigration status, and more. Previously this prohibition may have existed implicitly or in less structured form; it is now codified with a specific enumerated list. Developers must audit all app content — including user-generated content — to ensure nothing targets any of these groups. Violations can result in app removal or account termination.

This addition explicitly states that apps inciting hatred or violence against individuals or groups are not permitted on Google Play. While this aligns with longstanding platform values, its formal addition as a written rule means it is now an enforceable, citable policy. Developers building news, social, forum, or community apps must ensure their content moderation systems prevent such material from appearing in their apps.

A new Violence Policy Summary section has been added, stating that apps containing gratuitous violence or dangerous activities are prohibited. While violence-related restrictions have existed in spirit, this formal policy addition creates a clear, citable rule. Developers of gaming, action, stunt, or extreme sports apps should review their content to ensure any violent elements serve a narrative or gameplay purpose rather than being purely gratuitous. This could affect app ratings, distribution, or approval.

A new Violent Extremism policy summary has been introduced, explicitly prohibiting apps from dangerous organizations and apps that promote or glorify violent extremism. This is a newly surfaced, formally named policy section. Any app with content touching on extremist groups, movements, or ideologies — even for awareness purposes — must ensure it does not cross into promotion or glorification.

The full policy now explicitly states that terrorist organizations, and other dangerous organizations or movements involved in or claiming responsibility for violence against civilians, are prohibited from publishing on Google Play for any purpose — including recruitment. This is a comprehensive ban with no permitted use cases for such entities. Developers building apps on behalf of organizations should verify those organizations are not designated as dangerous.

As part of the new Key Considerations section, a clear 'Don't' directive has been added stating that developers must not publish apps from terrorist or other dangerous organizations. This reinforces the full policy statement and makes the prohibition prominent in developer-facing guidance. Developers acting as agencies or contractors should vet their clients against this requirement.

A new Bullying and Harassment Policy has been added, explicitly prohibiting apps from containing or facilitating harassment, exploitation, or bullying of any kind. Previously this policy section may not have been formally labeled or summarized in this location. Any app with social, messaging, community, or user interaction features must ensure it does not enable or host harassing behavior, and should have appropriate moderation or reporting mechanisms.

The full policy text has been added stating that Google does not allow apps that contain or facilitate threats, harassment, or bullying. This formalizes and expands on the summary policy at index 56 by explicitly including 'threats' as a prohibited category alongside harassment and bullying. Developers of any platform with user communication or content-sharing features must ensure their app cannot be used to threaten or harass individuals.

A new Dangerous Products Policy has been introduced that explicitly prohibits the sale of explosives, firearms, ammunition, and certain firearms accessories through apps on the platform. This is a newly formalized written policy in this section. Developers of e-commerce, marketplace, or retail apps that deal in any of these product categories must remove such transaction capabilities or risk rejection and removal from the Play Store.

A new dedicated Marijuana Policy section has been added, stating that apps facilitating the sale of marijuana or marijuana-derived products are not permitted on Google Play regardless of whether such sales are legal in the user's jurisdiction. This is a significant policy clarification that overrides regional legality considerations. Developers in cannabis-legal markets who have built or are planning dispensary, delivery, or cannabis commerce apps must remove or not implement any transactional sale functionality.

Building on the new Marijuana Policy, Google has added a specific prohibition against apps that allow users to place marijuana orders through an in-app shopping cart or similar e-commerce mechanism. This closes a potential ambiguity about whether transactional features (as opposed to informational content) were covered. Developers with cannabis-adjacent apps — including dispensary locators or menus — must ensure no ordering or cart functionality is integrated.

Previously, marijuana sale facilitation rules may not have been stated this directly in this section. Google now explicitly states that no app facilitating the sale of marijuana or marijuana products is allowed, regardless of whether it is legal in the user's jurisdiction. This is a blanket prohibition — even apps operating in fully legal markets are not permitted, making this a significant rejection risk for any cannabis commerce app.

Google has added a new policy summary explicitly prohibiting apps that facilitate the sale of tobacco or nicotine-containing products — including e-cigarettes, vape pens, and nicotine pouches — and apps that encourage illegal or inappropriate use of alcohol, tobacco, or nicotine. This is a new, clearly articulated prohibition in this section. Developers building any app with tobacco, nicotine, or alcohol commerce or promotional features need to review their app against this rule immediately.

The full policy text now explicitly prohibits apps that facilitate the sale of tobacco or nicotine products (e-cigarettes, vape pens, nicotine pouches) or that encourage the illegal or inappropriate use of alcohol, tobacco, or nicotine. This formalizes what was previously less explicit guidance into a clear, enforceable rule. Any app with tobacco/nicotine e-commerce functionality or that promotes these substances inappropriately faces rejection.

A new 'Don't' rule explicitly forbids apps from facilitating the sale of tobacco, e-cigarettes, or nicotine pouches. This is a direct, actionable prohibition that closes any ambiguity about whether nicotine product sales apps are allowed. Developers of vape shops, tobacco retailers, or nicotine product marketplaces must not enable purchase flows for these items.

The full policy text now formally states that apps containing or promoting sexual content, profanity, pornography, or any content or services intended to be sexually gratifying are not permitted on Google Play. This represents the canonical policy statement and covers both content within the app and services the app provides. Developers should treat this as the definitive compliance standard against which their app will be evaluated.

Google Play has added an explicit prohibition on distributing content associated with predatory behavior, illegal themes, or bestiality. While some of these topics may have been covered under broader existing policies, this new rule names them directly, removing any ambiguity. Developers distributing user-generated or third-party content should ensure their moderation systems flag and remove such material, as violations could result in app removal.

A new rule prohibits apps from promoting services that could be construed as soliciting sexual acts or facilitating non-consensual sexual content. This targets apps that may not explicitly offer such services but whose promotional language or features imply them. Developers of social, dating, or content apps should audit their in-app messaging, calls-to-action, and third-party ad content to ensure nothing could be interpreted this way.

The full Hate Speech Policy has been added, explicitly listing protected characteristics including race, ethnicity, religion, disability, age, nationality, veteran status, sexual orientation, gender, gender identity, caste, and immigration status, among others. Apps that promote violence or incite hatred against individuals or groups based on any of these attributes are prohibited. Developers of news, social, debate, or user-generated content apps should review their content moderation and app content against this comprehensive list.

A new Violent Extremism policy summary has been introduced, explicitly stating that apps from dangerous organizations, or apps that promote or glorify violent extremism, are not permitted on Google Play. This formalizes and surfaces the policy in a summary format, making it more visible to developers. Any app associated with or publishing content favorable to violent extremist groups or movements is at significant risk of rejection.

The full policy text now explicitly states that terrorist organizations and other dangerous organizations or movements involved in violence against civilians cannot publish apps on Google Play for any purpose — including recruitment. This closes any ambiguity about whether such organizations could publish ostensibly neutral apps. Developers who manage app portfolios or publish on behalf of third parties should verify that no associated entity falls into this category.

The policy now includes an explicit 'Don't' rule prohibiting the publication of apps from terrorist or other dangerous organizations. While this aligns with the broader policy intent already stated, its addition as a discrete, enumerated rule increases its enforceability and visibility. Developers and platform operators who publish apps on behalf of other entities should perform due diligence to ensure those entities are not classified as dangerous organizations.

Google has added a named Bullying and Harassment Policy with an explicit summary stating that apps must not contain or facilitate harassment, exploitation, or bullying of any kind. Previously, anti-harassment expectations may have been covered under general conduct policies without this explicit framing. Any app with social, messaging, or community features must ensure it cannot be used as a vehicle for bullying or exploitation. This formal policy introduction signals stricter enforcement in this area.

The full Bullying and Harassment Policy statement has been added, making clear that apps containing or facilitating threats, harassment, or bullying will not be allowed on Google Play. This is the enforceable policy text that backs up the summary introduced in index 135. Developers of social, gaming, communication, and community apps face the highest risk of violations. Robust content moderation, reporting mechanisms, and clear community standards are now essential compliance measures.

A new Dangerous Products Policy has been formally introduced, with a summary explicitly forbidding the sale of explosives, firearms, ammunition, and certain firearms accessories through apps on Google Play. This formalizes and names a policy area that may have previously been addressed less explicitly. Developers running e-commerce, marketplace, or classifieds apps must ensure none of these product categories are transactable within their app. Violations in this category are likely to result in immediate removal.

This addition reinforces the Dangerous Products Policy by adding an explicit prohibition against providing services related to the sale of the dangerous items listed in index 138. It extends the rule beyond just listing products to covering the facilitation of transactions or services around those products. Developers building any kind of marketplace, peer-to-peer platform, or service-listing app should ensure dangerous product categories are fully blocked. This is a direct enforcement-ready rule, not just guidance.

Google has added a clear, top-level policy statement prohibiting apps that facilitate the sale of explosives, firearms, ammunition, or certain firearms accessories. While this policy direction existed previously, the explicit codification in this section makes the scope and intent unambiguous. Developers with any commerce, marketplace, or classified-ad features touching these categories must ensure their apps cannot be used to transact these items.

Google has added a direct 'Don't' directive prohibiting developers from publishing apps that facilitate the sale of explosives, firearms, or ammunition. This formalises the prohibition as an actionable checklist item tied to app review. Any app that includes buying, selling, or brokering functionality for these items — even as a secondary feature — is at risk of removal.

A new Marijuana Policy summary section has been added, making clear that apps facilitating the sale of marijuana or marijuana products are prohibited on Google Play regardless of whether such sales are legal in the user's jurisdiction. Previously this may have been inferred from broader controlled substances policy. Developers of dispensary apps, cannabis delivery services, or any app with marijuana commerce features must remove transactional capabilities to remain compliant.

Google has added a specific prohibition on apps that allow users to place marijuana orders through an in-app shopping cart or similar transactional flow. This targets the mechanism of sale directly, meaning even apps that don't process payment themselves but enable order placement are in scope. Developers must remove cart, order, or checkout flows tied to marijuana products, even if the actual payment occurs off-platform.

Google has added a clear, standalone policy stating that apps facilitating the sale of marijuana or marijuana products are not allowed on the Play Store, with no exceptions for jurisdictions where it is legal. Previously this may have been ambiguous or handled case-by-case. Developers running cannabis marketplaces, delivery apps, or any transactional marijuana-related app must remove that functionality or risk rejection and removal.

The full policy text now clearly states that apps facilitating the sale of tobacco or nicotine products (e-cigarettes, vape pens, nicotine pouches) or encouraging illegal or inappropriate use of alcohol, tobacco, or nicotine are not permitted. This codifies and expands on prior guidance with specific product examples. Any app with a transactional flow for these products, or content that normalizes misuse, is at risk of rejection.

A new 'Don't' rule explicitly forbids apps from facilitating the sale of tobacco, e-cigarettes, or nicotine pouches. This goes beyond general language by naming specific product types, making it clear that dedicated sales flows for these products are not allowed. Developers of vape shops, tobacco marketplaces, or nicotine product apps must remove transactional features to avoid rejection.

This newly added rule directly bans the sale of personal and sensitive user data. While related restrictions existed in spirit across prior policies, this is now an explicit, standalone prohibition. Developers or businesses whose monetization model involves selling user data to third parties must fundamentally change that practice or face policy enforcement including removal from the Play Store.

This is a newly added, explicit top-level prohibition against violating child safety policies. While child safety rules existed in more detailed sub-policies before, elevating this to a standalone directive signals stronger enforcement intent. All developers — not just those targeting children — should review child safety requirements to ensure their apps cannot be used in ways that harm minors.

This newly added rule explicitly requires apps designed for children to comply with the Google Play Families policy, which carries its own strict data handling requirements. Previously these requirements existed in the Families policy itself; surfacing them here broadens their visibility and enforcement surface. Developers of any app that could be used by or marketed to children must review Families policy compliance or risk rejection.

Google has introduced a policy summary section specifically addressing the collection or use of sensitive personal or device data in ways users might not anticipate, such as background data collection. This formalizes and highlights existing consent and disclosure obligations under a named policy section. Developers whose apps collect data outside of direct user interaction should pay close attention, as this signals stricter enforcement. This is a structural and substantive addition to the policy, not merely a rewording.

Google now explicitly requires that developers provide a prominent, accessible, and descriptive disclosure inside the app — covering what data is accessed, collected, used, and shared — before requesting any permissions or obtaining user consent. This must happen proactively, not buried in a privacy policy. Apps that jump straight to permission prompts without a contextual disclosure screen will be non-compliant. Developers should audit their permission request flows to insert appropriate disclosure steps.

After providing the required prominent disclosure, developers must now collect explicit, affirmative consent from users via a clear and separate user action — passive acceptance or pre-checked boxes are not sufficient. This ensures users are making an informed, active choice before data collection begins. Developers relying on implied consent or consent bundled with other actions (e.g., agreeing to terms of service) will need to redesign their consent flows. Non-compliance could result in rejection or removal from Google Play.

Google has published the full policy text requiring prominent in-app disclosure whenever data access, collection, use, or sharing may not align with what a reasonable user would expect — including background data collection scenarios. The disclosure must occur within the app, not just in external documentation. This is the authoritative policy language developers and compliance teams should reference when evaluating their data practices. Apps with any background or non-obvious data collection must implement compliant disclosure before their next update submission.

A new policy summary section has been introduced that specifically targets apps accessing financial data, contact data, or persistent identifiers, signaling that these data categories are subject to stricter handling rules on Google Play. While the full details of these restrictions are not included in this excerpt, the creation of a named policy section indicates formal, enforceable requirements are attached. Developers building apps in fintech, communication, or any domain using advertising or device identifiers should review the full policy text for compliance obligations. This is a substantive policy addition that could affect app approval.

Google has introduced a formal requirement that child-directed apps must use SDKs that have been approved for use in apps targeting children. Previously, SDK choice may have been evaluated less prescriptively. Developers of apps in the Families program or otherwise directed at children must audit every third-party SDK they integrate and confirm it holds the appropriate approval. Using a non-approved SDK in a child-directed app is now grounds for rejection.

Google now explicitly restricts the practice of associating persistent identifiers (such as hardware IDs or IMEIs) with other user or device data to narrow legitimate use cases: telephony functions and enterprise device management. Apps outside these categories that currently link persistent identifiers to behavioral, personal, or ad-related data will need to restructure their data practices. Clear user disclosure is also required where this linking is permitted, adding a transparency obligation.

This entry restates the child SDK requirement from index 42 as an explicit action item within the Key Considerations table. The dual placement — as both a standalone rule and a table directive — reinforces that this is a hard requirement, not a recommendation. Developers must verify each SDK in a child-directed app against Google's approved SDK list before submission. Unapproved SDKs in Families-eligible apps are a clear rejection risk.

Google is adding an explicit prohibition on using unapproved SDKs in apps designed for or targeting children. This builds on existing Families Policy requirements and clarifies that third-party SDKs integrated into children's apps must be on Google's approved list. Developers with apps in children's categories must audit all integrated SDKs and remove any that are not approved, or risk rejection.

This entry reiterates and formalizes the prohibition on unapproved SDKs in children's apps as a standalone policy statement. It reinforces index 55 and makes this a clearly stated, independently enforceable rule rather than an implied restriction. Developers should treat this as a firm rejection criterion: any unapproved SDK in a children's-targeted app is a policy violation.

This is a new policy section establishing that Google Play requires complete transparency about what user data an app collects and how it is used. There was no prior formal Data Safety section requirement of this scope. All developers are now on notice that opacity around data collection is a policy violation. This sets the foundation for the more specific obligations described in subsequent policy items.

The full policy language formally states that every developer must provide a clear and accurate Data Safety section for each app, covering collection, use, and sharing of user data. This is the binding policy text (as opposed to the summary) and applies universally to all apps on Google Play. Developers with multiple apps must ensure each one has its own complete and accurate disclosure — there is no blanket or inherited exemption.

A new rule directly bans any attempt to obscure or conceal data collection and usage practices from users. While deceptive practices have generally been prohibited, this addition makes hiding data practices an explicit, named violation. Developers using obfuscation, vague language, or buried disclosures to downplay data collection should revise their approach, as this now constitutes a clear grounds for rejection or removal.

Google now mandates that any app supporting account creation must offer a clear and easily accessible mechanism for users to delete their accounts. This formalizes a requirement that many developers may not have fully implemented. Apps lacking a dedicated, user-facing deletion option risk rejection or removal from Google Play.

Apps are now explicitly prohibited from retaining user data after an account deletion request is fulfilled. Previously, data retention practices post-deletion were less clearly governed in this policy section. Developers need to ensure their backend systems and third-party services actually purge all associated user data upon deletion, not just deactivate the account.

This requirement reinforces that deleting an account must trigger the removal of all data associated with that user across the app and its services. Developers should map all data stores — including third-party integrations, analytics, and backups — to ensure complete data removal is achievable. Failure to fully delete user data upon account deletion is now a policy violation.

Google has introduced a named Account Deletion Requirement Policy, formally codifying that any app allowing users to create accounts must also provide a clear option to delete them. This is a significant policy addition that consolidates several related requirements into an explicit, enforceable standard. Apps that support account creation but lack a deletion mechanism are now at risk of rejection or removal from the Play Store.

This is a newly added policy section with no prior equivalent in the Developer Program Policy. Apps that handle personal data from users in the EEA, UK, or Switzerland must now explicitly comply with applicable privacy and data protection laws under this framework. Developers targeting these regions need to review whether their data practices meet GDPR and equivalent standards. Non-compliance is treated as a policy violation, making this directly relevant to app eligibility on Google Play.

This is the core full-policy text of the newly added EU-U.S., UK, and Swiss Data Privacy Frameworks section. It defines 'EU Personal Information' as any personal data originating from the EEA, UK, or Switzerland that Google makes available to developers, and sets binding obligations around lawful processing and consent. Developers who access such data through Google APIs or services must ensure their usage aligns with the user consent obtained and applicable laws. This is a substantive new enforceable requirement with potential rejection consequences.

This addition makes it unambiguous that non-compliance with applicable privacy laws (e.g., GDPR) is itself a violation of Google's Developer Program Policy, not merely a legal risk. Previously, privacy law compliance was a legal matter separate from Play Store policy enforcement. Now, developers can face app rejection or removal on policy grounds for legal non-compliance. This is a significant enforcement escalation for any developer handling EEA, UK, or Swiss user data.

A new requirement has been added stating that apps designed for children must use SDKs approved by Google Play. This likely ties into the Families Policy and the Play SDK console approval process. Developers of kids' apps need to audit all third-party SDKs in their app and replace any that are not on Google Play's approved list, or risk non-compliance and potential removal.

A new rule specifies that apps may only link persistent identifiers (such as device IDs) to other personal data for specific purposes: telephony functions or enterprise device management. Any such linking must also be accompanied by clear user disclosures. Developers using persistent identifiers for analytics, advertising, or other purposes outside these categories need to reassess their data practices.

Google now explicitly requires that when a user requests account deletion, apps must delete all associated user data rather than simply deactivating or freezing the account. This is a new and specific requirement that raises the bar beyond what many developers may currently implement. Developers need to ensure their backend systems are capable of fully purging user data upon request, and that this behavior is documented. Non-compliance could result in app rejection or removal.

Google now explicitly requires that when a user deletes their account, all associated data must be permanently deleted. Retaining data beyond what is legally required or previously disclosed is a violation. Developers should audit their backend data retention practices and ensure deletion requests propagate to all storage systems and third-party processors.

This requirement reinforces index 188, explicitly stating that account deletion must result in deletion of all data associated with that user. This applies to data held by the app, its backend, and potentially third-party services the app shares data with. Developers need to ensure their deletion pipeline is comprehensive and verifiable.

Google explicitly prohibits developers from selling or transferring user data unless every applicable legal and policy requirement is met. This targets data monetization and third-party sharing practices that may not have a compliant legal basis. Developers who share user data with advertisers, data brokers, analytics providers, or acquire/merge with other companies must ensure full compliance before any such transfer occurs, or risk violating this policy.

This new rule specifically calls out three categories that are now explicitly prohibited: content associated with predatory behavior, illegal themes, or bestiality. While some of these may have been covered under prior policies, naming them explicitly signals stricter enforcement. Developers distributing any user-generated or catalog content should ensure moderation systems catch and block these categories.

Google Play now limits permissible sexual content distribution to a specific app type: book or video catalog apps. Apps of other types — games, utilities, social platforms, etc. — cannot distribute sexual content under any circumstances. Developers outside the book/video catalog category who include any sexual content must remove it to avoid rejection.

Apps must not promote any services that could be interpreted as soliciting sexual acts, nor distribute or promote non-consensual sexual content. This new explicit rule targets apps that facilitate escort-type services, certain adult classified ads, or content depicting non-consensual scenarios. Developers in dating, social, or classifieds categories should review their content and service descriptions carefully.

Google has formally added a full hate speech and violence policy to its Inappropriate Content section. Apps may not promote violence or incite hatred against individuals or groups based on a broad list of characteristics including race, religion, gender identity, caste, immigration status, and more. This is a codified rejection category — apps containing such content are at direct risk of removal or rejection.

A new explicit 'Don't' rule prohibits publishing apps that incite hatred or violence against individuals or groups. While this aligns with general platform norms, its formal addition to the policy as a named violation makes it an actionable rejection criterion. Developers with user-generated content or community features should pay particular attention.

A new Violence Policy summary section has been added, stating that apps containing gratuitous violence or depictions of dangerous activities are prohibited. This formalizes violence as a distinct rejection category within the Inappropriate Content section. Developers of games, action, or extreme sports apps should review content to ensure violence is not presented gratuitously or framed as instructional for dangerous real-world acts.

A new Violent Extremism policy summary has been introduced stating that Google does not allow apps from dangerous organizations or apps whose content promotes or glorifies violent extremism. This is a newly surfaced policy section that makes the rule more discoverable and enforceable. Any app with content that could be interpreted as glorifying or promoting violent extremism is at risk of removal, even if not created by a formally designated organization.

The full policy text now explicitly states that terrorist organizations and other dangerous organizations or movements that have engaged in, prepared for, or claimed responsibility for violence against civilians are prohibited from publishing apps on Google Play for any purpose, including recruitment. This is a newly surfaced full-policy statement that formalizes a broad ban. Developers should ensure their organization or any affiliated entity cannot be classified under these categories.

A specific 'Don't' directive has been added stating that developers must not publish apps from terrorist or other dangerous organizations. This reinforces and makes more prominent the broader ban introduced in the full policy statement. Developers who build or distribute apps on behalf of third-party organizations should verify those organizations are not designated as terrorist or dangerous entities.

A new compliance requirement states that developers must ensure their app and all of its content do not belong to or promote a terrorist or dangerous organization. This extends accountability beyond the app's origin to its content, meaning even third-party or user-generated content that promotes such organizations could trigger a violation. Developers should implement content moderation policies accordingly.

Google has added an explicit ban on using apps as recruitment tools for dangerous organizations. This is a new named prohibition that goes beyond general violence policies. Developers building community, messaging, or social apps should ensure their platforms cannot be used for such recruitment, as this could constitute a rejection-level violation.

Google has introduced a formal Bullying and Harassment Policy, explicitly prohibiting apps that contain or facilitate harassment, exploitation, or bullying in any form. This is a new named policy section, not just a guideline tweak. Developers of social, messaging, gaming, or community apps need to ensure their platforms have adequate safeguards against these behaviors.

The full policy text has been added, confirming that apps containing or facilitating threats, harassment, or bullying are not allowed on Google Play. This formalizes what may have been implied before into an explicit, enforceable policy. Any app that enables direct user-to-user communication should review its moderation and reporting capabilities against this standard.

Google has introduced a formal Dangerous Products Policy that explicitly bans the sale of explosives, firearms, ammunition, and certain firearm accessories through apps on the Play Store. This is a new named policy and a clear rejection category for any app facilitating such transactions. Developers running e-commerce, marketplace, or classified-ad apps must ensure these product categories are excluded from their platforms.

This addition introduces a full policy statement explicitly prohibiting apps that facilitate the sale of explosives, firearms, ammunition, or certain firearms accessories. While similar rules have existed in spirit, this formal policy entry makes the prohibition explicit and enforceable. Any app that enables browsing, purchasing, or transacting in these categories is at risk of rejection or removal.

A new 'Don't' rule has been added stating that developers must not publish apps facilitating the sale of explosives, firearms, or ammunition. This moves what may have previously been implied policy into a concrete, listed prohibition. Apps that include any purchase flow, marketplace listing, or order facilitation for these items are now explicitly in violation and subject to removal.

A new rule explicitly requires that apps must not include instructions on converting firearms to automatic firing capabilities. This is a new, specific prohibition targeting how-to content, not just sales facilitation. Developers with any user-generated content, forums, guides, or instructional material related to firearms should audit and remove any such conversion instructions to avoid rejection.

A new 'Don't' rule prohibits apps from facilitating the sale of accessories that simulate or enable automatic fire — such as bump stocks or similar devices. This extends the firearms accessory prohibition to a specific, clearly defined subcategory. Apps in the firearms retail or accessories space must ensure no such products are listable or purchasable through their platform.

A new prohibition has been added barring apps from including instructions for creating weapons or restricted firearm accessories. This goes beyond sales facilitation to cover instructional or DIY content. Developers running content platforms, forums, or educational apps that could host such material need to implement moderation or content policies to prevent violations.

A new dedicated Marijuana Policy section has been introduced, stating that apps facilitating the sale of marijuana or its products are not allowed on Google Play regardless of whether such sales are legal in the user's jurisdiction. This is a significant policy addition for developers in cannabis-legal markets who may have assumed compliance was region-dependent. Any app with a marijuana sales or ordering feature must remove it to remain on the platform.

Building on the new Marijuana Policy, this addition specifically calls out in-app shopping cart or ordering features as a prohibited mechanism for marijuana sales. This level of specificity means even indirect facilitation — such as a cart or checkout flow that happens to include cannabis products — is a violation. Developers of delivery, retail, or dispensary apps must remove any such transactional functionality.

Google has added a formal full-policy statement making clear that apps facilitating marijuana or marijuana product sales are not allowed on the Play Store, regardless of whether such sales are legal in the user's jurisdiction. Previously this may not have been stated this explicitly in the policy text. Developers building cannabis commerce, delivery, or marketplace apps must remove sale-facilitation features or risk rejection.

A new summary section has been added covering tobacco and alcohol policy. Apps that facilitate the sale of tobacco or nicotine-containing products — including e-cigarettes, vape pens, and nicotine pouches — are prohibited. Apps that encourage illegal or inappropriate use of alcohol, tobacco, or nicotine are also banned. Developers should audit any app that touches these product categories to ensure it does not cross into facilitated sales or irresponsible promotion.

The full policy text now explicitly states that apps facilitating the sale of tobacco or any nicotine-containing products (e-cigarettes, vape pens, nicotine pouches) are not permitted, nor are apps that encourage illegal or inappropriate use of alcohol, tobacco, or nicotine. This gives the policy binding weight beyond the summary. Any app in the food, grocery, lifestyle, or health space that includes purchasing flows for these products must remove them to avoid rejection.

The full policy statement is now explicitly published, prohibiting apps that contain or promote sexual content, profanity, pornography, or any content or services intended to be sexually gratifying. This formalizes and consolidates the rules into a clearly stated policy section. Developers should note the broad scope — it covers not just content within the app but also associated services. Any app that connects users to sexually gratifying services externally could be in violation.

Google Play has added an explicit prohibition on distributing content associated with predatory behavior, illegal themes, or bestiality. While some of these topics may have been covered implicitly by prior policies, this new rule names them directly. Any app hosting or distributing user-generated or curated content must ensure none of it falls into these categories. Violations could result in immediate removal or account termination.

The full Hate Speech policy now explicitly enumerates protected characteristics including race, religion, disability, age, nationality, veteran status, sexual orientation, gender identity, caste, immigration status, and others linked to systemic discrimination. Previously, the scope of protected groups may not have been this explicitly detailed in policy text. Any app that promotes violence or incites hatred against individuals or groups on these bases is prohibited. Developers of social, news, or user-generated content apps must ensure their content moderation policies align with this expanded list.

A new Violent Extremism policy summary has been introduced, stating that apps from dangerous organizations or containing content that promotes or glorifies violent extremism are not allowed. This consolidates and surfaces an extremism-specific prohibition at the summary level. Developers of news, political, or community apps should audit their content to ensure nothing could be interpreted as promoting or glorifying violent extremist groups or acts.

The full policy text now explicitly states that terrorist organizations and dangerous organizations or movements that have engaged in, prepared for, or claimed responsibility for violence against civilians are prohibited from publishing apps on Google Play for any purpose, including recruitment. This is a formal, detailed articulation of a ban covering all use cases — not just violent content but organizational identity itself. Developers who build apps on behalf of third-party organizations should vet those organizations carefully before publishing.

A new 'Don't' rule has been added explicitly prohibiting the publication of apps from terrorist or other dangerous organizations. This reinforces the full policy statement (index 125) in a concise actionable format. Developers acting as publishers or aggregators for third-party apps should perform due diligence to confirm no affiliated organization falls into this category.

A new guideline requires that neither the app itself nor any of its content should belong to or promote a terrorist or dangerous organization. This extends the prohibition beyond just the publisher identity to encompass in-app content as well. Developers must audit both their organizational affiliations and their app's content — including user-generated content pipelines — for any material that could be construed as promoting such groups.

Google has introduced a Dangerous Products Policy Summary explicitly prohibiting the sale of explosives, firearms, ammunition, and certain firearms accessories through apps on the Play Store. Previously, such restrictions may have been addressed through broader dangerous goods policies; this now makes the prohibition explicit and named. Developers of e-commerce, marketplace, or classified-ad apps must ensure their platforms cannot be used to transact these items. Violation of this policy is grounds for rejection or removal.

Following the Dangerous Products policy summary, Google adds a direct prohibition: developers must not provide services facilitating the sale of the listed dangerous items. This reinforces that the ban covers the service layer — not just hosting listings, but any transactional or facilitation functionality. Marketplace, auction, or peer-to-peer selling app developers should audit their category restrictions and seller agreements to ensure compliance. This is an enforceable requirement that applies at the app functionality level.

This addition explicitly codifies that apps enabling the sale of explosives, firearms, ammunition, or certain firearms accessories are prohibited on Google Play. While this aligns with long-standing policy intent, the formal addition as a full policy statement makes the prohibition more explicit and enforceable. Developers running gun shops, marketplaces, or any commerce app that includes these product categories should ensure their app does not facilitate such transactions.

A clear 'Don't' rule has been added stating that apps facilitating the sale of explosives, firearms, or ammunition are not permitted on Google Play. This makes an existing policy stance more explicit and actionable as a rejection criterion. Any app—including third-party marketplaces or general e-commerce platforms—that allows these product categories to be sold must remove that functionality to remain compliant.

A new Marijuana Policy Summary section explicitly states that apps enabling the sale of marijuana or marijuana-derived products are not allowed on Google Play, regardless of whether such sales are legal in the user's jurisdiction. This removes any ambiguity that legal markets (e.g., US states or countries where cannabis is legal) might have created. Developers building dispensary apps, cannabis delivery platforms, or any app with marijuana commerce features must remove that functionality.

A specific rule has been added banning the use of in-app shopping cart or ordering mechanisms to purchase marijuana through a Google Play app. This clarifies that even if an app is primarily informational (e.g., a dispensary locator), adding transactional marijuana ordering features is prohibited. Developers must ensure no checkout, cart, or order flow within their app processes marijuana purchases.

Google has added an explicit, standalone policy stating that apps facilitating the sale of marijuana or marijuana products are not allowed on the Play Store, regardless of whether such sales are legal in a given jurisdiction. Previously this prohibition may have been implied under broader drug policies, but it is now stated outright. Developers running cannabis dispensary apps, delivery platforms, or any marketplace that includes marijuana products must remove that functionality or face removal from the store.

Google has introduced a dedicated Tobacco and Alcohol policy section with a summary card that explicitly prohibits apps facilitating the sale of tobacco or nicotine-containing products (including e-cigarettes, vape pens, and nicotine pouches) and apps that encourage illegal or inappropriate use of alcohol, tobacco, or nicotine. This formalizes and expands on rules that may not have been this clearly delineated before. Developers of any app touching nicotine product sales or substance-related content should review this new section immediately.

The full policy text formally prohibits apps that facilitate the sale of tobacco or nicotine-containing products (e-cigarettes, vape pens, nicotine pouches) or that encourage illegal or inappropriate use of alcohol, tobacco, or nicotine. This is the authoritative policy statement backing the summary in index 151. Developers of grocery, delivery, or lifestyle apps that include any nicotine or tobacco sales functionality need to assess whether their app violates this rule.

As part of the new Key Considerations guidance, Google has added an explicit 'Don't' rule prohibiting apps from facilitating the sale of tobacco, e-cigarettes, or nicotine pouches. This reinforces the full policy statement and makes clear that dedicated nicotine/tobacco sales flows are not permissible. Apps offering vape shops, tobacco delivery, or nicotine product marketplaces will be in violation and risk removal.

Google has announced that the updated Families Policies article will take effect on August 26, 2026, and a preview of the updated content is available via a linked page. This gives developers advance notice to review the forthcoming changes and adjust their apps before the enforcement date. Developers with child-directed or mixed-audience apps should review the preview immediately to identify any required changes.

Apps targeting a mixed audience (both children and adults) are now explicitly required in the summary to implement a neutral age screen—one that does not nudge users toward any age group—ensuring that child users are served only non-personalized ads. Previously this requirement existed in the full policy but is now prominently surfaced. Developers of mixed-audience apps without a compliant age screen should implement one before the August 2026 effective date.

Google has introduced a structured Do/Don't summary section to the Families Policies page. One of the explicit 'Do' items requires adhering to children's data laws such as COPPA and GDPR-K. This makes compliance with these regulations an explicit, documented expectation on the policy page, meaning failure to comply is more directly tied to potential app rejection.

Google has added a clear prohibition against serving personalized or interest-based ads to children in the Families Policies Do/Don't guidance. Previously this may have been implied through broader ad policy rules, but it is now a stated 'Don't' in the Families section. Developers whose apps target children or have a mixed audience must ensure their ad implementations do not serve personalized ads to child users.

A new requirement has been added stating that apps serving ads to children must use ad SDKs that are certified under Google's Families Ads program. If your app targets children or a mixed audience and serves ads, any ad SDK you use must appear on Google's approved list. Using uncertified ad SDKs in child-directed apps is grounds for removal from Google Play.

Google has added an explicit prohibition on collecting persistent device identifiers — including the Advertising ID (AAID) and IMEI — from child users. This applies to apps that target children or are aware they are serving children. Developers must audit their SDKs and data collection flows to ensure no persistent identifiers are gathered from child users, as violations could result in app removal.

Apps that target both children and adults are now explicitly required to implement a neutral age gate or age screen to differentiate users before serving content or ads. The screen must not nudge users toward a particular age selection. This is a behavioral and UX requirement that developers of mixed-audience apps must implement to remain compliant.

Google has added a 'Don't' item prohibiting the use of any SDK that has not been approved or certified for use in child-directed apps. This reinforces and expands on the certified ad SDK requirement to cover all SDKs, not just advertising ones. Developers must vet every third-party SDK integrated into apps that target children or mixed audiences against Google's approved list.

Google has added an explicit content prohibition to the Families Policies Do/Don't guidance, banning adult themes, excessive violence, and other age-inappropriate content from apps targeting children. While content restrictions have existed in broader Play policies, this addition makes inappropriate content a named violation within the Families Policy specifically. Developers should review all content — including ads, user-generated content, and linked materials — for age-appropriateness.

Google has added an explicit requirement for developers to accurately declare their app's target age group when submitting or updating an app in Play Console. Misrepresenting the intended audience — for example, claiming an adult audience to avoid Families Policy requirements — is now a stated violation. Developers should ensure their Play Console age group declaration truthfully reflects who the app is designed for.

Google has added a new Key Considerations table for child-directed apps, with the first item explicitly requiring adherence to laws like COPPA and GDPR regarding children's data. Previously, this compliance expectation may have been implied but is now surfaced as a direct, named obligation. Developers with apps that target or include children must ensure their data practices are fully compliant with these regulations or risk rejection.

A new 'Don't' rule has been added stating that personalized ads must not be served to children. This codifies a restriction that developers may have previously navigated less formally. Any app targeting children — or with a mixed audience that includes children — must ensure its ad configurations disable personalization for child users, or face potential rejection.

New guidance explicitly requires that apps serving ads to children use only certified ad SDKs. This is a concrete technical requirement, not just a policy principle. Developers must audit their ad SDK integrations and replace any non-certified SDKs to remain compliant — failure to do so could result in app rejection.

New guidance specifically calls out that persistent identifiers such as AAID and IMEI must not be collected from child users. This makes concrete what was previously a broader privacy principle by naming specific identifier types. Developers must review their data collection logic to ensure these identifiers are not gathered when children are or may be using the app.

Apps that target both children and adults are now explicitly required to implement a neutral age screen — one that does not encourage users to select a particular age. This is a new implementation requirement for mixed-audience apps. Developers must add or update their age-gate UI to be neutral and non-directed, or risk non-compliance.

New guidance adds a clear 'Don't' rule prohibiting the use of SDKs that are not certified for child-directed services. This reinforces the certified SDK requirement from a different angle by framing uncertified SDK use as an explicit violation. Developers building child-directed apps must verify every third-party SDK in their stack is certified for this context.

New guidance explicitly prohibits including adult themes, excessive violence, or other inappropriate content in apps directed at children. While content policies have existed, this addition places the prohibition directly within the children's Key Considerations checklist, making it a more prominent and enforceable rule. Developers must review all content — including ads, user-generated content, and linked media — for compliance.

New guidance requires developers to accurately declare their app's target age group in Play Console. Misrepresenting the intended audience — whether to avoid child-directed restrictions or for any other reason — is now explicitly called out as a violation. Developers should review their current age group declarations and ensure they genuinely reflect the app's intended user base.

Google Play has published a new section enumerating concrete examples of Device and Network Abuse violations, where no such explicit list existed before. Prohibited behaviors called out include ad-blocking apps that interfere with other apps' ads, game-cheating tools, hacking or security-bypass instructions, API/service usage that violates that service's terms, unapproved bypasses of system power management, and proxy services offered to third parties without meeting specific conditions. Developers should audit their apps and any bundled SDKs against these examples, as matching behaviors are grounds for rejection or removal.

Google has removed the explicit enumeration of what constitutes personal and sensitive user data (including PII, location, health data, Health Connect data, microphone, camera, etc.) from the Developer Program Policy. Previously, this definition served as the foundational reference for all downstream privacy requirements. Developers should check whether this definition has moved to a different section or document, as it directly affects how you scope your data handling obligations and Data Safety disclosures.

The explicit rule requiring an in-app prominent disclosure when your app accesses, collects, uses, or shares personal data in ways users wouldn't reasonably expect — such as background data collection — has been removed from this section. This requirement was a key rejection trigger for apps that collect data silently. Developers should verify whether this rule has been relocated elsewhere in Google's policies, as its removal here does not necessarily mean the obligation is gone.

The explicit mandate that all developers must complete an accurate Data Safety section in Play Console — covering data collection, use, and sharing — has been removed from this area of the Developer Program Policy. This was a high-visibility requirement tied directly to app store listings and user trust. Developers should confirm whether this obligation persists in another part of Google's policies before assuming it no longer applies.

The section detailing obligations for developers who access or process personal data originating from the EEA, UK, or Switzerland under the EU-U.S., UK, and Swiss Data Privacy Frameworks has been removed. This covered compliance with applicable privacy laws and restrictions on how EU personal information could be used. Developers handling EU/UK/Swiss user data should verify whether these obligations have been relocated or superseded by updated guidance.

A new 'Full Policy' definition of personal and sensitive user data has been added, providing a broader and more explicit list of data types covered. Notably, it now calls out Health Connect data, inventory of other apps on the device, and other sensitive device or usage data alongside previously understood categories. Developers should review this expanded definition to ensure their data collection, handling, and disclosure practices cover all newly enumerated data types.

A new 'Key Considerations' section with Do/Don't guidance has been added, explicitly stating that developers must have a valid privacy policy in both the app's Play Store listing and within the app itself. Previously this requirement may have existed elsewhere but was not surfaced in this format. Developers who only link a privacy policy in their store listing — but not inside the app — may need to update their apps to comply.

A new 'Don't' rule has been added explicitly prohibiting developers from providing misleading or inaccurate information about their data practices. This reinforces and formalizes the expectation that privacy disclosures — including the Data Safety section and privacy policy — must accurately reflect what the app actually does. Developers with inaccurate or outdated data disclosures risk policy violations and potential rejection or removal.

Previously, the Data Safety section in Play Console was introduced as a feature but requirements around it were less prescriptive in policy text. This addition makes it an explicit policy obligation to accurately disclose what data your app collects and shares. Developers who have incomplete or inaccurate Data Safety declarations now face a clearer policy violation risk. Audit your Data Safety form to ensure it fully reflects your app's actual data handling.

There was no previously stated blanket rule in this section prohibiting excess data collection by name. This new rule requires that every data point your app collects must be directly tied to its core functionality. Developers who collect broad or speculative data for future use cases or analytics beyond core purpose may now be in violation. Review your data collection scope and trim anything that cannot be justified as essential to what your app does.

This addition codifies that passive or implied consent is insufficient — users must actively and clearly agree before any personal or sensitive data is collected. Apps that rely on pre-ticked boxes, buried consent in terms of service, or no consent mechanism at all are now explicitly non-compliant. This is particularly important for apps that collect location, contacts, health, financial, or device identifiers. Developers should implement prominent, plain-language consent prompts tied directly to each data type collected.

This new rule requires developers to protect all user data with suitable security practices, with modern encryption for data in transit called out specifically. Apps that transmit user data over unencrypted or outdated protocols (e.g., plain HTTP, weak TLS versions) are now explicitly non-compliant at the policy level. This applies to any data exchanged between the app and backend servers, third-party APIs, or SDKs. Developers should audit all network communication and ensure TLS is implemented correctly and kept up to date.

This rule introduces a data minimization principle, stating that apps may only collect and use data that is genuinely necessary for the app to function. This complements index 21 (no non-critical data collection) and together they form a clear data minimization framework. Developers must be able to justify each data type collected as directly required for a specific feature. Apps with broad permissions or data collection practices driven by SDKs rather than core app needs are at particular risk.

This new rule bans both collecting data without consent and using dark patterns or manipulation to obtain consent. It closes a loophole where technically a consent dialog exists but is designed to deceive users into agreeing. This includes deceptive UI patterns, misleading language, false urgency, or making app functionality contingent on consenting to non-essential data collection. Developers should review all consent flows for fairness, clarity, and genuine user choice.

Google now explicitly requires that your app's privacy policy (or relevant data disclosure) be available in two places: within the app itself and on an external web resource. Previously, an external link alone may have been considered sufficient. Developers must ensure both access points are present and functional to avoid rejection.

Google now explicitly requires that apps offer a straightforward mechanism for users to delete both their account and their data. This goes beyond simply closing or deactivating an account — the deletion process must be clear and user-friendly. Developers who support account creation must audit their flows to ensure full deletion capability is present, or risk rejection.

Google has added a direct clarification that freezing or suspending an account does not satisfy the account deletion requirement. Previously, some developers may have implemented account deactivation as a workaround. Apps must now provide true deletion of account and user data, not just a disabled state, to comply with policy.

Google has introduced a formal policy summary section covering prominent disclosure and consent requirements for sensitive personal or device data. It specifically calls out scenarios where data collection may be unexpected by users, such as background data collection. Developers handling any sensitive data — especially outside of direct user interaction — need to review whether their disclosure practices meet the new documented standard.

Google now requires that developers provide a prominent, accessible, and descriptive in-app disclosure explaining what data is accessed, collected, used, and shared — and this must happen before any permission request or consent prompt is shown. This is a sequencing requirement: disclosure must precede the consent action. Apps that request permissions without prior contextual explanation are at risk of non-compliance.

After providing the required in-app disclosure, developers must obtain user consent through a clear and distinct affirmative action — passive acceptance or pre-checked boxes are not sufficient. This formalizes a two-step process: disclose first, then obtain active consent. Apps that rely on implied consent or bundle consent into general terms acceptance will need to update their flows.

Google has added an explicit prohibition on publicly exposing financial information or government ID numbers (e.g., SSNs, tax IDs, bank account numbers). Previously this may have been covered implicitly under general privacy rules, but it is now a standalone stated requirement. Developers handling any such data must ensure it is never surfaced publicly — failure to comply could result in app rejection or removal.

Google has added an explicit rule prohibiting the unauthorized publication of users' private contact information. This formalizes a restriction that may have previously been implied under broader privacy policies. Developers building apps that access contacts must ensure they have proper authorization before sharing or publishing any contact data, and should audit their data handling flows accordingly.

This entry adds a clear, actionable Do/Don't rule explicitly prohibiting the public disclosure of financial information or government ID numbers, reinforcing the standalone rule added at index 40. Having it appear in a Do/Don't table increases its visibility and enforceability during app review. Developers should treat this as a hard rejection criterion and ensure no such data is ever exposed publicly by their app.

This entry reinforces the child-directed SDK requirement introduced at index 42, now presented as an actionable directive within the policy's structured guidance section. The duplication in different policy formats (standalone rule and Do/Don't table) emphasizes that Google considers this a firm enforcement point. Developers of apps in the Families program or otherwise targeting children must verify SDK approval status before submission.

Google has added a broad rule prohibiting the public disclosure of sensitive data, serving as a general catch-all that complements the more specific rules about financial IDs and contact information added elsewhere. This broader framing means developers need to consider any category of sensitive data — not just the explicitly named types — when evaluating their app's data exposure risks. Apps that surface any sensitive user data publicly should be reviewed for compliance.

A new rule has been added stating that apps must not make users' financial data or government-issued IDs public. Previously there was no explicit standalone prohibition on this specific data exposure. Apps that display, store, or transmit such sensitive data must ensure it is never exposed publicly. Developers should audit any feature that surfaces user-submitted financial or identity documents.

Google has added a new requirement targeting apps with security or anti-virus functionality, mandating explicit disclosure of data use. This is a headline-level addition that precedes more detailed guidance in the following policy item. Developers shipping security-oriented apps should review their privacy policies to ensure data collection and sharing practices are clearly explained. Failure to comply could result in rejection or removal.

Apps that include anti-virus, anti-malware, or other security features are now required to have a privacy policy that clearly and comprehensively describes every type of data collected and every party data is shared with. There was no prior explicit standalone rule singling out security apps for this level of disclosure detail. This matters because vague or generic privacy policies will no longer be acceptable for this app category. Developers should update privacy policies to enumerate specific data types and third-party recipients.

A new policy explicitly forbids apps from exposing or distributing contact information that users have not made public, unless the user has authorized it. This closes a gap where apps accessing the contacts permission might share that data without a clear prohibition. Developers building social, messaging, or productivity apps that read contacts must ensure they have explicit user authorization before sharing any contact data externally. Unauthorized sharing of contacts could now be a direct grounds for rejection.

Google has added a rule limiting the pairing of persistent hardware identifiers like IMEI with other user data to narrowly defined purposes: telephony functions and enterprise device management. Previously, restrictions on persistent identifiers focused mainly on advertising use; this broadens the restriction to general data linking. Developers who combine IMEI or similar identifiers with behavioral, demographic, or analytics data outside these permitted scopes will be in violation. Apps should be audited to ensure persistent identifiers are isolated unless a qualifying use case applies.

Google has introduced a new rule requiring apps to disclose when they use persistent identifiers such as IMEI, serial numbers, or similar hardware IDs. This is a headline-level addition introducing a disclosure obligation that did not previously exist as a standalone rule. Developers using any persistent device identifier must now inform users of this practice, likely through the privacy policy and/or in-app disclosure. This is especially relevant for enterprise, telephony, and device management apps.

Building on the headline rule at index 57, this detailed addition specifies that disclosure of persistent identifier use must be prominent—not buried in a privacy policy. Developers cannot rely on a general data collection statement; the use of persistent identifiers must be surfaced clearly to users. This affects any app that reads IMEI, device serial numbers, or similar persistent hardware IDs for legitimate purposes like enterprise management. Update both in-app disclosures and privacy policies to satisfy this requirement.

A new rule prohibits unnecessarily linking persistent device identifiers to other user or behavioral data, reinforcing the principle of data minimization. This complements the restriction at index 54 by adding a general-purpose 'necessity' test: if there is no clear, permitted reason to associate a persistent identifier with other data, it must not be done. Developers should review data pipelines to ensure persistent identifiers are not passively joined to user profiles, analytics events, or other data stores without justification. This could require architectural changes in apps with centralized user data stores.

A new rule explicitly prohibits associating persistent identifiers (such as advertising IDs or device IDs) with other user data unless the use case falls within two specifically approved exceptions. Previously, this restriction was less explicitly stated. Developers using persistent identifiers for analytics, personalization, or targeting should audit their data practices immediately. Non-compliance could result in app rejection or removal.

The policy now explicitly requires every app to have a completed and up-to-date Data Safety section in the Play Console, covering not just the app's own data practices but also those of any third-party SDKs integrated into the app. This is a significant expansion of accountability — developers are now responsible for auditing their SDKs for data collection behavior. Apps with inaccurate or incomplete sections risk policy violations.

The new policy requires that the information declared in the Play Console Data Safety section must match what is disclosed in the app's privacy policy. If there are discrepancies between the two, the app could be flagged for a violation. Developers should review both documents together to ensure alignment. This adds a cross-document consistency requirement that didn't previously exist as explicit policy.

The full policy text now formally mandates that every app in the Play Store — without exception — must have a clear and accurate Data Safety section covering collection, use, and sharing of user data. This applies to all developers, including those with apps that collect minimal data. Even declaring that no data is collected is a required action. This is a universal compliance requirement.

Where applicable, the Data Safety section must be consistent with the app's privacy policy disclosures. This reinforces index 63 at the full-policy level, making cross-document consistency an enforceable requirement rather than a recommendation. Developers with long-standing privacy policies should re-evaluate them against the new Data Safety form fields. Mismatches may be treated as a violation.

There was no explicit policy mandating that data disclosures be both prominent and accessible inside the app itself. Developers must now surface data disclosures clearly within the app UI and, where consent is required, obtain it through an affirmative user action rather than passive acceptance. This directly affects any app that collects, shares, or processes user data — which is most apps — and non-compliance could trigger rejection.

Google has added an explicit definition clarifying that affirmative consent requires the user to take a deliberate action — such as tapping an 'Accept' button — rather than passively encountering a notice. Pre-checked boxes, implied consent, or simply displaying a disclosure no longer qualify where affirmative consent is required. Developers need to audit their consent flows to ensure they meet this definition.

Google has added an explicit rule prohibiting permission requests that appear before the user has consented to the app's data practices. Previously, the timing of permission prompts was largely a UX recommendation. Now it is a policy requirement, meaning apps that show runtime permission dialogs before presenting a consent flow may be non-compliant and subject to rejection.

Google has codified that app developers are responsible for auditing the data practices of every third-party SDK included in their app. This was previously implied but not an explicit policy obligation. Developers can no longer treat SDK data behavior as a black box — they must understand and be able to accurately disclose what each SDK collects and shares, or risk policy violations tied to third-party code.

Google has added a specific prohibition against consent dialogs that close automatically without user interaction in contexts where affirmative consent is required. Any popup that times out and dismisses itself — even if it records implied consent — violates this new rule. Developers using auto-dismiss patterns in consent or data disclosure flows must replace them with dialogs that require an explicit user action to proceed.

Google now explicitly requires that privacy policies cover all types of user and device data across the full data lifecycle: access, collection, use, and sharing. Partial or vague disclosures no longer satisfy the requirement. Developers should review their privacy policies to ensure every data type their app or its SDKs touches is accurately and completely described, as gaps could result in rejection or removal.

Previously, there was no explicit Play policy mandate requiring an in-app account deletion mechanism. Apps that allow users to create accounts must now offer a clear and accessible method for users to delete those accounts. This is a direct requirement that affects any app with user registration or account functionality, and missing it could lead to rejection or removal.

This new rule clarifies that when a user requests account deletion, developers must fully delete all associated user data rather than simply deactivating or freezing the account. Apps that retain data after a deletion request — even in a suspended state — will be non-compliant. Developers should audit their backend data pipelines to ensure a true deletion flow is implemented end-to-end.

Google now explicitly requires every app to include a privacy policy link in the designated Play Console field and either a link or the full privacy policy text inside the app. This applies to all apps, not just those collecting sensitive data. Developers who have not yet added an in-app privacy policy link are at risk of rejection or removal.

Google now explicitly requires that your app's privacy policy fully and accurately discloses every way user data is accessed, collected, used, and shared. Previously, general privacy policy guidance existed but this specificity is newly codified. Apps with vague or incomplete data disclosures risk policy violations. Developers should audit their privacy policies to ensure every data practice is clearly described.

Google explicitly prohibits offering account freezing or deactivation as a substitute for true account deletion. If your app allows users to 'deactivate' or 'suspend' an account, that option cannot be presented as the equivalent of deleting it. Users must have a distinct, genuine path to permanently delete their account. Apps that conflate these options will be out of compliance.

Google now explicitly bans any UX patterns that make account deletion unnecessarily difficult, such as burying the option in menus, requiring excessive confirmations, or adding friction steps. The previous guidance focused on providing a deletion option; this addition targets deliberate obfuscation of that path. Developers should review their account deletion flow for any dark patterns or confusing navigation. Non-compliance is a direct rejection risk.

Google now explicitly requires that the Data Safety section in the Play Console be completed accurately and maintained over time as app data practices change. Previously, filling out the Data Safety form was required at submission, but the ongoing maintenance obligation is now codified as a policy rule. Developers who update their app's data practices without updating the Data Safety section will be in violation. Regular audits of this section are now a compliance necessity.

Google now requires that your app's privacy policy URL be accessible globally — it must not be geo-restricted or blocked in any region where the app is available. This is a new explicit requirement beyond simply having a privacy policy link. Developers hosting privacy policies on region-locked domains or behind access controls risk non-compliance. Ensure your policy URL resolves correctly from all countries where your app is distributed.

Google now explicitly requires that account deletion functionality be accessible in two places: directly within the app itself and through a designated external web resource (e.g., a webpage). Previously, in-app deletion alone may have been considered sufficient. Developers must audit their deletion flows to ensure both surfaces are covered, or risk non-compliance.

Google now explicitly states that when a user requests account deletion, all associated user data must be permanently deleted. Simply freezing, suspending, or deactivating the account does not satisfy this requirement. Developers who currently offer only account deactivation must update their systems to perform full data deletion, and should review any backend data retention pipelines accordingly.

Google now requires that the account deletion process be straightforward, with no dark patterns or unnecessary friction. Additionally, if any user data must be retained after deletion (e.g., for legal or financial compliance), developers must clearly disclose this in their privacy policy. Developers should review their deletion UX for confusing steps or discouraging patterns, and update privacy policies to reflect any lawful retention practices.

Google's policy now explicitly requires that if your app allows users to create an account from within the app, it must also allow users to request deletion of that account from within the app. This is a symmetry requirement — creation and deletion pathways must both exist in-app. Developers who only handle account deletion via external support channels or email requests will need to add an in-app deletion flow.

This addition reinforces that account deletion is not just about removing login credentials — all user data tied to that account must also be deleted. Developers cannot retain profile data, usage history, or other personal data after an account is deleted at the user's request. This has implications for database design, third-party data processors, and any analytics or marketing platforms that receive user data.

Google now explicitly lists it as a violation to fail to provide both an in-app deletion option and an external web-based deletion method. This 'Don't' rule makes it a clear policy breach to offer only one of the two required deletion surfaces. Developers must ensure both pathways exist and are functional before submitting or updating their app.

In addition to in-app deletion, Google now explicitly requires developers to provide an external web resource — such as a webpage or web form — where users can request account deletion. This is particularly important for users who may have lost access to the app itself. Developers should create and link to a publicly accessible deletion request page and reference it appropriately in their store listing.

Google now explicitly prohibits hidden patterns (dark patterns) and undue rigor in the account deletion process. This means developers cannot use tactics like repeated confirmation dialogs, guilt-tripping language, excessive re-authentication, or multi-step barriers designed to discourage deletion. Developers should audit their deletion UX against these criteria to avoid policy violations.

Previously, apps could suspend or freeze accounts instead of fully deleting them when users requested deletion. Google now explicitly prohibits using account freezing as a substitute for actual account deletion. Developers who offer a 'freeze' or 'deactivate' state must ensure it does not replace a true deletion flow. Apps that route deletion requests into a frozen-account state risk policy violations and potential rejection.

Google has added an explicit requirement that apps must delete all data associated with a user's account upon their request. This goes beyond simply removing login credentials — all stored user data tied to the account must be purged. Developers need to audit their data deletion pipelines to ensure nothing is retained without a disclosed legal basis. Failure to fully delete account data is now a policy violation.

This new rule reinforces that partial deletion of user data when an account is deleted is not acceptable under Google Play policy. Where index 111 states the affirmative obligation, this rule frames the same requirement as a prohibition, making it a clear enforcement target. Developers must ensure that all backend systems, third-party SDKs, and data stores associated with a user account are included in the deletion flow. Incomplete deletion pipelines could lead to app removal.

Complementing the requirement in index 113, Google now explicitly prohibits privacy policies that leave out necessary data retention disclosures. If your app retains any user data after deletion for legal or operational reasons, omitting that information from your privacy policy is a direct violation. Developers should review their privacy policies to confirm that any post-deletion data retention is documented clearly and accurately. This omission could be treated as a deceptive privacy practice.

App Set ID must not be used for ads personalization or ads measurement, and it must not be associated with personally identifiable information or other device identifiers such as the Android Advertising ID (AAID). This is a new explicit prohibition that closes off potential misuse of App Set ID as an advertising tracking workaround. Developers who pass App Set ID to ad networks, measurement SDKs, or any system that joins it with user-level identifiers are now in violation. Immediate review of any third-party SDK integrations involving App Set ID is recommended.

Android is rolling out a new identifier called the App Set ID, designed to support essential non-advertising use cases such as analytics and fraud prevention. Previously, no dedicated policy-governed ID existed for these purposes under this framework. Developers using other identifiers for analytics or fraud detection should evaluate migrating to or incorporating the App Set ID. This is a significant structural addition to how Google manages device identifiers.

The policy now explicitly states that developers must obtain legally valid user consent before collecting or using the App Set ID where consent is required by law. This aligns with existing privacy regulations such as GDPR and CCPA. Developers operating in regulated jurisdictions must ensure their consent flows are adequate before implementing App Set ID. Failing to obtain proper consent where required could result in policy violations.

The policy introduces explicit 'Do/Don't' guidance stating that the App Set ID may be used for essential functions such as analytics and fraud prevention. This sets a clear boundary for acceptable use cases. Developers must ensure any implementation of the App Set ID stays within these permitted categories. Using it outside these bounds — particularly for advertising — is prohibited per accompanying policy changes.

Developers must now disclose their collection and use of the App Set ID in both a legally adequate in-app privacy notification and their app's privacy policy. This extends existing privacy disclosure obligations to cover this new identifier. Developers who implement the App Set ID without updating their privacy documentation will be non-compliant. Privacy policies should be reviewed and updated before shipping any App Set ID integration.

This entry reinforces and elaborates on the consent requirement introduced in index 122, making explicit that consent must be obtained prior to both collecting and using the App Set ID in jurisdictions where it is legally required. Developers should build consent gate logic before any App Set ID collection begins, not after. This requirement applies at the point of data collection, so runtime consent prompts must precede API calls. Non-compliance in applicable regions could trigger policy enforcement.

Developers are explicitly prohibited from omitting App Set ID usage from their privacy policy. This complements the broader disclosure requirement in index 125 by calling out omission as a specific violation. Even apps that consider their use of the App Set ID minor or incidental must document it. Developers should audit their privacy policies to ensure this identifier is mentioned wherever it is used.

As part of the new Data Privacy Frameworks policy, developers must obtain explicit user consent before processing personal data from EEA, UK, or Swiss users. Data must also be actively protected against misuse. This directly affects how apps design consent flows and data handling practices for European audiences.

The new policy introduces an ongoing self-monitoring obligation for developers handling EU personal data. Critically, if a developer determines they cannot meet the policy's requirements, they must notify Google immediately rather than waiting for enforcement action. This creates an active compliance duty beyond simply following the rules at launch.

Google has added a structured Do/Don't reference table as part of the new Data Privacy Frameworks policy. The 'Do' column explicitly calls out adherence to laws such as GDPR. This makes compliance with applicable privacy law a named, enforceable policy requirement rather than just an implied obligation.

The Do/Don't guidance reinforces that personal data from EU/UK/Swiss users may only be accessed and used for purposes the user has consented to. This is a named 'Do' requirement, meaning any data use beyond consented purposes is a policy violation. Developers should audit their data pipelines to ensure they align with stated consent purposes.

The new policy requires developers to put in place both technical controls (e.g., encryption, access controls) and organizational measures (e.g., data handling procedures, staff training) to secure EU personal data. This aligns with GDPR Article 32 obligations and means security practices are now a Play policy requirement, not just a legal one. Apps lacking adequate security for European user data are at risk of policy enforcement.

Google has explicitly added a prohibition against insecurely handling personal data. Previously, secure data handling was implied through broader privacy policies, but this makes it an explicit named violation. Developers must ensure their data storage, transmission, and processing practices are secure. Failing to do so is now a clearly stated policy breach that could trigger enforcement action.

A new requirement has been added mandating that developers who cannot meet Google's data handling conditions must immediately contact data-protection-office@google.com and take corrective action. This formalizes an incident-response obligation that did not previously exist in explicit policy text. Developers should have a process in place to identify compliance gaps and report them promptly, as failing to notify Google is itself a violation.

Google has added a standalone prohibition against failing to notify them when a developer cannot comply with data conditions. This reinforces index 141 by making non-notification itself a named offense rather than just an implied duty. Developers should treat this as a mandatory reporting obligation and build internal workflows to detect and escalate compliance failures quickly.

Google has added an explicit ban on selling or transferring user data unless all legal and policy requirements are satisfied. While data sale restrictions have existed in broader privacy policy, this makes it a named, standalone prohibition. Developers who share user data with third parties, monetize data, or transfer data in acquisitions or partnerships must ensure full compliance before doing so or risk policy violation.

Previously, disclosure requirements were less explicitly structured. Apps must now show a prominent, accessible, and descriptive in-app notice detailing exactly what data is accessed, collected, used, and shared — and this must happen before any permission prompt or consent request is triggered. This affects any app that requests permissions or collects user data, and failure to include this disclosure upfront could lead to rejection.

Following the required disclosure, apps must now obtain consent through a clear and separate affirmative user action — passive acceptance or bundled consent is not sufficient. This ensures users are making an informed, deliberate choice. Developers should audit their consent flows to ensure consent is never assumed or implied, and that it follows, rather than accompanies, the disclosure step.

A new explicit rule states that apps must never publicly expose financial or government ID numbers. While this likely reflects existing intent within broader data protection rules, codifying it as a standalone requirement increases the risk of rejection for apps that surface such data in shared or publicly accessible contexts. Developers handling payment, banking, or identity data should audit how this information is displayed or transmitted.

Google has added an explicit prohibition against publishing users' private contacts without authorization. Apps that access the Contacts API or aggregate contact data must ensure they have proper authorization and are not exposing that data publicly or to unauthorized parties. This formalizes a restriction that developers should already be following, but now carries clearer policy grounds for rejection.

Previously, this specific prohibition was not explicitly called out in this section. Apps must not publicly expose financial data (e.g., bank account numbers, credit card details) or government-issued ID numbers (e.g., SSNs, passport numbers). This matters if your app handles any such data — even incidental exposure in logs, APIs, or UI could trigger a violation.

This is a newly added requirement targeting apps that are directed at children. Any third-party SDK integrated into a child-directed app must be approved for that purpose — unapproved SDKs are not permitted. Developers should audit all SDKs in children's apps and confirm each one is certified or approved for child-directed use to avoid rejection.

This newly added rule is a broad prohibition on making sensitive personal data publicly accessible. While some specific cases (financial data, government IDs, contacts) are covered by other rules in this section, this catch-all clause extends the restriction to any sensitive data category. Developers should review any feature that surfaces user data externally to ensure nothing sensitive is exposed.

This addition reinforces and restates the prohibition on publicly exposing financial information and government identification numbers. It appears to serve as a summary-level restatement of index 160 within the same section. Developers handling sensitive financial or identity data must ensure this information is never surfaced in public-facing endpoints, logs, or interfaces.

Apps that offer anti-virus, anti-malware, or other security features are now required to have a privacy policy that comprehensively describes all data collection and sharing practices. This is a more detailed elaboration of the rule at index 164. If your app has any security feature — even as a secondary function — your privacy policy must be thorough and explicit, or the app may be rejected.

This new rule prohibits apps from exposing or sharing contact data that is not already public, unless the user has explicitly authorized it. Developers who build apps accessing the contacts API — such as messaging, CRM, or social apps — must ensure they have clear user consent before sharing any contact information externally or making it discoverable.

Apps may only associate persistent hardware identifiers like IMEI with other user data for narrowly defined purposes: telephony functions or enterprise device management. Previously, this restriction may not have been so explicitly scoped. Developers using device identifiers for analytics, advertising, or other purposes outside these categories need to reassess their data practices to avoid policy violations.

This rule reiterates the prohibition (also stated at index 161) on using unapproved SDKs in apps targeting children. The repeated emphasis signals that Google considers this a significant enforcement area. Developers of children's apps should immediately audit all integrated SDKs and remove or replace any that lack explicit child-directed approval.

This is another restatement of the child-directed SDK restriction (see indexes 161 and 168), further underscoring Google's firm stance on this requirement. Any SDK without approval for child-directed use is prohibited in apps targeting children. Developers should treat this as a potential rejection trigger and proactively verify SDK compliance before submission.

A new rule explicitly requires apps to disclose their use of persistent identifiers. Previously, this requirement was not called out as a standalone obligation in this section. Apps must now make this disclosure prominent, meaning burying it in a long privacy policy may not be sufficient. Developers should audit any use of persistent identifiers and ensure disclosures are clearly surfaced to users.

This new rule clarifies and strengthens the disclosure requirement: all permitted uses of persistent identifiers must be prominently disclosed to users, not just mentioned somewhere in app documentation. This is a meaningful escalation from a general privacy expectation to a specific, enforceable standard. Developers should review how and where they communicate identifier use and ensure it is visible and clear, not hidden in fine print.

A new standalone rule explicitly prohibits linking persistent identifiers to other user data without justification. This signals Google is tightening restrictions on identifier-based data correlation practices. Developers who aggregate or join persistent identifiers with behavioral, demographic, or other user data need to ensure they fall within the approved use cases or risk policy violations.

This new rule specifies that persistent identifiers may only be linked to other user data in two approved use cases defined by Google. Previously, this restriction was not explicitly stated in this form. Developers who link device or advertising identifiers to user profiles, analytics data, or third-party data must verify their use case is among those approved or refactor their data practices to comply.

A new requirement mandates that any app offering account creation must provide users with a clear and accessible way to delete their account. This was not previously stated explicitly in this section. Developers who offer user accounts need to implement and surface an account deletion flow that is easy for users to find and use, or risk non-compliance.

Previously, privacy policy requirements were more general. Google now explicitly prohibits omitting any user or device data handling from your privacy policy. Developers must audit their policy to ensure every category of data their app touches — including device identifiers, sensors, and background data — is documented. Incomplete disclosures risk rejection or removal.

Google has added an explicit requirement that your privacy policy be reachable from inside the app, not just from the Play Store listing or an external website. Apps that only link to a privacy policy on their store listing or require users to leave the app to find it may no longer comply. Developers should add an in-app link (e.g., in Settings or an About screen) to their privacy policy.

Google has added a rule explicitly prohibiting privacy policies that lack required app or company identification. Your privacy policy must clearly name the app and the developer or company responsible for it. This ensures users can identify whose policy they are reading and who is accountable for data handling. Missing this information is now a direct compliance failure.

Google now explicitly requires that privacy policies accurately reflect every dimension of data handling: what data is accessed, collected, how it is used, and with whom it is shared. Vague, incomplete, or misleading disclosures are prohibited. Developers should cross-check their policy against actual app behavior, including third-party SDKs, to ensure full accuracy. Discrepancies can lead to app removal.

Google has added an explicit prohibition against presenting account freezing, suspension, or deactivation as an equivalent to account deletion. Previously, some apps offered a 'freeze' option in place of true deletion. Users must be given a genuine deletion path that removes their account and data, not just a dormant-account state. Apps that only offer account freezing as their 'deletion' option will need to implement a real deletion flow.

Google now explicitly prohibits designing the account deletion flow in a way that is confusing, buried, or artificially difficult — sometimes called 'dark patterns.' Previously, the focus was on offering deletion; now the ease and clarity of the process is also enforceable. Developers should review their deletion UX to ensure it is straightforward, easy to find, and free of unnecessary confirmation loops or hidden steps.

Google has added a positive requirement that apps provide a clear and accessible account deletion mechanism, not just avoid blocking deletion. This means the option must be easy to discover — for example, in a prominent settings menu — and the steps must be straightforward. Apps that bury deletion behind multiple menus or require contacting support without an in-app path may no longer comply.

A new explicit reminder has been added stating that developers must not neglect completing and maintaining an accurate Data safety section. While this expectation existed implicitly before, it is now called out as a distinct requirement. Developers who have incomplete or outdated Data safety declarations are at greater risk of policy violations or app rejection.

Google has added an explicit requirement that your app's privacy policy must be globally accessible — meaning it cannot be geo-restricted or otherwise unavailable to users in certain regions. Previously this was not called out as a separate rule. Developers should verify that their privacy policy URL works from all countries and is not blocked by region-based restrictions.

A new 'Don't' item states that ignoring privacy laws constitutes a direct policy violation. While non-compliance was always against policy implicitly, this explicit labeling in a Do/Don't list makes enforcement intent clearer. Apps operating in EEA, UK, or Swiss markets that fail to meet applicable privacy laws now have an explicit policy basis for rejection or removal.

Previously, consent requirements for EU personal data were implied under broader privacy policies. Google now explicitly states that apps must not access or process personal data for any purpose a user has not consented to. This applies to all apps handling EU Personal Information under the Data Privacy Frameworks. Developers must audit their data processing activities to ensure every use case has clear, documented user consent.

Google has added an explicit requirement that developers put in place both technical (e.g., encryption, access controls) and organizational (e.g., policies, training) measures to secure EU Personal Information. This goes beyond general best-practice advice and is now a stated policy obligation under the EU-U.S., UK, and Swiss Data Privacy Frameworks. Failure to demonstrate such measures in place could result in policy violations. Developers should review and document their security posture specifically for EU data handling.

A new rule explicitly prohibits insecure handling of personal data under the EU-U.S., UK, and Swiss Data Privacy Frameworks, specifically calling out risks of data loss or misuse. While secure data handling was an implied expectation before, this addition codifies it as a concrete, enforceable requirement. Developers should ensure data storage, transmission, and access controls meet a defensible security standard. Lapses could now be cited as a direct policy violation.

Google has added a formal obligation requiring developers to contact data-protection-office@google.com immediately and take corrective action if they are unable to comply with EU-U.S., UK, and Swiss Data Privacy Framework conditions. This is a new, specific procedural requirement with a named contact point that did not previously exist in the policy. Developers should establish an internal process to monitor compliance and trigger this notification if a gap is identified. Failing to notify could compound a violation.

In addition to requiring notification when conditions cannot be met, Google has separately called out that failing to notify is itself a prohibited action. This makes the notification duty a standalone enforceable rule under the Data Privacy Frameworks, not just a procedural step. Developers who identify a compliance issue and stay silent now face a dual violation. This underscores the importance of having a clear escalation and notification workflow in place.

Google has added a requirement for developers to actively and regularly monitor their compliance with the EU-U.S., UK, and Swiss Data Privacy Framework conditions, with a specific call-out to reassess after any regulatory or legal updates. This moves compliance from a one-time review to a continuous obligation. Developers operating in affected regions should build periodic compliance reviews into their release cycles or legal review processes. Ignoring updates to applicable laws or policies could now directly constitute a policy violation.

The explicit standalone section prohibiting apps that contain or promote sexual content, profanity, or pornography has been removed from the Inappropriate Content page. This does not necessarily mean the policy no longer exists — it may have been consolidated elsewhere or restructured. Developers should locate the current authoritative version of this policy to confirm whether their compliance obligations have changed. Treat this as a structural change requiring verification, not a relaxation of rules.

The explicit section prohibiting apps that promote violence or incite hatred based on protected characteristics (including race, religion, gender identity, disability, and others) has been removed from the Inappropriate Content page. This may reflect a consolidation or restructuring of the policy rather than its elimination. Developers building apps with user-generated content or community features should verify where this policy now lives and confirm their compliance approach remains valid.

The dedicated section prohibiting apps that depict or facilitate gratuitous violence or other dangerous activities has been removed from the Inappropriate Content guidelines page. As with other removals in this update, this likely reflects a reorganization rather than policy elimination. Developers of games, action apps, or any content involving violence should confirm where this policy now resides to ensure ongoing compliance.

The section explicitly banning terrorist and dangerous organizations from publishing apps — including for recruitment purposes — has been removed from the Inappropriate Content page. This is a significant structural removal that developers and compliance teams should investigate to confirm whether equivalent language exists elsewhere in the current policy set. Platform integrity tools or app review processes likely still enforce equivalent restrictions.

The dedicated section prohibiting apps that contain or facilitate threats, harassment, or bullying has been removed from the Inappropriate Content page. For developers of social, messaging, or community-driven apps, this was a key policy reference. Its removal likely reflects reorganization rather than policy abandonment, but developers should locate the current policy location to ensure their moderation and content policies remain aligned.

The section explicitly prohibiting apps that facilitate the sale of explosives, firearms, ammunition, or certain accessories has been removed from the Inappropriate Content page. Developers building marketplace, classifieds, or commerce apps that could touch on these product categories should verify where this restriction is now documented. The underlying prohibition is expected to remain in force under a different section.

The section explicitly prohibiting apps that facilitate the sale of marijuana or marijuana products — regardless of local legality — has been removed from the Inappropriate Content page. Developers building cannabis-adjacent apps should not interpret this as a policy relaxation without confirming what the current guidelines state. This may have been moved to a different section of the developer policy center.

The section prohibiting apps that facilitate the sale of tobacco or nicotine products (e-cigarettes, vape pens, nicotine pouches) or encourage inappropriate alcohol use has been removed from the Inappropriate Content page. Developers in this space should urgently verify whether equivalent restrictions exist elsewhere in the current policy, as enforcement likely continues even if the section has been restructured or relocated.

The policy now explicitly calls out pornography and content or services intended to be sexually gratifying or to solicit sexual acts for compensation as prohibited categories. Previously, the scope may not have been this explicitly enumerated in this section. Apps that offer any form of compensated sexual services or explicitly gratifying content are squarely within the rejection category. Developers in adjacent categories (e.g., dating, adult entertainment) should carefully audit their content.

Developers are now explicitly required to ensure their apps do not promote or facilitate prohibited sexual activities or material. This extends responsibility beyond just hosting content — it includes features, links, or flows that could be seen as facilitation. This is a direct developer obligation, not just a content rule, meaning the app's design and user journeys are in scope. Apps with user-generated content or third-party integrations should pay close attention.

Under the new catalog app exemption, apps may distribute a minor fraction of sexual content provided it is not actively promoted and access is restricted from minors. This means passive availability in a broad catalog is treated differently from featuring or surfacing such content. Developers must implement robust age-gating and avoid algorithmic promotion of sexual content to remain compliant. Failure to restrict minor access would likely void this exemption and result in rejection.

The full policy text has been added, explicitly prohibiting apps that contain or promote sexual content, profanity, pornography, or any content or services intended to be sexually gratifying. This formalizes and consolidates rules that may have existed in scattered form, giving them a single authoritative location. For developers, this full-text addition is the enforceable standard, and the summary sections are subordinate to it. Any app with adult or mature content should be reviewed against this explicit language.

A new Key Considerations section with Do/Don't guidance has been added, with at least one explicit directive to protect minors by restricting their access to sexual content. This positions minor protection not just as best practice but as a named compliance requirement within the policy framework. Developers offering any content that could be rated mature or above must implement age verification or access restriction mechanisms. This could affect app store rating selections, login requirements, and content gating logic.

Previously, restrictions on sexual imagery were less explicitly enumerated. Google Play now explicitly prohibits depictions of sexual nudity, sexually suggestive poses, and sex acts within apps. Developers with any user-generated content, media, or imagery features should audit their content pipelines immediately, as violations can lead to removal.

Google Play has added a proportionality rule: sexual content cannot dominate an app's catalog and must remain a minor fraction of the total offering. Apps that primarily or heavily feature sexual content will likely be non-compliant even if individual items might otherwise be permissible. Developers should review their catalog composition and ensure sexual content is clearly subordinate to the broader content library.

Google Play now explicitly requires that app store listings — including descriptions, titles, and promotional copy — are free of lewd, profane, or sexually explicit text. This extends content restrictions beyond the app itself to the storefront presentation. Developers should review all metadata fields in their Play Console listings and update any language that could be flagged under this rule.

A new 'Key Considerations' section has been added to the Inappropriate Content policy, establishing a do/don't framework for hate speech compliance. The first item instructs developers to familiarize themselves with what legally and policy-wise constitutes a protected group. This signals that Google expects developers to proactively educate themselves rather than rely solely on reactive enforcement. Apps with any community, social, or content-sharing features are most likely to be affected.

A new guidance item advises developers to review local laws concerning Educational, Documentary, Scientific, or Artistic (EDSA) content related to Nazism. Some countries permit such content in educational contexts while others restrict it broadly. This matters for history, education, documentary, or media apps that may include WWII or related content — developers must ensure their content complies with the laws of every region where their app is distributed.

Google now explicitly prohibits content that frames any protected group as evil, corrupt, or dangerous. This goes beyond direct incitement and covers more subtle forms of harmful characterization, such as conspiracy-style narratives or stereotyping tropes. Developers of news aggregators, opinion platforms, or apps with user-generated content need to assess whether their content moderation policies catch this type of material. Non-compliance could lead to rejection or removal.

Developers are now explicitly required to remove content that promotes hate symbols, slurs, or stereotypes targeting protected groups. This is a direct, actionable requirement rather than general guidance, meaning apps found containing such content face policy enforcement. This affects any app where users can post, share, or display text or images — robust content moderation or filtering systems are essential to remain compliant.

A new rule explicitly bans content that encourages others to discriminate against individuals or groups. This extends the hate speech policy beyond direct hate speech to cover content that promotes discriminatory behavior or attitudes. Developers with social, marketplace, or community apps should review how their platforms could be used to facilitate or promote discrimination, and update moderation policies accordingly.

Apps must not contain content asserting that any group is inferior or inhuman — a standard dehumanization test commonly used in hate speech frameworks. This is now a written, enforceable requirement. Developers should treat this as a hard content line: any user-generated or editorial content meeting this description must be detectable and removable. Failure to moderate such content could result in app suspension.

Google now explicitly prohibits the use of flags, symbols, or insignia associated with hate groups within apps. This applies to all content types — icons, images, stickers, avatars, and user-generated media. Developers of creative or social apps that allow image sharing or custom avatars need to implement detection or moderation for known hate group symbols. This is an enforceable content requirement, not just a recommendation.

A new clause has been added stating that apps must not promote or encourage CSAM-related material. While this type of content was already implicitly prohibited, the explicit addition of a promotion/encouragement ban broadens the scope. Developers whose apps involve user-generated content, links, or community features should ensure no pathways exist that could facilitate such promotion.

A formal full-policy statement has been added making it explicit that apps depicting or facilitating gratuitous violence or other dangerous activities are not allowed. This formalizes and surfaces a rule that may have existed in spirit but was not stated as a standalone full-policy clause. Developers of action, combat, or edgy content apps should review whether their content crosses into 'gratuitous' territory.

Developers seeking an exception to violent extremism content restrictions must now explicitly provide Educational, Documentary, Scientific, or Artistic (EDSA) context. Without this justification, exceptions will not be granted. Apps covering extremism-related topics for legitimate informational or artistic purposes must proactively document and demonstrate that context.

A new compliance requirement has been added stating that developers must ensure their app and all its content neither belongs to nor promotes a terrorist or dangerous organization. This places an affirmative due-diligence obligation on developers, not just a passive prohibition. Apps with user-generated content, third-party integrations, or community features must have safeguards to prevent such associations.

This is a newly added rule under Google's Inappropriate Content policy. Apps must not contain any content that promotes or incites violence. Previously this may have been implied, but it is now an explicit written requirement. Developers should audit all user-generated content systems, static content, and messaging features to ensure nothing promotes or incites violent acts.

Google has added an explicit developer obligation to proactively review their apps for content that glorifies, plans, or celebrates acts of violence. This goes beyond passive compliance — it places an affirmative duty on developers to audit their content. Apps with user-generated content or editorial content touching on violence are especially at risk if no review process is in place.

A new rule has been added prohibiting apps from being used as recruitment tools for dangerous organizations. This is a new explicit restriction that was not previously stated in this section. Developers running community, social, or messaging apps should ensure their platforms cannot be exploited for this purpose, as facilitating such recruitment — even passively — could violate this policy.

This newly added rule forbids posting content that glorifies violence or helps users prepare for violent acts. While similar to index 50's prohibition on inciting violence, this rule specifically targets content that celebrates violence or provides instructional/preparatory material. Developers of gaming, educational, news, or community apps should carefully consider whether any content could be interpreted as glorifying or enabling violence.

Google has added a formally labeled 'Full Policy' statement explicitly prohibiting apps that facilitate the sale of explosives, firearms, ammunition, or certain firearms accessories. Previously this prohibition may have existed in less structured form; this addition gives it a clear, authoritative policy designation. Any app involved in commerce, marketplaces, or listings that could include these items must ensure it is not enabling such transactions.

A new 'Key Considerations' section has been introduced with structured Do/Don't guidance, specifically calling out that apps must not facilitate the sale of restricted firearms accessories. This structured format makes the expectations more concrete and actionable compared to general policy language. Developers building any e-commerce, marketplace, or classifieds-style app should check whether their category filters or listing controls could allow restricted accessories to be sold.

As part of the new Key Considerations section, Google has added a specific 'Don't' item prohibiting apps from facilitating the sale of explosives, firearms, or ammunition. This makes the prohibition actionable and directly tied to app rejection criteria. Developers with marketplace, auction, or commerce apps must ensure their platforms cannot be used to list or transact these items.

A new rule requires that apps must not include or provide instructions for converting firearms to automatic firing capabilities. This is a specific and concrete content prohibition that goes beyond sales facilitation into informational content. Developers with apps covering firearms education, guides, forums, or user-generated content must audit and remove any such conversion instructions to avoid rejection.

Google has added an explicit prohibition against apps facilitating the sale of firearm accessories that simulate or enable automatic fire, such as bump stocks or auto-sears. This extends the firearms policy beyond traditional weapons to specific accessory categories. Developers running any firearms-related retail, marketplace, or classifieds apps must ensure such accessories are not listable or purchasable through their platforms.

A new 'Don't' rule explicitly bans apps from containing instructions on how to create weapons or restricted firearm accessories. This covers not just sales facilitation but also how-to content, guides, and potentially user-generated content within apps. Developers with content, community, or instructional apps must ensure no such content is hosted or accessible, including in user-submitted material.

A new 'Do/Don't' guidance table has been introduced. The one permitted exception is age-gated sale of alcohol and limited tobacco products, but only within food or grocery apps. This narrows the scope of what is acceptable — standalone tobacco or alcohol commerce apps are not covered by this exception. Developers of grocery or food delivery apps that include alcohol or tobacco must implement age-gating to remain compliant.

Google has added an explicit rule prohibiting apps from encouraging the use of alcohol or tobacco by minors. While age-gating was implied by previous policy, this 'Don't' makes targeting or appealing to minors for alcohol or tobacco use a direct violation. Apps with alcohol or tobacco content that lack robust age controls, or that use marketing language appealing to younger audiences, are now at clear rejection risk.

A new explicit prohibition prevents apps from advertising or promoting tobacco products, and specifically calls out links to sites that sell tobacco. This goes beyond commerce facilitation — even informational or content apps that link to tobacco sellers could be in violation. Developers should audit any tobacco-related content, affiliate links, or promotional material within their apps.

Google now explicitly prohibits apps from implying that tobacco use enhances a user's social, professional, or intellectual standing. This rule targets lifestyle-style tobacco marketing and brand association rather than direct sales. Developers creating any content — including games, social apps, or media — where tobacco use is glamorized or positively associated with success or status should revise that content to avoid rejection.

Google has added an explicit prohibition against apps that portray excessive drinking in a favorable light. Previously, the alcohol policy focused on facilitating illegal or inappropriate use of alcohol but did not call out favorable depictions of excessive consumption. This new rule affects apps in entertainment, social, gaming, and lifestyle categories that include alcohol-related content or themes. Developers should audit any content, imagery, or messaging that could be interpreted as glamorizing binge drinking or overindulgence.

This addition explicitly names pornography and content or services designed to be sexually gratifying or to solicit sexual acts for compensation as prohibited categories. Previously, these may have been implied under broader content policies. Developers running any platform with user-generated content or adult-adjacent services should audit their offerings to ensure they do not fall into these newly enumerated categories.

Google Play now explicitly states that developers must ensure their apps do not promote or facilitate prohibited sexual activities or material, not just avoid hosting such content directly. This extends developer responsibility to indirect facilitation, such as linking out to or enabling access to prohibited content. App developers — particularly those with third-party integrations or user-generated content — need to actively audit their facilitation pathways.

Building on the catalog app exemption, Google Play specifies that such apps may include a small proportion of sexual content under two conditions: it must not be actively promoted, and access must be restricted so minors cannot reach it. Developers relying on this exemption must implement robust age-gating mechanisms and avoid surfacing or advertising the sexual content portion of their catalog.

Google Play has added a Do/Don't key considerations section, with the first 'Do' item explicitly requiring developers to protect minors by restricting their access to sexual content. This formalizes minor-protection as an active developer obligation rather than an implicit expectation. Any app that could be accessed by minors and contains any level of mature content needs robust age-verification or access control mechanisms.

Google Play's new key considerations section explicitly lists depictions of sexual nudity, sexually suggestive poses, and sex acts as prohibited content. While the general prohibition existed, this level of explicit enumeration in a Do/Don't format makes enforcement criteria clearer and more actionable. Developers should audit all visual assets, user-generated content, and in-app imagery against these specific categories to avoid rejection.

A new rule explicitly states that sexual content must represent only a small portion of an app's total content catalog. Previously, there was no explicit proportionality requirement. Apps that are primarily or heavily focused on sexual content — even if individually permissible — may now be at risk of removal. Developers running content catalog apps should audit their ratio of sexual to non-sexual titles.

Google Play now restricts the distribution of sexual content to apps that function specifically as book or video catalog apps. Previously, the permitted app types for such content were less explicitly defined. Developers in other app categories — such as games, social, or utility apps — that include any sexual content must remove it or risk policy violations. This is a meaningful narrowing of who is allowed to host this content type.

A new guideline explicitly bans lewd, profane, or sexually explicit content within an app's Play Store listing, including descriptions, screenshots, and promotional text. This clarifies that the content restrictions extend beyond the app itself to its storefront presence. Developers with mature apps should carefully review their listing copy and assets to ensure compliance, even if the app's internal content is permitted.

A new explicit 'Don't' rule has been added stating that apps inciting hatred or violence against individuals or groups are prohibited. While this concept existed in spirit under general hate speech rules, it is now a formally stated standalone requirement in the policy checklist. Developers should audit any user-generated content features, editorial content, or community tools in their apps that could facilitate or amplify hateful or violent rhetoric.

Google has added a new requirement for developers to review local laws regarding Educational, Documentary, Scientific, or Artistic (EDSA) content that references Nazism. Previously, the policy did not explicitly call out this regional legal review obligation. This is particularly relevant for developers targeting European markets where such content is heavily regulated. Failing to comply with local law in this area could result in both legal liability and app removal.

A new explicit 'Don't' item forbids including content that characterizes a protected group as evil, corrupt, or dangerous. This goes beyond incitement and targets subtler forms of dehumanizing narrative within app content. Developers building news, entertainment, educational, or user-generated content platforms need to ensure moderation and editorial policies screen for this type of framing. This could affect apps that aggregate or display third-party content without sufficient moderation.

Google now explicitly requires developers to remove any content promoting hate symbols, slurs, or stereotypes. This is a new affirmative action item — 'remove' implies an ongoing moderation obligation, not just a one-time review at submission. Apps with user-generated content, chat, or community features are particularly at risk if they lack robust moderation for this type of content. Non-compliance could lead to app rejection or removal from the Play Store.

A new checklist item explicitly prohibits apps from encouraging others to discriminate against any individual or group. This extends the hate speech policy beyond the app's own content to include how the app may prompt or incentivize user behavior. Developers should review calls-to-action, prompts, recommendations, and algorithmic features that could be interpreted as nudging users toward discriminatory behavior.

Google has added an explicit requirement that apps must not contain content asserting any group is inferior or subhuman. Dehumanizing language and content is now a named, standalone violation in the policy checklist. This is broader than incitement — it covers content that demeans without necessarily calling for action. Developers should audit static content, dynamic content feeds, and AI-generated content within their apps for compliance.

A new explicit 'Don't' rule prohibits the use of flags, symbols, or insignia associated with hate groups anywhere in an app. This is a newly formalized standalone rule in the policy checklist. Developers building historical, educational, gaming, or customization apps (e.g., sticker packs, avatars) need to carefully vet any symbolic imagery included. Context may be considered under EDSA provisions, but the default prohibition is clear.

Google has added a new Violence Policy Summary section explicitly stating that apps containing gratuitous violence or dangerous activities are prohibited. While violence restrictions existed in prior policy text, this summary section formalizes and consolidates the policy's scope in a new prominent location. Developers of gaming, action, or extreme sports apps should ensure their content does not cross the line into gratuitous territory, as this summary signals heightened enforcement focus.

Complementing the Violence Policy Summary, a new explicit rule states that apps must not promote or encourage gratuitous violence or dangerous activities. This extends the prohibition from merely containing such content to actively promoting it — a broader behavioral standard. Developers should review in-app messaging, reward structures, and content framing to ensure they are not inadvertently incentivizing dangerous behavior. This applies equally to user-generated content platforms.

A formal full-policy declaration has been added stating that apps depicting or facilitating gratuitous violence or other dangerous activities are not allowed on Google Play. While this likely reflects existing enforcement practice, its explicit addition to the policy text makes the rule more prominent and enforceable. Developers with apps containing graphic violence or content that enables real-world dangerous behavior should review their content carefully to avoid rejection.

Developers seeking an exception to the Violent Extremism policy must now explicitly provide EDSA (Educational, Documentary, Scientific, or Artistic) context. Without this context, no exception will be granted. Developers building apps that legitimately cover extremism-related topics — such as news, research, or educational tools — must ensure they clearly document and communicate their EDSA justification.

A new 'Key Considerations' section has been added to the Violent Extremism policy, outlining a Do/Don't framework. The 'Do' side requires developers to provide EDSA (Educational, Documentary, Scientific, or Artistic) context for any content related to violent extremism. This is now a documented best practice and likely a factor in exception reviews. Apps in journalism, education, or research that touch on extremism topics must ensure their EDSA framing is explicit and credible.

Developers are now explicitly required to confirm that their app — including its content — does not belong to or promote a terrorist or dangerous organization. This extends responsibility beyond just the app's publishing account to the actual content within the app. Developers whose apps reference, platform, or amplify content from any such organization, even indirectly, may be at risk of policy violations.

An explicit rule has been added stating that apps must not include content that promotes or incites violence. Previously, this may have been implied under broader violence or extremism policies, but it is now a standalone enumerated prohibition. Developers should audit user-generated content features, community sections, and any editorial content to ensure nothing could be interpreted as promoting or inciting real-world violence.

Previously this prohibition may have been implied under broader content policies. Google now explicitly requires developers to review their apps to ensure they do not glorify, plan, or celebrate violent acts. This matters because apps with user-generated content, gaming narratives, or community features could be flagged if they permit or promote such content. Developers should audit content moderation systems and community guidelines accordingly.

Google has added a new explicit prohibition against using apps to recruit members into dangerous organizations. This is a new standalone rule rather than a clarification of an existing one. Apps with community, messaging, or social features are most at risk if their platforms can be exploited for such recruitment. Developers should ensure their terms of service and moderation policies actively prevent this use case.

Google has introduced an explicit requirement that apps adhere to local laws concerning sensitive content, which goes beyond Google's own policy rules. This is significant for developers distributing apps across multiple regions, as what is permissible in one jurisdiction may be illegal in another. Developers operating internationally should conduct jurisdiction-specific legal reviews of their content. Non-compliance could result in regional removal or broader enforcement action.

This new rule explicitly prohibits posting content that glorifies or prepares users to commit violent acts. While related to index 130, this is framed as a direct content posting prohibition rather than an app-level review requirement. Apps that host user-generated content, forums, or instructional material are particularly affected. Developers should update moderation pipelines to detect and remove such content proactively.

A new 'Key Considerations' section has been introduced with explicit Do/Don't directives. The key 'Don't' here is that apps must not facilitate the sale of restricted firearms accessories. This structured guidance makes it easier for Google reviewers to flag violations, raising the rejection risk for apps in adjacent categories such as sporting goods, hunting, or general marketplaces that lack sufficient content controls.

Google has added a specific directive requiring developers to remove any content or instructions that explain how to convert a firearm to automatic firing capability. Previously, this may have been covered under broader dangerous content rules, but it is now called out explicitly. Apps containing user-generated content, forums, guides, or instructional media related to firearms must actively moderate for this content.

A new explicit prohibition has been added against apps facilitating the sale of firearm accessories that simulate or enable automatic fire, such as bump stocks or auto-sear devices. This goes beyond general firearms accessory restrictions by targeting a specific product class. Marketplace, e-commerce, or classifieds apps must ensure their category filters, listing policies, and moderation tools block these products.

Google has added a 'Don't' rule prohibiting apps from including instructions for creating weapons or restricted firearm accessories, such as 3D-printing guides or DIY conversion kits. This applies to both first-party app content and user-generated content hosted within an app. Developers of content, community, or DIY apps must review and enforce content policies to avoid violation.

A new Tobacco and Alcohol Policy Summary has been introduced, explicitly prohibiting apps that facilitate the sale of tobacco or nicotine-containing products (including e-cigarettes, vape pens, and nicotine pouches) and apps that encourage illegal or inappropriate use of alcohol, tobacco, or nicotine. This summary serves as an introductory overview before the full policy details. Developers with any app touching these categories should review the full policy immediately to assess compliance.

A new 'Key Considerations' section has been introduced with explicit Do/Don't guidance. The 'Do' item requires that apps selling alcohol — and any limited tobacco sales within food or grocery apps — must implement age-gating safeguards. This is new prescriptive guidance that defines a compliant path for grocery or delivery apps that include alcohol. Developers in this space must ensure age verification mechanisms are in place.

A new rule prohibits apps from encouraging the use of alcohol or tobacco by minors. This adds an explicit minor-protection clause that was not previously stated in this form. Apps with content, marketing, or features that could appeal to or target underage users in relation to these substances need to be reviewed and updated accordingly.

Apps are now explicitly banned from advertising or promoting tobacco products, and this prohibition extends to including links to sites that sell tobacco. Even if an app does not directly sell tobacco, linking out to tobacco retailers or featuring promotional tobacco content is now grounds for rejection. Developers of lifestyle, content, or social apps should audit any tobacco-related advertising integrations or outbound links.

The explicit enumerated definition of personal and sensitive user data — which listed categories such as location, contacts, health data, Health Connect data, camera, microphone, and others — has been removed from the Developer Program Policy. This definition previously anchored many data-handling requirements. Developers should check whether this definition has moved to another section or document, as its removal may signal a restructuring of privacy policy content rather than a relaxation of requirements.