I den här artikeln utforskar vi sanningen om varför Snapdragon 801-enheter inte får Android Nougat. Från chipsettillverkare till leverantörer, problemen är många!
Uppdaterad för att återspegla antingen-eller Vulkan eller OpenGL ES 3.1-kravet för Android 7.0
Nyligen har det skrivits många artiklar om versionsuppdateringar, interaktionen mellan leverantör och chipsettillverkare och vad detta betyder för enheter framöver. Varför har detta kommit att stiga den här veckan?
Tja, det dök upp denna vecka med tanke på att den ärevördiga Nexus 5 inte kommer att få uppdateringen till Android 7.0 (Nougat), och Qualcomm meddelade att det inte kommer att bli det ger stöd för MSM8974 (mer känd som Snapdragon 801) på 7.0. Den här artikeln skrevs som ett samarbete med XDA Recognized Utvecklare humla.
Ämnet har väckt en del intresse från olika nyhetssajter, men många missar de subtila nyanserna av vad som verkligen händer bakom scenens. Den här artikeln kommer att förklara lite mer om hur programuppdateringar fungerar, med hjälp av vår erfarenhet av att arbeta med OEM-tillverkare på deras officiella firmwareuppdateringar. Vi går igenom vad som händer bakom kulisserna (och varför), och varför du kanske inte får den senaste programvaran på din telefon.
Det första steget i livet för en Android-firmwareuppdatering är uppströmsuppdateringen. Detta är vad Google jobbar med internt. Till skillnad från "öppna arbetsflöden" utvecklas Android med ett slutet arbetsflöde, med källkod som kastas över väggen varje år eller så, när en ny version kommer ut. Ursprungligen sa Google att detta var för att förhindra fragmentering från personer som kör avancerade versioner medan saker och ting utvecklades snabbt under de första dagarna, men de verkar ha hållit denna policy kvar plats.
Vid någon tidpunkt, vanligtvis innan det offentliga tillkännagivandet av en uppdatering (även om dessa tidsskalor förändras med den senaste introduktionen av offentliga betaversioner), OEM-tillverkare kommer att göras medvetna om en kommande uppdatering. De kommer sedan att få källkoden vid en andra tidpunkt för den slutliga uppdateringen (förr var det ibland lite före lanseringen, även om vi också är medvetna om fall där det inte är tidigt släpp).
Uppströms AOSP-förråden innehåller enhetsstöd för endast ett begränsat antal enheter. Dessa är vanligtvis dina Nexus-enheter. Av skäl som kommer att bli klara inom kort är det dock viktigt att notera att Google inte har fullständig maskinvarukontroll över dessa enheter; enheterna tillverkas av en OEM, och den OEM kommer att köpa ett System-on-Chip (SoC) från en chipsettillverkare.
När källkoden har släppts kommer OEM: s firmware-team (bildligt talat) luta sig tillbaka och sätta upp fötterna. Det huvudsakliga Android-källträdet har inte hårdvarustöd för den myriad av chipset som används i fraktenheter. Ditt Qualcomm-chipset stöds troligen inte inom AOSP, till exempel. Din Exynos en är definitivt inte det. Mediatek eller HiSilicon? Glöm det!
BSP innehåller drivrutiner och hårdvaruabstraktionslager (HAL) som behövs för att få Android att köras
Vad som behövs nu är en Board Support Package (BSP). Detta är ett superkonfidentiellt paket med proprietära komponenter, levererat av en chipsettillverkare till en OEM. BSP innehåller den nödvändiga källkoden för att låta OEM-tillverkare bygga Android och de nödvändiga drivrutinerna för sin enhet.
Det är värt att notera här att OEM-tillverkare som Qualcomm inte nödvändigtvis litar fullt ut på sina OEM-partners – BSP görs tillgänglig på basis av "need to know". OEM-tillverkare får vanligtvis inte tillgång till källkoden för vissa av de superhemliga delarna av enheten (som programvaran som körs på basbandet). Att ha den här delen stängd har säkert också potentiella problem, vilket framgår av de närmaste riklig och återkommande ASN.1 analysera sårbarheter.
BSP innehåller drivrutiner och hårdvaruabstraktionslager (HAL) som behövs för att få Android att köras på din enhet. AOSP innehåller en uppsättning HALs, som fungerar som definitioner av vad operativsystemet förväntar sig att dina drivrutiner ska implementera. För att använda ett löjligt förenklat (och påhittat, i demonstrationssyfte) exempel, låt oss föreställa oss ficklampan på din telefon.
Ett exempel HAL - Din ficklampa
Låt oss föreställa oss att din enhet har en ficklampa på baksidan (om du har en Nexus 7 2013 måste du tänka lite mer än alla andra – förlåt!). Detta styrs av en förare. För vårt galet enkla exempel, låt oss anta att v1 HAL säger att du ska ha en funktion som kallas "setLED" som tar en enda parameter, ljusets tillstånd. Det är en boolesk - sant eller falskt. I C skulle detta se ut ungefär så här:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Denna funktion definieras i BSP-källkoden. BSP: n kompileras sedan av OEM under byggandet av ROM, och detta blir ett av de proprietära ".so"-biblioteken på leverantörspartitionen eller området på din enhet. Detta låter en OEM hålla vissa delar av hur deras enhet fungerar hemliga. För nu, låt oss anta att de vill stoppa alla att se hur de slår på och släcker den lysdioden.
Föreställ dig nu att Google släpper en uppdaterad version av sina HALs i en framtida version av Android. De bestämmer nu att det skulle vara trevligt att låta dig uppdatera ljusstyrkan på din LED, snarare än att bara slå på eller av den. Kanske är det här för adaptiv blixt, eller kanske är det bara för att tvinga fram en HAL-uppdatering och hålla chipsettillverkarna i affärer? Vi låter dig, läsaren, komma fram till din egen åsikt om den. Vissa HAL-uppdateringar har tydliga fördelar (som den nya Camera HAL som exponerar råfotografering och liknande), medan andra är något mindre tydliga i syfte.
Med denna nya (fiktiva) HAL för ljusstyrka, låt oss anta att Google säger att du måste exponera en funktion som kallas setLED igen, men den här gången med ett heltal som skickas in för ljusstyrka. Nu skulle 0 stänga av den och 255 sätta den på full.
Om du är OEM kan du ta din superhemliga kod för att slå på den lysdioden och sätta den i den här nya funktionen. Du kan till och med använda pulsbreddsmodulering för att justera ljusstyrkan på lysdioden baserat på antalet. Du ändrar funktionen så att den ser ut så här nu:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Än sen då? Nåväl, nu är den här nya versionen av Android inkompatibel med befintliga "blobs". Din OEM behöver använda dessa nya blobbar, eftersom Android OS förväntar sig att se den nya funktionsdefinitionen och kommer inte att "hitta" den gamla när den letar efter ett sätt att ställa in LED.
Låt oss nu ta en kort paus för att titta på hur Custom ROMs (byggda från källan) hanterar här. Det är vad den skarpsinniga bland er kommer att skrika mot din skärm just nu - trots allt är vi XDA, hemmet för HTC HD2, den längsta hållbara telefonen i världen... (bara för protokollet, de galna genierna där borta springer Android 6.0 på HD2 nu för tiden! Inte illa för en telefon som ursprungligen levererades med Windows Mobile 6.5 2009)
Det finns olika tillvägagångssätt här - ibland hackar utvecklare runt i ROM och säger till operativsystemet att använda de gamla funktionsdefinitionerna. Det är lite rörigt och gör många förändringar att underhålla. Den andra metoden är att "shim" OEM-binären.
"Shim"-metoden är att skriva och bygga ett litet nytt bibliotek själv, som innehåller den förväntade funktionsdefinitionen - för vårt exempel skulle vi stödja heltal för ljusstyrka. Sedan, inom mellanlägget, översätts detta för att uppfylla kraven i den gamla HAL. Så för vårt exempel skulle vi kanske säga att varje ljusstyrka som begärs över 128 kommer att slå på lysdioden, och allt under som skulle stänga av den. Eller så kan du säga att allt som inte är noll slår på det. Det är upp till utvecklaren. De kompilerar mellanlägget och får Android att använda det istället för det ursprungliga. Mellanlägget kallar sedan OEM-blobben.
En snabb "adb-push" och omstart bör få igång shimsen och låta dig styra din fiktiva LED, även om du bara har den gamla HAL.
Problemet är att detta helt klart är en ofullkomlig process. Du kommer nu att få konstigheter - den här enheten kommer att ha en ganska skum blixt, som antingen är helt på eller helt avstängd. Det är inte idealiskt – operativsystemet tycker att det ger ett mycket mildt ljus, men den faktiska LED-lampan får höra att den tävlar i en konstgjord soltävling och försöker göra dig blind. Men hej, livet är inte perfekt, och du har nu en fungerande LED på din gamla telefon!
(Ja, det här är en av anledningarna till att det finns konstigheter och buggar när XDA-användare och utvecklare hanterar sina galna och vansinniga prestationer av porteringsförmåga. Jag menar fan, den Galaxy S II är en till synes användbar Android 6.0 ROM nu. Många telefoner som släpptes förra året har fortfarande inte 6.0!)
Låt oss hoppa tillbaka till OEM: s perspektiv. Tyvärr arbetar de flesta OEM-tillverkare redan minst 1 telefon före där vi är just nu. Deras fokus ligger på nästa telefon de är på väg att sälja – du kan inte riktigt skylla på dem, eftersom de bara tjänar pengar på enheter de säljer. De tjänar inga pengar på enheter de sålde för ett eller två år sedan, så de måste fortsätta släppa nya enheter för att existera. Detta är en anledning till att HTC och Blackberry har problem - det spelar ingen roll hur många chefer som behåller ett dödsgrepp om sin gamla Blackberry Curve, eftersom de inte får en ny enhetsförsäljning där.
Om OEM inte får en BSP, kommer de inte att gå ner på XDA-metoden att hacka ihop en build. Varför? Väl, de behöver stödja denna firmware för sina kunder. Om de släpper en firmware som är halvt fungerande, kommer användarna att hata dem och gnälla och rave, och låta sina supportlinjer ringa i flera dagar.
OEM-tillverkare måste också brottas med transportörer, åtminstone på icke-europeiska marknader. Operatörer vill inte att kunder ska ha problem med programuppdateringar. Faktum är att operatörer ofta hellre inte släpper programuppdateringar.
För att förstå detta, föreställ dig din store faster Alice. Det är hon som ringer dig vid obekväma tider på dygnet för att be om hjälp med "den där datorgrejen". Du beskriver sedan hur du klickar på "Start-menyn", och måste identifiera den som den "stora flaggan i det nedre vänstra hörnet", och möts av förvirring. Cirka 45 minuter (och mycket frustration) senare visar det sig att moster Alice har dragit sin startmeny till höger skärmkant och helt enkelt behövt dra den tillbaka. Ja, med vänster musknapp!
Föreställ dig nu att du har tusen tant Alice'. De ringer alla till din kundsupport, kan inte hitta Candy Crush på sin telefon, oroliga att en hackare raderat den från sin telefon. Åh, och ikonerna ser lite annorlunda ut nu - kanske hackaren fortfarande finns i sin telefon?
Ja, det här är tänkt att vara lite lättsam humor, men tills du upplever anledningarna till att folk ringer upp sin operatör för att få stöd, kommer du inte att tro på problemen de har. En mjukvaruuppdatering som ändrar hur telefonen fungerar, eller var saker är, kommer att orsaka en betydande supportoverhead. Åtminstone kräver det omutbildning av supportpersonal (eftersom de flesta av dem inte är din ivrig XDA-läsare, tyvärr).
När OEM har fått BSP kommer de att överföra sitt ROM och tillämpa alla sina ändringar på ROM. De samlar på sig sina bloatware och lägger till en fruktansvärd tecknad hud som skulle se mer hemma i en tonårings anime. Då ska de testa det.
Mycket.
Det finns alla möjliga krav som din telefon måste uppfylla. Mobilnäten är designade för att lita på att användarutrustningen (det vi kallar telefonen) beter sig korrekt. Det betyder att det krävs en hel del tester för att få enheten godkänd. Programuppdateringar riskerar att ändra beteenden, så saker och ting måste testas igen. Det är därför du vanligtvis kommer att se information om kommande Sony-programuppdateringar från externa testtjänster, som bekräftar att den fasta programvaran är kompatibel med testkraven.
Nu... vad händer efter en uppdatering eller två (eller i vissa fall ingen)? SoC-tillverkaren kommer inte att ge OEM en uppdaterad BSP. När allt kommer omkring kommer SoC-tillverkaren inte att få mycket av detta. OEM tjänar inte mer pengar på din telefon sedan den såldes. Och vid det här laget får din telefon inga fler större versionsuppdateringar.
Att skära ner på antalet BSP: er som OEM vill ha levererat är ett bra sätt att spara pengar - om du bara behöver den nuvarande och inte tänker leverera någon större version ökar, kommer detta att spara pengar på det första SoC-köpet och licensieringen, men på bekostnad av några arga nördar på XDA längre fram som undrar varför de inte fick en uppdatering.
Uppdateringar är komplexa. Det är många olika personer inblandade i kedjan. Inget av detta ursäktar OEMs från det nuvarande bristfälliga och patetiska tillståndet för uppdateringar på Android. Ändå finns det några verkliga utmaningar här.
Många OEM-tillverkare bär skulden för att de lovar för mycket, och det oundviklig underleverans som vi nu förknippar. Den sorgliga verkligheten är att för de flesta OEM-tillverkare är mjukvaruuppdateringar bara ett irritationsmoment de skulle kunna klara sig utan.
Mobilsektorn har mestadels fastnat i tankesättet för funktionstelefoner. Det vill säga där en enhet aldrig får några uppdateringar. Testa det en gång, skicka det och se dig aldrig tillbaka. Med säkerhetsproblemen med moderna smartphones och den rena komplexiteten i att köra ett fullständigt generellt operativsystem, med hundratals externa bibliotek, är det inte längre ett alternativ. Eller åtminstone det borde inte vara. Google har tagit några steg för att åtgärda detta, genom att åtminstone publicera säkerhetsbulletiner och patchar för befintliga versioner av Android (kom ihåg att tills helt nyligen var det enda sättet att få säkerhetsuppdateringar via en ny större Android OS-version!)
Tyvärr är detta inte riktigt tillräckligt. Även om Google fortsätter att släppa uppdateringar, är din enhets säkerhet fortfarande beroende av SoC-tillverkaren - eftersom SoC-tillverkare är så förstenade över någon som upptäcker hur de tänder ett par lysdioder eller gör ett ljud genom en högtalare, de skickar enorma mängder binära blobbar på sina enheter. Dessa blobbar innehåller ganska fruktansvärt osäker kod (ta bara en titt på tidigare Googles säkerhetsbulletiner om du tycker att detta är en överdrift!), och behöver uppdateras. Vilket innebär att uppdaterade BSP: er krävs.
Stationära datorer (och i förlängningen bärbara datorer) är helt annorlunda i arkitektur från mobila enheter. Din mobiltelefon eller surfplatta är i själva verket en kraftigt proprietär kiselklump, designad i en hast av vissa människor som menar väl, men som inte har tillräckligt med tid för att göra något bra. Marknaden rör sig så snabbt att de knappt kan hänga med i den takt som marknadsföring kräver att nya produkter lanseras.
Det betyder att genvägar tas - du kommer inte att hitta din telefon som stöds av Linux-kärnan, och du kommer att upptäcka att varje telefon har ett annat sätt att starta. Men på din bärbara eller stationära dator bestämde sig leverantörerna för några vanliga sätt att starta - tidigare var det MBR (master boot record) med ett BIOS, och nu är det UEFI. Denna standardisering gör det möjligt att köra samma programvara på varje enhet.
Även om det har tagits några steg mot detta nyligen, särskilt med Sonys uppsökande program och deras enhetlig kärna, är det inte praktiskt att köra en huvudlinjekärna på de flesta telefoner, på grund av det stora antalet nya leverantörsspecifika hack som introduceras till varje enhet.
Har du kopplat hörlursuttaget åt fel håll? Bara hacka den i drivrutinerna! Det finns ingen tid att fixa det i produktionsdesignen.
Har tillverkningsteamet monterat kameramodulen upp och ner i produktionsbatch 1? Kasta in ett hack för att kontrollera den interna versionskoden och vänd på videon om det är version 1!
Hack som dessa löser det omedelbara problemet, men skrapar bara ytan på de konstiga och produktspecifika förändringarna som pågår. Heck, det finns ibland helt olika chips i olika versioner av samma telefon, på grund av kommersiella beslut. Dessa leder till hack i drivrutiner och konstiga beslut som bara var vettiga just då, för att få telefonen att fungera så att den kan skickas nästa vecka.
Även om det pågår arbete med att stödja huvudlinjen för 64-bitars ARM-chips för att starta upp med UEFI, har det hittills varit ingen tydlig rörelse mot ett mer standardiserat sätt att starta ARM-enheter. Och det är tråkigt, för det betyder att telefoner kommer att fortsätta att kastas ut långt innan deras slut arbetsliv, eftersom det helt enkelt är för dyrt att upprätthålla den tekniska skulden och belastningen på sina programvara.
Men å andra sidan, om en OEM bara kommer att tjäna pengar på försäljning av en enhet, behöver de inte se till att folk fortsätter att köpa nya telefoner? Skulle PC-marknaden gå över till den här modellen om det inte redan fanns 30 år av fart och äldre mjukvara där ute med den öppna PC-plattformen och standarden?
Detta är en svår fråga utan insiderkunskap från Qualcomm, som vi tyvärr inte har för tillfället. Däremot kan vi hämta lite information från 7.0 Android-drivrutin API och CTS-krav. CTS-kraven anger vad Google förväntar sig av en enhet som kör en viss firmware. Den "stora hammaren" som används för att upprätthålla dessa krav är Googles licensiering att använda deras egenutvecklade Google Play Services-paket - om du inte följer detta kan du inte skicka Google Apps på enheten. Medan, för vissa, detta kan ses som en fördel, detta är uppenbarligen inte vad användarna vill ha och förväntar sig av en enhet.
Android 7.0 har inte lagt till mycket i form av ändringar i HAL eller drivrutiner (som beskrivits ovan), så någon inkompatibilitet kommer sannolikt inte att komma därifrån specifikt. Vad som är mer sannolikt att utgöra ett problem är dock införandet av en nytt krav för antingen Vulkan grafik API eller GLES 3.1, att vara tillgänglig för att klara CTS.
För närvarande har många Systems-on-Chip (SoC) inte haft Vulkan-stöd på sin grafikprocessor, inklusive MSM8974. Det är också mest troligt där problemet med kompatibilitet med Android 7.0 kommer att uppstå. Men igen, utan insiderkännedom från Qualcomm och deras framtidsplaner, är det svårt för oss att ge ett definitivt uttalande utan att kvalificera det. För närvarande tror vi dock att det är troligt att detta är det "enkla" fallet där Qualcomm upphör med stödet för den (i deras ögon) åldrande MSM8974-chipset, och inte tillhandahåller ett BSP (kortstödspaket) för 7.0 på den plattformen. Om så var fallet skulle det betyda att OEM-tillverkare är nästan säkra på att inte skicka 7.0 på enheten - de måste på något sätt hitta Vulkan eller GLEs 3.1-stöd för sin GPU och GPU-källa kod är en av de löjligt hårt skyddade delarna av de mobila stackarna (utan egentlig anledning, skulle vi tillägga - se AMD, öppna källan för sin egen AMDGPU-drivrutin på skrivbordet för Linux). Tyvärr är dock Vulkan- och accelererad (GLES)-grafik i allmänhet lite mer komplex än en enkel LED, så det här är inget vi kommer att se shims att införa kompatibilitet för.
Eftersom 7.0 inte har varit ute på länge, finns det en reell möjlighet för andra styrkretsar (andra än det lilla antalet inom AOSP själv) att bli kvar bakom på 6.0, på grund av antingen hårdvaru- och drivrutinsproblem (dvs. ingen uppdaterad BSP) eller brist på SoC-leverantörsstöd med avseende på Vulkan eller GLES 3.1 API. För närvarande stöder varken Snapdragon 800 eller 801 någon av dessa.
Det bästa alternativet är att titta på detta utrymme - Utvecklare på XDA gör redan goda framsteg med inofficiella portar till 7.0 för många av enheterna som inte får officiellt 7.0-stöd från Google. Dessa är dock utan Vulkan eller GLES 3.1-stöd - kanske utvecklare av spel på Android kommer att börja uppleva frustration genom fragmentering om tillräckligt många användare börjar köra anpassade ROM utan Vulkan eller GLES 3.1 Stöd?
Apple tenderar att stödja sin iPhone-linje på den senaste iOS-versionen i cirka 5 år - iPhone 4s lanserades i oktober 2011 och har hållits uppdaterad till iOS 9. Den kommer dock inte att få den kommande iOS 10-uppdateringen, vilket skulle ge telefonen en effektiv livslängd på 5 år, förutsatt att iOS 10 lanseras runt oktober. Det är värt att notera att Apple inte alltid backportar grafik API-stöd - iPhone 4s och iPhone 5 gör det inte har Apples Metal graphics API, vilket är ett något liknande scenario som det man ser med Android i Vulkan. Den enda skillnaden är att Apple fortsatte att stödja de äldre enheterna utan det nya grafik-API: et.
Vad tror du? Kommer du att flasha en anpassad ROM på din telefon för att förlänga dess livslängd? Har du sagt i kommentarerna nedan.