उपयोगकर्ता खाते लागू करना

Android Enterprise में रजिस्टर करने के लिए, उपयोगकर्ता की पहचान के दो मुख्य टाइप होते हैं: मैनेज किए जा रहे Google Play खाते और मैनेज किए जा रहे Google खाते. Managed Google Play खाते, डिवाइस के हिसाब से होते हैं. इसका मतलब है कि ये किसी खास उपयोगकर्ता की Google पहचान से नहीं जुड़े होते. इसके उलट, मैनेज किए जा रहे Google खाते, उपयोगकर्ता की कॉर्पोरेट Google पहचान से लिंक होते हैं. इससे उपयोगकर्ता को बेहतर अनुभव मिलता है, क्योंकि वह अपने डिवाइसों पर लॉग इन रहता है.

Managed Google Play खातों का इस्तेमाल पहले स्टैंडर्ड के तौर पर किया जाता था. हालांकि, Google अब सभी नए डेवलपमेंट को बेहतर एनरोलमेंट फ़्लो का इस्तेमाल करने के लिए प्रोत्साहित करता है. इससे डिफ़ॉल्ट रूप से मैनेज किए जा रहे Google खाते बनाए जाते हैं.

इस दस्तावेज़ के आखिर में, पुराने तरीके से लागू करने के बारे में जानकारी दी गई है. हालांकि, सभी नए डेवलपमेंट में, यहां दिए गए एनरोलमेंट के नए फ़्लो का पालन किया जाना चाहिए.

खास जानकारी

डिवाइस रजिस्टर करने की बेहतर सुविधा से, डिवाइस सेटअप करने की प्रोसेस आसान हो जाती है. ऐसा कई नए कॉम्पोनेंट का इस्तेमाल करके किया जाता है. साथ ही, कस्टम डिवाइस नीति कंट्रोलर (डीपीसी) को लागू करने का तरीका भी बदल दिया जाता है. इस नए तरीके के लिए, कस्टम DPC समाधानों को Android Management API (AMAPI) SDK और Android Device Policy के साथ इंटिग्रेट करना ज़रूरी है. इससे डिवाइस तैयार करने और उपयोगकर्ता के रजिस्ट्रेशन से जुड़े फ़ंक्शन पूरे किए जा सकते हैं.

AMAPI SDK, डिवाइस पर Android Device Policy के साथ इंटरैक्ट करने के लिए ज़रूरी एपीआई उपलब्ध कराता है. सर्वर साइड पर, एंटरप्राइज़ मोबिलिटी मैनेजमेंट (ईएमएम) समाधान, Play EMM API का इस्तेमाल करके, डिवाइस के रजिस्ट्रेशन की प्रोसेस शुरू करने के लिए ज़रूरी रजिस्ट्रेशन टोकन जनरेट करेंगे.

Android Device Policy ऐप्लिकेशन अब डिवाइस से जुड़ी कार्रवाइयों को मैनेज करने में अहम भूमिका निभाता है. AMAPI SDK का इस्तेमाल, डिवाइस पर इसे इंस्टॉल करने और ज़रूरी अपडेट को मैनेज करने के लिए किया जाता है. Android Device Policy भी उपयोगकर्ता की पुष्टि करने के फ़्लो को अपने कंट्रोल में ले लेती है. यह सीधे तौर पर उपयोगकर्ता की पुष्टि करती है और ईएमएम को उपयोगकर्ता की पहचान की जानकारी देती है. अगर Google किसी वजह से उपयोगकर्ता की पुष्टि नहीं कर पाता है, तो एक नया मैनेज किया गया Google Play खाता बनाया जाता है. साथ ही, इसे डिवाइस में फ़ॉलबैक के तौर पर जोड़ दिया जाता है.

