تعد صورة Kernel العامة من Google هي الخطوة التالية نحو حل مشكلة تجزئة Android

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

تخفيف آلام تحديث الأندرويد

كانت أول مبادرة رئيسية في مشروع Google طويل المدى لتقليل عبء التطوير مشروع التريبل. تم الإعلان عن Project Treble جنبًا إلى جنب مع Android 8.0 Oreo في عام 2017، وهو يعمل على تقسيم نظام Android إلى وحدات عن طريق فصل إطار عمل نظام التشغيل عن تنفيذ البائع (HALs وشوكة Linux kernel الخاصة بالجهاز). وقد سهّل ذلك على مصنعي الأجهزة الأصلية لنظام التشغيل Android إعادة تأسيس أنظمة التشغيل الخاصة بهم على أحدث إطار عمل AOSP، حيث يمكنهم تشغيل الإصدار الأحدث دون الحاجة إلى تعليمات برمجية محدثة من البائعين. ونتيجة لذلك، يمكن لمصنعي المعدات الأصلية تجهيز شوكات Android المخصصة الخاصة بهم بشكل أسرع من ذي قبل، وبالتالي، نشر تحديثات نظام التشغيل الرئيسية بسرعة أكبر.

كانت الخطوة التالية في خطط Google هي تبسيط عملية تسليم التحديثات لمكونات Android الرئيسية. جوجل دعت هذه المبادرة مشروع الخط الرئيسي عندما قدمته إلى جانب Android 10 في عام 2019. سيطرت Google بشكل أساسي على مكونات نظام التشغيل الرئيسية ومنعت مصنعي المعدات الأصلية من تعديلها. ثم قاموا بإعداد آلية تسليم عبر Google Play حتى يتمكنوا من نشر التحديثات عن بعد لهذه المكونات الرئيسية دون الحاجة إلى انتظار مصنعي المعدات الأصلية لتطبيق التصحيحات بأنفسهم. أدى Mainline إلى تحسين كبير في مدى سرعة تلقي الأجهزة للإصدارات المحدثة من مكونات نظام التشغيل المهمة، مما أدى بدوره إلى تحسين أمان نظام Android البيئي ككل.

عندما يتعلق الأمر بـ Treble، لا ينبغي من الناحية الواقعية دمج نواة Linux مع كود البائع مغلق المصدر. تود كجوس في مؤتمر Linux Plumbers لهذا العام لقد أوضحت في الماضي الصعوبات التي تمت مواجهتها عندما يتعلق الأمر بالتجزئة على نظام Android، ويتركز الكثير منها الآن حول نواة Linux التي يشحنها مصنعو المعدات الأصلية مع أجهزتهم. للسياق، تقوم Google بتقسيم كل نواة Linux رئيسية إلى "نواة أندرويد المشتركة"(ACK)، الذي يتتبع الإصدار الرئيسي عن كثب ولكنه يضيف بعض التصحيحات الخاصة بنظام Android. ثم يتم تفرع بائعي SoC مثل Qualcomm وMediaTek وSamsung الذي - التي نواة لكل شركة نفط الجنوب التي يقومون بها. يأخذ مصنعو المعدات الأصلية بعد ذلك النواة الخاصة بـ SoC ويضيفون تصحيحات إضافية لتنفيذ الدعم للأجهزة المحددة التي يريدون شحنها.

يوضح الرسم البياني أعلاه كيف تمر نواة الجهاز عبر عدة طبقات من التغيير التي تجردها من نواة Linux LTS. لتبسيط الأمر، نبدأ مع Linux Kernel، ويتم دمجه في Android Common Kernel مع بعض التغييرات. من هناك، يتم دمج Android Common Kernel في نواة البائع (Qualcomm، MediaTek، إلخ) مع تعديلاته وتغييراته الخاصة. وأخيرًا، يتم دمج نواة البائع في نواة خاصة بجهاز الشركة المصنعة للمعدات الأصلية (OEM). في هذه المرحلة، تكون نواة أي جهاز بعيدة كل البعد عن نواة Linux LTS التي بدأ بها.

