قائمة تحقق لأجهزة Android الجاهزة للتطبيقات لفرق SaaS والبرمجيات

الإجابة المختصرة

تساعد هذه القائمة فرق SaaS والبرمجيات على تقرير ما إذا كانت أدلة الجهاز الجاهز للتطبيق موجودة فعلًا قبل الالتزام بدُفعة. مصطلح «جاهز للتطبيق» مصطلح مشروع لدى Vantora في هذا الدليل، وليس اعتمادًا من Google أو Android. ويجب أن يربط فريق المشروع آليات Android المنفصلة للتوافق والأذونات والتوزيع والإدارة والتحديث بسير عمل فعلي واحد على تهيئة دقيقة.

التثبيت لا يساوي الجاهزية للتطبيق

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

سجل خط الأساس قبل الاختبار

لا تعتمد «إصدار Android» أو «APK» بصورة مجردة. أنشئ للعينة المرجعية سجل تهيئة. سجل في الحد الأدنى الطراز وSKU الإقليمية وإصدار Android والبرامج الثابتة وحزمة التطبيق وإصداره ومصدر التوقيع ومسار التوزيع ووضع الإدارة وإصدار السياسة والطرفيات وافتراضات الشبكة والأسواق المستهدفة وتاريخ الاختبار.

1. افحص إجراءات التطبيق الحقيقية

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

• تحديد المستخدم الأساسي والمهمة والبيئة ونتيجة النجاح.
• توفير سيناريوهات تمثيلية لتسجيل الدخول والمستأجر والدور واسترداد الحساب للاختبار.
• تغطية الاتصال والشبكة الضعيفة والعمل دون اتصال والمزامنة وانقطاع الجلسة عند الصلة.
• إدراج تفاعلات الكاميرا وNFC والرمز الشريطي والطابعة والماسح وقاعدة التوصيل وBluetooth أو USB المطلوبة.
• تسجيل افتراضات النظام الخلفي والشهادة وVPN والنطاق والوقت والموقع أو API.

2. افحص العتاد ونسخة السوق بدقة

هذه مدخلات جدوى لا ادعاءات شاملة عن المنتج. قارن المسارات الشائعة والمتينة أو الأعمق لدى OEM بالمتطلبات قبل الالتزام بالكمية.

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

3. افحص تسليم التطبيق وهوية الإصدار

اختر مسار التسليم عمدًا: Managed Google Play أو تحميلًا مسبقًا متفقًا عليه أو تجهيز APK مضبوطًا. لا يمكن استبدال هذه المسارات بعضها ببعض. توثق Google أن Managed Google Play يستطيع تثبيت التطبيقات عبر سياسة الجهاز وتقييد تطبيق خاص بمؤسسة واحدة؛ راجع وثائق توزيع التطبيقات المُدارة. يفيد ذلك عمليات النشر المُدارة المدعومة، لكنه لا يجعل المسار نفسه متاحًا على كل تهيئة AOSP أو non-GMS أو OEM أو غير مُدارة.

• تسجيل اسم الحزمة ورمز الإصدار وقناة الإصدار ومالك التوقيع.
• عمل المسار المختار من حالة الجهاز النظيفة المقصودة.
• صحة ظهور التطبيق الخاص وتعيينه للمستأجر عند استخدام Managed Google Play.
• وجود مسار دعم لفشل التثبيت وانقطاع التنزيل وإعادة التثبيت.
• تلقي دُفعة الإنتاج الحزمة والمسار المعتمدين نفسيهما.

4. افحص التشغيل الأول والأذونات والتهيئة

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

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

5. افحص حدود الإدارة والكشك والمستخدم

قرر أولًا ما إذا كان الجهاز شخصيًا أو مملوكًا للشركة مع استخدام مختلط أو مُدارًا بالكامل أو مخصصًا. في Android Management API يحدد رمز التسجيل وطريقة التزويد الملكية ووضع الإدارة؛ راجع وثائق التزويد لدى Google. وقد تختلف هندسات EMM الأخرى، لذلك تحقق من المنصة بدل نسخ سياسة نموذجية. يستطيع مثال Google لسياسة الجهاز المخصص تشغيل تطبيق كشك معين تلقائيًا عند الإقلاع؛ وهو مثال تنفيذ لا وعد تحكم شامل.

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

6. افحص التحديثات والاسترداد وضبط التغيير

الإصدار الأول مجرد بداية لبرنامج الجهاز. لا يقبل Android تحديث التطبيق إلا عند استيفاء الهوية والتوقيع: يجب أن يتطابق معرّف التطبيق (ID) وشهادة التوقيع، أو يُستخدم إثبات دوران صالح، وأن يتحقق شرط الإصدار. راجع قواعد تحديث تطبيقات Android قبل تغيير قناة التوزيع أو عهدة التوقيع. تصف إرشادات تحديث Android Management API أوضاعًا افتراضية مشروطة وعالية الأولوية ومؤجلة للتطبيقات المُدارة؛ لكنها لا تتحكم في إصدارات برامج OEM الثابتة.

• توثيق ملكية إصدار التطبيق وعهدة التوقيع والاعتماد وتوقيت النشر.
• فهم السلوك العادي والعاجل والمرحلي للقناة المختارة.
• اختبار فشل التحديث وانقطاعه وترحيل البيانات والاسترداد عند الأهمية.
• وجود محفزات لإعادة التحقق عند تغيير البرامج الثابتة أو التطبيق أو النظام الخلفي أو السياسة أو الطرفيات.
• عدم الوعد بـ«التراجع» ما لم تدعم القناة ونموذج بيانات التطبيق مسار استرداد مختبرًا.

7. افحص قبول العينة

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

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

8. افحص تجهيز الدُفعة وتسليمها

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

• إعداد وحدات الإنتاج من خط أساس التطبيق والبرامج الثابتة والسياسة والإعداد المقبول.
• تسجيل الأرقام التسلسلية وIMEI والأصول والمواقع والمستأجر وSIM/APN والملحقات والملصقات والكراتين والاستثناءات عند انطباقها.
• مقارنة QA للدُفعة بالعينة المرجعية مع قاعدة إيقاف للانحراف المهم.
• جاهزية تعليمات التفعيل والاستبدال والضمان والدعم والتصعيد وإعادة الطلب.
• معرفة الفريق المستلم الإجراءات المتبقية في الموقع والحالة التي يجب أن تكون موجودة عند الوصول.

أسند المسؤولية قبل التجربة

ما يلي نموذج تخطيط لا عقد شامل. أكّد كل صف في مصفوفة مسؤوليات المشروع الفعلية. تصف صفحة شركاء التطبيقات وSaaS لدى Vantora نطاق التسليم المرتبط.

لا تفرج عن الدُفعة إلا عند اتصال الأدلة

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