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

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

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

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

نظرة عامة

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

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

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

يتمثّل جزء رئيسي من مسار التسجيل الجديد هذا في إدارة إمكانية وصول الجهاز إلى خدمات Google. تبدأ الأجهزة في حالة مُقيّدة تلقائيًا، ويؤدي موفّر إدارة خدمات جوّالة للمؤسسات دورًا مهمًا في تفعيل إمكانية الوصول بعد أن يصبح الجهاز متوافقًا مع السياسات.

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

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

دليل تنفيذ عملية التسجيل

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

إعداد البيئة

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

نموذج الرموز البرمجية

قبل أن تتمكّن وحدة التحكّم في سياسة الجهاز من استخدام 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 ببدء هذه العملية في أقرب وقت ممكن في الخلفية وعرض واجهة مستخدم مناسبة أثناء انتظار المستخدم. عند اكتمال العملية، يصبح الجهاز جاهزًا لوحدة التحكّم في سياسة الجهاز لاستخدام AccountSetup API.

مسار التسجيل

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

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

إعفاء رموز التسجيل المميزة الحالية

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

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

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

يتضمّن مسار تسجيل وحدة التحكّم المخصّصة في سياسة الجهاز المحسّن الخطوات التالية:

حالة الجهاز الأولية المهمة: عند تسجيل جهاز باستخدام وحدة تحكّم مخصّصة في سياسة الجهاز، يبدأ حساب Google الذي تمت إضافته إلى الجهاز في حالة غير مفعّلة. يعني ذلك أنّ إمكانية الوصول إلى خدمات Google، بما في ذلك Google Play، تكون مُقيّدة في البداية.

تنطبق حالة "غير مفعّلة" التلقائية والشرط اللاحق بأن يضع موفّر إدارة خدمات جوّالة للمؤسسات علامة على الجهاز بأنّه متوافق مع السياسات (مثل استدعاء Devices.SetState) على وجه التحديد في الحالات التالية:

  1. أثبتت المؤسسة ملكية نطاقها لدى Google.
  2. فعّل مشرف تكنولوجيا المعلومات بشكلٍ صريح إدارة أجهزة Android الجوّالة التابعة لجهات خارجية لوحدة تنظيمية معيّنة للمستخدم ضمن "وحدة تحكّم المشرف في Google".
  1. إنشاء رمز تسجيل مميز: ينشئ موفّر إدارة خدمات جوّالة للمؤسسات رمز تسجيل مميزًا باستخدام واجهة برمجة التطبيقات Play EMM API.
  2. إعداد البيئة: تستخدم وحدة التحكّم المخصّصة في سياسة الجهاز مسار "إعداد البيئة" للتحقّق من أنّ الجهاز جاهز للتسجيل.
  3. بدء التسجيل: تستدعي وحدة التحكّم المخصّصة في سياسة الجهاز واجهة برمجة التطبيقات startAccountSetup في حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات لإدارة Android، مع تمرير رمز التسجيل المميز. ملاحظة: يجب أن تكون وحدة التحكّم في سياسة الجهاز مالك الجهاز أو مالك الملف الشخصي قبل استدعاء واجهة برمجة التطبيقات هذه.
  4. بدء نشاط المصادقة باستخدام Google: إذا لزم الأمر، تستدعي وحدة التحكّم المخصّصة في سياسة الجهاز واجهة برمجة التطبيقات launchAuthenticationActivity في حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات لإدارة Android، مع تمرير AccountSetupAttempt. يبدأ ذلك نشاط مصادقة باستخدام Google، ويعود المستخدم إلى وحدة التحكّم المخصّصة في سياسة الجهاز بعد نجاح المصادقة. يمكن للمستخدم أيضًا تخطّي هذه العملية. في هذه الحالة، ستتم إضافة حساب على Google Play للأعمال إلى الجهاز. يمكن ضبط هذا الخيار باستخدام googleAuthenticationOptions.
  5. إكمال عملية التسجيل: تُعلم حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات لإدارة Android وحدة التحكّم المخصّصة في سياسة الجهاز بنتيجة التسجيل.
  6. تفعيل خدمات Google: بعد أن توفّر وحدة التحكّم المخصّصة في سياسة الجهاز الجهاز بالكامل وتؤكّد أنّه متوافق مع جميع سياسات المؤسسة، يجب أن يستدعي خادم موفّر إدارة خدمات جوّالة للمؤسسات Devices.setState() مع ضبط المعلَمة accountState على "enabled".
  • سبب أهمية ذلك: يضع طلب بيانات من واجهة برمجة التطبيقات هذا علامة على الجهاز بأنّه متوافق مع السياسات.
  • نتيجة عدم استدعاء واجهة برمجة التطبيقات: بدون استدعاء Devices.setState(setStateRequest)، يظل الحساب في حالة "غير مفعّل". لن يتمكّن المستخدم من الوصول إلى Google Play (لتثبيت التطبيقات أو تحديثها) وخدمات Google الأخرى التي تتطلّب مصادقة الحساب.