इस नए एनरोलमेंट फ़्लो का मुख्य हिस्सा, Google की सेवाओं को डिवाइस का ऐक्सेस मैनेज करना है. डिफ़ॉल्ट रूप से, डिवाइसों को प्रतिबंधित मोड में शुरू किया जाता है. डिवाइस के ज़रूरी शर्तें पूरी करने के बाद, ईएमएम डिवाइस को ऐक्सेस करने की सुविधा चालू करने में अहम भूमिका निभाता है.

एपीआई इंटिग्रेशन

शुरू करने से पहले, पुष्टि करें कि Play EMM API क्लाइंट और AMAPI SDK के सबसे नए वर्शन का इस्तेमाल किया जा रहा हो.

रजिस्ट्रेशन की सुविधा लागू करने के बारे में जानकारी

इस गाइड में, रजिस्टर करने के लिए ज़रूरी चरणों के बारे में बताया गया है. इसमें एनवायरमेंट तैयार करना, रजिस्ट्रेशन के अलग-अलग तरीकों को मैनेज करना, और डिवाइस के लाइफ़साइकल को मैनेज करना शामिल है.

एनवायरमेंट तैयार करना

खाता सेट अप करने से पहले, डिवाइस का एनवायरमेंट तैयार करना ज़रूरी है. इसके लिए, Play Store को उसके नए वर्शन पर अपडेट किया जाता है. साथ ही, डिवाइस पर Android Device Policy (com.google.android.apps.work.clouddpc) को साइलेंट मोड में इंस्टॉल किया जाता है. Android Device Policy ऐप्लिकेशन को इंस्टॉल करना ज़रूरी है, क्योंकि इसमें खाता सेट अप करने की प्रोसेस के अहम कॉम्पोनेंट होते हैं. EMM को मैन्युअल तरीके से एनवायरमेंट तैयार करने की ज़रूरत नहीं होती. इसके बजाय, उन्हें EnvironmentClient का इस्तेमाल करना चाहिए. इसके बारे में यहां बताया गया है. साथ ही, उन्हें कोड के दिए गए उदाहरणों का पालन करना चाहिए.

नमूना कोड

डिवाइस पर काम से जुड़ा खाता जोड़ने के लिए, AccountSetup API का इस्तेमाल करने से पहले, DPC को यह पुष्टि करनी होगी कि डिवाइस का एनवायरमेंट तैयार है.

  • EnvironmentClientFactory का इस्तेमाल करके, EnvironmentClient को इंस्टैंशिएट करें और prepareEnvironment या prepareEnvironmentAsync को कॉल करें

    val notificationReceiverServiceName = ComponentName(context,
NotificationReceiver::class.java)

// An EMM should implement android.app.admin.DeviceAdminReceiver and use that
// class to instantiate a ComponentName

val admin = ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java)

EnvironmentClientFactory.create(context)
    .prepareEnvironment(
        PrepareEnvironmentRequest.builder()
            .setRoles(
                listOf(
                    Role.builder().setRoleType(
                        Role.RoleType.DEVICE_POLICY_CONTROLLER
                    ).build()
                )
            )
    .setAdmin(admin)
            .build(),
          notificationReceiverServiceName,
        )

[Proceed with AccountSetup]

इस प्रोसेस में कुछ सेकंड या मिनट लग सकते हैं, क्योंकि सही वर्किंग एनवायरमेंट की पुष्टि करने के लिए ऐप्लिकेशन इंस्टॉल या अपडेट किए जा सकते हैं. Google का सुझाव है कि इस प्रोसेस को बैकग्राउंड में जल्द से जल्द शुरू कर दें. साथ ही, जब तक उपयोगकर्ता इंतज़ार करता है, तब तक उसे सही यूज़र इंटरफ़ेस (यूआई) दिखाएं. यह प्रोसेस पूरी होने के बाद, डिवाइस पर DPC, AccountSetup API का इस्तेमाल कर सकता है.

रजिस्ट्रेशन फ़्लो

