Diepgaande capitulatie van waarom SD801-apparaten zijn uitgesloten van Nougat

Bijgewerkt om de óf-of Vulkan- of OpenGL ES 3.1-vereiste voor Android 7.0 weer te geven

De laatste tijd zijn er veel artikelen geschreven over versie-updates, de interacties tussen leverancier en chipsetmaker, en wat dit betekent voor toekomstige apparaten. Waarom is dit deze week gestegen?

Welnu, dit bleek deze week, aangezien de eerbiedwaardige Nexus 5 de update naar Android 7.0 (Nougat) niet zal ontvangen, en Qualcomm heeft aangekondigd dat dit niet het geval zal zijn ondersteuning bieden voor de MSM8974 (beter bekend als de Snapdragon 801) op 7.0. Dit artikel is geschreven in samenwerking met XDA Recognized Ontwikkelaar hommel.

Het onderwerp heeft behoorlijk wat belangstelling getrokken van verschillende nieuwssites, maar velen missen de subtiele nuances van wat er werkelijk achter de schermen gebeurtS. In dit artikel wordt iets meer uitgelegd over hoe software-updates werken, waarbij we gebruik maken van onze ervaring in het werken met OEM's aan hun officiële firmware-updates. We laten u zien wat er achter de schermen gebeurt (en waarom) en waarom u mogelijk niet de nieuwste software op uw telefoon krijgt.

De eerste stap in het leven van een Android-firmware-update is de upstream-update. Dit is waar Google intern aan werkt. In tegenstelling tot "open workflows" wordt Android ontwikkeld met behulp van een gesloten workflow, waarbij de broncode elk jaar over de muur wordt gegooid als er een nieuwe release uitkomt. Oorspronkelijk zei Google dat dit was om fragmentatie te voorkomen van mensen die de nieuwste versies gebruiken terwijl de zaken zich in de beginperiode snel ontwikkelden, maar ze lijken dit beleid in stand te hebben gehouden plaats.

Op een bepaald moment, meestal vóór de publieke aankondiging van een update (hoewel deze tijdschema's met de recente introductie van publieke bèta's verschuiven), OEM's worden op de hoogte gebracht van een aankomende update. Ze ontvangen dan de broncode op een tweede tijdstip voor de definitieve update (in het verleden was dat zo). soms iets vóór de lancering, hoewel we ons ook bewust zijn van gevallen waarin er geen vroege lancering is uitgave).

De upstream AOSP-opslagplaatsen bevatten apparaatondersteuning voor slechts een beperkt aantal apparaten. Dit zijn doorgaans uw Nexus-apparaten. Om redenen die binnenkort duidelijk zullen worden, is het echter belangrijk op te merken dat Google geen volledige hardwarecontrole over deze apparaten heeft; de apparaten worden vervaardigd door een OEM, en die OEM koopt een System-on-Chip (SoC) van een chipsetmaker.

Zodra de broncode is vrijgegeven, zal het firmwareteam van de OEM (figuurlijk) achterover leunen en hun voeten omhoog leggen. De belangrijkste Android-bronstructuur biedt geen hardwareondersteuning voor de talloze chipsets die worden gebruikt in verzendapparaten. Jouw Qualcomm-chipset wordt hoogstwaarschijnlijk niet ondersteund binnen bijvoorbeeld AOSP. Jouw Exynos-exemplaar is dat zeker niet. Mediatek of HiSilicon? Laat maar!

De BSP bevat de stuurprogramma's en hardware-abstractielagen (HAL's) die nodig zijn om Android werkend te krijgen

Wat nu nodig is, is een Bestuursondersteuningspakket (BSP). Dit is een supervertrouwelijk pakket met eigen componenten, geleverd door een chipsetmaker aan een OEM. De BSP bevat de benodigde broncode om OEM's Android te laten bouwen en de benodigde stuurprogramma's voor hun toestel.

