Google Home Developer Policies Overview (original) (raw)

These policies ("Google Home Developer Policies") are designed to provide requirements to developers using and building integrations on Google's platform (including the Google Home Developer Center and the tools and materials available through the Google Home Developer Center) that lets you integrate your products, apps, and services with Google's smart home products and services ("Google Home Developer Platform"), including during any transition period from Actions on Google.

The Google Home Developer Policies are organized into four sections:

1. The General Policies, which apply to any developer integrating with the Google Home Developer Platform.
2. The Smart Home API Integrationssection governs the use of cloud to connect your devices to Google to enable control via voice, the Google Home app, orthe Home APIs & Home Hub Runtime Integration.
3. The Matter Integrations section outlines how to ensure your Matter device is compatible with the Google Home Developer Platform.
4. The Home APIs & Home Hub Runtime Integration section applies to developers integrating with the Home APIs & Home Hub Runtime software to make a device that can act as a hub for Google Home.

Some partners may have access to additional APIs and be subject to varying terms of service and policies, including, but not limited to, the Google API Terms of Service and Google API Services User Data policy. For the purposes of this policy, the term integration applies to the project, app, or individual integrations within that project. This policy applies to all aspects of integrations with the Google Home Developer Platform. For any policies that are not expressly discussed within this Google Home Developer Policy, the Actions on Google policies will apply to all aspects of those integrations. In the event of any conflict between these Google Home Developer Policies and others, these Google Home Developer Policies will apply.

Avoiding a policy violation is always better than managing one, but when violations do occur, we're committed to ensuring developers understand how they can bring their use of the Google Home Developer Platform into compliance.

If we find that your integration violates our policy, you will receive a notification with a specific reason for deprecation, removal, or rejection. Repeated or serious violations of the policy may result in termination of individual, related or partner accounts.

We may take action based on a number of factors, including, but not limited to, a pattern of harmful behavior or high risk of abuse. We identify risk of abuse based on factors, including, but not limited to, previous violation history, user feedback, and misuse of popular brands, characters, and other assets.

As a developer of applications and services connecting to the Google Home Developer Platform, you often collect and manage sensitive user information. By accessing or integrating with the Google Home Developer Platform (including any developer materials made available through the Google Home Developer Platform), you agree to the following policies.

1. General Policies

Privacy and Security

User Data

