כניעה מעמיקה של הסיבה לכך שמכשירי SD801 אינם נכללים בנוגט

עודכן כדי לשקף את הדרישה או-או Vulkan או OpenGL ES 3.1 עבור אנדרואיד 7.0

לאחרונה נכתבו הרבה מאמרים על עדכוני גרסאות, האינטראקציות בין הספק ליצרן ערכות השבבים, ומה זה אומר לגבי מכשירים קדימה. למה זה הגיע לעלות השבוע?

ובכן, זה התברר השבוע בהתחשב בכך שה-Nexus 5 המכובד לא יקבל את העדכון לאנדרואיד 7.0 (Nougat), וקוואלקום הודיעה שזה לא יהיה מתן תמיכה עבור MSM8974 (הידוע יותר בשם Snapdragon 801) ב-7.0. מאמר זה נכתב כשיתוף פעולה עם XDA Recognized מפתח דבורת בומבוס.

הנושא עורר מעט עניין מאתרי חדשות שונים, אבל רבים מפספסים את הניואנסים העדינים של מה שבאמת קורה מאחורי הקלעיםס. מאמר זה יסביר מעט יותר כיצד עדכוני תוכנה עובדים, תוך שימוש בניסיון שלנו בעבודה עם יצרני OEM על עדכוני הקושחה הרשמיים שלהם. אנו נדריך אותך במה שקורה מאחורי הקלעים (ומדוע), ולמה ייתכן שלא תקבל את התוכנה העדכנית ביותר בטלפון שלך.

הצעד הראשון בחייו של עדכון קושחת אנדרואיד הוא העדכון במעלה הזרם. זה מה שגוגל עובדת עליו באופן פנימי. בניגוד ל"זרימות עבודה פתוחות", אנדרואיד מפותחת באמצעות זרימת עבודה סגורה, כאשר קוד מקור נזרק מעל הקיר מדי שנה בערך, כשיוצאת מהדורה חדשה. במקור, גוגל אמרה שזה היה כדי למנוע פיצול מאנשים שמריצים גרסאות מתקדמות אמנם דברים התפתחו במהירות בימים הראשונים, אבל נראה שהם שמרו על מדיניות זו מקום.

בנקודת זמן מסוימת, בדרך כלל לפני ההכרזה הפומבית על עדכון (אם כי עם ההשקה האחרונה של בטא ציבוריות, לוחות הזמנים הללו משתנים), יצרני OEM יידעו על עדכון קרוב. לאחר מכן הם יקבלו את קוד המקור בנקודת זמן שנייה לעדכון הסופי (בעבר, כך היה לפעמים קצת לפני ההשקה, אם כי אנחנו מודעים גם למקרים שבהם אין מוקדם לְשַׁחְרֵר).

מאגרי AOSP במעלה הזרם מכילים תמיכה במכשירים למספר מוגבל של מכשירים בלבד. אלו הם בדרך כלל מכשירי ה-Nexus שלך. עם זאת, מסיבות שיתבררו בקרוב, חשוב לציין שלגוגל אין שליטה מלאה בחומרה על מכשירים אלו; המכשירים מיוצרים על ידי יצרן ציוד מקורי, ו-OEM זה יקנה System-on-Chip (SoC) מיצרנית ערכות שבבים.

לאחר שחרור קוד המקור, צוות הקושחה של ה-OEM ישוב (באופן פיגורטיבי) לאחור וירים את רגליים. לעץ המקור הראשי של אנדרואיד אין תמיכה בחומרה עבור שלל ערכות השבבים המשמשות במשלוח התקני. סביר להניח שערכת השבבים של Qualcomm שלך אינה נתמכת בתוך AOSP, למשל. ה-Exynos שלך בהחלט לא. Mediatek או HiSilicon? שכח מזה!

ה-BSP מכיל את מנהלי ההתקן ושכבות הפשטת החומרה (HALs) הדרושים כדי להפעיל את אנדרואיד