Het is vermeldenswaard dat OEM's zoals Qualcomm hun OEM-partners niet noodzakelijkerwijs volledig vertrouwen; de BSP wordt beschikbaar gesteld op een "need to know"-basis. OEM's krijgen doorgaans geen toegang tot de broncode van sommige supergeheime onderdelen van het apparaat (zoals de software die op de basisband draait). Het afsluiten van dit deel brengt zeker ook potentiële problemen met zich mee, zoals blijkt uit het onderstaande overvloedig En terugkerend ASN.1 kwetsbaarheden parseren.

De BSP bevat de stuurprogramma's en hardware-abstractielagen (HAL's) die nodig zijn om Android op uw apparaat te laten werken. AOSP bevat een reeks HAL's, die fungeren als definities van wat het besturingssysteem verwacht dat uw stuurprogramma's implementeren. Om een ​​belachelijk eenvoudig (en verzonnen, ter demonstratie) voorbeeld te gebruiken: laten we ons de zaklamp op uw telefoon voorstellen.

Een voorbeeld HAL - Uw zaklamp

Laten we ons voorstellen dat uw apparaat een zaklamp aan de achterkant heeft (als u een Nexus 7 2013 heeft, moet u wat meer fantasie hebben dan alle anderen - sorry!). Deze wordt bestuurd door een chauffeur. Laten we voor ons waanzinnig eenvoudige voorbeeld veronderstellen dat de v1 HAL zegt dat je één functie moet hebben genaamd "setLED", waarbij één enkele parameter wordt gebruikt: de toestand van het licht. Het is een booleaanse waarde: waar of onwaar. In C zou dit er ongeveer zo uitzien:

void setLED(bool ledState) {

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

}

Deze functie is gedefinieerd in de BSP-broncode. De BSP wordt vervolgens door de OEM gecompileerd tijdens het bouwen van de ROM, en dit wordt een van de eigen ".so"-bibliotheken op de leverancierspartitie of het gebied van uw apparaat. Hierdoor kan een OEM bepaalde delen van de werking van zijn apparaat geheim houden. Laten we voorlopig aannemen dat ze willen voorkomen dat iedereen ziet hoe ze die LED aan en uit zetten.

Stel je nu voor dat Google een bijgewerkte versie van hun HAL's uitbrengt in een toekomstige versie van Android. Ze besluiten nu dat het leuk zou zijn als je de helderheid van je LED zou kunnen bijwerken, in plaats van hem alleen maar aan of uit te zetten. Misschien is dit voor adaptieve flitser, of misschien is het gewoon om een ​​HAL-update af te dwingen en de chipsetmakers draaiende te houden? We laten u, de lezer, daarover uw eigen mening vormen. Sommige HAL-updates hebben duidelijke voordelen (zoals de nieuwe Camera HAL die onbewerkte opnamen en dergelijke blootlegt), terwijl andere een wat minder duidelijk doel hebben.

Laten we met deze nieuwe (fictieve) HAL voor helderheid aannemen dat Google zegt dat je opnieuw een functie met de naam setLED moet weergeven, maar deze keer met een geheel getal dat wordt doorgegeven voor helderheid. Nu zou 0 het uitschakelen en 255 zou het op vol vermogen zetten.

Als u de OEM bent, kunt u uw supergeheime code gebruiken om die LED in te schakelen en deze in deze nieuwe functie plaatsen. U kunt zelfs pulsbreedtemodulatie gebruiken om de helderheid van de LED aan te passen op basis van het getal. U wijzigt de functie zodat deze er nu als volgt uitziet:

void setLED(uint8_t ledBrightness) {

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

}

Dus? Welnu, nu is deze nieuwe versie van Android incompatibel met bestaande "blobs". Uw OEM moet deze nieuwe blobs gebruiken, omdat het Android-besturingssysteem verwacht de nieuwe functiedefinitie te zien en de oude niet zal "vinden" wanneer het op zoek gaat naar een manier om de LED in te stellen.

Laten we op dit punt een korte pauze nemen om te kijken hoe aangepaste ROM's (gebouwd vanaf de broncode) hier werken. Het is wat de scherpzinnigen onder jullie nu naar je scherm zullen schreeuwen - wij zijn tenslotte XDA, de thuisbasis van de HTCHD2, de langst meegaande telefoon ter wereld... (voor de goede orde: de gekke genieën daar zijn op de vlucht Android 6.0 op de HD2 tegenwoordig! Niet slecht voor een telefoon die oorspronkelijk in 2009 werd geleverd met Windows Mobile 6.5)