نتيجة لكل هذه التفرعات، فإن ما يصل إلى 50% من التعليمات البرمجية التي يتم تشغيلها على جهاز Android هي تعليمات برمجية خارج الشجرة، مما يعني أنها ليست من نواة Linux أو AOSP الشائعة. وهذا يجعل من الصعب للغاية (ناهيك عن استهلاك الوقت والمكلف) دمج التغييرات الأولية. بالنسبة لمصنعي المعدات الأصلية، ليس هناك حافز للقيام بذلك، ولكن هذه الممارسة يمكن أن تكون ضارة بأمان الجهاز. وهذا أيضًا هو السبب وراء ترك الكثير من أجهزة Android على إصدارات LTS kernel الأقدم، الأمر الذي له تأثير جانبي يتمثل في فقدان الأجهزة للوصول إلى ميزات Linux kernel الجديدة.

نظام Android مجزأ، وجوجل تعرف ذلك

جوجل تعلم جيدًا أن هذه مشكلة، ولديها قسم يسمى "تكاليف التجزئة" في وثائق مطور Android. جوجل يقول ذلك "تأتي معظم الأجهزة الرئيسية مزودة بإصدار kernel يبلغ عمره 18 شهرًا على الأقل". والأسوأ من ذلك أن جوجل تقول ذلك أيضًا "يدعم Android 10 نواة 3.18 و4.4 و4.9 و4.14 و4.19، والتي لم يتم تحسينها في بعض الحالات بميزات جديدة منذ Android 8 في عام 2017." وهذا يجعل من الصعب إضافة ميزات تتطلب إصدارات جديدة من Linux kernel. تم إطلاق Linux kernel 3.18 في ديسمبر 2014، عندما كان Android 5.0 Lollipop هو الإصدار الأحدث من Android. من الواضح أن هذه مشكلة ويمكن أن تعيق النظام الأساسي.

على سبيل المثال، يستضيف Code Aurora Forum، أو CAF باختصار، الكود المصدري للعديد من معالجات Qualcomm Snapdragon SoCs. كوالكوم، باعتبارها شركة نفط الجنوب يقوم البائع بتوزيع نسخة متشعبة من Linux kernel على مصنعي المعدات الأصلية/مصنعي التصميم الأصلي، ثم تقوم هذه الشركات بإضافة تغييرات خاصة بالجهاز عند الشحن الأجهزة. وهذا ما يضيف عدة طبقات من التجزئة. بالإضافة إلى ذلك، تجري شركة Qualcomm تغييرات على إطار عمل AOSP لتحسين نظام Android لكل منصة من منصات Snapdragon المحمولة الخاصة بالشركة. تقوم شركة Qualcomm بتوزيع نواة Linux المعدلة وإطار عمل AOSP وأدوات البرامج الأخرى بشكل خاص على شركائها كجزء من حزمة دعم اللوحة أو BSP. CAF هو المكان الذي تنشر فيه شركة Qualcomm بشكل علني تغييرات Linux kernel وتغييرات إطار عمل AOSP.

يمكن أن يكون إصدار CAF هذا مفيدًا لمطوري ROM المخصص الذين يرغبون في استخدامه كنقطة بداية بدلاً من AOSP الخالص، ولهذا السبب ترى أحيانًا ROM "المعتمد على CAF" في منتدياتنا. هل تتذكر Snapdragon 625 الذي بدا أنه يعمل على تشغيل العديد من الهواتف الذكية متوسطة المدى لسنوات؟ تم إطلاق ذلك مع Linux Kernel 3.18، وفي نهاية عام 2018 فقط (بعد عامين من إطلاق مجموعة الشرائح) قامت شركة Qualcomm بتحديث مصادر kernel ونشرها على كاف لـ msm8953 (اسم مجموعة الشرائح لـ Snapdragon 625) مما يوفر الدعم لنظام التشغيل Linux Kernel 4.9. المشكلة هي أن معظم مصنعي المعدات الأصلية لن يتم تحديث الهواتف إلى هذا الإصدار الجديد من Linux kernel، خاصة الهواتف متوسطة المدى بعد عامين من تحديث الشريحة مطلق سراحه. من المسلم به أنه من النادر جدًا أن يحدث تحديث كبير للنواة في المقام الأول، ولكن النقطة المهمة هي أنه لديه حدث ذلك، لذلك فهو ليس مجرد سيناريو مستحيل.

بشكل عام، التجزئة الحالية في نظام Android عبارة عن فوضى، إذا أردنا التعبير عنها باستخفاف. أحدث محاولات Google لإصلاح هذا التجزئة تأتي في شكل صورة Kernel العامة، أو GKI.