מה שצריך עכשיו זה א חבילת תמיכה בלוח (BSP). זוהי חבילה סופר-סודית של רכיבים קנייניים, הנמסרת על ידי יצרן ערכות שבבים ל-OEM. ה-BSP מכיל את קוד המקור הדרוש כדי לאפשר ליצרני OEM לבנות אנדרואיד ואת מנהלי ההתקן הדרושים למכשיר שלהם.

ראוי לציין כאן שיצרני OEM כמו קוואלקום לא בהכרח סומכים על שותפי ה-OEM שלהם באופן מלא - ה-BSP זמין על בסיס "צריך לדעת". יצרני OEM אינם מקבלים בדרך כלל גישה לקוד המקור עבור חלק מהחלקים הסודיים ביותר של המכשיר (כגון התוכנה הפועלת על פס הבסיס). לסגירת החלק הזה יש בהחלט גם בעיות פוטנציאליות, כפי שהוכח על ידי הקרובים שׁוֹפֵעַ ו מַחזוֹרִי ASN.1 ניתוח נקודות תורפה.

ה-BSP מכיל את מנהלי ההתקן ושכבות הפשטת החומרה (HALs) הדרושים כדי להפעיל את אנדרואיד במכשיר שלך. AOSP מכיל קבוצה של HALs, הפועלים כהגדרות לגבי מה שמערכת ההפעלה מצפה מהנהגים שלך ליישם. אם להשתמש בדוגמה פשוטה מדי (וממציאה, לצורך הדגמה) בצורה מגוחכת, בואו נדמיין את הפנס בטלפון שלכם.

דוגמה HAL - הפנס שלך

בואו נדמיין למכשיר שלכם יש פנס מאחור (אם יש לכם Nexus 7 2013, תצטרכו לדמיין קצת יותר מכולם - סליחה!). זה נשלט על ידי נהג. עבור הדוגמה הפשוטה בטירוף שלנו, נניח שה-v1 HAL אומר שתהיה לך פונקציה אחת שנקראת "setLED" שלוקחת פרמטר בודד, מצב האור. זה בוליאני - נכון או שקר. ב-C זה ייראה בערך כך:

void setLED(bool ledState) {

// here is the actual code to turn on or off the LED, based on ledState

}

פונקציה זו מוגדרת בתוך קוד המקור של BSP. לאחר מכן, ה-BSP מורכב על ידי ה-OEM במהלך בניית ה-ROM, וזה הופך לאחת מספריות ".so" הקנייניות במחיצת הספק או באזור המכשיר שלך. זה מאפשר ל-OEM לשמור בסוד חלקים מסוימים של פעולת המכשיר שלהם. לעת עתה, בואו נניח שהם רוצים למנוע מכולם לראות איך הם מדליקים ומכבים את ה-LED הזה.

כעת דמיינו שגוגל משחררת גרסה מעודכנת של ה-HALs שלהם בגרסה עתידית של אנדרואיד. כעת הם מחליטים שזה יהיה נחמד לאפשר לך לעדכן את בהירות ה-LED שלך, במקום רק להדליק או לכבות אותו. אולי זה מיועד לפלאש אדפטיבי, או אולי זה רק כדי לאלץ עדכון HAL, ולהשאיר את יצרניות השבבים בעסק? אנו ניתן לך, הקורא, להגיע לדעה משלך בעניין זה. לחלק מעדכוני HAL יש תועלת ברורה (כגון המצלמה HAL החדשה שחושפת צילום גולמי וכדומה), בעוד שאחרים קצת פחות ברורים במטרתם.

עם ה-HAL החדש (הבדיוני) הזה לבהירות, נניח שגוגל אומרת שאתה צריך לחשוף שוב פונקציה שנקראת setLED, אבל הפעם עם מספר שלם שמועבר לבהירות. כעת, 0 יכבה אותו, ו-255 יפעיל אותו במלואו.