Er zijn hier verschillende benaderingen gevolgd - soms hacken ontwikkelaars binnen de ROM en vertellen ze het besturingssysteem om de oude functiedefinities te gebruiken. Dat is een beetje rommelig en er zijn veel wijzigingen die moeten worden gehandhaafd. De andere benadering is om het OEM-binaire bestand op te vullen.

De "shim"-aanpak is om zelf een kleine nieuwe bibliotheek te schrijven en te bouwen, die de verwachte functiedefinitie bevat - in ons voorbeeld ondersteunen we het gehele getal voor helderheid. Vervolgens wordt dit binnen de shim vertaald naar de eisen van de oude HAL. Dus voor ons voorbeeld zouden we misschien zeggen dat elke gevraagde helderheid boven de 128 de LED zal inschakelen, en alles daaronder de LED zou uitschakelen. Of je zou kunnen zeggen dat alles wat niet nul is, het zal inschakelen. Het is aan de ontwikkelaar. Ze compileren de shim en zorgen ervoor dat Android deze gebruikt in plaats van de oorspronkelijke. De shim roept vervolgens de OEM-blob aan.

Een snelle 'adb push' en reboot zou de shim aan de gang moeten krijgen, en je de controle geven over je fictieve LED, ook al heb je alleen de oude HAL.

Het probleem is dat dit duidelijk een onvolmaakt proces is. Je zult nu eigenaardigheden krijgen: dit apparaat heeft een nogal slordig flitser, die volledig aan of volledig uit staat. Dat is niet ideaal - het besturingssysteem denkt dat het heel zacht licht geeft, maar de eigenlijke LED krijgt te horen dat hij meedoet aan een kunstmatige zonnewedstrijd en je probeert te verblinden. Maar goed, het leven is niet perfect, en je hebt nu een werkende LED op je oude telefoon!

(Ja, dit is een van de redenen waarom er eigenaardigheden en bugs zijn wanneer XDA-gebruikers en -ontwikkelaars hun gekke en krankzinnige prestaties op het gebied van porten beheersen. Ik bedoel, de Galaxy S II is een schijnbaar bruikbaar exemplaar Android 6.0-ROM nu. Veel telefoons die vorig jaar zijn uitgebracht, hebben nog steeds geen 6.0!)

Laten we teruggaan naar het perspectief van de OEM. Helaas werken de meeste OEM's al minstens één telefoon eerder dan waar we nu zijn. Hun focus ligt op de volgende telefoon die ze gaan verkopen. Je kunt het ze niet echt kwalijk nemen, aangezien ze alleen geld verdienen met apparaten die ze verkopen. Ze verdienen geen geld met apparaten die ze een jaar of twee geleden hebben verkocht, dus moeten ze nieuwe apparaten blijven uitbrengen om te kunnen bestaan. Dit is één van de redenen waarom HTC en Blackberry in de problemen zitten. Het maakt niet uit hoeveel leidinggevenden hun oude Blackberry Curve in de greep houden, omdat ze daar geen nieuwe apparaten kunnen verkopen.

Als de OEM geen BSP krijgt, zullen ze niet de XDA-aanpak volgen door een build samen te hacken. Waarom? Goed, ze moeten deze firmware voor hun klanten ondersteunen. Als ze een firmware uitbrengen die maar half werkt, zullen gebruikers ze haten, tieren en razen, en hun ondersteuningslijnen dagenlang laten rinkelen.

Ook OEM’s hebben te maken met vervoerders, althans op niet-Europese markten. Vervoerders willen niet dat klanten problemen krijgen met software-updates. Vervoerders brengen vaak liever geen software-updates uit.

Om dit te begrijpen, stel je je oudtante Alice voor. Zij is degene die je op ongelegen momenten van de dag opbelt om hulp te vragen met "dat computergedoe". U beschrijft vervolgens hoe u op het "Startmenu" klikt, en moet dit identificeren als de "grote vlag in de linkerbenedenhoek", en stuit op verwarring. Ongeveer 45 minuten (en veel frustratie) later blijkt dat tante Alice haar startmenu naar de rechterrand van het scherm heeft gesleept, en dat ze het eenvoudigweg terug moest slepen. Ja, met de linkermuisknop!