You must be transparent in how you handle user and/or device data (e.g., information provided by a user, collected about a user, and collected about a user's use of the integration or device). This policy establishes the Google Home Developer Platform minimum privacy requirements; you or your integration may need to comply with additional restrictions or procedures if required by an applicable law.

All integrations must adhere to the following:

• Provide a link to your applicable privacy policy in the Google Home Developer Center: The privacy policy must, together with any integration disclosures, comprehensively disclose how your integration collects, uses, and shares user data, including the types of parties with whom it's shared. It must be written in each of the languages your integration is enabled for. You must limit your use of the data to the activities described in the disclosures. You must allow Google crawlers to access and scan the content of the privacy document. Your privacy policy must remain accessible and legible for all potential and existing users of your integration.
• Request appropriate permissions: Don't request access to data that you don't need to provide the primary features of your application or service.
• Be transparent: Accurately represent and explain to users what data you will collect, why you will collect it, and how you will use it.
• Secure user data: Handle user data securely throughout the entire lifecycle of the data (including but not limited to: collection, transmission, processing, and storage) by demonstrating adherence to modern security practices and/or additional specifications as required by Google.
• Protect users' privacy: Don't use any data obtained through any Google-related integration, including but not limited to the Google Home Developer Platform, Google Cloud Platform, or any other Google product, for prohibited uses, like selling or using user data for advertising purposes.
• Respect users' wishes: Honor user requests to delete their data.
• Data Prohibition on AI Use: Using data from any Google Home Developer Platform integration, including the Home APIs & Home Hub Runtime, for training artificial intelligence models or any other related tools is prohibited.

Intellectual property

We don't allow integrations or developer accounts that infringe the intellectual property rights of others, including trademark, copyright, patent, trade secret, and other proprietary rights. We also don't allow Integrations that encourage or induce infringement of intellectual property rights.

We will respond to clear notices of alleged copyright infringement. For more information or to file a Digital Millennium Copyright Act request, please visit our copyright procedures.

If you are a trademark owner and you believe an integration is infringing on your trademark rights, we encourage you to reach out to the developer directly to resolve your concern. If you can't reach a resolution with the developer, please submit a trademark complaint through this form.

Impersonation

We don't allow integrations that mislead users by impersonating someone else (e.g., another developer, company, entity) or another Integration, or falsely applying affiliation. This includes misusing icons, descriptions, display names, or other integration features that could mislead users.

Here are some examples of violations:

• Claiming to be a supplier or provider of a brand with no authorization from the owner of the brand.
• Using an icon in your Integration that you do not own.
• Claiming to be the "official" Integration of a brand or company with no authorization from the owner of the brand.

We don't allow integrations that infringe copyright. Modifying copyrighted content may still lead to a violation. Developers may be required to provide evidence of their rights to use copyrighted content.

Please be careful when using copyrighted content to demonstrate the functionality of your Integration. In general, the safest approach is to create something that's original.

Here are some examples of copyrighted content that is often used without authorization or a legally valid reason:

• Cover art for music albums, video games, and books.
• Marketing images from movies, television, or video games.
• Artwork or images from comic books, cartoons, movies, music videos, or television.

Encouraging infringement of copyright

We don't allow integrations that induce or encourage copyright infringement. Before you publish your Integration, look for ways it may be encouraging copyright infringement and get legal advice if necessary.

Here are some examples of violations:

• Streaming integrations that allow users to download a local copy of copyrighted content without authorization.
• Integrations that encourage users to stream and download copyrighted works, including music and video, in violation of applicable copyright law.

Trademark infringement

We don't allow integrations that infringe on others' trademarks. A trademark is a word, symbol, or combination that identifies the source of a good or service. Once acquired, a trademark gives the owner exclusive rights to the trademark usage with respect to certain goods or services.

Trademark infringement is the improper or unauthorized use of an identical or similar trademark in a way that is likely to cause confusion as to the source of that product. If your Integration uses another party's trademarks in a way that is likely to cause confusion, your Integration may be removed.

Counterfeit

We don't allow integrations that sell or promote the sale of counterfeit goods. Counterfeit goods contain a trademark or logo that is identical to or substantially indistinguishable from the trademark of another. They mimic the brand features of the product in an attempt to pass themselves off as a genuine product of the brand owner.

Deceptive behavior

We don't allow integrations that attempt to deceive users. Integrations must provide an accurate description of their functionality and perform as reasonably expected by the user. Integrations must not attempt to falsely mimic system functionality or warnings of any kind. Any changes to device settings must be made with the user's knowledge and consent and be easily reversible by the user.

Misleading Claims

We don't allow integrations that contain false or misleading information or claims, including description, integration name, or icon. Don't try to imply an endorsement or relationship with another entity where none exists.

Examples of misleading claims include:

• Misrepresenting or not accurately describing what your device is capable of once it is integrated with Google Home;
• Misrepresenting interoperability with Google or another device that does not exist;
• Using an integration name or icon in Google Home Developer Platform that is similar to another existing entity in order to impersonate them, or cause a user to erroneously enter your setup process in the Google Home app. This includes, but is not limited to a generic name or product category name so as to potentially mislead the user.

Malicious behavior

We don't allow integrations that steal data, secretly monitor or harm users or that are otherwise malicious. This includes, but is not limited to, engaging device functionality such as audio or video recording without accurately representing the state of the device to the user.

We don't allow integrations that interfere with, disrupt, damage, or access in an unauthorized manner the user's device or other devices, computers, servers, networks, application programming interfaces (APIs), or services. This includes other integrations, any Google service, and the device's network.

All integrations that collect user data must comply with the User Data policy and fully disclose their functions.

The following are explicitly prohibited:

• Viruses, trojan horses, malware, spyware, and any other malicious software.
• Promoting or facilitating the distribution or installation of malicious software.
• Introducing or exploiting security vulnerabilities.
• Stealing a user's authentication information (such as usernames or passwords).
• Tricking users into disclosing personal or authentication information.
• Indicating the integration has closed or exited, but continuing to record the user.
• Running other integrations without the user's prior consent.
• Secretly collecting device usage.

Integrations must not provide any means to activate or access functionality that violate these terms.

Security vulnerabilities

If your integration is associated with a security vulnerability that could be exploited to compromise another integration, application, device, or service, we may deprecate or remove it to protect users.

If your integration is associated with a security breach leading to the accidental or unlawful device or network malfunction; or destruction, loss, alteration, unauthorized disclosure of, or access to, data on systems managed by or otherwise controlled by you, you must disclose this to Google in writing in a timely manner after the breach discovery. You must cooperate with Google in the investigation, coordination, and resolution of the malfunction or data breach.

Data feeds

If you provide us with data, including, but not limited to content metadata, via a data feed or other mechanism, the data must comply with these policies, including the section on Intellectual Property.

Your provision of data to us must not include user personally identifiable information (PII), including but not limited to persistent device ID, phone numbers, or email addresses. You must correctly implement all technical requirements and provide content for all required fields. The data provided must be relevant to the use case of feed and accurate. We may disable the feed (or a portion of it), disable use of the data, or remove any related integrations for violations of these policies or if they create a poor user experience.

Support Duration

• Support Duration
  • All integrations with the Google Home Developer Platform must provide security updates for at least three years from the date when the integration is first certified in the Google Home Developer Center.
• End of Life
  • You must provide Google with at least 90 days notice should you wish to end support for any integration or device with the Google Home Developer Platform. Failure to do so may adversely affect your other integrations, future or then current, with Google Home or your standing with the Works with Google Home badge.
  • Google reserves the right, without notice, to stop support of any integrations with the Google Home Developer Platform that have stopped receiving developer partner support.

Conflicting terms

These policies do not limit or amend any terms of service or other agreements that apply to the user's use of the applicable Google products or services, unless the policies expressly state that they are amending specific terms of service or agreements.

Enforcement

If your integration has violated any of our policies, we may take one or more enforcement actions against your integration or your developer account, as outlined below. In addition, we'll notify you with relevant information about the enforcement action we've taken, along with instructions on how to appeal if you believe we've taken enforcement action in error.

Please note that removal or administrative notices may not indicate each and every policy violation present in your integration. You are responsible for addressing any policy issue and conducting extra due diligence to ensure that the remainder of their integration is fully policy compliant. Failure to address policy violations in all of your integrations may result in additional enforcement actions, including permanent removal of your integration or account termination.

Repeated or serious violations (such as malware, fraud, and integrations that may cause user or device harm) of the terms of service or policies for integrations on Google may result in termination of individual or related integrations on Google developer accounts.

Rejection

• A new integration or integration update submitted for review will not be made available on Google Home Developer Platform or through other Google-connected interfaces until the review is complete and approved.
• If an update to an existing integration was rejected, the integration version published prior to the update will remain available on Google Home Developer Platform.
• Rejections don't impact your access to a rejected integration's existing user installs, statistics, and ratings.
• Rejections don't impact the standing of your integrations on your Google developer account.

Limited visibility

• Your integration's discoverability through Google interfaces such as suggested devices and automations, partner catalogs, and additional features may be restricted. The integration will remain on the Google Home Developer Platform.
• Having your integration placed in a limited visibility state doesn't impact the standing of your other integrations on your Google Developer account.

Account termination

• When your developer account is terminated, all integrations in your catalog will be removed from the Google Home Developer Platform and you will no longer be able to submit new integrations. This also means that any related Google Home Developer Platform accounts will also be permanently suspended.
• Multiple suspensions or suspensions for egregious policy violations may also result in the deprecation of your integration, termination of your developer account, or the decommissioning of your existing fleet of devices from the Works with Google Home certification program. This will disable all Works with Google Home functionality beyond the Matterprotocol, including access to Cloud-based integrations, and Owner Test Accounts in the Google Home Developer Center.

Because the integrations within the terminated account are removed, users will not be able to see the integration's existing listing, existing user installs, statistics, and ratings.

Appealing an enforcement action

We will reinstate integrations if an error was made and we find that your integration does not violate the terms of service and policies for integrations on Google. If you've reviewed the policies carefully and feel that our enforcement action may have been in error, please follow the instructions provided in our notice to you to appeal our decision. You can also contact ushere.

2. Smart Home API Integrations

This section on Smart Home API Integrations governs the use of cloud to connect your devices to Google to enable control via voice, the Google Home app, or the Home APIs & Home Hub Runtime. Security or surveillance integrations must not log PII of individuals outside the primary user without their consent. For example, doorbell integrations cannot log information about who may be at the door without the express consent of that individual.

We do not allow integrations that may violate applicable laws. This includes, but is not limited to, integrations that instruct passenger transport vehicles to move, allow for the controlling of pool covers from inside the home, or any other safety-related or other prohibited features.

Secondary User Verification

Google requires partners to enable a secondary user verification for any operation that may change the device state to a non-secure or disabled state, such as unlocking a door, turning off a camera, disabling a security system, or opening a device that may have a safety concern.

While the nature of the security and safety precautions may vary by the type of device, at minimum these devices must require account linking and a secondary user verification, such as confirmation on a secured mobile device or a password/PIN. Irrespective of the nature of the integration, adding the additional layer of security is required to comply with Google's policies. However, with regards to cloud integrations, after the user has established a secondary verification, you may provide an opt-out option for the user. The opt-out language must be precise and clear to the user.

Works with Google Home Certification

When users search for and buy devices labeled with the Works with Google Home badge, they should expect robust functionality and a safe, reliable, and seamless experience. Developers must also meet the following requirements for device certification and use of the Works with Google Home badge:

Functionality

The Smart Home API supports device types and traits to match the functionality of smart home devices. Device type representation should be accurate and specific based on the identity of the device itself. This also applies to Matter-enabled devices, which should expose to the Google Home Developer Platform all the standards-compliant Matter clusters and functionality made available to any non-Google ecosystem. For example, if you have a smart switch that may control lights, then the device type that you use is Switch, since that represents the nature of the physical device. Integrations that use incorrect device types or traits (e.g., a space heater that is implemented as a dimmable light) may be removed at Google's discretion. Google provides guides on devices and their required functionalityhere.

Additionally, if new device traits are added to your device via any other non-Google ecosystem or integration, those capabilities must be made accessible to Google users at the same time. As an example, for color light bulbs, users should be able to change the color of the bulbs, turn the bulbs on and off, adjust the bulbs' brightness, etc., through Google interfaces. Further, if new features are made available through device updates, these traits and/or clusters must also be available to the Google Home Developer Platform at launch.

Google reserves the right to not certify submissions if your device fails Google testing, fails to integrate all functionality present on the device with compatible Smart Home API traits allowing Google to provide a complete experience, is incompatible with standard Matter clusters, or evinces performance or reliability issues. Likewise, if local reporting ofMatter cluster state changes proves to be unreliable or latent, device certification may be denied or revoked.

Reporting User Configuration Changes

You will report device configuration updates in your ecosystem to Google; for example if the developer updates functionality like supported traits, or if the user adds, reconfigures, or removes a device, the developer must report those updates to Google. This eliminates the need for users to remove or add the device to their account to receive updates after they make an update in the developer app. This can be accomplished through the Request Sync APIor the appropriate Matter descriptor clusters.

Google Device Control Authorization Page

In order to comply with our legal and privacy policies, your OAuth page should show that your app is linking / sharing data with Google, not Google Home or Google Assistant. You must have a Google authorization statement such as "By signing in, you are authorizing Google to control your devices."

Persistent Connections

With the exception of Wake-on-LAN devices, cloud connected smart devices should have a persistent connection for cloud control, whether that's through the device itself, or through a stationary partner hub. For example, mobile devices and tablets cannot be used as intermediaries for smart home devices. For devices with low power states that disconnect the device from its connectivity protocol such as WiFi, the device should implement methods to enable waking up the device for cloud control.

Safety Certificate

There are certain devices that may have safety implications, such as cooking appliances that may get hot enough to be a safety concern. For any device that can potentially pose a heightened safety risk, we ask that you share the UL certificate (or similar safety certification) for that device. Additional details on safety certificate requirements can be foundhere.

Quality

Maintaining a high level of performance and reliability is key to jointly delivering helpful user experiences. Partners can access metrics on the usage and performance of their integration by visiting their Google Cloud Platform project page. More information on accessing performance metrics can be foundhere.

After the initial certification, developers should maintain an acceptable level of performance for their devices. There are multiple aspects of performance:

1. Latency and reliability associated with executing commands
2. Reliable account linking and token refresh
3. Report state accuracy and latency of reporting state changes
4. Properly sync and resync devices to Google as the devices change

Quality expectations are outlined on a device type level in the Smart Home API Documentation. Persistent failure to meet these expectations could result in your integration having reduced visibility, or in extreme cases being disabled, until performance is improved.

Name requirements

Your integration name is how users discover and account link to your project. Integration names are unique, so once a name is approved, no other project can register using the same name.

Integration Names must meet the following requirements:

• Integration name is unique to your brand or trademark within the regions in which your project can be accessed.
• Integration name should not indicate it's for testing, demo or personal use purpose
• Integration name should not contain any profanity, vulgarity, sexually explicit, hate speech or other content restrictions.

We don't allow integration names that are:

• A known brand name if your project or company does not have all rights required to use that name for this integration.
• Potentially confusing users into thinking they are interacting with Google
  • "Google"
  • "Google Assistant"
  • "Hey Google"
  • "OK Google"
  • "Nest"
• Generic, including words or phrases that are categories of products, services, or content. We will consider exceptions to this prohibition on a case-by-case basis.
  • Examples of generic Names that violates our requirements:
    * Smart Home
    * Home Action
    * Home
  • Allowed Examples: Once other words are added, it's policy compliant to use "Home" or "Smart Home"
    * "gHome Ultra"
    * "Mini Home Super"
    * "Tidy Home"
    * "<_your brand_> Smart Home"
• Using special characters such as but not limited to "#, +, @, !, -, :", unless it's identical to your company name, brand name or app name.
  • Tidy Home!
  • Tidy-Home
  • Smart Home: Tidy Home

Registration

Each developer must register their integration with the Google Home Developer Center and provide applicable details, such as the device types and features that will be accessed. For apps, the app identifier must be provided. This information must be kept up to date. Failure to comply may result in enforcement as further described herein.

Certification Refresh

Smart Home API integrations should be recertified when the API has functionality changed or when your device otherwise adds new capabilities that are supported by the Smart Home API. This is inclusive of additional devices that the partner adds to their integration. For example, as new devices are included, the certification requirement must also be met for those devices.

Additionally, Google reserves the right to require integrations to be recertified periodically. This will ensure you maintain eligibility for the Works with Google Home badge and your integration remains in good standing. Failure to recertify, will revoke your approval for use of the Works with Google Home badge and can potentially lead to one or more enforcement actions against your Smart Home API integration.

3. Matter Integrations

• Matter Certification
  • All Matter-enabled devices integrating with the Google Home Developer Platform must be certified in accordance with the Connectivity Standards Alliance (the "Alliance") process prior to obtaining Works with Google Home certification.
  • Matter integrations that wish to receive the Works with Google Home badge must conform to: 1) the Alliance's Matter certification, and 2) all other requirements as provided by Google.
