طرق تزويد أجهزة Android: دليل لاختيار مسار الطرح

اختر حالة الإدارة قبل طريقة الدخول

غالبًا يُدمج قراران في قرار واحد. تحدد حالة الملكية والإدارة حدود التحكم بعد الإعداد، أما طريقة الدخول إلى التزويد فهي مجرد المسار المؤدي إلى تلك الحالة المدعومة. لا يعني رمز QR بذاته «جهازًا مخصصًا»، ولا يحدد التسجيل دون تدخل السياسة التي سيتلقاها الجهاز. راجع أولًا الأجهزة المخصصة مقارنةً بالمُدارة بالكامل؛ كما تشير إرشادات Google لإعداد أجهزة Android Enterprise إلى اختلاف دعم الطرق حسب مورّد EMM.

التزويد والتسجيل وتجهيز الدُفعة مترابطة، لكنها ليست متطابقة

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

• يُضاف ملف العمل على جهاز شخصي عادةً إلى جهاز مهيأ بالفعل من دون إعادة ضبط المصنع.
• تُنشأ عادةً حالات ملف العمل على جهاز الشركة والإدارة الكاملة والجهاز المخصص أثناء معالج الإعداد على جهاز جديد أو معاد ضبطه.
• ينزّل المعرّف afw#setup تطبيق Android Device Policy أثناء مسار مدعوم في معالج الإعداد؛ أما بيانات التسجيل نفسها فهي أصل منفصل.
• يجب ألا تظهر رموز الإنتاج أو حمولات QR أو معرّفات المستأجر أو بيانات الاعتماد أو قوائم الأجهزة في محتوى عام أو أدلة قبول عادية.

مقارنة طرق الدخول الرئيسية إلى التزويد

هذه المصفوفة أداة اختيار لا وعد دعم شامل. أكّد الطراز وSKU الإقليمية وإصدار Android والبرامج الثابتة ومسار GMS أو AOSP ومنصة EMM أو DPC والترخيص وحالة الإدارة والشبكة قبل اعتماد أي مسار. يوثق دليل التزويد الحالي لـAndroid Management API المسارات والمتطلبات التي تدعمها Google.

استبعد المسارات غير المدعومة قبل العمل التجريبي

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

• الحالة المستهدفة — ملف عمل على جهاز شخصي أو جهاز الشركة، أو مُدار بالكامل، أو مخصص.
• خط أساس الجهاز — الطراز وSKU الإقليمية وإصدار Android والبرامج الثابتة وحالة الأمان ذات الصلة.
• مسار خدمات Google — ‏GMS وGoogle Play Services ودعم Android Enterprise حيث يتطلبها المسار.
• هندسة EMM — طريقة الدخول وحالة الإدارة المدعومتان على التهيئة الدقيقة.
• سلسلة التوريد — المسؤولون عن تسجيل الجهاز وتعيين التهيئة وبرنامج OEM واستثناءات الحساب.
• الشبكة — ‏Wi-Fi الفعلي والبوابة المقيدة والوكيل والجدار الناري وDNS والوقت والوصول إلى الخدمات.
• الاسترداد — حالة البداية المتفق عليها والاستجابة للانقطاع أو إعادة الضبط أو الاستبدال أو فشل التسجيل.

تحقق من المسار انطلاقًا من حالة البداية المقصودة

تثبت الوثائق وجود الطريقة؛ أما قبول المشروع فيتطلب تنفيذ الطريقة الدقيقة واختبارها. شغّل المسار على عينة مضبوطة الإصدار وسجل أدلة غير سرية لكل نقطة تحقق. يثبت نجاح التزويد الطريقة والحالة المُدارة المختبرتين في الظروف المسجلة فقط، ولا يثبت إجراءات التطبيق الكاملة أو سلوك الكشك أو الأجهزة الطرفية أو ملاءمة المنطقة أو التحديثات أو اتساق الدُفعة. وهذا التمييز جوهر الجاهزية لـMDM مقارنةً بالجاهزية للطرح.

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

حوّل المسار المقبول إلى تعليمات دُفعة مضبوطة