אם אתה ה-OEM, אתה יכול לקחת את הקוד הסודי שלך כדי להדליק את ה-LED הזה ולהכניס אותו לפונקציה החדשה הזו. אתה יכול אפילו להשתמש באפנון רוחב הדופק כדי להתאים את בהירות הנורית על סמך המספר. אתה משנה את הפונקציה להופיע כך עכשיו:

void setLED(uint8_t ledBrightness) {

// some super-secret and ultra-confidential proprietary way to set LED brightness

}

אז מה? ובכן, כעת הגרסה החדשה הזו של אנדרואיד אינה תואמת ל"כתמים" קיימים. ה-OEM שלך צריך להשתמש בבלובים החדשים האלה, מכיוון שמערכת ההפעלה של אנדרואיד מצפה לראות את הגדרת הפונקציה החדשה, ולא "תמצא" את הישנה כשהיא מחפשת דרך להגדיר את ה-LED.

בשלב זה, בואו ניקח הפסקה קצרה כדי להסתכל על איך ROMs מותאמים אישית (הבנויים ממקור) מתנהלים כאן. זה מה שהפיקח מכם יצעק על המסך שלך עכשיו - אחרי הכל, אנחנו XDA, הבית של HTC HD2, הטלפון העמיד ביותר בעולם... (רק לפרוטוקול, הגאונים המטורפים שם רצים אנדרואיד 6.0 ב-HD2 בימים אלה! לא רע עבור טלפון שנשלח במקור עם Windows Mobile 6.5 בשנת 2009)

ישנן גישות שונות שננקטו כאן - לפעמים מפתחים פורצים בתוך ה-ROM ואומרים למערכת ההפעלה להשתמש בהגדרות הפונקציה הישנות. זה קצת מבולגן ועושה הרבה שינויים לתחזוקה. הגישה הנוספת היא "שיים" את ה-OEM הבינארי.

גישת ה-"shim" היא לכתוב ולבנות ספריה חדשה וקטנטנה בעצמך, המכילה את הגדרת הפונקציה הצפויה - לדוגמה שלנו, היינו תומכים במספר השלם עבור בהירות. לאחר מכן, בתוך ה-shim, זה מתורגם כדי לעמוד בדרישות של HAL הישן. אז לדוגמא שלנו, אולי היינו אומרים שכל בהירות שמבוקשת מעל 128 תדליק את ה-LED, וכל דבר מתחת לזה יכבה אותה. או שאתה יכול לומר שכל דבר שאינו אפס יפעיל אותו. זה תלוי במפתח. הם מרכיבים את ה-shim ומביאים לאנדרואיד להשתמש בו במקום המקורי. לאחר מכן, ה-shim קורא ל-OEM blob.

דחיפה מהירה של adb ואתחול מחדש אמורים להפעיל את ה-shim ולאפשר לך לשלוט ב-LED הבדיוני שלך, למרות שיש לך רק את ה-HAL הישן.

הבעיה היא שברור שזה תהליך לא מושלם. כעת תקבלו מוזרויות - למכשיר הזה יהיה פלאש די גס, שהוא או כבוי לחלוטין או כבוי. זה לא אידיאלי - מערכת ההפעלה חושבת שהיא מפיקה אור עדין מאוד, אבל ה-LED בפועל נאמר שהיא מתחרה בתחרות שמש מלאכותית, ומנסה לסנוור אותך. אבל היי, החיים לא מושלמים, ועכשיו יש לך נורת LED פועלת בטלפון הישן שלך!

(כן, זו אחת הסיבות לכך שיש מוזרויות ובאגים כאשר משתמשי ומפתחים של XDA מנהלים את הישגיהם המטורפים והמטורפים של כושר הניוד. אני מתכוון לעזאזל, ה גלקסי S II הוא שמיש לכאורה אנדרואיד 6.0 ROM עכשיו. להרבה טלפונים שיצאו בשנה שעברה עדיין אין 6.0!)

