SD801 Cihazlarının Neden Nougat'tan Hariç Tutulduğuna Dair Derinlemesine Teslim

Android 7.0 için ikisinden biri veya Vulkan veya OpenGL ES 3.1 gereksinimini yansıtacak şekilde güncellendi

Son zamanlarda sürüm güncellemeleri, satıcı ile yonga seti üreticisi arasındaki etkileşimler ve bunun ilerideki cihazlar için ne anlama geldiği hakkında çok sayıda makale yazıldı. Bu hafta neden yükseldi?

Saygıdeğer Nexus 5'in Android 7.0 (Nougat) güncellemesini almayacağı bu hafta ortaya çıktı ve Qualcomm da almayacağını duyurdu. 7.0'da MSM8974 (daha yaygın olarak Snapdragon 801 olarak bilinir) için destek sağlıyor. Bu makale XDA Recognized ile işbirliği içinde yazılmıştır. Geliştirici yaban arısı.

Konu çeşitli haber sitelerinde oldukça ilgi gördü, ancak Birçoğu sahne arkasında gerçekte olup bitenlerin ince nüanslarını kaçırıyorS. Bu makale, OEM'lerle resmi donanım yazılımı güncellemelerinde çalışma deneyimimizi kullanarak, yazılım güncellemelerinin nasıl çalıştığı hakkında biraz daha fazla bilgi verecektir. Size perde arkasında neler olup bittiğini (ve nedenlerini) ve telefonunuza neden en son yazılımı alamayabileceğinizi açıklayacağız.

Bir Android ürün yazılımı güncellemesinin ömründeki ilk adım, yukarı akış güncellemesidir. Google'ın dahili olarak üzerinde çalıştığı şey budur. "Açık iş akışlarının" aksine Android, her yıl yeni bir sürüm çıktığında kaynak kodunun çöpe atıldığı kapalı bir iş akışı kullanılarak geliştirilir. Başlangıçta Google bunun, son teknoloji sürümleri çalıştıran kişilerden kaynaklanan parçalanmayı önlemek olduğunu söyledi. ilk günlerde işler hızla gelişirken, bu politikayı devam ettirmiş görünüyorlar yer.

Zamanın bir noktasında, genellikle bir güncellemenin kamuya duyurulmasından önce (her ne kadar yakın zamanda halka açık betaların kullanıma sunulmasıyla birlikte bu zaman çizelgeleri değişiyorsa da), OEM'ler yaklaşan bir güncellemeden haberdar edilecek. Daha sonra son güncelleme için kaynak kodunu ikinci bir zamanda alacaklardır (geçmişte Bazen lansmandan biraz önce, ancak erken çıkmanın mümkün olmadığı durumların da farkındayız. serbest bırakmak).

Yukarı akışlı AOSP depoları yalnızca sınırlı sayıda cihaz için cihaz desteği içerir. Bunlar genellikle Nexus cihazlarınızdır. Ancak kısa süre içinde netleşecek nedenlerden dolayı, Google'ın bu cihazlar üzerinde tam donanım kontrolüne sahip olmadığını belirtmek önemlidir; cihazlar bir OEM tarafından üretilmektedir ve bu OEM, bir yonga seti üreticisinden bir Çip Üzerinde Sistem (SoC) satın alacaktır.

Kaynak kodu yayınlandıktan sonra, OEM'in donanım yazılımı ekibi (mecazi olarak) arkasına yaslanacak ve ayaklarını uzatacaktır. Ana Android kaynak ağacı, nakliye cihazlarında kullanılan sayısız yonga seti için donanım desteğine sahip değildir. Örneğin Qualcomm yonga setiniz büyük olasılıkla AOSP'de desteklenmiyor. Exynos'unuz kesinlikle değil. Mediatek mi HiSilicon mu? Unut gitsin!

BSP, Android'in çalışmasını sağlamak için gereken sürücüleri ve donanım soyutlama katmanlarını (HAL'ler) içerir