EMM को सभी डिवाइसों के लिए, users.generateAuthenticationToken() और users.insert() का इस्तेमाल बंद करना होगा. इसके बजाय, ईएमएम को असली उपयोगकर्ता की पुष्टि करने के लिए, डिवाइस पर मौजूद एपीआई को कॉल करना होगा. नया एपीआई, DPC को userId और email की जानकारी देगा. अगर Google उपयोगकर्ता की पुष्टि नहीं कर पाता है, तो Managed Google Play खाता बनाया जाएगा और उसे डिवाइस में जोड़ दिया जाएगा. ऐसे में, Google उस खाते का userId वापस कर देगा.

Google ने अब एनरोलमेंट टोकन का इस्तेमाल शुरू कर दिया है. इन्हें पुष्टि करने वाले एपीआई को पास करना ज़रूरी है. ईएमएम तय करते हैं कि टोकन कब और कैसे बनाया जाए. साथ ही, यह मौजूदा एनरोलमेंट पेलोड (जैसे, क्यूआर कोड या ज़ीरो-टच कॉन्फ़िगरेशन) का हिस्सा हो सकता है.

हालांकि, Google का सुझाव है कि टोकन को ज़रूरत के हिसाब से बनाया जाए. साथ ही, मैनेज किए जा रहे Google Play खातों के लिए मौजूदा एपीआई को नए एपीआई से बदल दिया जाए, ताकि बदलाव को कम किया जा सके.

पिछले एपीआई के साथ डीपीसी का सामान्य इंटिग्रेशन
पहली इमेज.
उपयोगकर्ता के बिना डिवाइसों के लिए, नए एपीआई के साथ DPC इंटिग्रेशन का उदाहरण
दूसरी इमेज. उपयोगकर्ता के बिना डिवाइसों के लिए, नए एपीआई के साथ DPC इंटिग्रेशन का उदाहरण
उपयोगकर्ता के डिवाइसों के लिए, नए एपीआई के साथ DPC इंटिग्रेशन का उदाहरण
तीसरी इमेज. उपयोगकर्ता के डिवाइसों के लिए, नए एपीआई के साथ DPC इंटिग्रेशन का उदाहरण

कस्टम डीपीसी में बेहतर तरीके से रजिस्टर करने के लिए, यह तरीका अपनाएं:

डिवाइस की शुरुआती स्थिति के बारे में अहम जानकारी: कस्टम डीपीसी के साथ किसी डिवाइस को रजिस्टर करते समय, डिवाइस में जोड़ा गया Google खाता बंद स्थिति में होता है. इसका मतलब है कि Google Play के साथ-साथ Google की अन्य सेवाओं को ऐक्सेस करने पर भी पाबंदी लगाई जाती है.