إدارة حالة الجهاز وإمكانية الوصول إلى الخدمة

بعد التسجيل الأولي، يكون موفّر إدارة خدمات جوّالة للمؤسسات مسؤولاً عن الحفاظ على إمكانية وصول الجهاز إلى خدمات Google استنادًا إلى حالة امتثاله للسياسات.

معالجة انقطاعات الخدمة: BAD_DEVICE_MANAGEMENT

إذا تم حظر إمكانية وصول الجهاز إلى خدمات Google، ستنشر "خدمات Google Play" (GMSCore) هدفًا يتضمّن الإجراء: com.google.android.gms.auth.BAD_DEVICE_MANAGEMENT. يمكن أن يحدث ذلك لعدة أسباب:

  • لم يستدعِ موفّر إدارة خدمات جوّالة للمؤسسات أبدًا `Devices.setState("enabled")` بعد تسجيل الجهاز الأولي.
  • لم يعُد الجهاز متوافقًا مع سياسات موفّر إدارة خدمات جوّالة للمؤسسات، ولم يعُد موفّر إدارة خدمات جوّالة للمؤسسات تفعيل الجهاز بعد.
  • ضبط موفّر إدارة خدمات جوّالة للمؤسسات حالة الجهاز بشكلٍ صريح على "غير مفعّل" من خلال استدعاء `Devices.setState()` مع ضبط `accountState` على "غير مفعّل". قد يرجع ذلك إلى مخاوف أمنية أو إجراءات إدارية أو أسباب أخرى.

يتضمّن هذا الهدف رمز حالة، مثل "ThirdPartyDeviceManagementRequired".

على وحدات التحكّم المخصّصة في سياسة الجهاز تنفيذ BroadcastReceiver للاستماع إلى هذا الهدف BAD_DEVICE_MANAGEMENT.

عند تلقّي هذا البث، على وحدة التحكّم في سياسة الجهاز إجراء ما يلي:

  1. إعادة تقييم الامتثال للسياسات: تحقَّق مما إذا كان الجهاز يستوفي جميع السياسات التي وضعها موفّر إدارة خدمات جوّالة للمؤسسات.
  2. اتّخاذ إجراء:
    • إذا كان الجهاز متوافقًا مع السياسات: على وحدة التحكّم في سياسة الجهاز إعلام خادم موفّر إدارة خدمات جوّالة للمؤسسات. على خادم موفّر إدارة خدمات جوّالة للمؤسسات بعد ذلك استدعاء Devices.setState() مع accountState ضبط على "enabled" لمعرّف المستخدم ومعرّف الجهاز المحدّدين لمحاولة استعادة إمكانية الوصول إلى الخدمة.
    • إذا لم يكن الجهاز متوافقًا مع السياسات: بعد حلّ المشاكل وتوافق الجهاز مع السياسات، على موفّر إدارة خدمات جوّالة للمؤسسات استدعاء 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. وسِّع 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.

                // 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 لتحديد أنّه سيتفاعل مع تطبيق Android Device Policy.

      <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: تستدعي وحدة التحكّم المخصّصة في سياسة الجهاز واجهة برمجة التطبيقات prepareEnvironment في حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات لإدارة Android، مع تمرير الطلب الصحيح.

  3. انتظار نتيجة PrepareEnvironment: تنتظر وحدة التحكّم المخصّصة في سياسة الجهاز اكتمال prepareEnvironment.

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

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

    في هذه المرة، يجب أن يكون إصدار تطبيق Android Device Policy أعلى من الإصدار في الخطوة 1.

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

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

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

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

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

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

يستخدم مسار تسجيل وحدة التحكّم المخصّصة في سياسة الجهاز المحسّن الخطوات التالية، عندما تكون المصادقة باستخدام Google غير مفعّلة:

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