Şimdi ihtiyaç duyulan şey bir Yönetim Kurulu Destek Paketi (BSP). Bu, bir yonga seti üreticisi tarafından bir OEM'e teslim edilen, özel bileşenlerden oluşan süper gizli bir pakettir. BSP, OEM'lerin Android'i ve cihazları için gerekli sürücüleri oluşturmasına olanak tanıyan gerekli kaynak kodunu içerir.

Qualcomm gibi OEM'lerin OEM ortaklarına tamamen güvenmediğini burada belirtmekte fayda var; BSP "bilinmesi gereken" esasına göre sunulmaktadır. OEM'ler genellikle cihazın bazı süper gizli parçalarının (temel bantta çalışan yazılım gibi) kaynak koduna erişemez. Bu kısmın kapalı olması, yakındaki fotoğrafta da görüldüğü gibi, kesinlikle potansiyel sorunlara da sahiptir. bol Ve tekrarlanan ASN.1 güvenlik açıklarını ayrıştırma.

BSP, Android'in cihazınızda çalışmasını sağlamak için gereken sürücüleri ve donanım soyutlama katmanlarını (HAL'ler) içerir. AOSP, işletim sisteminin sürücülerinizin uygulamasını beklediği şeyleri tanımlayan bir dizi HAL içerir. Gülünç derecede aşırı basitleştirilmiş (ve gösteri amacıyla uydurulmuş) bir örnek kullanmak için, telefonunuzdaki el fenerini hayal edelim.

Örnek Bir HAL - El Feneriniz

