تنفيذ حسابات المستخدمين

هناك نوعان أساسيان من هويات المستخدمين لعمليات تسجيل Android Enterprise: حسابات Google Play للأعمال وحسابات Google المُدارة. تكون حسابات Managed Google Play مرتبطة بالجهاز، ما يعني أنّها غير مرتبطة بهوية مستخدم معيّن على Google. في المقابل، تكون حسابات Google المُدارة مرتبطة بهوية Google الخاصة بالمستخدم في الشركة، ما يحسّن تجربة المستخدم من خلال إبقائه مسجّلاً الدخول على أجهزته.

كانت "حسابات Google Play للأعمال" هي المعيار في السابق. ومع ذلك، تشجّع Google الآن جميع عمليات التطوير الجديدة على استخدام عملية التسجيل المحسّنة، والتي يتم ضبطها تلقائيًا على إنشاء حسابات Google خاضعة للإدارة.

مع أنّ الإرشادات الخاصة بالتنفيذ القديم متوفّرة في نهاية هذا المستند لتوفير السياق، يجب أن تتّبع جميع عمليات التطوير الجديدة مسار التسجيل الجديد الموضّح هنا بالتفصيل.

نظرة عامة

يعمل مسار تسجيل الأجهزة المحسّن على تبسيط عملية إعداد الأجهزة من خلال الاستفادة من عدة مكوّنات جديدة وتغيير طريقة تنفيذ أدوات التحكّم المخصّصة في سياسة الجهاز (DPC). يتطلّب هذا النهج الجديد دمج حلول مخصّصة لجهاز تحكّم لسياسة الجهاز (DPC) مع حزمة تطوير البرامج (SDK) الخاصة بواجهة برمجة التطبيقات Android Management API (AMAPI) وتطبيق Android Device Policy لتنفيذ وظائف إعداد الجهاز وتسجيل المستخدمين.

توفّر حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات AMAPI واجهات برمجة التطبيقات اللازمة للتفاعل مع تطبيق Android Device Policy على الجهاز نفسه. من جهة الخادم، ستستخدم حلول إدارة الخدمات الجوّالة للمؤسسات (EMM) واجهة برمجة التطبيقات Play EMM API لإنشاء الرموز المميزة للتسجيل المطلوبة لبدء عملية تسجيل الجهاز.

يؤدي تطبيق Android Device Policy الآن دورًا أساسيًا في التعامل مع العمليات التي تتم على الجهاز. يتم استخدام حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات AMAPI لإدارة عملية تثبيتها والتحديثات اللازمة على الجهاز. يتولّى تطبيق Android Device Policy أيضًا مسار مصادقة المستخدم، ويتعامل مع مصادقة المستخدم مباشرةً ويقدّم هوية المستخدم إلى "إدارة الخدمات الجوّالة للمؤسسات". إذا تعذّر على Google إثبات هوية المستخدم لأي سبب، يتم إنشاء حساب جديد على "Google Play للأعمال" وإضافته إلى الجهاز كحلّ احتياطي.

دمج واجهة برمجة التطبيقات

قبل البدء، تأكَّد من استخدام أحدث إصدار من برنامج واجهة برمجة التطبيقات Play EMM وحزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات AMAPI.

دليل تنفيذ التسجيل

يقدّم هذا الدليل الخطوات اللازمة لتنفيذ عملية التسجيل. ويشمل ذلك إعداد البيئة والتعامل مع طرق التسجيل المختلفة وإدارة دورة حياة الجهاز.

إعداد البيئة

قبل بدء عملية إعداد الحساب، يجب إعداد بيئة الجهاز. تتضمّن عملية الإعداد هذه تحديث "متجر Play" إلى أحدث إصدار وتثبيت تطبيق Android Device Policy (com.google.android.apps.work.clouddpc) على الجهاز بدون أي إجراء من المستخدم. يُعدّ تثبيت تطبيق Android Device Policy أمرًا ضروريًا لأنّه يتضمّن المكوّنات الأساسية لعملية إعداد الحساب. لا تحتاج "إدارة الخدمات الجوّالة للمؤسسات" إلى إجراء إعداد يدوي للبيئة. بدلاً من ذلك، يجب استخدام EnvironmentClient، كما هو موضّح في المستندات، والالتزام بأمثلة الرموز البرمجية المقدَّمة.

نموذج التعليمات البرمجية

قبل أن يتمكّن DPC من استخدام واجهة برمجة التطبيقات AccountSetup لإضافة حساب العمل على الجهاز، عليه أولاً التأكّد من أنّ بيئة الجهاز جاهزة.

  • استخدِم 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.

مسار التسجيل