تقديم صورة النواة العامة

ومن أجل معالجة هذا التشرذم، عملت Google على Android Generic Kernel Image (GKI). هذا في الأساس نواة تم تجميعها مباشرة من فرع ACK. تعمل GKI على عزل تخصيصات بائعي SoC وOEM إلى وحدات المكونات الإضافية، مما يؤدي إلى التخلص من التعليمات البرمجية خارج الشجرة والسماح لـ Google بدفع تحديثات kernel مباشرةً إلى المستخدم النهائي. منذ أكثر من عام، تعمل جوجل على إيجاد طريقة لتوصيل تحديثات GKI عبر متجر Play، من خلال استخدام وحدة الخط الرئيسي.

ونتيجة لذلك، يجب على الأجهزة التي تعمل بنظام التشغيل Android 12 والتي تعمل بنظام التشغيل Linux kernel 5.10.43 أو أعلى القيام بأحد الإجراءات التالية، بحسب مشعل الرحمن.

• انشر صورة تمهيد موقعة من Google

أو

• انشر صورة تمهيد باستخدام نواة تقوم بتصدير KMI (واجهة وحدة Kernel) وهي مجموعة فرعية من KMI المصدرة بواسطة GKI، تصدير واجهة برمجة تطبيقات مساحة المستخدم التي تعد مجموعة شاملة من UAPI التي يعرضها GKI، ودعم جميع ميزات GKI المقابلة إصدار

يمكن للموردين إنشاء وحدات يتم توصيلها بـ GKI، لكن فكرة GKI هي أن Google تتحمل عبء مسؤولية التعامل مع تغييرات kernel. تعد واجهة وحدة Kernel (أو KMI، المزيد حول هذا الأمر في الأجزاء اللاحقة من المقالة) هي المكان الذي من المتوقع أن تذهب إليه التعليمات البرمجية خارج الشجرة.

تم إطلاق سلسلة Google Pixel 6 بنظام التشغيل Android 12 ويأتي مع Linux kernel 5.10، وهو أول هاتف يتم شحنه مزودًا بـ GKI. نظرًا لأنه من المحتمل أن تقوم Google بتحديث النواة من خلال متجر Play، فقد نرى تحديثات متكررة للنواة، حيث يتم عادةً إصدار تحديثات kernel LTS أسبوعيًا. وفي كلتا الحالتين، فهو نظام أفضل بكثير من الطريقة المرهقة حاليًا للتحديث عبر OTA، على الرغم من أن هذا يعني أنه مرتبط بطبيعته بإطار عمل GMS.

تُعرّف Google ببساطة GKI على النحو التالي:

• لقد تم بناؤه من مصادر ACK.
• إنها عبارة عن نواة واحدة ثنائية بالإضافة إلى وحدات قابلة للتحميل مرتبطة بكل بنية، لكل إصدار LTS (حاليًا فقط الذراع 64 لـ android11-5.4 و android12-5.4).
• تم اختباره مع جميع إصدارات نظام Android الأساسي المدعومة لـ ACK المرتبط. لا يوجد أي إهمال للميزات طوال عمر إصدار kernel GKI
• يعرض KMI مستقرًا للسائقين داخل LTS معين.
• لا يحتوي على SoC أو رمز خاص باللوحة.

تريد Google أيضًا أن تكون في وضع يسمح لها بحلول عام 2023 باتخاذ نموذج تطوير "المنبع أولاً". سيساعد هذا Google على ضمان وصول التعليمات البرمجية الجديدة أولاً إلى Linux kernel الرئيسي، مما يقلل من "الديون الفنية" المتراكمة على أجهزة Android.

واجهة وحدة Kernel (KMI)

تعد واجهة وحدة Kernel، أو KMI، جزءًا من حل Google للتجزئة المستمرة في Android. في جوهر الأمر، لم يعد دعم SoC واللوحة موجودًا في النواة الأساسية ويتم نقلهما بدلاً من ذلك إلى وحدات قابلة للتحميل. يمكن تحديث كل من النواة والوحدات بشكل مستقل بعد ذلك، حيث يتم تحديث الوحدات /lib/modules. من المفترض أن تكون GKI نفسها نظيفة وعامة قدر الإمكان، وهو ما أصبح ممكنًا عن طريق إلغاء تحميل ما أصبح الآن رمزًا خارج الشجرة إلى وحدات منفصلة.

