كيفية تحميل التطبيقات مسبقًا على أجهزة Android على نطاق واسع

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

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

كيف يصل التطبيق إلى الجهاز: أربع عائلات من المسارات

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

التحميل المسبق للتطبيق مقارنةً بالتكامل مع تطبيقات النظام

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

متطلبات الحزمة المسبقة التي تحدد أي المسارات يبقى مفتوحًا

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

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

من يملك التحديث بعد التسليم

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

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

إثبات التسليم والتحديث على العينة مضبوطة الإصدار

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

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

التعامل مع الشيفرة وبيانات الاعتماد في سلسلة التسليم

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

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

القيود المعروفة لمسارات التحميل المسبق

الإطار أعلاه أداة تخطيط، ويجدر بيان الموضع الذي يكفّ فيه عن الانتظام. فتوفّر المسارات يعتمد في كل موضع على OEM وإصدار Android وEMM والعتاد، ولذلك فالمسار المؤكَّد على طراز ليس مؤكَّدًا على خَلَفه ولا على إصدار إقليمي مختلف من الطراز نفسه.

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

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

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