على موفّري إدارة الخدمات الجوّالة للمؤسسات (EMM) التوقّف عن استخدام users.generateAuthenticationToken() وusers.insert() لجميع الأجهزة. بدلاً من ذلك، يجب أن تستخدم أنظمة إدارة الخدمات الجوّالة للمؤسسات واجهة برمجة التطبيقات على الجهاز لإجراء مصادقة المستخدم النهائي. ستعرض واجهة برمجة التطبيقات الجديدة userId وemail في "وحدة التحكّم بسياسة الجهاز". إذا لم تتمكّن Google من إثبات هوية المستخدم، سيتم إنشاء حساب Google Play للأعمال وإضافته إلى الجهاز. في هذه الحالة، ستعيد Google userId لهذا الحساب.

تتيح Google الآن استخدام رموز مميّزة للتسجيل، ويجب تمريرها إلى واجهة برمجة التطبيقات الخاصة بالمصادقة. تحدّد حلول إدارة الخدمات الجوّالة للمؤسسات (EMM) وقت إنشاء الرمز المميز وطريقة إنشائه، ويمكن أن يكون جزءًا من حمولة تسجيل حالية (مثل رمز استجابة سريعة أو إعداد بدون لمس).

ومع ذلك، تنصح Google بإنشاء الرمز المميز عند الطلب واستبدال واجهة برمجة التطبيقات الحالية لحسابات Managed Google Play بواجهة برمجة التطبيقات الجديدة للحدّ من التغيير.

عملية الدمج النموذجية لوحدة التحكّم في سياسات الأجهزة (DPC) مع واجهات برمجة التطبيقات السابقة
الشكل 1. عملية الدمج النموذجية لميزة "الشراء المباشر داخل التطبيق" مع واجهات برمجة التطبيقات السابقة
مثال على دمج وحدة التحكّم بسياسة الجهاز مع واجهات برمجة التطبيقات الجديدة للأجهزة غير المرتبطة بمستخدم
الشكل 2. مثال على دمج "وحدة التحكّم بسياسة الجهاز" مع واجهات برمجة التطبيقات الجديدة للأجهزة التي لا يستخدمها أي مستخدم
مثال على دمج وحدة التحكّم بسياسة الجهاز مع واجهات برمجة التطبيقات الجديدة لأجهزة المستخدمين
الشكل 3. مثال على دمج وحدة التحكّم بسياسة الجهاز مع واجهات برمجة التطبيقات الجديدة لأجهزة المستخدمين

تتضمّن عملية التسجيل المحسّنة في DPC المخصّصة الخطوات التالية:

  1. إنشاء رمز مميّز للتسجيل: تنشئ إدارة الخدمات الجوّالة للمؤسسات (EMM) رمزًا مميّزًا للتسجيل باستخدام واجهة برمجة التطبيقات Play EMM API.
  2. إعداد البيئة: يستخدم DPC المخصّص مسار إعداد البيئة للتحقّق من أنّ الجهاز جاهز للتسجيل.
  3. بدء التسجيل: يطلب عنصر التحكّم في سياسة الجهاز (DPC) المخصّص startAccountSetup API في حزمة تطوير البرامج (SDK) الخاصة بواجهة برمجة تطبيقات Android لإدارة الأجهزة (AMAPI)، مع تمرير رمز التسجيل. ملاحظة: يجب أن يكون DPC إما مالك الجهاز أو مالك الملف الشخصي قبل طلب واجهة برمجة التطبيقات هذه.
  4. بدء نشاط مصادقة Google: إذا لزم الأمر، يستدعي DPC المخصّص واجهة برمجة التطبيقات launchAuthenticationActivity في حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات AMAPI، مع تمرير AccountSetupAttempt. يبدأ هذا الإجراء نشاط مصادقة Google، ويعيد المستخدم إلى DPC المخصّص عند إتمام المصادقة بنجاح. يمكن للمستخدم أيضًا تخطّي هذه العملية. في هذه الحالة، ستتم إضافة حساب Google مُدار إلى الجهاز. يمكن ضبط هذا الخيار باستخدام googleAuthenticationOptions.
  5. إنهاء التسجيل: تُرسِل حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات AMAPI إشعارًا إلى أداة DPC المخصّصة بشأن نتيجة التسجيل.
  6. تفعيل خدمات Google: بعد أن يصبح جهاز المستخدم الذي يتضمّن حساب Google المُدار متوافقًا مع سياسات المؤسسة، على إدارة الخدمات الجوّالة للمؤسسات (EMM) استدعاء Devices.setState(). يتيح هذا الإجراء الوصول إلى خدمات Google للحساب على الجهاز. وبدون هذا الاتصال، لن يعمل "متجر Play" وخدمات 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. وسِّع NotificationReceiverService وقدِّم مثيل AccountSetupListener الذي تم إنشاؤه في الخطوة 2 من خلال إلغاء getAccountSetupListener().

    // 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.
    
                }
                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>
    

    إذا كان تطبيقك يستهدف المستوى 30 أو مستوى أحدث من حزمة تطوير البرامج (SDK)، يجب توفُّر عنصر queries في AndroidManifest.xml لتحديد أنّه سيتفاعل مع "إعلانات المطوّرين على التطبيقات الأخرى".

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

