Mélyreható magyarázat arról, hogy miért zárják ki az SD801-es eszközöket a Nougatból

Frissítve, hogy tükrözze az Android 7.0 vagy-or Vulkan vagy OpenGL ES 3.1 követelményeit

A közelmúltban sok cikk jelent meg a verziófrissítésekről, a gyártó és a lapkakészlet-gyártó közötti kölcsönhatásokról, és arról, hogy ez mit jelent a jövőben az eszközök számára. Miért emelkedett ez a héten?

Nos, a héten kiderült, hogy a tiszteletreméltó Nexus 5 nem kapja meg az Android 7.0 (Nougat) frissítését, és a Qualcomm bejelentette, hogy nem. az MSM8974 (közismertebb nevén a Snapdragon 801) támogatása a 7.0-s verzióban. Ez a cikk az XDA Recognized együttműködésével készült Fejlesztő poszméh.

A téma eléggé felkeltette az érdeklődést különböző híroldalakról, de sokan lemaradnak a színfalak mögötti történések finom árnyalatairóls. Ez a cikk egy kicsit részletesebben ismerteti a szoftverfrissítések működését, felhasználva az OEM-ekkel a hivatalos firmware-frissítéseken szerzett tapasztalatainkat. Végigvezetjük, mi történik a színfalak mögött (és miért), és miért nem a legfrissebb szoftvert kapja meg telefonjára.

Az Android firmware-frissítésének első lépése az upstream frissítés. Ezen dolgozik a Google belsőleg. A „nyílt munkafolyamatokkal” ellentétben az Androidot zárt munkafolyamattal fejlesztik, a forráskódot évente, amikor új kiadás jelenik meg, a falra dobják. Eredetileg a Google azt mondta, hogy ez azért volt, hogy megakadályozzák a töredezettséget az olyan emberek miatt, akik a legmodernebb verziókat futtatják miközben a dolgok gyorsan fejlődtek a kezdeti időkben, de úgy tűnik, megtartották ezt a politikát hely.

Valamikor, általában a frissítés nyilvános bejelentése előtt (bár a nyilvános béták közelmúltbeli bevezetésével ezek az időskálák eltolódnak), Az OEM-eket értesíteni fogják egy közelgő frissítésről. Ezután egy második időpontban megkapják a forráskódot a végső frissítéshez (a múltban ez volt néha kicsit az indulás előtt, bár tisztában vagyunk olyan esetekkel is, amikor nincs korai kiadás).

Az upstream AOSP-tárolók csak korlátozott számú eszközhöz tartalmaznak eszköztámogatást. Ezek általában az Ön Nexus eszközei. Hamarosan világossá váló okokból azonban fontos megjegyezni, hogy a Google nem rendelkezik teljes hardveres vezérléssel ezen eszközök felett; az eszközöket egy OEM gyártja, és ez az OEM vásárol egy System-on-Chip-et (SoC) egy lapkakészlet-gyártótól.

A forráskód kiadása után az OEM firmware-csapata (képletesen) hátradől, és felteszi a lábát. A fő Android forrásfa nem rendelkezik hardver támogatással a szállítási eszközökben használt számtalan chipkészlethez. A Qualcomm lapkakészletét valószínűleg nem támogatja például az AOSP. A te Exynosod egészen biztosan nem. Mediatek vagy HiSilicon? Felejtsd el!

A BSP tartalmazza az Android futtatásához szükséges illesztőprogramokat és hardveres absztrakciós rétegeket (HAL).

Amire most szükség van, az a Board Support Package (BSP). Ez a szabadalmaztatott komponensek rendkívül bizalmas csomagja, amelyet egy lapkakészlet-gyártó szállít az OEM-nek. A BSP tartalmazza a szükséges forráskódot, amely lehetővé teszi az OEM-ek számára az Android létrehozását és a szükséges illesztőprogramokat az eszközükhöz.

Itt érdemes megjegyezni, hogy az olyan OEM-ek, mint a Qualcomm, nem feltétlenül bíznak teljesen OEM-partnereikben – a BSP-t „tudnunk kell” alapon teszik elérhetővé. Az OEM-ek általában nem férnek hozzá az eszköz egyes szupertitkos részeinek forráskódjához (például az alapsávon futó szoftverekhez). Ennek a résznek a lezárása minden bizonnyal potenciális problémákkal is jár, amint azt a közeli is mutatja bőséges és ismétlődő ASN.1 sérülékenységek elemzése.