डिफ़ॉल्ट रूप से "बंद है" स्थिति और ईएमएम के लिए डिवाइस को नीति का पालन करने वाला डिवाइस के तौर पर मार्क करने की ज़रूरत (जैसे, Devices.SetState को कॉल करके) खास तौर पर इन स्थितियों में लागू होती है:

  1. संगठन ने Google के साथ अपने डोमेन के मालिकाना हक की पुष्टि कर ली है.
  2. आईटी एडमिन ने Google Admin console में, उपयोगकर्ता की खास संगठन की इकाई (ओयू) के लिए, तीसरे पक्ष के Android मोबाइल मैनेजमेंट को साफ़ तौर पर चालू किया हो.
  1. रजिस्ट्रेशन टोकन बनाना: ईएमएम, Play EMM API का इस्तेमाल करके रजिस्ट्रेशन टोकन बनाता है.
  2. एनवायरमेंट तैयार करना: कस्टम DPC, एनवायरमेंट तैयार करने के फ़्लो का इस्तेमाल करता है, ताकि यह पुष्टि की जा सके कि डिवाइस रजिस्ट्रेशन के लिए तैयार है.
  3. पंजीकरण शुरू करना: कस्टम डीपीसी, AMAPI SDK में startAccountSetup एपीआई को शुरू करता है. साथ ही, इसमें रजिस्ट्रेशन टोकन पास करता है. ध्यान दें: इस एपीआई को कॉल करने से पहले, DPC को डिवाइस का मालिक या प्रोफ़ाइल का मालिक होना चाहिए.
  4. Google पर पुष्टि करने की गतिविधि शुरू करना: अगर ज़रूरी हो, तो कस्टम डीपीसी, AMAPI SDK में launchAuthenticationActivity एपीआई को कॉल करता है और AccountSetupAttempt पास करता है. इससे Google की पुष्टि करने की गतिविधि शुरू होती है. पुष्टि हो जाने पर, उपयोगकर्ता को कस्टम डीपीसी पर वापस भेज दिया जाता है. उपयोगकर्ता इस प्रोसेस को स्किप भी कर सकता है. इस मामले में, डिवाइस में मैनेज किया गया Google Play खाता जोड़ा जाएगा. इस विकल्प को googleAuthenticationOptions का इस्तेमाल करके कॉन्फ़िगर किया जा सकता है.
  5. रजिस्ट्रेशन पूरा करना: AMAPI SDK, कस्टम DPC को रजिस्ट्रेशन के नतीजे के बारे में सूचना देता है.

  6. Google की सेवाएं चालू करें: जब कस्टम DPC, डिवाइस को पूरी तरह से प्रोविज़न कर देता है और यह पुष्टि कर देता है कि डिवाइस, एंटरप्राइज़ की सभी नीतियों का पालन करता है, तब EMM सर्वर को Devices.setState() को कॉल करना ज़रूरी है. साथ ही, accountState पैरामीटर को "enabled" पर सेट करना भी ज़रूरी है.

    • यह क्यों ज़रूरी है: इस एपीआई कॉल से, डिवाइस को नीति का पालन करने वाले डिवाइस के तौर पर मार्क किया जाता है.
    • कॉल न करने पर: इस Devices.setState(setStateRequest) कॉल के बिना, खाता "बंद" स्थिति में रहता है. उपयोगकर्ता, Google Play को ऐक्सेस नहीं कर पाएगा. इससे वह ऐप्लिकेशन इंस्टॉल या अपडेट नहीं कर पाएगा. साथ ही, वह Google की उन सेवाओं को भी ऐक्सेस नहीं कर पाएगा जिनके लिए खाते की पुष्टि करना ज़रूरी है.

डिवाइस का स्टेटस और सेवा का ऐक्सेस मैनेज करना

शुरुआती रजिस्ट्रेशन के बाद, EMM की यह ज़िम्मेदारी होती है कि वह डिवाइस के लिए Google की सेवाओं का ऐक्सेस बनाए रखे. यह इस बात पर निर्भर करता है कि डिवाइस, नीति का पालन कर रहा है या नहीं.

सेवा में रुकावटों को मैनेज करना: BAD_DEVICE_MANAGEMENT

अगर किसी डिवाइस के लिए Google की सेवाओं का ऐक्सेस ब्लॉक कर दिया जाता है, तो Google Play services (GMSCore) इस कार्रवाई के साथ एक इंटेंट ब्रॉडकास्ट करेगा: com.google.android.gms.auth.BAD_DEVICE_MANAGEMENT. ऐसा कई वजहों से हो सकता है:

  • डिवाइस को रजिस्टर करने के बाद, ईएमएम ने कभी भी Devices.setState("enabled") को कॉल नहीं किया.
  • डिवाइस अब ईएमएम की नीतियों का पालन नहीं करता है. साथ ही, ईएमएम ने इसे अब तक फिर से चालू नहीं किया है.
  • ईएमएम ने डिवाइस की स्थिति को साफ़ तौर पर "बंद है" पर सेट किया है. इसके लिए, उसने Devices.setState() को कॉल किया है और accountState को "बंद है" पर सेट किया है. ऐसा सुरक्षा से जुड़ी चिंताओं, एडमिन की कार्रवाइयों या अन्य वजहों से हो सकता है.