• Matter and Cloud dual-stack devices
  • In order for a dual-stack device to receive and/or maintain a Works with Google Home badge, it must pass both 1) Matterintegration certification as above and 2) Works with Google Home Cloud integration certification. This includes any requirements for deduplication of dual-stack devices.
• Other Matter Requirements
  • If your app sets up Matter devices, support for the Commissioning API on Android is required for Works with Google Home certification.

4. Home APIs & Home Hub Runtime Integrations

This section applies to developers integrating with the Home APIs and any related Home hub runtime software of the Google Home Developer Platform (the "Home APIs & Home Hub Runtime").

1. Relevant APIs under this section include the Commissioning API,Home APIs, Automations API, and any further APIs that may be added from time to time.
2. The Home hub runtime includes all software required to turn a device into a hub for Google Home.

In the event of any conflict between the Google Home Developer Policies and this section on Home APIs & Home Hub Runtime integrations, the terms of the Home APIs & Home Hub Runtime integrations will control.

Each application integrating with the Home APIs & Home Hub Runtime - whether integrating via Google Play, third party app store, or other means - must comply with these Home APIs & Home Hub Runtime policies, the policies in the Google Play Developer Policy Center, Google'sOAuth API requirements, and API Services User Data Policy, and any other applicable Google requirements.