Stel je nu eens voor dat je duizend tante Alice hebt.' Ze bellen allemaal uw klantenondersteuning, maar kunnen Candy Crush niet op hun telefoon vinden, omdat ze bang zijn dat een hacker het van hun telefoon heeft verwijderd. Oh, en de pictogrammen zien er nu een beetje anders uit: misschien zit de hacker nog steeds in zijn telefoon?

Ja, dit is bedoeld als een beetje luchtige humor, maar totdat je de redenen ervaart waarom mensen hun provider voor ondersteuning bellen, zul je de problemen die ze hebben niet geloven. Een software-update die de manier verandert waarop de telefoon werkt of waar dingen zich bevinden, zal een aanzienlijke ondersteuningsoverhead veroorzaken. Het vereist op zijn minst een herscholing van ondersteunend personeel (omdat de meeste van hen helaas niet jouw enthousiaste XDA-lezer zijn).

Zodra de OEM de BSP heeft, zullen ze hun ROM overbrengen en al hun wijzigingen op de ROM toepassen. Ze stapelen hun bloatware erin en voegen een gruwelijke cartoonachtige skin toe die er meer thuis zou uitzien in de Anime van een tiener. Dan gaan ze het testen.

Veel.

Er zijn allerlei eisen waar je telefoon aan moet voldoen. De mobiele netwerken zijn ontworpen om erop te vertrouwen dat de gebruikersapparatuur (wat wij de telefoon noemen) zich correct gedraagt. Dit betekent dat er veel tests nodig zijn om het apparaat goedgekeurd te krijgen. Software-updates riskeren gedragsverandering, dus dingen moeten opnieuw worden getest. Dit is de reden waarom u vaak informatie ziet over aankomende Sony-software-updates van externe testservices, die bevestigen dat de firmware voldoet aan de testvereisten.

Nu... wat gebeurt er na een update of twee (of in sommige gevallen geen)? De SoC-maker wil de OEM geen bijgewerkte BSP geven. De SoC-maker zal hier immers weinig profijt van hebben. De OEM verdient geen geld meer aan uw telefoon sinds deze is verkocht. En op dit moment ontvangt uw telefoon geen grote versie-updates meer.

Het terugbrengen van het aantal BSP's dat de OEM geleverd wil hebben, is een geweldige manier om geld te besparen - als u alleen de huidige nodig heeft en niet van plan bent een grote versie te leveren toeneemt, zal dit geld besparen op de initiële SoC-aankoop en licentieverlening, maar ten koste van een paar boze nerds op XDA later, die zich afvragen waarom ze geen update.

Updates zijn complex. Bij de keten zijn veel verschillende mensen betrokken. Niets van dit alles excuseert OEM's voor de huidige gebrekkige en zielige status van updates op Android. Toch zijn er hier enkele echte uitdagingen.

Veel OEM's zijn verantwoordelijk voor het feit dat ze te veel beloven onvermijdelijke onderprestatie die we nu associëren. De trieste realiteit is dat software-updates voor de meeste OEM's slechts een ergernis zijn waar ze zonder kunnen.

De mobiele sector zit vooral vast in de mentaliteit van featurephones. Dat wil zeggen, waarbij een apparaat nooit updates krijgt. Test het één keer, verzend het en kijk nooit meer achterom. Met de beveiligingsproblemen van moderne smartphones en de enorme complexiteit van het draaien van een volledig besturingssysteem voor algemene doeleinden, met honderden externe bibliotheken, is dat niet langer een optie. Of tenminste zou niet moeten zijn. Google heeft enkele stappen gezet om dit op te lossen, door in ieder geval beveiligingsbulletins en patches voor bestaande releases te publiceren van Android (onthoud dat tot voor kort de enige manier om beveiligingsupdates te krijgen was via een nieuwe grote Android OS-versie!)