בואו נקפוץ חזרה לנקודת המבט של ה-OEM. למרבה הצער, רוב יצרני ה-OEM כבר עובדים לפחות טלפון אחד לפני המקום בו אנו נמצאים כעת. ההתמקדות שלהם היא בטלפון הבא שהם עומדים למכור - אי אפשר באמת להאשים אותם, מכיוון שהם מרוויחים כסף רק על מכשירים שהם מוכרים. הם לא מרוויחים כסף ממכשירים שהם מכרו לפני שנה או שנתיים, אז הם צריכים להמשיך לשחרר מכשירים חדשים כדי להתקיים. זו אחת הסיבות ש-HTC ובלקברי נמצאים בצרות - זה לא משנה כמה מנהלים שומרים על אחיזת מוות ב-Blackberry Curve הישן שלהם, מכיוון שהם לא מקבלים שם מכירת מכשיר חדש.

אם ה-OEM לא יקבל BSP, הם לא יורידו את גישת ה-XDA של פריצת מבנה. למה? נו, הם צריכים לתמוך בקושחה זו עבור הלקוחות שלהם. אם הם ישחררו קושחה שחצי עובדת, המשתמשים ישנאו אותם, וישתוללו וישתוללו, וישמרו על קווי התמיכה שלהם לצלצל במשך ימים.

יצרני OEM צריכים להתמודד גם עם ספקים, לפחות בשווקים שאינם אירופיים. הספקים לא רוצים שללקוחות יהיו בעיות עם עדכוני תוכנה. למעשה, ספקים מעדיפים לרוב לא לשחרר עדכוני תוכנה.

כדי להבין זאת, דמיינו את דודתכם הגדולה אליס. היא זו שמתקשרת אליך בשעות לא נוחות ביום כדי לבקש עזרה ב"דבר המחשב הזה". לאחר מכן אתה מתאר כיצד ללחוץ על "תפריט התחל", וצריך לזהות אותו כ"דגל הגדול בפינה השמאלית התחתונה", ונתקל בבלבול. כ-45 דקות (ותסכול רב) לאחר מכן, מתברר שדודה אליס גררה את תפריט ההתחלה שלה לקצה המסך הימני, ופשוט הייתה צריכה לגרור אותו אחורה. כן, עם לחצן העכבר השמאלי!

עכשיו תאר לעצמך שיש לך אלף דודה אליס'. כולם מתקשרים לתמיכת הלקוחות שלך, לא מצליחים למצוא את Candy Crush בטלפון שלהם, מודאגים שהאקר מחק את זה מהטלפון שלהם. אה, והסמלים נראים קצת אחרת עכשיו - אולי ההאקר עדיין בטלפון שלהם?

כן, זה אמור להיות קצת הומור קליל, אבל עד שלא תחווה את הסיבות לכך שאנשים יתקשרו לספק שלהם לתמיכה, לא תאמין לבעיות שיש להם. עדכון תוכנה שמשנה את אופן הפעולה של הטלפון, או היכן הדברים נמצאים, יגרום לתקורת תמיכה משמעותית. לכל הפחות, זה דורש הכשרה מחדש של צוות תמיכה (מכיוון שרובם אינם קורא ה-XDA הנלהב שלך, למרבה הצער).

ברגע שה-OEM יקבל את ה-BSP, הם יעבירו את ה-ROM שלהם ויחילו את כל השינויים שלהם על ה-ROM. הם יערמו את כלי הנפיחות שלהם ויוסיפו עור קריקטורה נורא שייראה יותר בבית באנימה של מתבגר. ואז הם יבדקו את זה.

הרבה.

יש כל מיני דרישות שהטלפון שלך צריך לעמוד בהן. הרשתות הסלולריות נועדו לסמוך על ציוד המשתמש (מה שאנו מכנים טלפון) שיתנהג נכון. זה אומר שדרושות הרבה בדיקות כדי לקבל את אישור המכשיר. עדכוני תוכנה מסתכנים בשינוי התנהגויות, כך שהדברים צריכים לבדוק שוב. זו הסיבה שבדרך כלל תראה מידע על עדכוני תוכנה קרובים של Sony משירותי בדיקה חיצוניים, המאשרים שהקושחה תואמת לדרישות הבדיקה.

