من Store to Shelf: استسلام متعمق عن سبب استبعاد أجهزة MSM8974 من Nougat

تم التحديث ليعكس متطلبات إما Vulkan أو OpenGL ES 3.1 لنظام Android 7.0

في الآونة الأخيرة ، كان هناك الكثير من المقالات المكتوبة حول تحديثات الإصدار ، والتفاعلات بين البائع وصانع الشرائح ، وماذا يعني ذلك بالنسبة للأجهزة التي تتقدم. لماذا ارتفع هذا الأسبوع؟

حسنًا ، ظهر هذا الأسبوع بالنظر إلى أن جهاز Nexus 5 الموقر لن يتلقى التحديث لنظام Android 7.0 (Nougat) ، وأعلنت شركة كوالكوم أنها لن تقدم الدعم لـ MSM8974 (المعروف باسم Snapdragon 801) في الإصدار 7.0. كُتِب هذا المقال بالتعاون مع نحلة المطور المعترف بها.

لقد اجتذب هذا الموضوع قدرًا كبيرًا من الاهتمام من مختلف المواقع الإخبارية ، لكن الكثير منهم يفقدون الفروق الدقيقة لما يحدث بالفعل خلف الكواليس . تشرح هذه المقالة المزيد حول كيفية عمل تحديثات البرامج ، باستخدام خبرتنا في العمل مع OEMs على تحديثات البرامج الثابتة الرسمية الخاصة بهم. سنتعرف على ما يجري وراء الكواليس (ولماذا) ، ولماذا قد لا ينتهي بك الأمر إلى الحصول على أحدث البرامج على هاتفك.

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

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

تحتوي مستودعات AOSP الأولية على دعم الجهاز لعدد محدود من الأجهزة فقط. هذه هي عادة أجهزة Nexus الخاصة بك. لأسباب ستتضح بعد قليل ، من المهم الإشارة إلى أن Google ليس لديها تحكم كامل بالأجهزة على هذه الأجهزة ؛ يتم تصنيع الأجهزة من قبل الشركة المصنّعة للمعدات الأصلية (OEM) ، وستقوم الشركة المصنّعة (OEM) بشراء نظام (On-Chip) من صانع شرائح.

بمجرد إصدار التعليمات البرمجية المصدر ، سيقوم فريق البرامج الثابتة التابع لـ OEM (مجازيًا) بالجلوس ووضع أقدامهم. لا تحتوي شجرة مصدر Android الرئيسية على دعم الأجهزة لعدد لا يحصى من الشرائح المستخدمة في أجهزة الشحن. غالبًا ما تكون شرائح Qualcomm غير مدعومة ضمن AOSP ، على سبيل المثال. لديك Exynos واحد بالتأكيد لا. Mediatek أو HiSilicon؟ انسى ذلك!

"يحتوي BSP على طبقات تجريد الأجهزة (HALs) اللازمة لتشغيل Android"

ما نحتاجه الآن هو حزمة دعم المجلس (BSP) . هذه حزمة فائقة السرية من المكونات الاحتكارية ، يتم تسليمها من قبل صانع شرائح إلى مصنع OEM. يحتوي BSP على الكود المصدري الضروري للسماح لمصنعي المعدات الأصلية ببناء نظام أندرويد وبرامج التشغيل اللازمة لجهازهم.

تجدر الإشارة هنا إلى أن المصنّعين الأصليين مثل Qualcomm لا يثقون بالضرورة تمامًا في شركاء OEM لديهم - يتوفر BSP على أساس "need to know". لا يحصل مصنعو المعدات الأصلية عادةً على إمكانية الوصول إلى الكود المصدري لبعض الأجزاء فائقة السرية من الجهاز (مثل البرنامج الذي يعمل على النطاق الأساسي). من المؤكد أن إغلاق هذا الجزء أيضًا ينطوي على مشكلات محتملة ، كما هو موضح في نقاط الضعف ASN.1 التحليلية الكثيرة والمتكررة.

يحتوي BSP على طبقات تجريد الأجهزة (HALs) اللازمة لتشغيل Android على جهازك. يحتوي AOSP على مجموعة من HALs ، والتي تعمل بمثابة تعريفات لما يتوقعه نظام التشغيل من برامج التشغيل الخاصة بك. لاستخدام مثال مفرط التبسيط يبعث على السخرية (ومصنع ، لأغراض العرض التوضيحي) ، دعونا نتخيل المصباح على هاتفك.

