EDLA مقارنةً بـGMS وAOSP: ماذا يعني كل مصطلح لأجهزة المؤسسات

إجابة مباشرة

EDLA وGMS وAOSP ليست ثلاثة أنظمة تشغيل Android متكافئة. AOSP هو الأساس مفتوح المصدر للمنصة. أما GMS فهي مجموعة مرخّصة بشكل منفصل من تطبيقات وواجهات برمجة تطبيقات Google تُضاف إلى إصدار Android. تصف مواد الشركات المصنّعة (OEM) والشركاء العامة EDLA بأنها مسار ترخيص يتيح لفئات معينة من أجهزة المؤسسات المؤهلة شحن طبقة GMS تلك. لم تعثر هذه المراجعة على مواصفات عامة رسمية من Google لـEDLA تغطي الأهلية والاختبارات والرسوم ونطاق الطُرز؛ لذا يجب التعامل مع EDLA على أنها ادعاء يتطلب دليلًا دقيقًا على مستوى الطراز من الشركة المصنّعة أو الجهة المرخِّصة المعنية.

ابدأ بنموذج طبقات، لا بثلاثة خيارات متوازية

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

كيف ترتبط هذه الطبقات ببعضها

الجهاز المُسوَّق بوصفه EDLA يظل قائمًا على Android. القرار ليس "EDLA أو GMS أو AOSP". بل يجب السؤال عن إصدار Android المستخدَم، وما إذا كانت طبقة Google مرخّصة بشكل قانوني، وما المسار المنطبق على فئة الجهاز، وما إذا كانت متطلبات المشروع قد تم التحقق منها.

ماذا تعني AOSP

توضّح نظرة عامة على AOSP أن شيفرة Android المصدرية متاحة للعامة وقابلة للتعديل، ويمكن لصانعي الأجهزة إنشاء نسخ مختلفة منها. ويشترط برنامج توافق Android بشكل منفصل وثيقة تعريف التوافق (CDD) المعنية واختبار CTS لتحقيق توافق Android. وهذا يثبت أن AOSP يمكن أن تكون أساسًا للمنصة، وأن التوافق حالة إضافية يجب إثباتها بالأدلة. لكنه لا يثبت ترخيص GMS، أو سلوك التطبيقات، أو إدارة المؤسسات، أو التحديثات، أو أن إصدار AOSP يعمل دون اتصال فقط أو بتطبيقات خاصة فقط. حدِّد الإصدار الدقيق، وتبعيات التوزيع والسحابة، وأدلة التوافق، واختبارات التطبيقات، ومسار الإدارة، والجهة المسؤولة عن دورة الحياة، بدلًا من قبول "AOSP" كبنية كاملة.

ماذا تعني GMS

تُعرّف Google خدمات Google Mobile Services بأنها مجموعة مرخّصة من تطبيقات وواجهات برمجة تطبيقات Google، وهي ليست جزءًا من AOSP؛ وقد تختلف هذه المجموعة حسب توفر كل دولة ومتطلباتها. أما خدمات Google Play فهي طبقة خدمات على الجهاز تستخدمها حزم Google للتطوير (SDKs)، وليست مرادفًا لكامل GMS. يحدِّد الادعاء الصحيح لـGMS طبقة برمجيات Google المرخّصة، لكنه لا يثبت أن كل تطبيق أو حزمة تطوير (SDK) أو مسار حساب أو قناة تطبيقات مُدارة مطلوبة، أو نتيجة تحقق Play Integrity، تعمل بشكل صحيح مع التطبيق والسوق المستهدف.

• احصِ التطبيقات وواجهات برمجة التطبيقات والحسابات وقناة التوزيع والخدمات الخلفية وسلوك عدم الاتصال واستدعاءات التحقق من السلامة المطلوبة؛ واختبرها على الإصدار المعروض بالفعل.
• لا تنقل متطلب تحقق قديمًا إلى مواصفات مشروع جديد: تذكر Google أن SafetyNet Attestation أُوقف بالكامل في يناير 2025.
• سجِّل واختبر تطبيق Play Integrity الفعلي في تطبيق الإنتاج بدلًا من استنتاجه من تسمية الجهاز.

ماذا تعني EDLA - وما لا تقوله الأدلة العامة

يصف شرح EDLA من BenQ خدمة EDLA بأنها تتيح تفعيل GMS المدمجة في حلول المؤسسات مثل السبورات الذكية، بينما تصف صفحة الشركاء الخاصة بـKuori شراكة EDLA لشاشات العرض التجارية المتوافقة مع GMS. وتوجّه صفحة شركاء Android Enterprise العامة من Google بعض متطلبات برامج الأجهزة إلى مواد الشركاء أو جهات الاتصال التجارية بدلًا من نشر مواصفات عامة لـEDLA. تُثبت هذه المصادر من الموردين والشركاء استخدامًا موثّقًا في السوق لخدمات Google المرخّصة على فئات معينة من أجهزة المؤسسات المؤهلة. لكنها لا تُثبت شروط عقد Google الخاصة، أو الأهلية الشاملة، أو حالة مورّد آخر، أو حالة كل كشك أو شاشة عرض أو جهاز طرفي أو هاتف أو جهاز لوحي.