עַכשָׁיו... מה קורה לאחר עדכון או שניים (או במקרים מסוימים, אף אחד)? יצרנית ה-SoC לא תיתן ל-OEM BSP מעודכן. אחרי הכל, יצרנית ה-SoC לא תפיק מזה הרבה. ה-OEM לא מרוויח יותר כסף מהטלפון שלך מאז שהוא נמכר. ובשלב זה, הטלפון שלך לא מקבל עוד עדכוני גרסאות גדולים יותר.

צמצום מספר ה-BSPs שה-OEM רוצה שיימסרו היא דרך מצוינת לחסוך כסף - אם אתה רק צריך את הנוכחי, ולא מתכוון לספק שום גרסה גדולה עולה, זה יחסוך כסף ברכישת ה-SoC והרישוי הראשוניים, אבל על חשבון כמה חנונים כועסים ב-XDA בהמשך הקו, שתוהים למה הם לא קיבלו עדכון.

העדכונים מורכבים. יש הרבה אנשים שונים שמעורבים בשרשרת. כל זה לא מתרץ יצרני ציוד מקורי מהמצב העדכני והפתטי הנוכחי של עדכונים באנדרואיד. עם זאת, יש כאן כמה אתגרים אמיתיים.

יצרני OEM רבים אשמים בהבטחת יתר, והן תת-מסירה בלתי נמנעת שאנו מקשרים כעת. המציאות העצובה היא שעבור רוב יצרני ה-OEM, עדכוני תוכנה הם רק מטרד שהם יכולים להסתדר בלעדיו.

מגזר הסלולר תקוע בעיקר בהלך הרוח של הטלפונים הניידים. כלומר, מקום שבו מכשיר לעולם לא מקבל עדכונים. בדוק אותו פעם אחת, שלח אותו, ולעולם אל תסתכל לאחור. עם בעיות האבטחה של סמארטפונים מודרניים, והמורכבות העצומה של הפעלת מערכת הפעלה כללית מלאה, עם מאות ספריות חיצוניות, זו כבר לא אופציה. או לפחות זה לא צריך לִהיוֹת. גוגל עשתה כמה צעדים לקראת תיקון זה, על ידי לפחות פרסום עלוני אבטחה ותיקונים עבור מהדורות קיימות של אנדרואיד (זכור שעד לאחרונה, הדרך היחידה לקבל עדכוני אבטחה הייתה באמצעות גרסת מערכת הפעלה אנדרואיד גדולה חדשה!)

אבוי, עם זאת, זה לא באמת מספיק. למרות שגוגל ממשיכה לשחרר עדכונים, אבטחת המכשיר שלך עדיין תלויה ביצרן ה-SoC - מכיוון שיצרני ה-SoC כל כך מאובנים מישהו שמגלה איך הוא מדליק כמה נוריות לד או משמיע צליל דרך רמקול, הוא שולח כמויות עצומות של כתמים בינאריים על מכשירים. הכתמים האלה מכילים קוד די לא מאובטח (פשוט תסתכל על עלוני האבטחה של Google אם אתה חושב שזו הגזמה!), וצריך לעדכן. מה שאומר שנדרשים BSP מעודכנים.

מחשבים שולחניים (ובהרחבה, מחשבים ניידים) שונים לחלוטין בארכיטקטורה ממכשירים ניידים. הטלפון הנייד או הטאבלט שלך הם למעשה גוש סיליקון קנייני, שעוצב במהירות על ידי כמה אנשים שמתכוונים לטוב, אבל אין להם מספיק זמן לעשות משהו טוב. השוק נע כל כך מהר שהם בקושי מצליחים לעמוד בקצב שבו השיווק דורש השקת מוצרים חדשים.