مثال هال - مصباحك

دعنا نتخيل أن جهازك يحتوي على مصباح يدوي في الخلف (إذا كان لديك جهاز Nexus 7 2013 ، فستحتاج إلى القيام بخيال أكثر قليلاً من أي شخص آخر - آسف!). يتم التحكم في هذا بواسطة سائق. على سبيل المثال ، مثالنا البسيط المجنون ، دعنا نفترض أن v1 HAL تنص على أنه ينبغي أن يكون لديك وظيفة واحدة تسمى "setLED" تأخذ معلمة واحدة ، هي حالة الضوء. إنها منطقية - صحيحة أو خاطئة. في C ، سيبدو هذا كالتالي:

void setLED (bool ledState) {

// هنا هو الكود الفعلي لتشغيل أو إيقاف تشغيل LED ، بناءً على ledState

}

يتم تعريف هذه الوظيفة ضمن شفرة مصدر BSP. يتم تجميع BSP من قِبل الشركة المصنّعة للمعدات الأصلية أثناء إنشاء ROM ، ويصبح هذا أحد مكتبات ".so" الخاصة في قسم البائع أو منطقة جهازك. يتيح ذلك لـ OEM الاحتفاظ بأجزاء معينة من أعمال أجهزتهم سرية. في الوقت الحالي ، دعنا نفترض أنهم يريدون إيقاف كل شخص يرى كيف يشغلون ويشتعلون هذا المصباح.

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

باستخدام HAL الجديد (الخيالي) للسطوع ، دعنا نفترض أن Google تقول إنك بحاجة إلى الكشف مرة أخرى عن وظيفة تسمى setLED ، لكن هذه المرة مع عدد صحيح تم تمريره للسطوع. الآن ، 0 سيطفئه ، و 255 سوف يضعه بالكامل.

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

مجموعة باطلة LED (uint8_t ledBrightness) {

// بعض الطرق فائقة السرية والملكية الفائقة لتعيين سطوع LED

}

وماذا في ذلك؟ حسنًا ، هذا الإصدار الجديد من Android لا يتوافق مع "النقط" الحالية. يحتاج OEM الخاص بك إلى استخدام هذه النقاط الجديدة ، لأن نظام التشغيل Android يتوقع أن يرى تعريف الوظيفة الجديد ، ولن "يجد" القديم عندما يبحث عن طريقة لتعيين مؤشر LED.

في هذه المرحلة ، دعنا نأخذ استراحة قصيرة للنظر في كيفية إدارة ذاكرة القراءة فقط المخصصة (المبنية من المصدر) هنا. هذا ما يخبركه الأذكياء على شاشتك الآن - بعد كل شيء ، نحن ، موطن HTC HD2 ، أطول هاتف دائم في العالم ... (فقط للتسجيل ، يتم تشغيل العباقرة المجانين على نظام Android 6.0 على HD2 هذه الأيام! ليس سيئًا للهاتف المشحون أصلاً مع Windows Mobile 6.5 في 2009)

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

تتمثل طريقة "shim" في كتابة وبناء مكتبة جديدة صغيرة بنفسك ، والتي تحتوي على تعريف الوظيفة المتوقع - على سبيل المثال ، نحن ندعم العدد الصحيح للسطوع. ثم ، داخل الرقائق ، يتم ترجمة هذا لتلبية متطلبات HAL القديمة. لذلك على سبيل المثال ، قد نقول أن أي سطوع مطلوب أعلاه 128 سيؤدي إلى تشغيل المصباح وأي شيء أدناه من شأنه أن يطفئه. أو يمكنك أن تقول أي شيء لا الصفر سوف تشغيله. الأمر متروك للمطور. يقومون بتجميع الرقائق ، وحمل Android على استخدامه بدلاً من النسخة الأصلية. ثم يستدعي shim blob OEM.

من المفترض أن يؤدي تشغيل 'adb push' (إعادة التشغيل السريع) وإعادة التشغيل إلى تشغيل اللمبة ، وتتيح لك التحكم في LED الخيالي ، على الرغم من أن لديك HAL القديم فقط.

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