A BSP tartalmazza azokat az illesztőprogramokat és hardveres absztrakciós rétegeket (HAL), amelyek ahhoz szükségesek, hogy az Android futhasson az eszközén. Az AOSP egy sor HAL-t tartalmaz, amelyek meghatározzák, hogy az operációs rendszer mit vár el az illesztőprogramoktól. Egy nevetségesen leegyszerűsített (és szemléltetés céljából kitalált) példa használatához képzeljük el a zseblámpát a telefonon.

Egy példa HAL - Az Ön zseblámpája

Képzeljük el, hogy az eszköz hátulján zseblámpa van (ha Nexus 7 2013-as telefonja van, akkor mindenkinél többet kell képzelnie – elnézést!). Ezt egy sofőr vezérli. A mi őrülten egyszerű példánkban tegyük fel, hogy a v1 HAL szerint egy "setLED" nevű függvénynek kell lennie, amely egyetlen paramétert, a fény állapotát veszi fel. Ez egy logikai érték – igaz vagy hamis. C-ben ez valahogy így nézne ki:

void setLED(bool ledState) {

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

}

Ezt a függvényt a BSP forráskódja határozza meg. A BSP-t ezután az OEM fordítja le a ROM felépítése során, és ez lesz az egyik szabadalmaztatott ".so" könyvtár az eszköz szállítói partícióján vagy területén. Ez lehetővé teszi az OEM-nek, hogy titokban tartsa eszköze működésének bizonyos részeit. Egyelőre tegyük fel, hogy meg akarják akadályozni, hogy mindenki lássa, hogyan kapcsolja be és ki a LED-et.

Most képzelje el, hogy a Google kiadja HAL-jaik frissített verzióját az Android jövőbeli verziójában. Most úgy döntöttek, hogy jó lenne, ha lehetővé tenné a LED fényerejének frissítését, ahelyett, hogy egyszerűen be- vagy kikapcsolná. Lehet, hogy ez az adaptív flash-hez való, vagy talán csak a HAL-frissítés erőltetése, és a lapkakészlet-gyártók üzleti életben tartása? Hagyjuk, hogy Ön, az olvasó, kifejtse saját véleményét erről. Egyes HAL-frissítéseknek egyértelmű előnyei vannak (például az új Camera HAL, amely a nyers felvételeket teszi lehetővé és hasonlók), míg mások céljai valamivel kevésbé egyértelműek.

Tegyük fel, hogy ezzel az új (kitalált) HAL-al a fényerőre vonatkozóan a Google azt mondja, hogy ismét fel kell tennie a setLED nevű függvényt, de ezúttal egy egész számmal kell megadni a fényerőt. Most a 0 kikapcsolná, a 255 pedig teljesen bekapcsolná.

Ha Ön az OEM, akkor a szupertitkos kódjával bekapcsolhatja a LED-et, és beillesztheti ebbe az új funkcióba. Akár impulzusszélesség-modulációval is beállíthatja a LED fényerejét a szám alapján. Megváltoztatja a függvényt, hogy most így jelenjen meg:

void setLED(uint8_t ledBrightness) {

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

}

És akkor mi van? Nos, most az Android új verziója nem kompatibilis a meglévő "blobokkal". Az OEM-nek ezeket az új blobokat kell használnia, mert az Android operációs rendszer az új funkciódefiníciót várja, és nem "találja" a régit, amikor a LED beállításának módját keresi.

Ezen a ponton tartsunk egy rövid szünetet, hogy megnézzük, hogyan működnek itt a (forrásból épített) egyéni ROM-ok. Ez az, amit az okoskodó köztetek most kiabál majd a képernyőjére – elvégre mi vagyunk az XDA, a HTC HD2, a világ leghosszabb élettartamú telefonja... (Csak a jegyzet kedvéért, az őrült zsenik ott futnak Manapság Android 6.0 a HD2-n! Nem rossz egy olyan telefonhoz képest, amelyet eredetileg Windows Mobile 6.5-tel szállítottak 2009-ben)