המשמעות היא שננקטו קיצורי דרך - לא תמצאו את הטלפון שלכם נתמך על ידי ליבת לינוקס הראשית, ותגלו שלכל טלפון יש דרך אחרת לאתחל. עם זאת, במחשב הנייד או השולחני שלך, הספקים הסתפקו בכמה דרכים סטנדרטיות לאתחול - בעבר זה היה MBR (רשומה מאסטר אתחול) עם BIOS, ועכשיו זה UEFI. סטנדרטיזציה זו מאפשרת להפעיל את אותה תוכנה בכל מכשיר.

אמנם היו כמה צעדים לקראת זה לאחרונה, במיוחד עם תוכנית ההסברה של סוני ושלהם קרנל מאוחד, זה לא מעשי להפעיל גרעין מרכזי ברוב הטלפונים, בגלל המספר העצום של פריצות חדשות ספציפיות לספק שהוכנסו לכל מכשיר.

חיברת את שקע האוזניות בצורה לא נכונה? פשוט פרוץ את זה לדרייברים! אין זמן לתקן את זה בתכנון הייצור.

צוות הייצור הרכיב את מודול המצלמה הפוך בקבוצת ייצור 1? לזרוק פריצה כדי לבדוק את קוד הגרסה הפנימי, ולהפוך את הסרטון אם זה גרסה 1!

פריצות כמו אלה פותרות את הבעיה המיידית, אבל רק מגרדות את פני השטח של השינויים המוזרים והספציפיים למוצר המתרחשים. לעזאזל, יש אפילו לפעמים שבבים שונים לגמרי בגרסאות שונות של אותו טלפון, בגלל החלטות מסחריות. אלה מובילים לפריצות לנהגים ולהחלטות מוזרות שהיו הגיוניות רק באותו זמן, כדי לגרום לטלפון לעבוד כדי שיוכל להישלח בשבוע הבא.

אמנם נמשכת עבודה לתמיכה מרכזית בשבבי ARM של 64 סיביות לאתחול באמצעות UEFI, אך עד כה אין תנועה ברורה לעבר דרך סטנדרטית יותר לאתחל התקני ARM. וזה עצוב, כי זה אומר שהטלפונים ימשיכו להיזרק הרבה לפני תום חיי עבודה, כי זה פשוט יקר מדי לשמור על החוב הטכני והנטל עליהם תוֹכנָה.

מצד שני, אם יצרן OEM ירוויח כסף רק על מכירת מכשיר, האם הם לא צריכים להבטיח שאנשים ימשיכו לקנות טלפונים חדשים? האם שוק המחשבים האישיים יעבור לדגם הזה אם לא היו כבר 30 שנה של מומנטום ותוכנה מדור קודם באמצעות פלטפורמת המחשב והתקן הפתוחים?

זו שאלה קשה ללא ידע פנימי מקוואלקום, שלצערי אין לנו כרגע. עם זאת, אנו יכולים לשאוב קצת מידע מדרישות ה-API של מנהל ההתקן של אנדרואיד 7.0 ו-CTS. דרישות ה-CTS מפרטות מה גוגל מצפה ממכשיר המריץ קושחה נתונה. "הפטיש הגדול" המשמש לאכיפת דרישות אלה הוא הרישיון של גוגל להשתמש בחבילת שירותי Google Play הקניינית שלהם - אם אינך מציית, לא תוכל לשלוח את Google Apps במכשיר. בעוד, עבור חלק, זה עשוי להיראות כיתרון, ברור שזה לא מה שהמשתמשים רוצים ומצפים ממכשיר.

אנדרואיד 7.0 לא הוסיפה הרבה בדרך של שינויים ב-HAL או במנהלי התקנים (כמתואר לעיל), כך שסביר להניח שכל אי התאמה לא תגיע משם ספציפית. עם זאת, מה שסביר יותר להוות בעיה היא הכנסת א דרישה חדשה עבור ה-API הגרפי של Vulkan, או GLES 3.1, להיות זמין על מנת לעבור CTS.