(نعم ، هذا هو أحد الأسباب وراء وجود المراوغات والأخطاء عندما يدير المستخدمون والمطورون مآثرهم المجنونة والمجنونة من براعة النقل. أعني أن هيك ، يعمل Galaxy S II على إصدار Android 6.0 ROM الآن على ما يبدو قابلاً للاستخدام. الهواتف التي تم إصدارها العام الماضي ما زالت لا تملك 6.0!)

دعونا القفز مرة أخرى إلى وجهة نظر OEM. للأسف ، يعمل معظم مصنعي المعدات الأصلية بالفعل على هاتف واحد على الأقل قبل أن نكون في الوقت الحالي. ينصب تركيزهم على الهاتف التالي الذي هم على وشك بيعه - لا يمكنك إلقاء اللوم عليهم حقًا ، حيث أنهم يكسبون المال فقط على الأجهزة التي يبيعونها. إنهم لا يكسبون أي أموال من الأجهزة التي باعوها منذ عام أو عامين ، لذلك عليهم الاستمرار في إطلاق أجهزة جديدة في الوجود. هذا هو أحد الأسباب التي تواجه HTC و Blackberry في مشكلة - لا يهم كم من المديرين التنفيذيين يحتفظون بقبضة الإعدام على Blackberry Curve القديم ، حيث أنهم لا يحصلون على بيع جهاز جديد هناك.

إذا لم يحصل مصنع المعدات الأصلية على BSP ، فلن يسقط في نهج اختراق بنية ما. لماذا ا؟ حسنًا ، يحتاجون إلى دعم هذه البرامج الثابتة لعملائهم . إذا قاموا بإصدار برنامج ثابت نصف عمل ، فسوف يكرههم المستخدمون ، ويتشدقون ويذخرون ، ويبقون خطوط الدعم الخاصة بهم طيلة أيام.

يجب على مصنعي المعدات الأصلية أيضًا التعامل مع شركات النقل ، على الأقل في الأسواق غير الأوروبية. لا تريد شركات النقل أن يواجه العملاء مشكلات مع تحديثات البرامج. في الواقع ، غالباً ما لا تقوم شركات الاتصالات بنشر تحديثات البرامج.

لفهم هذا ، تخيل أليس لديك العمة العظمى. إنها الشخص الذي يتصل بك هاتفياً في أوقات غير مريحة من اليوم لطلب المساعدة بشأن "شيء الكمبيوتر". ثم تصف كيفية النقر فوق "قائمة ابدأ" ، ويجب عليك تحديدها على أنها "علامة كبيرة في الركن الأيسر السفلي" ، وتواجه الارتباك. بعد حوالي 45 دقيقة (وإحباط كبير) في وقت لاحق ، ظهر أن Aunt Alice قد سحبت قائمة البداية إلى حافة الشاشة اليمنى ، وتحتاج ببساطة إلى سحبها للخلف. نعم ، مع زر الماوس الأيسر!

الآن تخيل أن لديك ألف عمة أليس. إنهم جميعًا يتصلون بدعم العملاء ، وغير قادرين على العثور على Candy Crush على هواتفهم ، قلقون من قيام أحد المتطفلين بحذفه من هواتفهم. أوه ، والرموز تبدو مختلفة بعض الشيء الآن - ربما لا يزال القراصنة في هواتفهم؟

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

بمجرد حصول OEM على BSP ، ستقوم بنقل ذاكرة الوصول العشوائي الخاصة بهم وتطبيق جميع التغييرات على ROM. سوف يتراكمون في bloatware الخاصة بهم ، ويضيفون بشرة كرتونية رائعة من شأنها أن تبدو أكثر في المنزل في أنيمي المراهق. ثم سوف يختبرونه.

كثير.

هناك كل أنواع المتطلبات التي يجب أن يلتزم بها هاتفك. تم تصميم شبكات الهاتف المحمول لتثق في أجهزة المستخدم (ما نسميه الهاتف) لتتصرف بشكل صحيح. هذا يعني أن هناك الكثير من الاختبارات اللازمة للحصول على موافقة الجهاز. تهدد تحديثات البرامج بتغيير السلوكيات ، لذلك يجب اختبار الأشياء مرة أخرى. لهذا السبب سترى عادة معلومات حول تحديثات برامج Sony القادمة من خدمات الاختبار الخارجية ، والتي تؤكد أن البرنامج الثابت متوافق مع متطلبات الاختبار.