Különféle megközelítések léteznek itt – néha a fejlesztők feltörik a ROM-ot, és azt mondják az operációs rendszernek, hogy használja a régi függvénydefiníciókat. Ez egy kicsit zavaros, és sok változtatást igényel a karbantartás érdekében. A másik megközelítés az OEM bináris "kiegyenlítése".

A "shim" megközelítés az, hogy saját maga írjon és építsen fel egy apró új könyvtárat, amely tartalmazza a várt függvénydefiníciót – a mi példánkban a fényerő szempontjából az egész számot támogatnánk. Ezután az alátéten belül ez lefordítva megfelel a régi HAL követelményeinek. Például a mi példánkban azt mondanánk, hogy a 128 feletti fényerősség bekapcsolja a LED-et, és minden, ami alatta van, kikapcsolja. Vagy mondhatsz bármit, ami nem nulla bekapcsolja. Ez a fejlesztőn múlik. Lefordítják az alátétet, és ráveszik az Androidra, hogy használja a natív helyett. Az alátét ezután az OEM blob-ot hívja.

Egy gyors "adb push" és újraindítás hatására az alátét működésbe lép, és lehetővé teszi a kitalált LED vezérlését, annak ellenére, hogy csak a régi HAL-ja van.

A probléma az, hogy ez nyilvánvalóan tökéletlen folyamat. Most furcsaságokat fog kapni – ennek az eszköznek elég roncsos vakuja lesz, ami vagy teljesen be van kapcsolva, vagy teljesen kikapcsolva. Ez nem ideális – az operációs rendszer azt hiszi, hogy nagyon gyengéd fényt bocsát ki, de a tényleges LED-nek azt mondják, hogy egy mesterséges napfény versenyben versenyez, és megpróbálja elvakítani. De hé, az élet nem tökéletes, és most már van egy működő LED a régi telefonodon!

(Igen, ez az egyik oka annak, hogy vannak furcsaságok és hibák, amikor az XDA-felhasználók és fejlesztők kezelik őrült és őrült portolási képességeiket. Úgy értem a fenébe, a Galaxy S II cipel egy használhatónak tűnőt Android 6.0 ROM most. Sok tavaly kiadott telefonban még mindig nincs 6.0!)

Ugorjunk vissza az OEM nézőpontjához. Sajnos a legtöbb OEM már legalább 1 telefonnal előrébb dolgozik, mint jelenleg. Középpontjában a következő telefon áll, amelyet hamarosan eladnak – nem igazán lehet őket hibáztatni, mivel csak az általuk eladott készülékeken keresnek pénzt. Nem keresnek pénzt az egy-két éve eladott készülékekből, ezért folyamatosan új készülékeket kell kiadniuk, hogy létezzenek. Ez az egyik oka annak, hogy a HTC és a Blackberry bajban van – nem mindegy, hogy hány vezető tartja meg a halálát a régi Blackberry Curve-n, mivel ott nem kapnak új készüléket.

Ha az OEM nem kap BSP-t, akkor nem hagyja abba az XDA megközelítését, hogy összetörjön egy buildet. Miért? Jól, támogatniuk kell ezt a firmware-t ügyfeleik számára. Ha kiadnak egy félig működő firmware-t, a felhasználók utálni fogják őket, háborognak és tombolnak, és napokig csöngetnek a támogatási vonalaik.

Az eredeti gyártóknak a fuvarozókkal is meg kell küzdeniük, legalábbis a nem európai piacokon. A szolgáltatók nem akarják, hogy az ügyfeleknek problémái legyenek a szoftverfrissítésekkel. Valójában a szolgáltatók gyakran inkább nem adnak ki szoftverfrissítéseket.

Ennek megértéséhez képzelje el Alice nagynénijét. Ő az, aki felhív a nap kellemetlen szakaszaiban, hogy segítséget kérjen "azzal a számítógépes dologgal kapcsolatban". Ezután leírja, hogyan kell rákattintani a "Start menüre", és azt a "bal alsó sarokban lévő nagy zászlóként" kell azonosítania, és zavarba jön. Körülbelül 45 perccel később (és sok frusztrációval) kiderül, hogy Alice néni a képernyő jobb szélére húzta a Start menüjét, és egyszerűen vissza kellett húznia. Igen, a bal egérgombbal!