Device Sharing

Developers who integrate with the Home APIs & Home Home Hub Runtime must also contribute all their devices and signals supported by the Google Home data model to the Google Home Developer Platform. Doing so is a requirement of using the Home APIs & Home Hub Runtime, and certification for Works with Google Home. The following will also apply:

• To access the Home APIs & Home Hub Runtime and Works with Google Home badging, the following applies to the below types of developers:
  • All Developers: You must share all non-device signals supported by the Google Home data model that are used as starters for automations. Hypothetical examples include, whole home signals (e.g., presence, etc.) or customer behavior signals (e.g., food delivery occurring, etc).
  • For Matter and/or Cloud to Cloud OEM Developers: You must support sharing your devices to the Google Home platform. How you share those devices depends on the connectivity capabilities of the device:
    i. For Devices that support Matter connectivity only: You must use the Commissioning API with Home flag set to true on all platforms, in order to add the device to the Google Home fabric. In addition, you may also add the device to your own fabric if you so wish.
    ii. For Devices that can only be shared via Cloud to Cloud: You must support sharing all your devices to Google Home via cloud to cloud linking. This must include all required traits (attributes, events (including device state), commands) supported for that device type in the Google Home data model.
    iii. For Devices supporting both Matter and Cloud to Cloud connections: You must support sharing your devices to Google Home via (i) and/or (ii).
