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

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

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

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

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

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

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

كيفية اختبار إصدار التطبيق على جهاز مرشّح

تذكر معظم قوائم التحقق ما ينبغي التحقق منه وتترك الطريقة ضمنية، وهنا يختل التقييم بهدوء: تُجرى الاختبارات وتنجح، لكنها تثبت أقل مما يظن الفريق. ابدأ بمسار التثبيت، لأنه يغيّر معنى كل نتيجة تليه. فأثناء التقييم يدفع المهندس عادةً الإصدار عبر adb من محطة عمل مفعَّل فيها تصحيح أخطاء USB، وهي طريقة معقولة للتكرار السريع على عيب وظيفي، لكنها ليست المسار الذي سيستخدمه الأسطول. أما التثبيت المُدار الذي تقوده وحدة التحكم في سياسة الجهاز (DPC) فيحدث دون حضور مستخدم، وربما قبل أن يسجّل أحد دخوله، وتحت القيود التي تطبقها السياسة أصلًا، مع نسبة التثبيت إلى القناة المُدارة لا إلى جلسة محلية. ومجموعة قيود الإنتاج هي ما يفاجئ الفرق: فالسياسة التي تمنع التثبيت من المصادر غير المعروفة، أو تحجب تصحيح أخطاء USB أو تثبيت التطبيقات كليًا، تغلق المسار الذي اعتمد عليه التقييم، فلا يبقى للحزمة التي ثُبتت بنظافة على وحدة منضدة أي طريق إلى جهاز إنتاجي إطلاقًا. اختبر المسار المُدار على الجهاز المرشّح قبل اعتبار التطبيق قابلًا للتثبيت، وأبقِ التحميل الجانبي لدورات التصحيح التي يُعاد اختبارها بعدها. وإطار مسارات التسليم نفسه معروض في تحميل التطبيقات مسبقًا على أجهزة Android على نطاق واسع؛ والمقصود هنا أضيق — فالمسار المستخدم لإجراء اختبار جزء من نتيجة ذلك الاختبار. ثم أكّد المعمارية التي تُسلَّم فعلًا. تعلن الأجهزة عن ABI أساسية وأخرى ثانوية، وغالبًا arm64-v8a مع دعم 32 بت حيث ما زالت المنصة توفره، وتصف وثائق ABI لدى Android كيفية مطابقة المكتبات الأصلية في الحزمة بالجهاز. ونادرًا ما تبدو إخفاقات ABI الخاطئة كإخفاقات ABI: فإما يُرفض التثبيت لعدم وجود شيفرة أصلية مطابقة، وإما ينجح التثبيت لأن الحزمة تحمل مصادفةً مجلد مكتبات صالحًا ثم يموت التطبيق لاحقًا بخطأ تحميل مكتبة أصلية عند أول استخدام حقيقي للماسح أو مسار الكاميرا أو وحدة التعمية. وإذا كان التطبيق يُشحن على هيئة Android App Bundle، فإن APK الشاملة التي يحمّلها المختبِر جانبيًا والتقسيمة التي تولّدها قناة مُدارة لذلك الجهاز بعينه ليستا القطعة نفسها، فسجّل أيهما اختُبر وطابقه مع ما سيستلمه الأسطول. وتستحق حدود الإصدارات القدر نفسه من الحرفية. فمستويا API الأدنى والمستهدف المعلنان في ملف البيان يحددان الأهلية والسلوك معًا: إذ يُستبعد الجهاز المرشّح الذي يعمل بإصدار Android دون الحد الأدنى المعلن من القناة المُدارة بدل أن يظهر له خطأ، فيكون العَرَض جهازًا لا يتلقى التعيين أصلًا، بينما يحدد المستوى المستهدف سلوكيات توافق المنصة التي تنطبق. كما تفرض Google متطلب مستوى API المستهدف المتجدد على الرفعات الجديدة، فقد يكون إصدار داخلي أقدم قابلًا للاختبار تمامًا وغير قابل للنشر عبر القناة التي ينوي البرنامج استخدامها. ثم اختبر الإصدار الذي سيصل إلى الأسطول لا الإصدار المفتوح لدى المطوّر. فإصدار التصحيح يختلف عن مرشّح النشر بطرق تخفي إخفاقات حقيقية: مفتاح توقيع مختلف، وراية قابلية التصحيح مضبوطة، وتقليص الشيفرة والتشويش مخففان أو متجاوَزان، وتسجيل مسهب مُبقًى، ثم — وهي مفاجأة متأخرة متكررة — تجاوزات التصحيح في تهيئة أمان الشبكة فاعلة، فتتوقف شهادة داخلية أو ذاتية التوقيع عملت طوال التقييم عن العمل في الإصدار الموقّع. ويجلب التقليص صنفًا خاصًا من العيوب، إذ يميل الانعكاس والتسلسل وحقن التبعيات إلى الانكسار فقط بعد تطبيق التشويش. ثم تهم هوية التوقيع إلى ما بعد التثبيت الأول، لأن قبول التحديث يتوقف عليها؛ فاحسم عهدة التوقيع، الموصوفة تحت توقيع التطبيقات، قبل قبول العينة لا بعده. ونفّذ ذلك كله على SKU الإقليمية الدقيقة التي ستُطلب. فقد تتقاسم عائلة طراز واحدة اسمًا تسويقيًا عبر أرقام طرازات تختلف في نطاقات الراديو، وفئة الذاكرة، والبرمجيات المثبتة مسبقًا، وقناة البرامج الثابتة، ومجموعة اللغات الافتراضية، وفي بعض الأسواق في وجود خدمات Google من عدمه — والوحدة الشبيهة المستعارة من زميل جهاز مفيد لاكتشاف العلل وسيئ للقبول. وأخيرًا التقط الحقول نفسها من كل تشغيل، وإلا تعذّرت مقارنة النتائج لاحقًا: طراز الجهاز ورقم الطراز، وبصمة الإصدار ومستوى تصحيح الأمان، واسم الحزمة مع اسم الإصدار ورمزه، وبصمة شهادة التوقيع، ومسار التثبيت، وإصدار السياسة النافذ، والمختبِر والتاريخ، إضافة إلى المخرجات الخام — مقتطف سجل حول أي إخفاق، وتسجيل لسير العمل، وأي بلاغ تعطل أو ANR. وهذه المجموعة هي ما يحوّل نتيجة اختبار إلى صف في مصفوفة القبول، وما يتيح لـتجهيز الدُفعات إعادة إنتاج الظروف المختبَرة لا مقاربتها.

ما يخفيه اختبار المكتب: التنفيذ في الخلفية وسياسة الطاقة

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

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

1. افحص سير عمل التطبيق الحقيقي

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لا تُفرج عن الدُفعة إلا حين تترابط الأدلة

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