Most képzeld el, hogy van ezer Alice néni. Mindannyian felhívják az ügyfélszolgálatot, nem találják a Candy Crusht a telefonjukon, és attól tartanak, hogy egy hacker törölte a telefonjukról. Ja, és az ikonok most egy kicsit másképp néznek ki – lehet, hogy a hacker még mindig a telefonjukban van?

Igen, ezt egy kicsit könnyed humornak szántuk, de amíg nem tapasztalod meg, hogy az emberek miért hívják fel a szolgáltatójukat támogatásért, addig nem hiszed el a problémáikat. Egy szoftverfrissítés, amely megváltoztatja a telefon működését vagy a dolgok helyét, jelentős támogatási többletköltséget okoz. Legalább a támogató személyzet újraképzését igényli (mert a legtöbbjük sajnos nem az Ön lelkes XDA-olvasója).

Miután az OEM megszerzi a BSP-t, áthelyezi a ROM-ját, és az összes módosítást alkalmazza a ROM-on. Elhalmozzák a bloatware-t, és egy borzasztó rajzfilmszerű bőrt adnak hozzá, amely otthonosabban fog kinézni egy tinédzser animében. Aztán tesztelik.

Nagyon.

A telefonnak mindenféle követelménynek meg kell felelnie. A mobilhálózatokat úgy alakították ki, hogy megbízzanak a felhasználói berendezésekben (amit telefonnak nevezünk) a megfelelő működésben. Ez azt jelenti, hogy sok tesztelésre van szükség az eszköz jóváhagyásához. A szoftverfrissítések azt kockáztatják, hogy a viselkedés megváltozik, ezért a dolgokat újra tesztelni kell. Ez az oka annak, hogy gyakran látni fogja a külső tesztszolgáltatásoktól érkező Sony szoftverfrissítésekről szóló információkat, amelyek megerősítik, hogy a firmware megfelel a tesztkövetelményeknek.

Most... mi történik egy-két frissítés (vagy bizonyos esetekben semmi) után? A SoC gyártó nem ad frissített BSP-t az OEM-nek. Hiszen a SoC gyártónak ebből nem sok lesz. Az OEM nem keres több pénzt a telefonján, amióta eladták. És ezen a ponton a telefon nem kap több jelentős verziófrissítést.

Az OEM által szállítani kívánt BSP-k számának csökkentése nagyszerű módja a pénzmegtakarításnak – ha csak a jelenlegire van szüksége, és nem kíván nagyobb verziót szállítani. növekszik, ez pénzt takarít meg a kezdeti SoC vásárláson és licencelésen, de néhány dühös dühös rovására az XDA-n, akik azon töprengenek, miért nem kaptak frissítés.

A frissítések összetettek. Sok különböző ember vesz részt a láncban. Ezek egyike sem menti fel az OEM-eket az Android frissítéseinek jelenlegi hiányos és szánalmas állapota alól. Ennek ellenére van néhány igazi kihívás.

Sok OEM okolható a túlzott ígéretért, és a elkerülhetetlen alulteljesítés, amelyet most társítunk. A szomorú valóság az, hogy a legtöbb OEM számára a szoftverfrissítések csak bosszúságot jelentenek, amit nélkülöznének.

A mobilszektor leginkább a funkciós telefonok gondolkodásmódjában ragadt meg. Vagyis ahol egy eszköz soha nem kap frissítést. Próbáld ki egyszer, küldd el, és soha ne nézz vissza. A modern okostelefonok biztonsági problémái és a teljes, általános célú operációs rendszer, több száz külső könyvtárral rendelkező operációs rendszer üzemeltetésének óriási bonyolultsága miatt ez már nem lehetséges. Vagy legalábbis azt nem kellene lenni. A Google tett néhány lépést ennek kijavítása érdekében: legalább biztonsági közleményeket és javításokat tett közzé a meglévő kiadásokhoz Android (ne feledje, hogy egészen a közelmúltig a biztonsági frissítések beszerzésének egyetlen módja az Android operációs rendszer új, nagy verziója volt!)