• Device Name / Structure Sharing: If the customer has the ability to change the name of a device, or the association between a device and a room in your application, this information must be replicated to the Home APIs & Home Hub Runtime so that the view of a customer's home remains consistent across clients.
• Matter Device Decommissioning: If you remove the Google Home fabric from any Matter devices through your app, you must provide an explanation of the changes that will occur and get consent from the user before making those changes:
  • For Matter nodes that provide multiple endpoints, you must present users with a complete list of devices that will be removed once the fabric is removed.
  • You must also explain that the removed device(s) will also be removed from the Google Home app and any other Google Home partner app(s).
• Prohibition:
  • Non-Authenticated Surfaces: You may not use the Google Decommissioning APIs on shared surfaces, like TVs, where users aren't strongly authenticated at the time of use.
  • Programmatic Removal: If multiple fabrics are configured, you may not remove the Google Home fabric programmatically (e.g., without customer consent). This will result in enforcement pursuant to the Google Home Developer Policies.

Security, Privacy, and Prohibitions

• Security
  • Each app must comply with security assessment requirements as specified by Google, which may include assessments by third parties designated by Google, to maintain app access to the Home APIs & Home Hub Runtime.
• Google User Consent
  • Prior to accessing any user device and related data via the Home APIs & Home Hub Runtime, you must ensure that the user has provided consent before using the Home APIs & Home Hub Runtime to interact with the user's devices. You must not circumvent the collection of user consent required to grant access to your app to interact with the user's Google Home devices under any circumstances, including but not limited to, setup, control or automation interactions.
  • In addition to any other requirements set forth in these policies, in order for you to (1) have access to any Google-made device, including, but not limited to Google Nest, Google Home, or Chromecast, or (2) to obtain access to any user data from such devices using the Home APIs & Home Hub Runtime, you must obtain consent in a form approved by Google as well as include the Google Terms of Service and Privacy Policy in your app that uses the Home APIs & Home Hub Runtime that accesses the applicable Google Nest Devices.