• تعامل مع أوصاف BenQ وKuori على أنها أوصاف من موردين/شركاء، لا شروط برنامج رسمية من Google.
• اطلب بيانًا يحدد الطراز الدقيق ورمز SKU وإصدار Android والإصدار البرمجي والسوق والجهة المسؤولة عن الادعاء والدليل المعني.
• لا تقبل عبارة من كتيّب دعائي أو أيقونة Play Store الظاهرة كدليل كافٍ.

متى تكون EDLA ذات صلة

تركّز أمثلة EDLA العامة التي جرت مراجعتها هنا على شاشات العرض التفاعلية والتجارية. وهذا يدعم طرح السؤال عن EDLA عندما يستشهد بها مورّد لفئة جهاز مؤسسي خارج المسار المألوف للهواتف أو الأجهزة اللوحية؛ لكنه لا يُثبت قائمة كاملة بالأجهزة المؤهلة. أما بالنسبة للهاتف أو الجهاز اللوحي أو الجهاز المحمول التقليدي، فاسأل عمّا إذا كان الإصدار المشحون بالفعل مرخّصًا بشكل قانوني بـGMS ومعتمدًا من Play Protect. يُثبت هذا الفحص حالة اعتماد واحدة ملاحَظة، لا سلوك EMM أو مدة التحديث أو الموافقة الإقليمية أو سير العمل الميداني. سجِّل النتيجة مقابل الطراز/رمز SKU/الإصدار، ثم استخدم دليل قرار الطرح GMS مقارنةً بـAOSP لملاءمة التطبيق والإدارة والتزويد ودورة الحياة.

طبّق خمس بوابات قبل تقديم عرض سعر أو قرار عينة

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

1. 1ثبّت خط الأساس للجهاز: سجِّل الشكل الفيزيائي، والشركة المصنّعة، والطراز الدقيق ورمز SKU الإقليمي، وإصدار Android، ورقم البرنامج الثابت/الإصدار، ومستوى تصحيح الأمان، وأي وحدة حوسبة معيارية.
2. 2دقّق تبعيات التطبيق والخدمة: أدرج كل تطبيق أو حزمة تطوير (SDK) أو مسار حساب أو قناة توزيع أو خدمة خلفية أو سلوك عدم اتصال مطلوب من Google؛ واختبر التطبيق الفعلي.
3. 3تحقّق من دليل الترخيص المعني: حدِّد الجهة المسؤولة عن الادعاء والطراز/الإصدار/السوق الدقيق الذي يغطيه؛ وافصل بين استخدام مصدر AOSP، وتوافق Android، واعتماد Play Protect، وترخيص GMS، وحالة EDLA كما تصفها الجهة المصنّعة.
4. 4تحقّق من الإدارة والتسجيل بشكل منفصل: حدِّد نمط الملكية، ونظام EMM، وتطبيق DPC أو الوكيل، وقناة التطبيقات، ومتطلبات وضع الكشك، ومسار التزويد، ونموذج الحساب، وإجراء الاسترداد.
5. 5أكِّد المنطقة ودورة الحياة: سجِّل توفر الجهاز حسب الدولة، والجهة المسؤولة عن التحديثات، وبيان دعم نظام التشغيل والأمان، ومسار التحديث عبر الهواء (OTA)، وسلوك إعادة الضبط، ومسار الاستبدال، والقيود المعروفة، ومحفزات إعادة التحقق.

افصل بين Android Enterprise وEMM وZero-Touch وAER

تصف نظرة عامة على Android Enterprise من Google لوحة تحكم EMM، ومكوّن سياسات على الجهاز، وGoogle Play المُدارة. وتوثّق نظرة عامة على إدارة الأجهزة في AOSP مفاهيم مالك الجهاز، ومالك الملف الشخصي، وDPC، وإطار السياسات. أما متطلبات Android Enterprise Recommended فهي إشارة برنامج منفصلة وذات إصدارات. لذلك فإن الترخيص، وبنية الإدارة، والتزويد، وAER هي طبقات أدلة متمايزة.

اقبل الأدلة، لا التسميات

قبل اعتماد أي عينة، اجمع أدلة غير سرية يمكن أن ترافق الجهاز إلى مرحلة الإنتاج. يجب أن تُثبت العينة سير العمل المطلوب، لا كل إمكانية توحي بها تسمية ما.

حدِّد المسؤوليات

هذا نموذج تخطيطي، وليس عقدًا شاملًا. يمكن لـVantora تنسيق مراجعة جدوى المنصة والمساعدة في تحويل الادعاءات إلى متطلبات قابلة للاختبار. لكنها لا تمنح تراخيص Google، ولا تعتمد أجهزة EDLA، ولا تُشغّل مستأجر EMM الخاص بالعميل، ولا تَعِد بمسار ترخيص على كل طراز.

اطلب مراجعة جدوى المنصة

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