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

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 का इस्तेमाल करना चाहिए. इसके बारे में यहां बताया गया है. साथ ही, उन्हें कोड के दिए गए उदाहरणों का पालन करना चाहिए.

सैंपल कोड

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

  • 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() का इस्तेमाल बंद करना होगा. इसके बजाय, ईएमएम को असली उपयोगकर्ता की पुष्टि करने के लिए, उपयोगकर्ता के डिवाइस पर मौजूद एपीआई को कॉल करना होगा. नया एपीआई, डीपीसी को userId और email की जानकारी देगा. अगर Google उपयोगकर्ता की पुष्टि नहीं कर पाता है, तो एक मैनेज किया गया Google Play खाता बनाया जाएगा और उसे डिवाइस में जोड़ दिया जाएगा. ऐसे में, Google उस खाते का userId वापस कर देगा.

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

मौजूदा रजिस्ट्रेशन टोकन के लिए छूट

कुछ खरीदार, बार-बार रजिस्टर करने के लिए, लंबे समय तक मान्य रहने वाले एनरोलमेंट टोकन का इस्तेमाल करते हैं. यह पक्का करने के लिए कि मौजूदा वर्कफ़्लो में कोई रुकावट न आए, "Google का इस्तेमाल करके पुष्टि करें" की ज़रूरी शर्त लागू होने से पहले बनाए गए सभी टोकन को नए लॉगिन प्रॉम्प्ट से छूट दी गई है. ये पुराने टोकन पहले की तरह ही काम करते रहेंगे. इससे लोग, Google की पुष्टि करने की प्रोसेस से गुज़रे बिना डिवाइसों को रजिस्टर कर पाएंगे. हालांकि, 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 की सेवाएं चालू करना: जब कस्टम डीपीसी, डिवाइस को पूरी तरह से उपलब्ध करा देता है और यह पुष्टि कर देता है कि डिवाइस, एंटरप्राइज़ की सभी नीतियों का पालन करता है, तो ईएमएम सर्वर को Devices.setState() को कॉल करना ज़रूरी है. साथ ही, accountState पैरामीटर को "enabled" पर सेट करना भी ज़रूरी है.
  • यह क्यों ज़रूरी है: इस एपीआई कॉल से, डिवाइस को नीति का पालन करने वाले डिवाइस के तौर पर मार्क किया जाता है.
  • कॉल न करने पर होने वाली समस्या: इस Devices.setState(setStateRequest) कॉल के बिना, खाता "बंद है" स्थिति में रहता है. उपयोगकर्ता, Google Play को ऐक्सेस नहीं कर पाएगा. इससे वह ऐप्लिकेशन इंस्टॉल या अपडेट नहीं कर पाएगा. साथ ही, वह Google की उन अन्य सेवाओं को भी ऐक्सेस नहीं कर पाएगा जिनके लिए खाते की पुष्टि करना ज़रूरी है.

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

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

सेवा में रुकावटों को ठीक करना: BAD_DEVICE_MANAGEMENT

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

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

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

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

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

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

इस मैकेनिज़्म से यह पक्का किया जाता है कि अगर किसी डिवाइस को Google की सेवाओं का ऐक्सेस नहीं मिलता है, तो ऐसी स्थितियों का पता लगाया जा सके और उन्हें ठीक किया जा सके.

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

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

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

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

  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. NotificationReceiverService को बढ़ाएं और getAccountSetupListener() को बदलकर, दूसरे चरण में बनाया गया AccountSetupListener इंस्टेंस उपलब्ध कराएं.

    // 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 को रजिस्ट्रेशन के नतीजे के बारे में सूचना देता है.