كما تيد كجوس وأوضح في في مؤتمر Linux Plumbers لهذا العام، "تتمثل الدفعة الكبيرة المتعددة السنوات في إخراج جميع التعليمات البرمجية الخاصة بالأجهزة من النواة العامة إلى وحدات البائعين. يجب أن يكون لدينا واجهة مستقرة بين وحدات البائعين هذه والنواة العامة حتى يتمكنوا من الشحن بشكل غير متزامن." GKI 1.0 هو في الأساس "اختبار امتثال".

في الواقع، توافق GKI يعني أن الجهاز يجتاز اختبارات VTS وCTS-on-GSI+GKI مع صورة النظام العامة (GSI). ويتم تثبيت نواة GKI عن طريق وميض صورة تمهيد GKI في قسم التمهيد وصورة نظام GSI في النظام تقسيم. إن مجموعة اختبار البائع، أو VTS، عبارة عن اختبار تلقائي يجب على جميع الأجهزة اجتيازه حتى تعتبر متوافقة مع Project Treble. يلزم وجود مجموعة اختبار التوافق، أو CTS، للوصول إلى مجموعة تطبيقات Google.

يمكن أن يتم شحن الأجهزة باستخدام نواة منتج مختلفة ويمكنها استخدام وحدات قابلة للتحميل لا توفرها GKI. ومع ذلك، يجب على كل من المنتج ونواة GKI تحميل الوحدات النمطية من نفس قسم "التمهيد_المورد" و"المورد". ولذلك، يتعين على كافة نواة المنتج أن يكون لها نفس واجهة وحدة النواة الثنائية (KMI).

الرسم البياني أعلاه يوضح ما جوجل يريد للقيام به، ويشرح كيف ينوي الوصول إلى ذلك. ستكون وحدات Kernel العامة وGKI جزءًا من AOSP، ويمكن لـ GKI التواصل مع إطار عمل Android وطبقة تجريد الأجهزة (HAL) التي قد ينفذها البائع. سيتم بدلاً من ذلك دفع رمز الملكية المحدد الذي يريده البائع في النواة (على سبيل المثال، برامج تشغيل الكاميرا) إلى وحدة البائع التي تصبح امتدادًا لـ GKI عبر KMI.

كيف يمكن لـ GKI المساعدة في حل مشكلة تجزئة Android

لقد بذلت Google الكثير من العمل لتبسيط عملية تطوير الهواتف الذكية. يريد كل مصنع OEM هوية علامته التجارية الخاصة، ويريد كل مصنع OEM أن يكون قادرًا على ملكية أجهزته. على عكس برنامج Android One، يمكن للهواتف الذكية التي تعمل بنظام Android أن تكون ما تريد إلى حد كبير، طالما أنها تلتزم بمجموعة القواعد التي تحددها Google من أجل الحصول على ترخيص GMS. ومع ذلك، في الماضي، لم تفعل Google الكثير للسيطرة على تطوير أجهزة Android التغييرات مثل Project Treble وMainline والآن أصبح GKI أحدث بكثير في نظام Android تاريخ.

ولكن هل سيساعد؟ ينبغي أن يكون الأمر كذلك، على الرغم من أنه من المرجح أن يستغرق الأمر عدة سنوات ويؤتي ثماره بشكل واضح في وقت لاحق. سينطبق هذا فقط على الأجهزة التي تعمل بنظام Android 12، مما يعني أننا سنرى أجهزة لا تحتوي على GKI لسنوات قادمة. كان ذلك أيضًا بمثابة انتقاد لمشروع Treble عندما تم الإعلان عنه، على الرغم من أنه من الواضح أن جميع الأجهزة التي تم إطلاقها في الوقت الحاضر تدعمه. تستغرق هذه الأمور وقتًا، وبما أن Google تبسط سيطرتها ببطء على Android، فقد أصبحت عملية التطوير أسهل لجميع مصنعي المعدات الأصلية في نظام Android البيئي، حتى لو كان البعض منهم يفضل الاحتفاظ بالسيطرة الكاملة على Linux kernel المستخدم على Android الهواتف الذكية.