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

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

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

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

نظرة عامة

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

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

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

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

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

قبل البدء، تأكَّد من استخدام أحدث إصدار من برنامج واجهة برمجة التطبيقات 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.

مسار التسجيل

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

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

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

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

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

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

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

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

  6. تفعيل خدمات Google: بعد أن يوفّر DPC المخصّص الجهاز بالكامل ويتأكّد من امتثاله لجميع سياسات المؤسسة، على خادم إدارة الخدمات الجوّالة للمؤسسات (EMM) إرسال طلب إلى Devices.setState() مع ضبط المَعلمة accountState على "enabled".

    • أهمية ذلك: يحدّد طلب البيانات من واجهة برمجة التطبيقات هذا الجهاز على أنّه متوافق.
    • نتيجة عدم إجراء المكالمة: بدون مكالمة Devices.setState(setStateRequest) هذه، سيظل الحساب في حالة "غير مفعّل". لن يتمكّن المستخدم من الوصول إلى Google Play (لتثبيت التطبيقات أو تعديلها) وخدمات Google الأخرى التي تتطلّب مصادقة الحساب.

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

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

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

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

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

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

يجب أن تنفّذ ملفات DPC المخصّصة BroadcastReceiver للاستماع إلى BAD_DEVICE_MANAGEMENT Intent هذا.

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

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

تضمن هذه الآلية توفُّر طريقة لرصد الحالات التي يفقد فيها الجهاز إمكانية الوصول إلى خدمات Google والتعافي منها.

اعتبارات الاستحواذ على حساب Enterprise

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

يجب أن تكون إدارة الخدمات الجوّالة للمؤسسات (EMM) على عِلم بأنّه إذا أبلغ المستخدمون عن مشاكل في الوصول إلى الخدمة بعد حدث معروف للاستحواذ، حتى إذا بدا أنّ الجهاز متوافق مع سياسات إدارة الخدمات الجوّالة للمؤسسات (EMM)، قد يكون من الضروري إجراء مكالمة إلى 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>

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

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

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

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

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

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

  1. إنشاء مؤسسة اختبارية: تنشئ إدارة الخدمات الجوّالة للمؤسسات (EMM) مؤسسة اختبارية على Google مرتبطة بنطاق اختبار EMM، مع enterprises.generateSignupUrl.
  2. تفعيل مصادقة Google: تفعّل إدارة الخدمات الجوّالة للمؤسسات (EMM) مصادقة Google للمؤسسة الاختبارية باتّباع هذه التعليمات في "وحدة تحكّم المشرف في Google".
  3. إنشاء رمز تسجيل: تنشئ إدارة الخدمات الجوّالة للمؤسسات (EMM) رمز تسجيل باستخدام واجهة برمجة تطبيقات Play EMM مع النوع userDevice.
  4. بدء التسجيل: يستدعي جهاز التحكّم بسياسة الجهاز (DPC) المخصّص واجهة برمجة التطبيقات startAccountSetup في حزمة تطوير البرامج (SDK) الخاصة بواجهة برمجة تطبيقات "إدارة Android"، مع تمرير رمز التسجيل.
  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 في حزمة تطوير البرامج (SDK) الخاصة بواجهة برمجة تطبيقات "إدارة Android"، مع تمرير رمز التسجيل.
  4. إنهاء التسجيل: تُرسِل حزمة تطوير البرامج (SDK) لواجهة برمجة التطبيقات AMAPI إشعارًا إلى وحدة التحكّم في سياسة الجهاز (DPC) المخصّصة بشأن نتيجة التسجيل.