Helaas is dit echter niet echt genoeg. Hoewel Google updates blijft uitbrengen, is de beveiliging van je apparaat nog steeds afhankelijk van de SoC-maker - omdat SoC-makers zo bang zijn voor iemand ontdekt hoe ze een paar LED's aanzetten of geluid maken via een luidspreker, ze verzenden enorme hoeveelheden binaire blobs op hun apparaten. Deze blobs bevatten nogal gruwelijk onveilige code (kijk maar eens naar eerdere Google-beveiligingsbulletins als je denkt dat dit overdreven is!) en moeten worden bijgewerkt. Dat betekent dat bijgewerkte BSP’s nodig zijn.

Desktopcomputers (en bij uitbreiding laptops) zijn qua architectuur compleet anders dan mobiele apparaten. Je mobiele telefoon of tablet is in feite een zwaar propriëtair brok silicium, haastig ontworpen door sommige mensen die het goed bedoelen, maar bij lange na niet genoeg tijd hebben om iets goeds te maken. De markt beweegt zo snel dat ze nauwelijks in staat zijn het tempo bij te houden waarin de marketing om de lancering van nieuwe producten vraagt.

Dit betekent dat er snelkoppelingen worden gemaakt: je telefoon wordt niet ondersteund door de standaard Linux-kernel, en je zult merken dat elke telefoon een andere manier heeft om op te starten. Op je laptop of desktop hebben leveranciers echter een aantal standaardmanieren gekozen om op te starten - voorheen was het MBR (master boot record) met een BIOS, en nu is het UEFI. Deze standaardisatie maakt het mogelijk om op elk apparaat dezelfde software te draaien.

Hoewel er de laatste tijd enkele stappen in de richting hiervan zijn gezet, vooral met het outreach-programma van Sony en hun verenigde kern, is het niet praktisch om op de meeste telefoons een hoofdkernel te gebruiken, vanwege het grote aantal nieuwe, leverancierspecifieke hacks die op elk apparaat zijn geïntroduceerd.

Heb je de koptelefoonaansluiting verkeerd om aangesloten? Hack het gewoon in de stuurprogramma's! Er is geen tijd om dit in het productieontwerp op te lossen.

Heeft het productieteam de cameramodule ondersteboven gemonteerd in productiebatch 1? Voeg een hack toe om de interne versiecode te controleren en draai de video om als het versie 1 is!

Hacks als deze lossen het directe probleem op, maar schetsen slechts de oppervlakte van de vreemde en productspecifieke veranderingen die gaande zijn. Heck, er zijn soms zelfs totaal verschillende chips in verschillende revisies van dezelfde telefoon, als gevolg van commerciële beslissingen. Deze leidden tot hacks in stuurprogramma's en rare beslissingen die op dat moment alleen maar logisch waren, om de telefoon werkend te krijgen zodat deze de volgende week verzonden kon worden.

Hoewel er wordt gewerkt aan de basisondersteuning voor het opstarten van 64-bits ARM-chips met behulp van UEFI, is er tot nu toe geen duidelijke beweging naar een meer gestandaardiseerde manier om ARM-apparaten op te starten. En dat is triest, want het betekent dat telefoons ruim voor het einde van hun levensduur zullen worden weggegooid werkende levens, omdat het simpelweg te duur is om de technische schulden en lasten op hun schouders te houden software.

Maar aan de andere kant: als een OEM alleen geld verdient aan de verkoop van een apparaat, moeten ze er dan niet voor zorgen dat mensen nieuwe telefoons blijven kopen? Zou de pc-markt naar dit model overstappen als er niet al dertig jaar momentum en oudere software op de markt was die gebruik maakte van het open pc-platform en de standaard?

Dit is een moeilijke vraag zonder voorkennis van Qualcomm, die we momenteel helaas niet hebben. We kunnen echter enige informatie putten uit de 7.0 Android-stuurprogramma-API en CTS-vereisten. De CTS-vereisten specificeren wat Google verwacht van een apparaat met een bepaalde firmware. De "grote hamer" die wordt gebruikt om deze vereisten af ​​te dwingen, is de licentie van Google om hun eigen Google Play Services-bundel te gebruiken - Als u hieraan niet voldoet, kunt u geen Google Apps op het apparaat verzenden. Terwijl voor sommigen dit kan als een voordeel worden gezien, dit is uiteraard niet wat gebruikers willen en verwachten van een apparaat.