Sajnos azonban ez nem igazán elég. Annak ellenére, hogy a Google folyamatosan ad ki frissítéseket, az eszköz biztonsága továbbra is az SoC-gyártótól függ – mivel az SoC-gyártók annyira megkövültek ha valaki felfedezi, hogyan kapcsol fel néhány LED-et vagy ad ki hangot a hangszórón keresztül, hatalmas mennyiségű bináris foltot szállít a készülékére. eszközöket. Ezek a blobok borzasztóan bizonytalan kódot tartalmaznak (ha úgy gondolja, hogy ez túlzás, vessen egy pillantást a Google korábbi biztonsági közleményeire!), és frissíteni kell. Ez azt jelenti, hogy frissített BSP-kre van szükség.

Az asztali számítógépek (és tágabb értelemben a laptopok) felépítésében teljesen eltérnek a mobileszközöktől. Mobiltelefonja vagy táblagépe tulajdonképpen egy erősen szabadalmaztatott szilíciumtömb, amelyet rohanásban terveztek olyan emberek, akik jót akarnak, de közel sincs elég idejük valami jó elkészítésére. A piac olyan gyorsan mozog, hogy alig tudnak lépést tartani azzal a tempóval, amellyel a marketing új termékek bevezetését követeli meg.

Ez azt jelenti, hogy a rendszer parancsikonokat használ – telefonját nem fogja támogatni a fő Linux kernel, és minden telefonnak más módja van a rendszerindításnak. Az Ön laptopján vagy asztali számítógépén azonban a gyártók néhány szabványos rendszerindítási mód mellett döntöttek – korábban MBR (master boot record) volt BIOS-szal, most pedig UEFI. Ez a szabványosítás lehetővé teszi ugyanazt a szoftvert minden eszközön.

Noha a közelmúltban történtek lépések e felé, különösen a Sony tájékoztató programja és az ő programja révén egységes kernel, nem praktikus fővonali kernelt futtatni a legtöbb telefonon, az egyes eszközökön bevezetett rengeteg új gyártó-specifikus hack miatt.

Rossz irányba kötötte be a fejhallgató-csatlakozót? Csak csapkodja be az illesztőprogramokban! Nincs idő javítani a gyártási tervben.

A gyártó csapat fejjel lefelé szerelte fel a kameramodult az 1. gyártási tételben? Hack be, hogy ellenőrizze a belső verziókódot, és fordítsa meg a videót, ha az 1-es verzió!

Az ilyen hackek megoldják az azonnali problémát, de csak a felszínét kaparják a folyamatban lévő furcsa és termékspecifikus változásoknak. A fenébe is, kereskedelmi döntések miatt néha teljesen különböző chipek vannak ugyanannak a telefonnak a különböző verzióiban. Ezek az illesztőprogramok feltöréséhez és furcsa döntésekhez vezetnek, amelyeknek akkoriban csak akkor volt értelme, hogy működjön a telefon, hogy a következő héten szállíthassák.

Miközben folyamatban van a fővonali támogatás a 64 bites ARM chipekhez az UEFI használatával történő rendszerindításhoz, eddig nincs egyértelmű elmozdulás az ARM-eszközök szabványosabb indítási módja felé. És ez szomorú, mert ez azt jelenti, hogy a telefonokat továbbra is jóval a vége előtt kidobják munkával töltött életet, mert egyszerűen túl drága fenntartani a technikai adósságot és terhet szoftver.

Másrészt azonban, ha egy OEM csak egy eszköz eladásával keres pénzt, nem kell gondoskodnia arról, hogy az emberek továbbra is új telefonokat vásároljanak? Áttérne-e a PC-piac erre a modellre, ha nem léteznének 30 évnyi lendülettel és régi szoftverekkel, amelyek a nyílt PC-platformot és szabványt használják?

Ez egy nehéz kérdés a Qualcomm belső ismeretei nélkül, amivel sajnos jelenleg nem rendelkezünk. Néhány információt azonban meríthetünk a 7.0 Android illesztőprogram API és CTS követelményeiből. A CTS-követelmények meghatározzák, hogy a Google mit vár el egy adott firmware-t futtató eszköztől. A követelmények érvényesítésére használt „nagy kalapács” a Google engedélye a saját Google Play szolgáltatáscsomag használatára – ha nem tartja be, nem szállíthatja a Google Apps csomagot az eszközre. Míg egyesek számára ez előnynek tekinthető, nyilvánvalóan nem ezt akarják és nem várják el a felhasználók egy eszköztől.