इस इंटेंट में स्टेटस कोड शामिल होता है, जैसे कि "ThirdPartyDeviceManagementRequired".

कस्टम डीपीस को इस BAD_DEVICE_MANAGEMENT इंटेंट को सुनने के लिए, BroadcastReceiver को लागू करना होगा.

इस ब्रॉडकास्ट को पाने के बाद, डीपीसी को यह काम करना चाहिए:

  1. नीतियों के मुताबिक होने की फिर से जांच करना: देखें कि डिवाइस, ईएमएम की ओर से सेट की गई सभी नीतियों का पालन कर रहा है या नहीं.
  2. कार्रवाई करें:
    • नीति का पालन करने पर: DPC को ईएमएम सर्वर को सूचना देनी चाहिए. इसके बाद, ईएमएम सर्वर को Devices.setState() को कॉल करना चाहिए. इसमें, accountState को "enabled" पर सेट किया गया हो. ऐसा, किसी खास यूज़र आईडी और डिवाइस आईडी के लिए सेवा का ऐक्सेस वापस पाने की कोशिश करने के लिए किया जाता है.
    • नीति का पालन न करने पर: जब समस्याएं हल हो जाएं और डिवाइस नीति का पालन करने लगे, तब EMM को Devices.setState() को कॉल करना चाहिए.

इस तरीके से यह पक्का किया जाता है कि अगर किसी डिवाइस का ऐक्सेस Google की सेवाओं से हट जाता है, तो उसे वापस पाने का कोई तरीका हो.

एंटरप्राइज़ टेकओवर से जुड़ी बातें

संगठन के खाते के टाइप में बदलाव हो सकता है. जैसे, ManagedGoogleDomainType.TYPE_TEAM से ManagedGoogleDomainType.TYPE_DOMAIN में बदलाव हो सकता है. आम तौर पर, इस प्रोसेस से ईएमएम बाइंडिंग नहीं हटती है. हालांकि, कभी-कभी इससे डिवाइसों पर Google की सेवाओं का ऐक्सेस बाधित हो सकता है.

ईएमएम को यह पता होना चाहिए कि अगर उपयोगकर्ता, खाता हैक होने के बाद सेवा को ऐक्सेस करने से जुड़ी समस्याओं की शिकायत करते हैं, तो Devices.setState() को कॉल करना ज़रूरी हो सकता है. भले ही, डिवाइस ईएमएम की नीतियों के मुताबिक हो. ऐसा इसलिए, ताकि डिवाइस की स्थिति को नए ग्राहक स्ट्रक्चर के तहत Google के बैकएंड के साथ फिर से सिंक किया जा सके. आम तौर पर, टेकओवर के बाद सभी डिवाइसों के लिए, कॉल करने की सुविधा की ज़रूरत नहीं होती. हालांकि, ऐक्सेस से जुड़ी समस्याओं को हल करने के लिए यह एक अहम टूल है.

खाता सेटअप - सैंपल कोड

  1. खाता सेट अप करने की कोशिश शुरू करने के लिए, कॉल करने वाला ऐप्लिकेशन AccountSetupClient का इस्तेमाल कर सकता है. साथ ही, startAccountSetup() या startAccountSetupFuture() में से किसी एक तरीके को कॉल कर सकता है. इसे लागू करने का उदाहरण देखने के लिए, यहां दिया गया कोड सैंपल देखें:

    // Create AccountSetupClient
val client = AccountSetupClientFactory.create(
    this,
    activityResultRegistry
)
lifecycle.addObserver(client.lifecycleObserver)