Android 7.0 heeft niet veel toegevoegd in de vorm van wijzigingen aan de HAL of stuurprogramma's (zoals hierboven beschreven), dus het is onwaarschijnlijk dat enige incompatibiliteit daar specifiek uit voortkomt. Wat echter waarschijnlijker een probleem zal opleveren, is de introductie van een nieuwe vereiste voor de Vulkan grafische API of GLES 3.1, beschikbaar zijn om te slagen voor CTS.

Op dit moment hebben veel Systems-on-Chip (SoC's) geen Vulkan-ondersteuning op hun grafische processor, inclusief de MSM8974. Dit is waarschijnlijk ook waar het probleem van de compatibiliteit met Android 7.0 zich zal voordoen. Maar nogmaals: zonder voorkennis van Qualcomm en hun toekomstplannen is het moeilijk voor ons om een ​​definitieve verklaring af te leggen zonder deze te kwalificeren. Op dit moment achten wij het echter waarschijnlijk dat dit het “eenvoudige” geval is waarin Qualcomm de steun voor de (in hun ogen) verouderende MSM8974-chipset, en geen BSP (board support package) voor 7.0 op dat platform. Als dat het geval zou zijn, zou dit betekenen dat OEM's er vrijwel zeker van zijn dat ze 7.0 niet op het apparaat zullen leveren - ze zouden op de een of andere manier Vulkan- of GLE's 3.1-ondersteuning voor hun GPU en GPU-bron moeten vinden code is een van de belachelijk streng bewaakte delen van de mobiele stacks (zonder echte reden, zouden we eraan toevoegen - zie AMD, open source hun eigen AMDGPU-stuurprogramma op de desktop voor Linux). Helaas zijn Vulkan en versnelde (GLES) graphics in het algemeen echter iets complexer dan een simpele LED, dus dit is niet iets waar we shims voor zullen zien om compatibiliteit voor te introduceren.

Omdat 7.0 nog niet zo lang op de markt is, is er een reële mogelijkheid dat andere chipsets (afgezien van het kleine aantal binnen AOSP zelf) overblijven achter op 6.0, vanwege hardware- en driverproblemen (dwz geen bijgewerkte BSP) of een gebrek aan ondersteuning van SoC-leveranciers met betrekking tot de Vulkan of GLES 3.1 API. Momenteel ondersteunen noch de Snapdragon 800 noch de 801 een van deze.

De beste gok is om deze ruimte in de gaten te houden - ontwikkelaars op XDA boeken al goede vooruitgang met onofficiële poorten naar 7.0 voor veel van de apparaten die geen officiële 7.0-ondersteuning krijgen van Google. Deze hebben echter geen Vulkan- of GLES 3.1-ondersteuning - misschien zullen ontwikkelaars van games op Android dat wel doen ervaar frustratie door fragmentatie als voldoende gebruikers aangepaste ROM's gaan gebruiken zonder Vulkan of GLES 3.1 steun?

Apple ondersteunt hun iPhone-lijn al ongeveer vijf jaar op de nieuwste iOS-versie - de iPhone 4s werd gelanceerd in oktober 2011 en is up-to-date gehouden tot iOS 9. De komende iOS 10-update zal de telefoon echter niet ontvangen, wat de telefoon een effectieve levensduur van 5 jaar zou geven, ervan uitgaande dat iOS 10 rond oktober wordt gelanceerd. Het is vermeldenswaard dat Apple niet altijd back-port grafische API-ondersteuning biedt - de iPhone 4s en iPhone 5 doen dat niet beschikken over de Metal graphics API van Apple, wat een enigszins vergelijkbaar scenario is als dat van Android Vulkaan. Het enige verschil is dat Apple de oudere apparaten bleef ondersteunen zonder de nieuwe grafische API.

Wat denk je? Wil je een aangepast ROM op je telefoon flashen om de levensduur ervan te verlengen? Zeg het in de reacties hieronder.