إرشادات بشأن إجراء الفحوصات

يقدّم هذا القسم مجموعة من الإرشادات وأفضل الممارسات لاختبار عملية التنفيذ.

اختبار PrepareEnvironment

  1. الحصول على الحالة الحالية للجهاز: ينفّذ نظام إدارة الخدمات الجوّالة للمؤسسات (EMM) ما يلي:

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

    للحصول على إصدار تطبيق Android Device Policy المثبَّت على الجهاز إذا لم يكن تطبيق Android Device Policy مثبّتًا، من المتوقّع أن تكون النتيجة فارغة.

  2. دمج PrepareEnvironment: يستدعي DPC المخصّص واجهة برمجة التطبيقات prepareEnvironment في حزمة تطوير البرامج (SDK) الخاصة بواجهة برمجة التطبيقات AMAPI، مع تمرير الطلب الصحيح.

  3. في انتظار نتيجة PrepareEnvironment: تنتظر أداة DPC المخصّصة اكتمال prepareEnvironment.

  4. تأكيد نجاح PrepareEnvironment: عند اكتمال العملية، يتم تشغيل إدارة الأجهزة الجوّالة للمؤسسات (EMM) مرة أخرى.

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

    في هذه المرة، يجب أن يكون إصدار "سياسة أمان Android" أحدث من الإصدار الذي تم تثبيته في الخطوة 1.

اختبار مصادقة حساب Google

  1. إنشاء مؤسسة اختبارية: تنشئ إدارة الخدمات الجوّالة للمؤسسات (EMM) مؤسسة اختبارية على Google مرتبطة بنطاق اختبار تابع لها، وذلك باستخدام enterprises.generateSignupUrl.
  2. تفعيل مصادقة Google: تفعّل إدارة الخدمات الجوّالة للمؤسسات (EMM) مصادقة Google للمؤسسة الاختبارية باتّباع هذه التعليمات في &quot;وحدة تحكّم المشرف في Google&quot;.
  3. إنشاء رمز تسجيل: تنشئ إدارة الخدمات الجوّالة للمؤسسات (EMM) رمز تسجيل باستخدام واجهة برمجة التطبيقات Play EMM API مع النوع userDevice.
  4. بدء التسجيل: يطلب عنصر التحكّم في سياسة الجهاز (DPC) المخصّص startAccountSetup API في حزمة تطوير البرامج (SDK) الخاصة بواجهة برمجة تطبيقات Android لإدارة الأجهزة (AMAPI)، مع تمرير رمز التسجيل.
  5. مطلوب بدء نشاط: تُعلم حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات AMAPI أداة DPC المخصّصة بأنّه يجب بدء نشاط للمصادقة على المستخدم.
  6. المصادقة على المستخدم: يستدعي DPC المخصّص launchAuthenticationActivity لبدء النشاط. يصادق المستخدم على هويته باستخدام حساب Google مُدار (جزء من المؤسسة التي تم إنشاؤها في الخطوة 1).
  7. إنهاء التسجيل: تُرسِل حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات AMAPI إشعارًا إلى أداة DPC المخصّصة بشأن نتيجة التسجيل.

اختبار تخطّي المصادقة باستخدام Google

سنستخدم الإعداد الموضّح سابقًا.

في هذه المرة، في الخطوة 7، يضغط المستخدم على تخطّي بدلاً من المصادقة باستخدام حسابه على Google. تكتمل عملية التسجيل بنجاح، مع توفّر حساب خدمة على الجهاز (أي أنّ AuthenticationType مجهول الهوية).

اختبار الأجهزة التي لا يستخدمها أحد

يستخدم مسار التسجيل المحسّن المخصّص لوحدة التحكّم في سياسة الجهاز (DPC) الخطوات التالية عند إيقاف مصادقة Google:

  1. إنشاء مؤسسة اختبارية: يمكن أن تكون هذه المؤسسة هي نفسها التي تم إنشاؤها سابقًا.
  2. إنشاء رمز مميّز للتسجيل: تنشئ إدارة الخدمات الجوّالة للمؤسسات (EMM) رمز تسجيل باستخدام واجهة برمجة التطبيقات Play EMM API مع النوع userlessDevice.
  3. بدء التسجيل: يطلب عنصر التحكّم في سياسة الجهاز (DPC) المخصّص startAccountSetup API في حزمة تطوير البرامج (SDK) الخاصة بواجهة برمجة تطبيقات Android لإدارة الأجهزة (AMAPI)، مع تمرير رمز التسجيل.
  4. إنهاء التسجيل: تُرسِل حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات AMAPI إشعارًا إلى أداة DPC المخصّصة بشأن نتيجة التسجيل.