الآن ... ماذا يحدث بعد التحديث أو اثنين (أو في بعض الحالات ، لا شيء)؟ صانع SoC لن يمنح مصنعي المعدات الأصلية BSP محدثين . بعد كل شيء ، فإن صانع شركة نفط الجنوب لن يحصل على الكثير من هذا. لا يبذل OEM أي أموال إضافية على هاتفك منذ بيعها. وفي هذه المرحلة ، لا يحصل هاتفك على المزيد من تحديثات الإصدار الرئيسية.

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

التحديثات معقدة. هناك الكثير من الأشخاص المختلفين المشاركين في السلسلة. لا شيء من هذا يعفي مصنعي المعدات الأصلية من حالة عدم الثبات والشفقة الحالية للتحديثات على نظام أندرويد. ومع ذلك ، هناك بعض التحديات الحقيقية هنا.

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

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

للأسف ، هذا ليس كافيًا حقًا. على الرغم من أن Google تواصل إصدار التحديثات ، إلا أن أمان جهازك لا يزال يعتمد على صانع SoC - نظرًا لأن صانعي SoC يشعرون بالصدمة من اكتشاف شخص ما كيف يشغلون مصابيح LED أو يصدرون صوتًا عبر مكبر صوت ، إلا أنهم يشحنون كميات هائلة من النقطات الثنائية على أجهزتهم. تحتوي هذه النقط على بعض التعليمات البرمجية غير الآمنة بشكل رهيب (ألقِ نظرة على نشرات أمان Google السابقة إذا كنت تعتقد أن هذه مبالغة!) وتحتاج إلى تحديث. مما يعني تحديث BSPs مطلوبة.

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

هذا يعني أن الاختصارات قد اتخذت - فلن تجد هاتفك مدعومًا من قِبل Linux kernel الرئيسي ، وستجد أن لكل هاتف طريقة مختلفة للتمهيد. على الكمبيوتر المحمول أو سطح المكتب الخاص بك ، استقر البائعون على بعض الطرق القياسية للتمهيد - كان سابقًا MBR (سجل التمهيد الرئيسي) مع BIOS ، والآن أصبح UEFI. يتيح هذا التقييس تشغيل البرنامج نفسه على كل جهاز.

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

سلكية مقبس سماعة الرأس بطريقة خاطئة الجولة؟ مجرد اختراقه في السائقين! ليس هناك وقت لإصلاحها في تصميم الإنتاج.

شنت فريق التصنيع وحدة الكاميرا رأسا على عقب في دفعة الإنتاج 1؟ قم بالاختراق للتحقق من رمز الإصدار الداخلي ، وقلب الفيديو حوله إذا كان الإصدار 1!

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

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

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

هذا سؤال صعب بدون معرفة داخلية من كوالكوم ، والذي للأسف ليس لدينا في الوقت الحالي. ومع ذلك ، يمكننا استخلاص بعض المعلومات من متطلبات API الخاصة ببرنامج تشغيل Android 7.0 و CTS. تحدد متطلبات CTS ما تتوقعه Google من جهاز يشغل برنامجًا محددًا. إن "المطرقة الكبيرة" المستخدمة لتطبيق هذه المتطلبات هي ترخيص Google لاستخدام حزمة خدمات Google Play الخاصة بها - إذا لم تمتثل ، فلن تتمكن من شحن تطبيقات Google على الجهاز . بينما ، بالنسبة للبعض ، قد يُنظر إلى ذلك على أنه ميزة ، فمن الواضح أن هذا ليس ما يريده المستخدمون ويتوقعونه من الجهاز.

لم يضف Android 7.0 الكثير عن طريق إدخال تغييرات على HAL أو برامج التشغيل (كما هو موضح أعلاه) ، لذلك فمن غير المرجح أن يأتي عدم التوافق من هناك على وجه التحديد. لكن من المرجح أن تطرح مشكلة ما ، هو تقديم متطلبات جديدة إما أن تكون واجهة برمجة تطبيقات رسومات Vulkan أو GLES 3.1 متاحة لتجاوز CTS.