// Create adminComponent
val notificationReceiver = ComponentName(this, AccountSetupNotificationReceiver::class.java)
// Helper method to get enrollment token created with Play EMM API
val enrollmentToken = getEnrollmentToken()
val request =
    StartAccountSetupRequest.builder()
        .setEnrollmentToken(enteredText)
        .setNotificationReceiverServiceComponentName(notificationReceiver)
        .setAdminComponentName(
            ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java))
        .build()
try {
    val accountSetupAttempt = client.startAccountSetup(request)
    // handle attempt
} catch (e: Exception) {
    // handle exception
}

  2. AccountSetupListener इंटरफ़ेस लागू करें. साथ ही, यह बताएं कि मिले हुए स्टेटस अपडेट को कैसे हैंडल किया जाए.

  3. getAccountSetupListener() को बदलकर, दूसरे चरण में बनाए गए AccountSetupListener इंस्टेंस को बढ़ाएं NotificationReceiverService.

    // Handles account setup changes
class AccountSetupNotificationReceiver :
      NotificationReceiverService(),
      AccountSetupListener {

    override fun getAccountSetupListener(): AccountSetupListener = this

    override fun onAccountSetupChanged(accountSetupAttempt:
  AccountSetupAttempt) {

        when (accountSetupAttempt.state.kind) {
            StateCase.ADDED_ACCOUNT -> {
                val enterpriseAccount = state.addedAccount()
                val userId = enterpriseAccount.userId
                val deviceId = enterpriseAccount.deviceId
                // Handle account added state.

                // IMPORTANT: The device/account is now added but *DISABLED*
                // for Google services. Your EMM backend MUST be notified to
                // perform policy compliance checks and then call Devices.setState()
                // to activate Google Play and other services.

            }
            StateCase.AUTHENTICATION_ACTIVITY_LAUNCH_REQUIRED -> {
                val request = LaunchAuthenticationActivityRequest.builder()
            .setAccountSetupAttempt(accountSetupAttempt)
            .build();
                // Send the attempt to the foreground activity to call:
                accountSetupClient.launchAuthenticationActivity(request)
            }
            StateCase.ACCOUNT_SETUP_ERROR -> {
                // Handle error state.
                val failureReason = state.accountSetupError().failureReason
            }
            else -> {
                // Handle unknown account setup attempt state.
            }
        }
    }
}

  4. एक्सटेंड की गई NotificationReceiverService क्लास को अपने AndroidManifest.xml में जोड़ें और पुष्टि करें कि इसे एक्सपोर्ट किया गया है.

      <application>
    <service
        android:name = ".accountsetup.AccountSetupNotificationReceiver"
        android:exported = "true" />
  </application>

    अगर आपका ऐप्लिकेशन SDK 30 या उसके बाद के वर्शन को टारगेट करता है, तो AndroidManifest.xml में queries एलिमेंट का होना ज़रूरी है. इससे यह पता चलता है कि ऐप्लिकेशन, ADP के साथ इंटरैक्ट करेगा.

      <queries>
    <package android:name="com.google.android.apps.work.clouddpc" />
  </queries>

टेस्टिंग से जुड़े दिशा-निर्देश

इस सेक्शन में, सदस्यता लागू करने की प्रोसेस की जांच करने के लिए दिशा-निर्देशों और सबसे सही तरीकों का सेट दिया गया है.

PrepareEnvironment की जांच करें

  1. डिवाइस की मौजूदा स्थिति का पता लगाना: ईएमएम,

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    डिवाइस पर मौजूद Android Device Policy ऐप्लिकेशन का वर्शन पाने के लिए. अगर Android Device Policy ऐप्लिकेशन इंस्टॉल नहीं है, तो आउटपुट खाली होगा.

  2. PrepareEnvironment को इंटिग्रेट करें: कस्टम DPC, AMAPI SDK में prepareEnvironment एपीआई को लागू करता है और सही अनुरोध पास करता है.

  3. PrepareEnvironment के नतीजे का इंतज़ार करना: कस्टम डीपीसी, prepareEnvironment के पूरा होने का इंतज़ार करता है.

  4. PrepareEnvironment की प्रोसेस पूरी होने की पुष्टि करें: प्रोसेस पूरी होने के बाद, EMM फिर से शुरू होता है

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    इस बार, Android Device Policy का वर्शन पहले चरण में इस्तेमाल किए गए वर्शन से ज़्यादा होना चाहिए.