Cihazınızın arkasında bir el feneri olduğunu hayal edelim (Nexus 7 2013'ünüz varsa, herkesten biraz daha fazla hayal kurmanız gerekecek - kusura bakmayın!). Bu bir sürücü tarafından kontrol edilir. Çılgınca basit örneğimiz için, v1 HAL'ın, tek bir parametreyi, yani ışığın durumunu alan "setLED" adında bir işleve sahip olmanız gerektiğini söylediğini varsayalım. Bu bir boole değeridir - doğru veya yanlış. C'de bu şuna benzer:

void setLED(bool ledState) {

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

}

Bu işlev BSP kaynak kodunda tanımlanmıştır. BSP daha sonra ROM'un oluşturulması sırasında OEM tarafından derlenir ve bu, cihazınızın satıcı bölümü veya alanındaki özel ".so" kitaplıklarından biri haline gelir. Bu, bir OEM'in cihazlarının işleyişinin belirli kısımlarını gizli tutmasına olanak tanır. Şimdilik, LED'i nasıl açıp kapattıklarını herkesin görmesini engellemek istediklerini varsayalım.

Şimdi Google'ın HAL'lerinin güncellenmiş bir sürümünü Android'in gelecekteki bir sürümünde yayınladığını hayal edin. Artık LED'inizi açmak veya kapatmak yerine parlaklığını güncellemenize izin vermenin iyi olacağına karar veriyorlar. Belki bu uyarlanabilir flaş içindir, belki de sadece HAL güncellemesini zorlamak ve yonga seti üreticilerini iş başında tutmak içindir? Okuyucu olarak sizlerin bu konuda kendi fikrinize ulaşmanıza izin vereceğiz. Bazı HAL güncellemelerinin açık faydaları vardır (örneğin, ham çekimi açığa çıkaran yeni Kamera HAL ve benzeri), diğerlerinin ise amacı daha az açıktır.

Parlaklık için bu yeni (kurgusal) HAL ile, diyelim ki Google, setLED adlı bir işlevi tekrar ortaya çıkarmanız gerektiğini söylüyor, ancak bu sefer parlaklık için bir tamsayı aktarıldı. Şimdi, 0 onu kapatacak ve 255 onu tam olarak açacaktır.

Eğer OEM iseniz, o LED'i açmak için süper gizli kodunuzu alabilir ve onu bu yeni fonksiyona yerleştirebilirsiniz. Hatta LED'in parlaklığını sayıya göre ayarlamak için darbe genişliği modülasyonunu bile kullanabilirsiniz. Şimdi işlevi şu şekilde görünecek şekilde değiştirirsiniz:

void setLED(uint8_t ledBrightness) {

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

}

Ne olmuş? Artık Android'in bu yeni sürümü mevcut "bloblar" ile uyumlu değil. OEM'inizin bu yeni blob'ları kullanması gerekiyor çünkü Android işletim sistemi yeni işlev tanımını görmeyi bekliyor ve LED'i ayarlamanın bir yolunu ararken eskisini "bulamayacak".

Bu noktada Custom ROM'ların (kaynaktan oluşturulmuş) burada nasıl yönetildiğine kısa bir ara verelim. Aranızdaki zeki kişiler şu anda ekranınıza bunu bağırıyor olacak - sonuçta biz XDA'yız, XDA'yız, HTC HD2Dünyanın en uzun ömürlü telefonu... (kayıt olsun diye söylüyorum, oradaki çılgın dahiler koşuyor Bugünlerde HD2'de Android 6.0! Orijinal olarak 2009'da Windows Mobile 6.5 ile gönderilen bir telefon için fena değil)

Burada çeşitli yaklaşımlar benimseniyor - bazen geliştiriciler ROM'un içinde geziniyor ve işletim sistemine eski işlev tanımlarını kullanmasını söylüyor. Bu biraz dağınık ve sürdürülmesi gereken birçok değişiklik var. Diğer yaklaşım ise OEM ikili dosyasını "kaydırmaktır".

"Shim" yaklaşımı, beklenen fonksiyon tanımını içeren küçük bir kütüphaneyi kendiniz yazmak ve oluşturmaktır - örneğimiz için parlaklık için tamsayıyı destekleriz. Daha sonra bu, eski HAL'in gereksinimlerini karşılayacak şekilde dönüştürülür. Örneğimiz için, 128'in üzerinde talep edilen herhangi bir parlaklığın LED'i açacağını ve bunun altındaki herhangi bir parlaklığın onu kapatacağını söyleyebiliriz. Veya sıfır dışında herhangi bir şeyin onu açacağını söyleyebilirsiniz. Geliştiriciye kalmış. Ayarı derliyorlar ve Android'in yerel olanın yerine onu kullanmasını sağlıyorlar. Ayarlama daha sonra OEM blobunu çağırır.

Hızlı bir 'adb push' ve yeniden başlatma, ayarlamayı başlatacak ve yalnızca eski HAL'e sahip olsanız bile kurgusal LED'inizi kontrol etmenize izin verecektir.

Sorun şu ki, bu açıkça kusurlu bir süreç. Şimdi tuhaflıklar yaşayacaksınız - bu cihazın ya tamamen açık ya da tamamen kapalı olan oldukça berbat bir flaşı olacak. Bu ideal değil; işletim sistemi çok yumuşak bir ışık ürettiğini düşünüyor, ancak gerçek LED'e yapay bir güneş yarışmasında yarıştığı ve sizi kör etmeye çalıştığı söyleniyor. Ama hey, hayat mükemmel değil ve artık eski telefonunuzda çalışan bir LED var!

(Evet, XDA kullanıcıları ve geliştiricileri yeteneklerini taşıma konusundaki çılgın ve çılgın becerilerini yönettiklerinde tuhaflıkların ve hataların ortaya çıkmasının nedenlerinden biri de budur. Demek istediğim, kahretsin Galaxy S II görünüşte kullanışlı bir şey taşıyor Android 6.0 ROM'u şimdi. Geçen yıl piyasaya sürülen pek çok telefon hala 6.0'a sahip değil!)

OEM'in bakış açısına geri dönelim. Ne yazık ki çoğu OEM halihazırda şu anda bulunduğumuz noktadan en az 1 telefon önde çalışıyor. Odaklandıkları nokta satmak üzere oldukları bir sonraki telefondur; yalnızca sattıkları cihazlardan para kazandıkları için onları suçlayamazsınız. Bir veya iki yıl önce sattıkları cihazlardan hiç para kazanmıyorlar, dolayısıyla var olabilmek için yeni cihazlar çıkarmaya devam etmek zorundalar. HTC ve Blackberry'nin başının dertte olmasının nedenlerinden biri de bu; kaç yöneticinin eski Blackberry Curve'lerine sıkı sıkıya bağlı olduğu önemli değil çünkü orada yeni bir cihaz satışı alamıyorlar.

OEM bir BSP alamazsa, XDA'nın bir yapıyı bir araya getirmeye yönelik yaklaşımından vazgeçmeyeceklerdir. Neden? Kuyu, müşterileri için bu ürün yazılımını desteklemeleri gerekiyor. Yarı çalışan bir ürün yazılımı yayınlarlarsa, kullanıcılar onlardan nefret edecek, bağırıp övünecek ve destek hatlarının günlerce çalmasını sağlayacak.

OEM'lerin taşıyıcılarla da mücadele etmesi gerekiyoren azından Avrupa dışı pazarlarda. Operatörler müşterilerin yazılım güncellemeleriyle ilgili sorun yaşamasını istemez. Aslında operatörler genellikle yazılım güncellemelerini yayınlamamayı tercih eder.

Bunu anlamak için Büyük Halanız Alice'i hayal edin. Günün uygunsuz saatlerinde sizi arayıp "şu bilgisayar meselesi" konusunda yardım isteyen kişi odur. Daha sonra "Başlat menüsüne" nasıl tıklayacağınızı ve bunu "sol alt köşedeki büyük bayrak" olarak tanımlamanız gerektiğini ve kafa karışıklığıyla karşılaştığınızı açıklıyorsunuz. Yaklaşık 45 dakika (ve büyük bir hayal kırıklığı) sonra, Alice Teyze'nin başlat menüsünü ekranın sağ kenarına sürüklediği ve geri sürüklemesi gerektiği ortaya çıktı. Evet, farenin sol tuşuyla!

Şimdi bin tane Alice Teyzeniz olduğunu hayal edin'. Hepsi müşteri desteğinizi arıyor, telefonlarında Candy Crush'u bulamıyorlar ve bir bilgisayar korsanının onu telefonlarından silmiş olabileceğinden endişeleniyorlar. Simgeler artık biraz farklı görünüyor; belki bilgisayar korsanı hâlâ telefonundadır?

Evet, bu biraz hafif bir mizah amaçlıdır, ancak insanların destek için operatörlerini aramalarının nedenlerini deneyimleyene kadar, yaşadıkları sorunlara inanmayacaksınız. Telefonun çalışma şeklini veya eşyaların yerini değiştiren bir yazılım güncellemesi, önemli bir destek yüküne neden olacaktır. En azından destek personelinin yeniden eğitilmesini gerektirir (çünkü çoğu sizin hevesli XDA okuyucunuz değildir ne yazık ki).

OEM BSP'yi aldıktan sonra ROM'larını aktaracak ve tüm değişikliklerini ROM'a uygulayacaktır. Bloatware'lerini bir araya toplayacaklar ve bir gencin Anime'sinde daha çok evde görünecek korkunç, karikatürize bir görünüm ekleyecekler. Daha sonra test edecekler.

Çok fazla.

Telefonunuzun uyması gereken her türlü gereksinim vardır. Mobil ağlar, kullanıcı ekipmanının (telefon dediğimiz şey) doğru şekilde davranacağına güvenecek şekilde tasarlanmıştır. Bu, cihazın onaylanması için çok fazla test yapılması gerektiği anlamına gelir. Yazılım güncellemeleri davranışları değiştirme riski taşır, bu nedenle bazı şeylerin yeniden test edilmesi gerekir. Bu nedenle, harici test hizmetlerinden gelecek ve ürün yazılımının test gereklilikleriyle uyumlu olduğunu doğrulayan Sony yazılım güncellemeleri hakkında bilgileri sıklıkla göreceksiniz.

Şimdi... bir veya iki güncellemeden sonra (veya bazı durumlarda hiç güncelleme yapılmadan) ne olur? SoC üreticisi OEM'e güncellenmiş bir BSP vermeyecek. Sonuçta SoC üreticisi bundan pek bir şey elde edemeyecek. OEM, satıldığından beri telefonunuzdan daha fazla para kazanmıyor. Ve bu noktada telefonunuz artık herhangi bir büyük sürüm güncellemesi almıyor.

OEM'in teslim edilmesini istediği BSP sayısını azaltmak, paradan tasarruf etmenin harika bir yoludur - yalnızca mevcut olana ihtiyacınız varsa ve herhangi bir büyük sürüm sunmayı düşünmüyorsanız artarsa, bu, ilk SoC satın alma ve lisanslama masraflarından tasarruf sağlayacaktır, ancak bu, XDA'da neden bir onay alamadıklarını merak eden birkaç kızgın ineğin pahasına olacaktır. güncelleme.

Güncellemeler karmaşıktır. Zincire pek çok farklı insan dahil oluyor. Bunların hiçbiri OEM'leri Android'deki mevcut yetersiz ve acıklı güncelleme durumundan muaf tutmaz. Yine de burada bazı gerçek zorluklar var.

Pek çok OEM aşırı vaatlerde bulunmaktan sorumludur ve şu anda ilişkilendirdiğimiz kaçınılmaz yetersiz dağıtım. Üzücü gerçek şu ki, çoğu OEM için yazılım güncellemeleri, onsuz da yapabilecekleri bir sıkıntıdır.

Mobil sektör çoğunlukla özellikli telefonların zihniyetine takılıp kalıyor. Yani, bir cihazın hiçbir zaman güncelleme almadığı yer. Bir kez test edin, gönderin ve bir daha arkanıza bakmayın. Modern akıllı telefonların güvenlik sorunları ve yüzlerce harici kütüphaneyle tam genel amaçlı bir işletim sistemini çalıştırmanın karmaşıklığı göz önüne alındığında, bu artık bir seçenek değil. Ya da en azından yapmamalı olmak. Google, en azından mevcut sürümler için güvenlik bültenleri ve yamalar yayınlayarak bu durumu düzeltmeye yönelik bazı adımlar attı. Android (yakın zamana kadar güvenlik güncellemelerini almanın tek yolunun yeni bir Android işletim sistemi sürümü kullanmak olduğunu unutmayın!)

Ancak ne yazık ki bu aslında yeterli değil. Google güncellemeler yayınlamaya devam etse de cihazınızın güvenliği hâlâ SoC üreticisine bağlıdır; çünkü SoC üreticileri bundan çok korkuyor. Birisi birkaç LED'i nasıl açtığını veya bir hoparlör aracılığıyla nasıl ses çıkardığını keşfederse, bilgisayarlarına büyük miktarlarda ikili damlalar gönderir. cihazlar. Bu lekeler oldukça korkunç derecede güvensiz kodlar içeriyor (bunun abartı olduğunu düşünüyorsanız geçmiş Google güvenlik bültenlerine bir göz atın!) ve güncellenmesi gerekiyor. Bu, güncellenmiş BSP'lerin gerekli olduğu anlamına gelir.

Masaüstü bilgisayarlar (ve buna bağlı olarak dizüstü bilgisayarlar) mimari olarak mobil cihazlardan tamamen farklıdır. Cep telefonunuz veya tabletiniz aslında iyi niyetli olan ancak iyi bir şey yapmak için yeterli zamanı olmayan bazı kişiler tarafından aceleyle tasarlanmış, büyük ölçüde tescilli bir silikon yığınıdır. Pazar o kadar hızlı hareket ediyor ki, pazarlamanın yeni ürünlerin piyasaya sürülmesini talep ettiği tempoya zar zor ayak uydurabiliyorlar.

Bu, kısayolların kullanıldığı anlamına gelir; telefonunuzun ana Linux çekirdeği tarafından desteklendiğini göremezsiniz ve her telefonun farklı bir önyükleme yöntemi olduğunu göreceksiniz. Bununla birlikte, dizüstü bilgisayarınızda veya masaüstü bilgisayarınızda, satıcılar bazı standart önyükleme yöntemleri üzerinde karar kıldılar; daha önce BIOS'lu MBR (ana önyükleme kaydı) idi ve şimdi UEFI. Bu standardizasyon, her cihazda aynı yazılımın çalıştırılmasını mümkün kılar.

Son zamanlarda buna yönelik bazı adımlar atılmış olsa da, özellikle Sony'nin sosyal yardım programı ve onların birleşik çekirdekHer cihaza sunulan satıcıya özel çok sayıda yeni hack nedeniyle çoğu telefonda ana hat çekirdeği çalıştırmak pratik değildir.

Kulaklık jakını yanlış şekilde mi bağladınız? Sadece sürücüleri hackleyin! Üretim tasarımında bunu düzeltmeye zaman yok.

Üretim ekibi, üretim partisi 1'de kamera modülünü baş aşağı mı monte etti? Dahili sürüm kodunu kontrol etmek için bir hack atın ve sürüm 1 ise videoyu ters çevirin!

Bunun gibi hack'ler acil sorunu çözer, ancak sadece devam eden tuhaf ve ürüne özgü değişikliklerin yüzeyini kazır. Hatta ticari kararlardan dolayı bazen aynı telefonun farklı versiyonlarında tamamen farklı çipler olabiliyor. Bunlar, sürücülerin hacklenmesine ve telefonun bir sonraki hafta gönderilebilmesi için çalışmasını sağlamak için o zamanlar mantıklı olan tuhaf kararlara yol açıyor.

UEFI kullanarak önyükleme yapmak üzere 64 bit ARM yongalarının ana hat desteğine yönelik çalışmalar devam ederken, şu ana kadar bu konuda çalışmalar yapıldı. ARM aygıtlarını önyüklemenin daha standartlaştırılmış bir yoluna doğru net bir hareket yok. Bu çok üzücü çünkü bu, telefonların kullanım süreleri dolmadan çöpe atılmaya devam edeceği anlamına geliyor. çalışma hayatları, çünkü teknik borçları ve yükleri üstlenmek çok pahalı yazılım.

Öte yandan, eğer bir OEM yalnızca cihazın satışından para kazanacaksa, insanların yeni telefon almaya devam etmesini sağlamaları gerekmez mi? Açık PC platformunu ve standardını kullanan 30 yıllık ivme ve eski yazılım olmasaydı, PC pazarı bu modele geçer miydi?

Bu, ne yazık ki şu anda sahip olmadığımız Qualcomm'un içeriden bilgisi olmadan zor bir soru. Ancak 7.0 Android sürücüsü API'sinden ve CTS gereksinimlerinden bazı bilgiler çıkarabiliriz. CTS gereksinimleri, Google'ın belirli bir donanım yazılımını çalıştıran bir cihazdan ne beklediğini belirtir. Bu gereklilikleri uygulamak için kullanılan "büyük çekiç", Google'ın kendi özel Google Play Hizmetleri paketini kullanma lisansıdır - uymazsanız Google Apps'ı cihaza gönderemezsiniz. Bazıları için ise bu avantaj olarak görülebilirAçıkçası bu, kullanıcıların bir cihazdan istediği ve beklediği şey değil.

Android 7.0, HAL'de veya sürücülerde (yukarıda açıklandığı gibi) çok fazla değişiklik yapmamıştır, dolayısıyla herhangi bir uyumsuzluğun özellikle buradan gelmesi pek mümkün değildir. Bununla birlikte, bir sorun yaratma olasılığı daha yüksek olan şey, bir Vulkan grafik API'si veya GLES 3.1 için yeni gereksinim, CTS'yi geçmek için mevcut olması.

Şu anda, MSM8974 de dahil olmak üzere birçok Çip Üzerinde Sistem (SoC), grafik işlemcilerinde Vulkan desteğine sahip değil. Bu aynı zamanda büyük olasılıkla Android 7.0 ile uyumluluk sorununun ortaya çıkacağı yerdir. Yine de Qualcomm'un içeriden edindiği bilgiler ve gelecek planları olmadan, bunu nitelendirmeden kesin bir açıklama yapmamız bizim için zor. Ancak şu anda bunun Qualcomm'un desteğini kesmesi gibi "basit" bir durum olduğuna inanıyoruz. (onların gözünde) yaşlanan MSM8974 yonga seti ve bu platformda 7.0 için bir BSP (anakart destek paketi) sağlamıyor. Durum böyle olsaydı, OEM'lerin cihaza 7.0 sürümünü göndermeyecekleri neredeyse kesin olurdu; GPU'ları ve GPU kaynakları için bir şekilde Vulkan veya GLE 3.1 desteği bulmaları gerekecekti. kod, mobil yığınların gülünç derecede sıkı korunan parçalarından biridir (gerçek bir neden olmadan şunu ekleriz - AMD'ye bakın, masaüstünde kendi AMDGPU sürücüsünü açık kaynak olarak kullanırız) Linux). Ancak ne yazık ki, Vulkan ve hızlandırılmış (GLES) grafikler genel olarak basit bir LED'den biraz daha karmaşıktır, dolayısıyla bu, uyumluluk sağlamak için şimler göreceğimiz bir şey değil.

7.0 uzun süredir piyasada olmadığından, diğer yonga setlerinin (AOSP'nin kendi içindeki küçük sayı dışında) kalma ihtimali gerçekten var Donanım ve sürücü sorunları (örn. güncellenmiş BSP olmaması) veya Vulkan veya GLES 3.1 ile ilgili SoC satıcı desteği eksikliği nedeniyle 6.0'ın gerisinde API'dir. Şu anda ne Snapdragon 800 ne de 801 bunlardan birini desteklemiyor.

En iyi bahis bu alanı izlemektir - XDA'daki geliştiriciler, Google'dan resmi 7.0 desteği alamayan cihazların çoğu için resmi olmayan bağlantı noktaları olan 7.0'a geçiş konusunda zaten iyi bir ilerleme kaydediyor. Ancak bunlar Vulkan veya GLES 3.1 desteğine sahip değil; belki de Android'deki oyun geliştiricileri bunu yapmaya başlayacaklardır. Yeterli sayıda kullanıcı Vulkan veya GLES 3.1 olmadan özel ROM'lar çalıştırmaya başlarsa parçalanma nedeniyle hayal kırıklığı yaşanır Destek?

Apple, iPhone serisini yaklaşık 5 yıldır en son iOS sürümünde destekleme eğilimindedir; iPhone 4s, Ekim 2011'de piyasaya sürüldü ve iOS 9'a kadar güncel tutuldu. Ancak, iOS 10'un Ekim ayı civarında piyasaya sürüleceği varsayılırsa, telefona 5 yıllık etkili bir kullanım ömrü verecek olan iOS 10 güncellemesini almayacak. Apple'ın grafik API desteğini her zaman desteklemediğini belirtmekte fayda var - iPhone 4s ve iPhone 5 desteklemez Android'de görülene biraz benzer bir senaryo olan Apple'ın Metal grafik API'sini içerir. Vulkan. Tek fark, Apple'ın eski cihazları yeni grafik API'si olmadan desteklemeye devam etmesidir.

Ne düşünüyorsun? Telefonunuzun ömrünü uzatmak için özel bir ROM'u flaşlayacak mısınız? Aşağıdaki yorumlarda söylediniz mi?