في الوقت الحالي ، لم يكن لدى الكثير من Systems-on-Chip (SoCs) دعم Vulkan على معالج الرسومات الخاص بهم ، بما في ذلك MSM8974. هذا هو الأرجح على الأرجح حيث تنشأ مشكلة التوافق مع Android 7.0. مرة أخرى رغم ذلك ، وبدون المعرفة الداخلية من كوالكوم ، وخططهم المستقبلية ، من الصعب علينا أن نقدم بيانًا نهائيًا دون تأهيله. ومع ذلك ، في الوقت الحالي ، نعتقد أنه من المحتمل أن تكون هذه هي الحالة "البسيطة" المتمثلة في وقف دعم كوالكوم لشرائح MSM8974 (في أعينهم) ، وعدم توفير BSP (حزمة دعم اللوحة) ل 7.0 على هذا النظام الأساسي. إذا كان الأمر كذلك ، فذلك يعني أن مصنعي المعدات الأصلية سيكونون متأكدين تقريبًا من عدم شحن 7.0 على الجهاز - سيجدون بطريقة أو بأخرى دعم Vulkan أو GLEs 3.1 لوحدة معالجة الرسومات الخاصة بهم ، ورمز مصدر GPU هو أحد رموز الحماية المشددة بسخرية أجزاء من مكدسات الأجهزة المحمولة (دون سبب حقيقي ، نضيف - انظر AMD ، نفتح مصادر برنامج تشغيل AMDGPU الخاص بهم على سطح المكتب لنظام Linux). ولكن من المحزن أن رسومات Vulkan والرسومات المتسارعة (GLES) بشكل عام أكثر تعقيدًا من مؤشر LED بسيط ، لذلك ليس هذا شيئًا سنرى الحشوات لإدخال التوافق عليه.

نظرًا لأن الإصدار 7.0 لم ينفد لفترة طويلة ، فهناك إمكانية حقيقية لشرائح أخرى (بخلاف العدد الصغير داخل AOSP نفسه) لتتخلف عن الإصدار 6.0 ، إما بسبب مشكلات في الأجهزة وبرامج التشغيل (أي عدم وجود BSP محدث) أو نقص دعم البائع SoC فيما يتعلق Vulkan أو GLES 3.1 API. في الوقت الحاضر ، لا Snapdragon 800 أو 801 تدعم واحدة من هذه.

أفضل رهان هو مشاهدة هذه المساحة - حيث يقوم المطورون بالفعل بتحقيق تقدم جيد مع المنافذ غير الرسمية إلى 7.0 للعديد من الأجهزة التي لا تحصل على دعم رسمي 7.0 من Google. هذه دون دعم Vulkan أو GLES 3.1 - ربما يبدأ مطورو الألعاب على Android في تجربة الإحباط من خلال التجزئة إذا بدأ عدد كاف من المستخدمين في تشغيل ROM مخصص دون دعم Vulkan أو GLES 3.1؟

تميل Apple إلى دعم خط iPhone الخاص بها على أحدث إصدار من نظام التشغيل iOS لمدة 5 سنوات تقريبًا - تم إطلاق جهاز iPhone 4s في أكتوبر 2011 ، وتم تحديثه باستمرار حتى نظام iOS 9. ولن يتلقى تحديث iOS 10 القادم ومع ذلك ، مما يمنح الهاتف عمرًا فعالًا لمدة 5 سنوات ، على افتراض أن iOS 10 قد تم إطلاقه في حوالي شهر أكتوبر. تجدر الإشارة إلى أن Apple لا تدعم دائمًا واجهة برمجة تطبيقات الرسومات في الخلف - لا يحتوي iPhone 4s و iPhone 5 على واجهة برمجة تطبيقات Apple للرسومات المعدنية ، وهو سيناريو مشابه إلى حد ما للسيناريو في Android في Vulkan. الفرق الوحيد هو أن Apple واصلت دعم الأجهزة القديمة دون واجهة برمجة تطبيقات الرسومات الجديدة.

ما رأيك؟ هل ستومض ذاكرة ROM مخصصة على هاتفك لتمديد عمر الخدمة؟ هل قلت في التعليقات أدناه.