נכון לעכשיו, להרבה Systems-on-Chip (SoCs) לא הייתה תמיכת Vulkan במעבד הגרפי שלהם, כולל MSM8974. קרוב לוודאי שכאן גם תתעורר בעיית התאימות לאנדרואיד 7.0. עם זאת, שוב, ללא ידע פנימי מקוואלקום, והתוכניות העתידיות שלהם, קשה לנו לתת הצהרה סופית מבלי לסייג אותה. עם זאת, כרגע אנו מאמינים שסביר להניח שזהו המקרה ה"פשוט" של קוואלקום הפסקת התמיכה עבור ערכת השבבים (בעיניהם) המזדקנת MSM8974, ואינה מספקת BSP (חבילת תמיכה בלוח) עבור 7.0 בפלטפורמה זו. אם זה היה המקרה, זה היה אומר שיצרני OEM יהיו כמעט בטוחים שלא ישלחו 7.0 במכשיר - הם יצטרכו למצוא איכשהו תמיכת Vulkan או GLEs 3.1 עבור ה-GPU שלהם, ומקור ה-GPU שלהם קוד הוא אחד החלקים המוגנים בצורה מגוחכת של ערימות הנייד (ללא סיבה אמיתית, היינו מוסיפים - ראה AMD, מקורות פתוחים של מנהל התקן AMDGPU משלהם על שולחן העבודה עבור לינוקס). עם זאת, למרבה הצער, גרפיקה של Vulkan ו-GLES (GLES) היא קצת יותר מורכבת מאשר LED פשוט, אז זה לא משהו שאנחנו הולכים לראות shims כדי להציג תאימות עבורו.

מכיוון ש-7.0 לא יצא זמן רב, ישנה אפשרות אמיתית שערכות שבבים אחרות (מלבד המספר הקטן בתוך AOSP עצמו) יישארו מאחור ב-6.0, עקב בעיות חומרה ומנהלי התקנים (כלומר ללא BSP מעודכן) או חוסר תמיכה של ספקי SoC לגבי Vulkan או GLES 3.1 ממשק API. נכון לעכשיו, גם ה-Snapdragon 800 או 801 לא תומכים באחד מאלה.

ההימור הטוב ביותר הוא לצפות בחלל הזה - מפתחים ב-XDA כבר מתקדמים היטב עם יציאות לא רשמיות ל-7.0 עבור רבים מהמכשירים שאינם מקבלים תמיכה רשמית ב-7.0 מגוגל. עם זאת, אלה ללא תמיכה ב-Vulkan או GLES 3.1 - אולי מפתחי משחקים באנדרואיד יתחילו לעשות זאת לחוות תסכול דרך פיצול אם מספיק משתמשים יתחילו להפעיל ROMs מותאמים אישית ללא Vulkan או GLES 3.1 תמיכה?

אפל נוטה לתמוך בקו האייפון שלהם בגרסת iOS העדכנית ביותר במשך כ-5 שנים - ה-iPhone 4s הושק באוקטובר 2011, ונשמר עדכני עד iOS 9. עם זאת, הוא לא יקבל את עדכון iOS 10 הקרוב, מה שיעניק לטלפון תוחלת חיים אפקטיבית של 5 שנים, בהנחה ש- iOS 10 יושק בסביבות אוקטובר. ראוי לציין שאפל לא תמיד תומכת ב-API גרפי ביציאות אחוריות - האייפון 4s והאייפון 5 לא כולל את ה-API לגרפיקה מתכת של אפל, שהוא תרחיש דומה במקצת לזה שנראה עם אנדרואיד ב וולקן. ההבדל היחיד הוא שאפל המשיכה לתמוך במכשירים הישנים יותר ללא ה-API הגרפי החדש.

מה אתה חושב? האם תבזבז ROM מותאם אישית בטלפון שלך כדי להאריך את תוחלת החיים שלו? האם אמרתם בתגובות למטה.