• User Data Retention and Privacy
  • Data Retention: All data may only be retained by you for a maximum of 10 days trailing from the date when the data is received, unless subject to a shorter local regulation. Data, including user data and device data, must be deleted.
• Prohibited Actions
  • The following are expressly prohibited:
    * Aggregate control of Google products, services, or user data across multiple structures except to the extent Google permits control of multiple structures in a single Google Account, or unless approved in writing by Google. This prohibition includes use of user data as training inputs to AI models or any other use that violates applicable user data policies.
    * Attempting to: (1) extract PII of users (either singularly or across users), devices, home information, or structure and devices, (2) deobfuscate identities, including from API-returned obfuscated identities and/or (3) share inferred data with other parties.
    * Creation of a client that performs demand response, or other energy or utility management programs intended to modify settings for the primary purpose of energy or utility savings, load reduction, or other energy or utility related targets for consumers, utility companies or other energy program or service providers, unless approved in writing by Google.
    * Offering or advertising a client that provides emergency response, life-safety, or other critical use services that require notifications to be provided without interruption.
    * Creating a client which bypasses platform user safety protections, whether accidental or purposeful bypassing of safety checks.
    * Putting at risk the physical safety of users, including algorithmically adjusting user devices such as thermostat settings, smoke/CO detectors, or any other device impacting the safety of users.
    * Hacking or otherwise accessing Home hub runtime on devices, allowing access to Home data not intended to be shared with developer. This may include, but not be limited to, data the user has not expressly shared with Google.
    * Without the prior written consent of Google, (1) sharing, sublicensing, reselling, or redistributing to any other party any information provided by the Home APIs & Home Hub Runtime, (2) otherwise monetizing any information provided by the Home APIs & Home Hub Runtime, or (3) attempting to do any of the foregoing in (1) or (2).
• Non-Android App Integration with Home APIs & Home Hub Runtime
  • If you integrate the Home APIs & Home Hub Runtime with a non-Android application, you must follow the requirements of the platform for which you are building. You must also make available the Terms of Use and a Privacy Policy with your application which meets the guidelines outlined in your Agreement with Google:
    * The Terms of Use and Privacy Policy must be publicly available.
    * You must explicitly state in your application's Terms of Use that by using your application, users are bound by Google's Terms of Service.
    * You must notify users in your Privacy Policy that you are using the Home APIs & Home Hub Runtime and incorporate by reference theGoogle Privacy Policy.
    * If developing a mobile app, it is recommended that you provide a link to the Terms of Use and Privacy Policy on your application's download page in the relevant application store and in an application settings menu.