Provisioning is the process of setting up a device to be managed using [`policies`](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies) by an [`enterprise`](https://developers.google.com/android/management/reference/rest/v1/enterprises). During the process a device installs Android Device Policy, which is used to receive and enforce [`policies`](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies). If provisioning is successful, the API creates a [`devices`](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices) object, binding the device to an enterprise. > [!NOTE] > **Note:** If a device remains offline for 270 consecutive days, it will need to be reprovisioned. Android Management API uses enrollment tokens to trigger the provisioning process. The enrollment token and provisioning method you use establishes a device's ownership (personally-owned or company-owned) and management mode (work profile or fully managed device). A [quota system](https://developers.google.com/android/management/permissible-usage#quotas_and_restrictions) controls how many devices each project can manage. You must [request](https://goo.gle/android-enterprise-response) initial device quota before you can provision your first device. ### Personally-owned devices *Android 5.1+* Devices owned by employees can be set up with a **work profile** . A work profile provides a self-contained space for work apps and data, separate from personal apps and data. Most app, data, and other management [`policies`](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies) apply to the work profile only, while the employee's personal apps and data remain private. To set up a work profile on a personally-owned device, [create an enrollment token](https://developers.google.com/android/management/provision-device#create_an_enrollment_token) (ensure `allowPersonalUsage` is set to `PERSONAL_USAGE_ALLOWED`) and use one of the following provisioning methods: - [Add work profile from "Settings"](https://developers.google.com/android/management/provision-device#add_work_profile_from_settings) - [Download Android Device Policy](https://developers.google.com/android/management/provision-device#download_android_device_policy) - [Enrollment token link](https://developers.google.com/android/management/provision-device#enrollment_token_link) - [Sign-in URL](https://developers.google.com/android/management/provision-device#sign-in_url) ### Company-owned devices for work and personal use *Android 8+* Setting up a company-owned device with a **work profile** enables the device for both work and personal use. On company-owned devices with work profiles: - Most app, data, and other management `policies` apply to the work profile only. - The employee's personal profile remains private. However, enterprises can enforce certain [device-wide policies](https://developers.google.com/android/management/policies/work-profile#device-wide_policies) and [personal usage policies](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#personalusagepolicies). - Enterprises can use [`blockScope`](https://developers.google.com/android/management/provision-device#create_an_enrollment_token) to enforce compliance actions on an entire device or only its work profile. - [`devices.delete`](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/delete) and [device commands](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/issueCommand) apply to an entire device. To set up a company-owned device with a work profile, [create an enrollment token](https://developers.google.com/android/management/provision-device#create_an_enrollment_token) (ensure `allowPersonalUsage` is set to `PERSONAL_USAGE_ALLOWED`) and use one of the following provisioning methods: - [Zero-touch enrollment](https://developers.google.com/android/management/provision-device#zero-touch_enrollment) - [QR code](https://developers.google.com/android/management/provision-device#qr_code_method) - [Sign-in URL](https://developers.google.com/android/management/provision-device#sign-in_url) - [DPC identifier](https://developers.google.com/android/management/provision-device#dpc_identifier_method) ### Company-owned devices for work use only *Android 5.1+* **Full device management** is suitable for company-owned devices intended exclusively for work purposes. Enterprises can manage all apps on the device and can enforce the full spectrum of Android Management API policies and commands. It's also possible to lock a device down ([via policy](https://developers.google.com/android/management/policies/dedicated-devices)) to a single app or small set of apps to serve a dedicated purpose or use case. This subset of fully managed devices is referred to as **dedicated devices** . Enrollment tokens for these devices must have `allowPersonalUsage` set to [`PERSONAL_USAGE_DISALLOWED_USERLESS`](https://developers.google.com/android/management/reference/rest/v1/AllowPersonalUsage#ENUM_VALUES.PERSONAL_USAGE_DISALLOWED_USERLESS). To set up full management on a company-owned device, create an enrollment token, ensuring `allowPersonalUsage` is set to [`PERSONAL_USAGE_DISALLOWED`](https://developers.google.com/android/management/reference/rest/v1/AllowPersonalUsage#ENUM_VALUES.PERSONAL_USAGE_DISALLOWED) or [`PERSONAL_USAGE_DISALLOWED_USERLESS`](https://developers.google.com/android/management/reference/rest/v1/AllowPersonalUsage#ENUM_VALUES.PERSONAL_USAGE_DISALLOWED_USERLESS), and use one of the following provisioning methods. - [Zero-touch enrollment](https://developers.google.com/android/management/provision-device#zero-touch_enrollment) - [QR code](https://developers.google.com/android/management/provision-device#qr_code_method) - [Sign-in URL](https://developers.google.com/android/management/provision-device#sign-in_url) (not suitable for dedicated devices) - [NFC](https://developers.google.com/android/management/provision-device#nfc_method) - [DPC identifier](https://developers.google.com/android/management/provision-device#dpc_identifier_method) > [!NOTE] > **Note:** PERSONAL_USAGE_DISALLOWED requires users to sign in with a work email to access the device. PERSONAL_USAGE_DISALLOWED_USERLESS sets up an anonymous and userless account on the device. **Policies** can impact the generation of the UI during device provisioning. Such policies are: - [`PasswordPolicyScope`](https://developers.google.com/android/management/reference/rest/v1/PasswordRequirements): This determines password requirements. - [`PermittedInputMethods`](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#permittedInputMethods): This determines package input methods. - [`PermittedAccessibilityServices`](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#permittedAccessibilityServices): This determines which accessibility services are permitted for fully managed devices and work profile. - [`SetupActions`](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#setupaction): This determines what actions are executed during setup. - [`ApplicationsPolicy`](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#applicationpolicy): This determines the policy for an individual app. If you want for password steps to be shown alongside installation of work apps and device register cards during device provisioning, we suggest updating your policies to delay initiation of the UI generation by keeping the device in a [quarantine state](https://developers.google.com/android/management/provision-device#apply_a_policy_to_newly_enrolled_devices), which occurs if enrolled without an associated policy, until specifying the final selected policy for device setup populated with items relevant to your setup needs. Once provisioning of the device has been completed, you can [change the policy](https://developers.google.com/android/management/create-policy) as required. *** ** * ** *** ## Create an enrollment token > [!NOTE] > **Note:** If you're provisioning a device from a sign-in URL, you need to create an enrollment token differently. See [Sign-in URL](https://developers.google.com/android/management/provision-device#sign-in_url) for details. ![Android Management overview.](https://developers.google.com/static/android/management/images/enrollment-token.png) **Figure 1.** Create a token that enrolls and applies "policy1" to devices. After 1800 seconds (30 minutes), the token expires. You need an enrollment token for each device that you want to enroll (you can use the same token for multiple devices). To request an enrollment token, call [`enterprises.enrollmentTokens.create`](https://developers.google.com/android/management/reference/rest/v1/enterprises.enrollmentTokens/create). Enrollment tokens expire after one hour by default, but you can specify a [custom expiration time](https://developers.google.com/android/management/reference/rest/v1/enterprises.enrollmentTokens#EnrollmentToken.FIELDS.duration) (`duration`) up to approximately 10,000 years. A successful request returns an `enrollmentToken` object containing an `enrollmentTokenId` and a `qrcode` that IT admins and end users can use to provision devices. ### Specify a policy You might also want to specify a `policyName` in the request to apply a policy at the same time a device is enrolled. If you don't specify a `policyName`, see [Enroll a device without a policy](https://developers.google.com/android/management/provision-device#enroll_a_device_without_a_policy). ### Specify personal usage `allowPersonalUsage` determines if a work profile can be added to the device during provisioning. Set to `PERSONAL_USAGE_ALLOWED` to allow a user to create a work profile (required for personally-owned devices, optional for company-owned devices). ### Exemption for existing enrollment tokens Some customers use enrollment tokens with long expiration dates to perform repeated enrollments. To make sure these existing workflows aren't interrupted, any tokens created BEFORE the "Authenticate using Google" requirement was enabled for the first time are exempt from the new login prompts. These older tokens will continue to work as they did before, allowing users to enroll devices without undergoing the Google authentication process. However, any tokens created AFTER the Google authentication requirement was turned on for the first time follow the new authentication rules. This means that devices using these newer tokens require users to authenticate according to the settings chosen by the IT admin. For dedicated devices that shouldn't store user data, ensure `allowPersonalUsage` is set to `PERSONAL_USAGE_DISALLOWED_USERLESS` to avoid displaying the authentication screen. ### Enforce Google authentication on enrollment EMMs can enforce Google Account sign-in during device enrollment by setting the appropriate values on the enrollment token or sign-in token. This configuration determines whether the "Skip" button is hidden on the Google sign-in screen. When set, these options override the enterprise-wide `googleAuthenticationSettings` policy. #### Configuration options You can control authentication behavior using the googleAuthenticationOptions object within either an `EnrollmentToken` or a `SigninDetail`. |---|---|---| | Field | Description | Values | | `authenticationRequirement` | Specifies whether the user must authenticate with Google during enrollment. | **AUTHENTICATION_REQUIREMENT_UNSPECIFIED:** Falls back to the enterprise default settings. **OPTIONAL:** The user sees the Google sign-in screen but can choose to skip it. **REQUIRED:** The user cannot skip sign-in. The "Skip" button is hidden. | | `requiredAccountEmail` | The specific managed Google Account email the user must use. **Note:** `authenticationRequirement` MUST be set to REQUIRED if this field is used. | String (e.g., "user@enterprise.com") | #### JSON Payload Examples **Disable the skip button** To hide the "Skip" button and force the user to sign in with any valid enterprise account, set the authentication requirement to REQUIRED. { ... "googleAuthenticationOptions": { "authenticationRequirement": "REQUIRED" } } **Require a specific account email** To force the user to sign in with a designated account, define the `requiredAccountEmail` string. The token creation request will fail with an INVALID_ARGUMENT error if the requirement field is not set to REQUIRED alongside it. { ... "googleAuthenticationOptions": { "authenticationRequirement": "REQUIRED", "requiredAccountEmail": "user@enterprise.com" } } *** ** * ** *** ## About QR Codes QR codes work as an efficient device provisioning method for enterprises that maintain many different policies. The QR Code returned from `enterprises.enrollmentTokens.create` is made up of a payload of key-value pairs containing an enrollment token and all the information that's needed for Android Device Policy to provision a device. ### Example QR Code bundle > [!NOTE] > **Note:** When pasting the `qrCode` string, make sure to remove all escape '\\' characters. The bundle includes the download location of Android Device Policy and an enrollment token. { "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver", "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg", "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup", "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{ "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "{enrollment-token}" } } You can use the QR Code returned from `enterprises.enrollmentTokens.create` directly or customize it. For a full list of properties that you can include in a QR Code bundle, see [Create a QR Code](https://developers.google.com/android/work/play/emm-api/prov-devices#create_a_qr_code). To convert the `qrcode` string into a scannable QR Code, use a QR Code generator such as [ZXing](https://zxing.appspot.com/generator/). *** ** * ** *** ## Provisioning methods This section describes different methods for provisioning a device. ### Add work profile from "Settings" *Android 5.1+* > [!NOTE] > **Note:** This method requires Google Play services to be up-to-date; if a device has just been reset, the user may need to update Google Play services before trying to add a work profile. To set up a work profile on their device, a user can: 1. Go to **Settings** \> **Google** \> **Set up \& restore**. 2. Tap **Set up your work profile**. These steps initiate a setup wizard that downloads Android Device Policy on the device. Next, the user will be prompted to scan a [QR code](https://developers.google.com/android/management/provision-device#about_qr_codes) or manually enter an enrollment token to complete the work profile setup. ### Download Android Device Policy *Android 5.1+* To set up a work profile on their device, a user can download [Android Device Policy](https://play.google.com/store/apps/details?id=com.google.android.apps.work.clouddpc) from the Google Play Store. After the app is installed, the user will be prompted to [QR code](https://developers.google.com/android/management/provision-device#about_qr_codes) or manually enter an enrollment token to complete the work profile setup. ### Enrollment token link *Android 5.1+* > [!NOTE] > **Note:** This method requires Google Play services to be up-to-date; if a device has just been reset, the user may need to update Google Play services before trying to add a work profile. Using the enrollment token returned from `enrollmentTokens.create` or the enterprise's [`signinEnrollmentToken`](https://developers.google.com/android/management/see%20%5BSign-in%20URL%5D(#sign-in_url)%20below), generate a URL with the following format: https://enterprise.google.com/android/enroll?et= You can provide this URL to IT admins, who can provide it to their end users. When an end user opens the link from their device, they will be guided through the work profile setup. ### Sign-in URL With this method, users are directed to a page to enter any additional information required to complete provisioning. Based on the information the user enters, you can calculate the appropriate policy for the user before proceeding with device provisioning. For example: 1. Specify your sign-in URL in [`enterprises.signInDetails[]`](https://developers.google.com/android/management/reference/rest/v1/enterprises#signindetail). Set `allowPersonalUsage` to `PERSONAL_USAGE_ALLOWED` if you want to allow a user to create a work profile (required for personally-owned devices, optional for company-owned devices). Add the resulting `signinEnrollmentToken` as provisioning extra to a [QR code](https://developers.google.com/android/management/provision-device#qr_code_method), [NFC payload](https://developers.google.com/android/management/provision-device#nfc_method), or [Zero-touch configuration](https://developers.google.com/android/management/provision-device#zero-touch_enrollment). Alternatively, you can provide the `signinEnrollmentToken` to users directly. > [!NOTE] > **Note:** Similar to the enrollment token generation, if a sign-in URL created an enrollment token BEFORE the organization enabled "Authenticate using Google" for the first time, the user won't be prompted to sign in. However, any tokens created after that setting was turned on will follow updated behavior and use the authentication settings configured by the IT admin. 2. Choose an option: 1. **Company-owned devices:** After turning on a new or factory-reset device, pass the `signinEnrollmentToken` to the device (via QR Code, NFC bump, etc.) or ask users need to enter the token manually. The device will open the sign-in URL specified in Step 1. 2. **Personally-owned devices:** Ask users to [add a work profile from "Settings"](https://developers.google.com/android/management/provision-device#add_work_profile_from_settings). When prompted, the user scans a QR Code containing the `signinEnrollmentToken` or enters the token manually. The device will open the sign-in URL specified in Step 1. 3. **Personally-owned devices:** Provide users with an [enrollment token link](https://developers.google.com/android/management/provision-device#enrollment_token_link), where the enrollment token is the `signinEnrollmentToken`. The device will open the sign-in URL specified in Step 1. 3. Check whether Google has already authenticated the user. Get the device provisioning information (during device enrollment) using the GET parameter [`provisioningInfo`](https://developers.google.com/android/management/reference/rest/v1/provisioningInfo/get) and check for a value for the field `authenticatedUserEmail`. If there is a value in this field, the user was already successfully authenticated by Google and you can use this identity without further authentication. > [!NOTE] > **Note:** The `provisioningInfo` object is available for up to 24 hours after device provisioning. 4. If Google has not already authenticated the user then your sign-in URL should prompt users to enter their credentials. Based on their identity, you can determine the appropriate policy and get the device provisioning information (during device enrollment) using the GET parameter [`provisioningInfo`](https://developers.google.com/android/management/reference/rest/v1/provisioningInfo/get). > [!IMPORTANT] > **Best practice:** Use the organization's SSO provider to authenticate the credentials your users enter in the sign-in URL (or any subsequent redirects). Sign-in URLs are opened in a Chrome Custom Tab, and users' SSO are saved for future app sign-in using [App Auth](https://appauth.io/). 5. Call [`enrollmentTokens.create`](https://developers.google.com/android/management/reference/rest/v1/enterprises.enrollmentTokens/create), specifying the appropriate `policyId` based on the user's credentials. > [!NOTE] > **Note:** The `allowPersonalUsage` field is ignored because the value was already specified in [`enterprises.signInDetails[]`](https://developers.google.com/android/management/reference/rest/v1/enterprises#signindetail). It isn't possible to change the personal usage value during enrollment. 6. Return the enrollment token generated in Step 5 using URL redirect, in the form `https://enterprise.google.com/android/enroll?et=`. > [!NOTE] > **Note:** If a user isn't permitted to complete the provisioning process, you can display custom error screens and redirect to `https://enterprise.google.com/android/enroll/invalid` to help the user reset their device. ### Enforce Google authentication with sign-in URL flow When you use [`SigninDetail`](https://developers.google.com/android/management/reference/rest/v1/enterprises#signindetail) for third-party sign-in flows (via enterprises.create or enterprises.patch), you can pass `googleAuthenticationOptions`. This enforces rules before the user is redirected to the third-party sign-in URL. When an `EnrollmentToken` is created at the end of a sign-in URL flow, its authentication requirements interact with the initial `SigninDetail`: - If the user skipped Google sign-in because it wasn't required by `SigninDetail`, but the resulting `EnrollmentToken` has its requirement set to REQUIRED, the user will see an error and will need to sign in. - If `requiredAccountEmail` is set on the token and the user signed in with a different address belonging to the enterprise, they will receive a "Wrong account" error and will need to sign in again with the correct required email. ### QR Code method *Android 7.0+* To provision a company-owned device, you can [generate a QR code](https://developers.google.com/android/management/provision-device#about_qr_codes) and display it in your EMM console: 1. On a new or factory-reset device, the user (typically an IT admin) taps the screen six times in the same spot. This triggers the device to prompt the user to scan a QR Code. 2. The user scans the QR Code that you display in your management console (or similar application) to enroll and provision the device. ### NFC method *Android 6.0+* > [!NOTE] > **Note:** Devices must have NFC enabled. The NFC provisioning method only supports full device management provisioning and cannot be used for company-owned, personally enabled (COPE) provisioning on Android 11 devices. This method requires you to create an NFC programmer app that contains the enrollment token, initial policies and Wi-Fi configuration, settings, and all other provisioning details required by your customer to provision a fully managed or dedicated device. When you or your customer installs the NFC programmer app on an Android-powered device, that device becomes the programmer device. Detailed guidance on how to support the NFC method is available in the [Play EMM API](https://developers.google.com/android/work/play/emm-api/prov-devices#nfc_method) developer documentation. The site also includes [sample code of the default parameters](https://developers.google.com/android/work/play/emm-api/prov-devices#default_parameters) pushed to a device on an NFC bump. To install Android Device Policy, set the download location of the device admin package to: https://play.google.com/managed/downloadManagingApp?identifier=setup ### DPC identifier method If Android Device Policy can't be added using QR Code or NFC, a user or IT admin can follow these steps to provision a company-owned device: 1. Follow the setup wizard on a new or factory-reset device. 2. Enter Wifi login details to connect the device to the internet. 3. When prompted to sign in, enter **afw#setup**, which downloads Android Device Policy. 4. Scan a [QR code](https://developers.google.com/android/management/provision-device#about_qr_codes) or manually enter an enrollment token to provision the device. ### Zero-touch enrollment *Android 8.0+ (Pixel 7.1+)* Devices purchased from an [authorized zero-touch reseller](https://www.android.com/enterprise/management/zero-touch/) are eligible for zero-touch enrollment, a streamlined method for preconfiguring devices to provision themselves automatically on first boot. Organizations can create configurations containing provisioning details for their zero-touch devices, either through the [zero-touch enrollment portal](https://partner.android.com/zerotouch) or using your EMM console (see the [zero-touch customer API](https://developers.google.com/zero-touch/guides/customer/how-it-works)). On first boot, a zero-touch device checks if it's been assigned a configuration. If so, the device downloads Android Device Policy, which then completes setup of the device using the provisioning extras specified in its assigned configuration. If your customers use the [zero-touch enrollment portal](https://partner.android.com/zerotouch), they need to select *Android Device Policy* as the EMM DPC for each configuration they create. Detailed instructions on how to use the portal, including how to create and assign configurations to devices, are available in the [Android Enterprise help center](https://support.google.com/work/android/answer/7514005). If you prefer your customers to set and assign configurations directly from your EMM console, you need to integrate with the [zero-touch customer API](https://developers.google.com/zero-touch/guides/customer/how-it-works). When [creating a configuration](https://developers.google.com/zero-touch/reference/customer/rest/v1/customers.configurations/create), you specify provisioning extras in the `dpcExtras` field. The following JSON snippet shows a basic example of what to include in `dpcExtras`, with an added sign-in token. { "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver", "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":"I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg", "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{ "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":"{Sign In URL token}" } } *** ** * ** *** ## Launch an app during setup ![setupaction](https://developers.google.com/static/android/management/images/setupaction.png) **Figure 2.** Use `setupActions` to launch an app during setup. In `policies`, you can specify one app for Android Device Policy to launch during device or work profile setup. For example, you could launch a VPN app so users can configure VPN settings as part of the setup process. The app must return [`RESULT_OK`](https://developer.android.com/reference/android/app/Activity#RESULT_OK) to signal completion and allow Android Device Policy to complete device or work profile provisioning. To launch an app during setup: Ensure the app's `installType` is `REQUIRED_FOR_SETUP`. If the app can't be installed or launched on the device, provisioning will fail. { "applications":[ { "packageName":"com.my.vpnapp.", "installType":"REQUIRED_FOR_SETUP" } ] } Add the app's package name to `setupActions`. Use `title` and `description` to specify user-facing instructions. { "setupActions":[ { "title":{ "defaultMessage":"Configure VPN" }, "description":{ "defaultMessage":"Enable your VPN client to access corporate resources." }, "launchApp":{ "packageName":"com.my.vpnapp." } } ] } To distinguish that an app is launched from `launchApp`, the activity that's first launched as part of the app contains the boolean intent extra `com.google.android.apps.work.clouddpc.EXTRA_LAUNCHED_AS_SETUP_ACTION` (set to `true`). This extra lets you customize your app based on whether it's launched from `setupActions` or by a user. After the app returns `RESULT_OK`, Android Device Policy completes any remaining steps required to provision the device or work profile. ### Cancel enrollment during setup The app launched as [SetupAction](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#setupaction) can cancel enrollment returning [`RESULT_FIRST_USER`](https://developer.android.com/reference/android/app/Activity#RESULT_FIRST_USER). Canceling the enrollment resets a company-owned device or deletes the work profile on a personally-owned device. **Note** : Canceling the enrollment triggers the action without a user confirmation dialog. It is the responsibility of the app to show an appropriate error dialog to the user prior to returning `RESULT_FIRST_USER`. ## Apply a policy to newly enrolled devices The method you use to apply policies to newly enrolled devices is up to you and the requirements of your customers. Here are the different approaches you can use: - **(Recommended)** When [creating an enrollment token](https://developers.google.com/android/management/reference/rest/v1/enterprises.enrollmentTokens/create), you can specify the name of the policy (`policyName`) that will be initially linked to the device. When you enroll a device with the token, the policy is automatically applied to the device. - Set a policy as the default policy for an enterprise. If no policy name is specified in the enrollment token and there is a policy with the name `enterprises//policies/default`, each new device is automatically linked to the default policy at the time of enrollment. - [Subscribe to a Cloud Pub/Sub topic](https://developers.google.com/android/management/notifications) to receive notifications about newly enrolled devices. In response to an [`ENROLLMENT`](https://developers.google.com/android/management/reference/rest/v1/enterprises#notificationtype) notification, call [`enterprises.devices.patch`](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/patch) to link the device with a policy. ## Enroll a device without a policy If a device is enrolled without a valid policy, then the device is placed into **quarantine**. Quarantined devices are blocked from all device functions until the device is linked to a policy. If a device is not linked to a policy in five minutes, then device enrollment fails and the device is factory reset. The quarantine device state gives you the opportunity to implement licensing checks or other enrollment validation processes as part of your solution. ### Example licensing check workflow 1. A device is enrolled without a default policy or specific policy. 2. Check how many licenses the enterprise has remaining. 3. If there are licenses available, use [`devices.patch`](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/patch) to attach a policy to the device, and then decrement your license count. If there are no licenses available, use `devices.patch` to disable the device. Alternatively, the API factory resets any device that is not attached to a policy within five minutes of enrollment.