Az Android 7.0 nem sokat változtatott a HAL-on vagy az illesztőprogramokon (a fent leírtak szerint), így nem valószínű, hogy inkompatibilitás konkrétan onnan származik. Ami azonban nagyobb valószínűséggel vet fel problémát, az az a új követelmény a Vulkan grafikus API-hoz vagy a GLES 3.1-hez, elérhető a CTS átadásához.

Jelenleg sok Systems-on-Chip (SoC) grafikus processzora nem rendelkezik Vulkan támogatással, beleértve az MSM8974-et is. Valószínűleg itt vetődik fel az Android 7.0-val való kompatibilitás kérdése is. A Qualcomm belső ismeretei és jövőbeli terveik nélkül azonban nehéz határozott kijelentést adni anélkül, hogy minősítenénk. Jelenleg azonban valószínűnek tartjuk, hogy ez az „egyszerű” eset, amikor a Qualcomm megszünteti a az (az ő szemükben) az öregedő MSM8974 lapkakészletet, és nem biztosít BSP-t (kártya támogatási csomag) a 7.0-hoz ezen a platformon. Ha ez a helyzet, az azt jelentené, hogy az OEM-ek szinte biztosak lennének abban, hogy nem szállítják a 7.0-t az eszközön – valahogyan meg kellene találniuk a Vulkan vagy a GLEs 3.1 támogatását a GPU-hoz és a GPU-forráshoz. kód a mobilveremek egyik nevetségesen szigorúan őrzött része (valódi ok nélkül hozzátennénk – lásd az AMD-t, hogy nyílt forráskódú saját AMDGPU-illesztőprogramjukat az asztalon Linux). Sajnos azonban a Vulkan és a gyorsított (GLES) grafika általában egy kicsit bonyolultabb, mint egy egyszerű LED, így nem fogunk olyan alátéteket látni, amelyekkel kompatibilitást bevezetnénk.

Mivel a 7.0 nem sokáig jelent meg, fennáll annak a lehetősége, hogy más lapkakészletek (az AOSP-n belüli kis számon kívül) elhagyják elmarad a 6.0-tól, vagy hardver- és illesztőprogram-problémák (azaz nincs frissített BSP), vagy a Vulkan vagy a GLES 3.1 SoC-szállítói támogatásának hiánya miatt. API. Jelenleg sem a Snapdragon 800, sem a 801 nem támogatja ezeket.

A legjobb, ha figyeli ezt a teret - Az XDA fejlesztői már most is jól haladnak a nem hivatalos portok 7.0-s verziójával, sok olyan eszköz esetében, amely nem kap hivatalos 7.0-s támogatást a Google-tól. Ezek azonban nem támogatják a Vulkan vagy a GLES 3.1-et – talán az Androidon futó játékok fejlesztői elkezdik ezt frusztrációt tapasztal a töredezettség miatt, ha elegendő felhasználó kezd el egyéni ROM-okat futtatni Vulkan vagy GLES 3.1 nélkül támogatás?

Az Apple körülbelül 5 éve támogatja iPhone termékcsaládját a legújabb iOS-verzión – az iPhone 4s-t 2011 októberében mutatták be, és az iOS 9-ig folyamatosan frissítik. A közelgő iOS 10 frissítést azonban nem kapja meg, ami 5 év tényleges élettartamot biztosítana a telefonnak, feltételezve, hogy az iOS 10 október környékén indul. Érdemes megjegyezni, hogy az Apple nem mindig támogatja a back-port grafikus API-t – az iPhone 4s és iPhone 5 nem tartalmazzák az Apple Metal grafikus API-ját, ami némileg hasonló az Android esetén látotthoz Vulkan. Az egyetlen különbség az, hogy az Apple továbbra is támogatta a régebbi eszközöket az új grafikus API nélkül.

Mit gondolsz? Villogtat egy egyedi ROM-ot a telefonján, hogy meghosszabbítsa az élettartamát? Mondja el az alábbi megjegyzésekben.