بعد قبول مسار العينة، حوّله إلى تعليمات مضبوطة الإصدار. تجهيز الدُفعة ليس طريقة دخول أخرى في Android Enterprise؛ بل عملية تشغيلية تطبق المسار المقبول باتساق، وتتتبع الأجهزة والاستثناءات، وتجري الفحوص المتفق عليها، وتعد أدلة التسليم. راجع تزويد أجهزة Android وتجهيز الدُفعات للسياق الأوسع للتسليم.

• سجل الجهاز والبرامج الثابتة والحالة المستهدفة والطريقة وسياسة EMM ومراجع التطبيقات المعتمدة.
• استخدم مرجع ملف تسجيل غير سري بدل تضمين رمز إنتاج أو حمولة QR.
• وثق حالة البداية ومتطلبات الشبكة ونقاط المشغّل ومسار الاستثناء وقاعدة الإيقاف والمسؤول.
• اربط نطاقات الأرقام التسلسلية أو IMEI بالتهيئة والسياسة والتطبيق والملصقات والملحقات وحالة الكرتون المقبولة.
• أعد التحقق بعد تغيير التهيئة أو مسار GMS/AOSP أو EMM أو DPC أو السياسة أو التطبيق أو عملية الموزّع أو افتراضات الشبكة أو الاسترداد.

عامل برامج AOSP وnon-GMS كمسار جدوى منفصل

لا تفترض انتقال QR أو التسجيل دون تدخل أو معرّف DPC أو مسار Google المُدار بلا تغيير إلى تهيئة AOSP أو non-GMS. يعتمد مسار الإنتاج على تهيئة OEM ومكونات الإدارة المضمنة ونموذج التوقيع والامتيازات وتجربة الإعداد وملكية التحديث وعملية التجهيز. ابدأ بـدليل قرار GMS مقارنةً بـAOSP. يوثق AOSP هندسة إدارة الأجهزة وآليات تزويد مالك الجهاز، لكن المشروع الدقيق يظل بحاجة إلى أدلته الخاصة للأمان والاسترداد ودورة الحياة والقبول.

• قد يحتاج مشروع AOSP إلى إجراءات خاصة بـOEM أو البرامج الثابتة أو USB أو APK أو الوكيل أو التجهيز.
• لا ينبغي تقديم Device Admin القديم كاختصار حديث؛ فعلى حلول EMM الجديدة اتباع Android Management API بدل تسجيلات جديدة عبر Play EMM API أو DPC مخصص.
• يجب أن تتبع تطبيقات DPC المخصصة معالجات التزويد الحالية لإصدار Android وأن يُعاد التحقق منها بعد تغييرات OS أو البرامج الثابتة.

أسند الحسابات والمسؤوليات

نموذج الملكية أدناه خط أساس للتخطيط لا عقد شامل. تستطيع Vantora تنسيق برنامج الجهاز، لكنها لا تصبح مورّد EMM للعميل أو مالك المستأجر أو مشغّل Android Enterprise أو المالك العام لكل برنامج تسجيل لدى OEM.

حالات الفشل والاسترداد الشائعة

ترجع معظم حالات فشل التزويد إلى مجموعة صغيرة من تبعيات المشروع. اكتشفها على عينة مضبوطة وتمرّن على مسار الاسترداد قبل تحويل الطريقة المختارة إلى تعليمات إنتاج.

• بوابة مقيدة أو وكيل أو DNS أو جدار ناري أو شبكة غير مستقرة تمنع تنزيل DPC أو السياسة.
• مستأجر خاطئ أو عدم تطابق الحساب أو تهيئة دون تدخل غير معيّنة أو فجوة في تسجيل الموزّع.
• طراز أو SKU إقليمية أو تهيئة برامج ثابتة أو حالة إدارة غير مدعومة.
• رمز منتهي أو حمولة معيبة أو خطأ DPC أو معرّف جهاز مكرر.
• إعادة ضبط غير متوقعة أو حماية إعادة ضبط المصنع أو مسار إعادة تسجيل غير مكتمل.
• وصول السياسة أو التطبيق مع استمرار فشل إجراءات العمل بعد إعادة التشغيل أو التحديث أو فقد الشبكة المؤقت.