Google खाते की पुष्टि करने की सुविधा की जांच करना

  1. टेस्ट एंटरप्राइज़ बनाना: ईएमएम, enterprises.generateSignupUrl की मदद से, टेस्ट ईएमएम से लिंक किया गया टेस्ट डोमेन Google एंटरप्राइज़ बनाता है.
  2. Google की मदद से पुष्टि करने की सुविधा चालू करना: EMM, Google Admin console में इन निर्देशों का पालन करके, टेस्ट एंटरप्राइज़ के लिए Google की मदद से पुष्टि करने की सुविधा चालू करता है.
  3. रजिस्ट्रेशन टोकन बनाना: EMM, Play EMM API का इस्तेमाल करके रजिस्ट्रेशन टोकन बनाता है. इसका टाइप userDevice होता है.
  4. पंजीकरण शुरू करना: कस्टम डीपीसी, AMAPI SDK में startAccountSetup एपीआई को शुरू करता है. साथ ही, इसमें रजिस्ट्रेशन टोकन पास करता है.
  5. लॉन्च गतिविधि ज़रूरी है: AMAPI SDK, कस्टम डीपीसी को सूचना देता है कि उपयोगकर्ता की पुष्टि करने के लिए, गतिविधि को लॉन्च करना ज़रूरी है.
  6. उपयोगकर्ता की पुष्टि करना: कस्टम डीपीसी, गतिविधि शुरू करने के लिए launchAuthenticationActivity को शुरू करता है. उपयोगकर्ता, मैनेज किए जा रहे Google खाते से पुष्टि करता है. यह खाता, पहले चरण में बनाए गए एंटरप्राइज़ का हिस्सा होता है.
  7. रजिस्ट्रेशन पूरा करना: AMAPI SDK, कस्टम DPC को रजिस्ट्रेशन के नतीजे के बारे में सूचना देता है.

Google खाते से पुष्टि करने की सुविधा को स्किप करने की जांच करना

हम ऊपर बताए गए सेटअप का इस्तेमाल करेंगे.

इस बार, सातवें चरण में उपयोगकर्ता अपने Google खाते से पुष्टि करने के बजाय, अभी नहीं पर क्लिक करता है. डिवाइस पर सेवा खाते के साथ रजिस्ट्रेशन पूरा हो जाता है. इसका मतलब है कि AuthenticationType गुमनाम है.

बिना उपयोगकर्ता वाले डिवाइसों की जांच करना

Google खाते से पुष्टि करने की सुविधा बंद होने पर, बेहतर कस्टम डीपीसी एनरोलमेंट फ़्लो में यह तरीका अपनाया जाता है:

  1. टेस्ट के लिए एंटरप्राइज़ बनाएं: यह वही एंटरप्राइज़ हो सकता है जिसे आपने पहले बनाया था.
  2. रजिस्ट्रेशन टोकन बनाना: ईएमएम, Play EMM API का इस्तेमाल करके एक रजिस्ट्रेशन टोकन बनाता है. इसका टाइप userlessDevice होता है.
  3. पंजीकरण शुरू करना: कस्टम डीपीसी, AMAPI SDK में startAccountSetup एपीआई को शुरू करता है. साथ ही, इसमें रजिस्ट्रेशन टोकन पास करता है.
  4. रजिस्ट्रेशन पूरा करना: AMAPI SDK, कस्टम DPC को रजिस्ट्रेशन के नतीजे के बारे में सूचना देता है.