I denne artikel udforsker vi sandheden om, hvorfor Snapdragon 801-enheder ikke får Android Nougat. Fra chipsetproducenter til leverandører, problemerne er mange!
Opdateret for at afspejle enten-eller Vulkan- eller OpenGL ES 3.1-kravet til Android 7.0
For nylig er der skrevet en masse artikler om versionsopdateringer, samspillet mellem leverandør og chipsetproducent, og hvad det betyder for enheder fremover. Hvorfor er dette kommet til at stige i denne uge?
Nå, det kom frem i denne uge, da den ærværdige Nexus 5 ikke vil modtage opdateringen til Android 7.0 (Nougat), og Qualcomm meddelte, at det ikke ville være giver support til MSM8974 (mere kendt som Snapdragon 801) på 7.0. Denne artikel er skrevet som et samarbejde med XDA Recognized Udvikler humlebi.
Emnet har tiltrukket sig en del interesse fra forskellige nyhedssider, men mange går glip af de subtile nuancer af, hvad der virkelig foregår bag scenens. Denne artikel vil forklare lidt mere om, hvordan softwareopdateringer fungerer, ved at bruge vores erfaring med at arbejde med OEM'er om deres officielle firmwareopdateringer. Vi guider dig gennem, hvad der foregår bag kulisserne (og hvorfor), og hvorfor du måske ikke ender med at få den nyeste software på din telefon.
Det første skridt i livet for en Android-firmwareopdatering er upstream-opdateringen. Det er det, Google arbejder med internt. I modsætning til "åbne arbejdsgange" er Android udviklet ved hjælp af en lukket arbejdsgang, med kildekode kastet over væggen hvert år eller deromkring, når en ny udgivelse udkommer. Oprindeligt sagde Google, at dette var for at forhindre fragmentering fra folk, der kører blødende versioner mens tingene udviklede sig hurtigt i de tidlige dage, men de ser ud til at have holdt denne politik inde placere.
På et tidspunkt, normalt før den offentlige annoncering af en opdatering (selvom med den nylige introduktion af offentlige betaversioner ændrer disse tidsskalaer sig), OEM'er vil blive gjort opmærksomme på en kommende opdatering. De vil derefter modtage kildekoden på et andet tidspunkt for den endelige opdatering (tidligere var det nogle gange lidt før lanceringen, selvom vi også er opmærksomme på tilfælde, hvor der ikke er tidligt frigøre).
Opstrøms AOSP-lagre indeholder enhedsunderstøttelse for kun et begrænset antal enheder. Disse er typisk dine Nexus-enheder. Af årsager, der vil blive klart snart, er det dog vigtigt at bemærke, at Google ikke har fuldstændig hardwarekontrol over disse enheder; enhederne er fremstillet af en OEM, og den OEM vil købe en System-on-Chip (SoC) fra en chipsetproducent.
Når kildekoden er frigivet, vil OEM's firmware-team (billedligt talt) læne sig tilbage og sætte fødderne op. Det vigtigste Android-kildetræ har ikke hardwareunderstøttelse til de utallige chipsæt, der bruges i forsendelsesenheder. Dit Qualcomm-chipsæt er højst sandsynligt ikke understøttet i AOSP, for eksempel. Din Exynos er det absolut ikke. Mediatek eller HiSilicon? Glem det!
BSP'en indeholder de drivere og hardwareabstraktionslag (HAL'er), der er nødvendige for at få Android til at køre
Hvad der er brug for nu er en Board Support Package (BSP). Dette er en superfortrolig pakke af proprietære komponenter, leveret af en chipsetproducent til en OEM. BSP'en indeholder den nødvendige kildekode for at lade OEM'er bygge Android og de nødvendige drivere til deres enhed.
Det er værd at bemærke her, at OEM'er som Qualcomm ikke nødvendigvis har fuld tillid til deres OEM-partnere - BSP'en er gjort tilgængelig på en "need to know"-basis. OEM'er får normalt ikke adgang til kildekoden for nogle af de superhemmelige dele af enheden (såsom softwaren, der kører på basebåndet). At have denne del lukket har bestemt også potentielle problemer, som vist af de nærmeste rigelige og tilbagevendende ASN.1 parsing af sårbarheder.
BSP'en indeholder de drivere og hardwareabstraktionslag (HAL'er), der er nødvendige for at få Android til at køre på din enhed. AOSP indeholder et sæt HAL'er, der fungerer som definitioner af, hvad operativsystemet forventer, at dine drivere implementerer. For at bruge et latterligt forsimplet (og opdigtet, med henblik på demonstration) eksempel, lad os forestille os lommelygten på din telefon.
Et eksempel HAL - Din lommelygte
Lad os forestille os, at din enhed har en lommelygte på bagsiden (hvis du har en Nexus 7 2013, bliver du nødt til at forestille dig lidt mere end alle andre – undskyld!). Dette styres af en chauffør. For vores vanvittigt enkle eksempel, lad os antage, at v1 HAL siger, at du skal have en funktion kaldet "setLED", der tager en enkelt parameter, lysets tilstand. Det er en boolsk - sandt eller falsk. I C ville dette se sådan ud:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Denne funktion er defineret i BSP-kildekoden. BSP'en kompileres derefter af OEM'en under opbygningen af ROM'en, og dette bliver et af de proprietære ".so"-biblioteker på leverandørpartitionen eller -området på din enhed. Dette lader en OEM holde visse dele af deres enheds funktion hemmelige. Lad os nu antage, at de vil forhindre alle i at se, hvordan de tænder og slukker den LED.
Forestil dig nu, at Google frigiver en opdateret version af deres HAL'er i en fremtidig version af Android. De beslutter nu, at det ville være rart at give dig mulighed for at opdatere lysstyrken på din LED i stedet for bare at tænde eller slukke for den. Måske er dette til adaptiv flash, eller måske er det bare for at tvinge en HAL-opdatering og holde chipset-producenterne i gang? Vi lader dig, som læser, nå frem til din egen mening om den. Nogle HAL-opdateringer har klare fordele (såsom det nye kamera HAL, der eksponerer råoptagelser og lignende), mens andre er noget mindre tydelige i formålet.
Med denne nye (fiktive) HAL for lysstyrke, lad os antage, at Google siger, at du igen skal eksponere en funktion kaldet setLED, men denne gang med et heltal indgivet for lysstyrke. Nu ville 0 slå det fra, og 255 ville sætte det på fuld.
Hvis du er OEM, kan du tage din superhemmelige kode for at tænde den LED og sætte den i denne nye funktion. Du kan endda bruge pulsbreddemodulation til at justere lysstyrken på LED'en baseret på antallet. Du ændrer funktionen til at se sådan ud nu:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Og hvad så? Nå, nu er denne nye version af Android inkompatibel med eksisterende "blobs". Din OEM skal bruge disse nye blobs, fordi Android OS forventer at se den nye funktionsdefinition og vil ikke "finde" den gamle, når den leder efter en måde at indstille LED'en på.
Lad os på dette tidspunkt tage en kort pause for at se på, hvordan brugerdefinerede ROM'er (bygget fra kilden) klarer sig her. Det er, hvad de kloge blandt jer vil råbe på din skærm lige nu - vi er trods alt XDA, hjemstedet for HTC HD2, den længst holdbare telefon i verden... (bare for ordens skyld løber de skøre genier derovre Android 6.0 på HD2 i disse dage! Ikke dårligt for en telefon, der oprindeligt blev leveret med Windows Mobile 6.5 i 2009)
Der er forskellige tilgange her - nogle gange hacker udviklere rundt i ROM'en og fortæller OS'et at bruge de gamle funktionsdefinitioner. Det er lidt rodet og gør en masse ændringer at vedligeholde. Den anden tilgang er at "shim" OEM-binæren.
"Shim"-tilgangen er at skrive og bygge et lille nyt bibliotek selv, som indeholder den forventede funktionsdefinition - for vores eksempel ville vi understøtte heltal for lysstyrke. Derefter, inden for shim, er dette oversat til at opfylde kravene i den gamle HAL. Så for vores eksempel vil vi måske sige, at enhver lysstyrke, der anmodes om over 128, vil tænde LED'en, og alt under, der vil slukke den. Eller du kan sige, at alt andet end nul vil tænde det. Det er op til udvikleren. De kompilerer shim og får Android til at bruge det i stedet for det oprindelige. Mellemstykket kalder derefter OEM-klatten.
Et hurtigt 'adb-skub' og genstart skulle få shim'en i gang, og lade dig styre din fiktive LED, selvom du kun har den gamle HAL.
Problemet er, at dette helt klart er en ufuldkommen proces. Du vil nu få særheder - denne enhed vil have en temmelig crummy flash, der enten er helt tændt eller helt slukket. Det er ikke ideelt - OS synes, det giver et meget blidt lys, men den faktiske LED får at vide, at den konkurrerer i en kunstig solkonkurrence og forsøger at blinde dig. Men hey, livet er ikke perfekt, og du har nu en fungerende LED på din gamle telefon!
(Ja, dette er en af grundene til, at der er særheder og fejl, når XDA-brugere og -udviklere klarer deres skøre og vanvittige bedrifter med porteringsevner. Jeg mener for pokker Galaxy S II er toting en tilsyneladende brugbar Android 6.0 ROM nu. Mange telefoner udgivet sidste år har stadig ikke 6.0!)
Lad os springe tilbage til OEM's perspektiv. Desværre arbejder de fleste OEM'er allerede mindst 1 telefon foran, hvor vi er lige nu. Deres fokus er på den næste telefon, de er ved at sælge – man kan ikke rigtig bebrejde dem, da de kun tjener penge på enheder, de sælger. De tjener ingen penge på enheder, de solgte for et eller to år siden, så de er nødt til at blive ved med at udgive nye enheder for at eksistere. Dette er en af grundene til, at HTC og Blackberry er i problemer - det er lige meget, hvor mange ledere, der bevarer et dødsgreb om deres gamle Blackberry Curve, da de ikke får et nyt enhedssalg der.
Hvis OEM'en ikke får en BSP, vil de ikke gå ned i XDA-tilgangen med at hacke en build sammen. Hvorfor? Godt, de skal understøtte denne firmware for deres kunder. Hvis de frigiver en firmware, der er halvt-arbejdende, vil brugerne hade dem, og rage og rave, og holde deres supportlinjer ringe i dagevis.
OEM'er skal også kæmpe med transportører, i hvert fald på ikke-europæiske markeder. Transportører ønsker ikke, at kunder skal have problemer med softwareopdateringer. Faktisk vil udbydere ofte hellere ikke udgive softwareopdateringer.
For at forstå dette, forestil dig din store tante Alice. Det er hende, der ringer dig op på ubelejlige tidspunkter af dagen for at bede om hjælp til "den computerting". Du beskriver derefter, hvordan du klikker på "Start-menuen", og skal identificere det som "det store flag i nederste venstre hjørne", og bliver mødt med forvirring. Omkring 45 minutter (og meget frustration) senere viser det sig, at tante Alice har trukket sin startmenu til den højre skærmkant og blot havde brug for at trække den tilbage. Ja, med venstre museknap!
Forestil dig nu, at du har tusind tante Alice'. De ringer alle til din kundesupport, ude af stand til at finde Candy Crush på deres telefon, bekymrede for, at en hacker har slettet det fra deres telefon. Åh, og ikonerne ser lidt anderledes ud nu - måske er hackeren stadig i deres telefon?
Ja, det her er ment som en smule lethjertet humor, men før du oplever grundene til, at folk ringer til deres udbyder for at få støtte, vil du ikke tro på de problemer, de har. En softwareopdatering, som ændrer, hvordan telefonen fungerer, eller hvor tingene er, vil medføre betydelige supportomkostninger. Det kræver som minimum genoptræning af supportpersonale (fordi de fleste af dem desværre ikke er din ivrige XDA-læser).
Når OEM'en får BSP'en, overfører de deres ROM og anvender alle deres ændringer på ROM'en. De samler deres bloatware og tilføjer et forfærdeligt tegneserieagtigt skin, der ville se mere hjemme i en teenagers Anime. Så vil de teste det.
En masse.
Der er alle mulige krav, som din telefon skal overholde. Mobilnetværkene er designet til at stole på, at brugerudstyret (det vi kalder telefonen) opfører sig korrekt. Det betyder, at der skal en masse test til for at få enheden godkendt. Softwareopdateringer risikerer at ændre adfærd, så tingene skal testes igen. Dette er grunden til, at du ofte vil se oplysninger om kommende Sony-softwareopdateringer fra eksterne testtjenester, som bekræfter, at firmwaren er i overensstemmelse med testkravene.
Nu... hvad sker der efter en opdatering eller to (eller i nogle tilfælde ingen)? SoC-producenten vil ikke give OEM en opdateret BSP. Det får SoC-producenten trods alt ikke meget ud af. OEM tjener ikke flere penge på din telefon, siden den blev solgt. Og på dette tidspunkt får din telefon ikke flere større versionsopdateringer.
At skære ned på antallet af BSP'er, som OEM ønsker leveret, er en fantastisk måde at spare penge på - hvis du kun har brug for den nuværende og ikke har til hensigt at levere nogen større version stiger, vil dette spare penge på det indledende SoC-køb og licensering, men på bekostning af nogle få vrede nørder på XDA, der undrer sig over, hvorfor de ikke fik en opdatering.
Opdateringer er komplekse. Der er mange forskellige mennesker involveret i kæden. Intet af dette undskylder OEM'er fra den nuværende mangelfulde og patetiske tilstand af opdateringer på Android. Ikke desto mindre er der nogle reelle udfordringer her.
Mange OEM'er er skyld i at over-love, og det uundgåelig underlevering, som vi nu forbinder. Den triste virkelighed er, at for de fleste OEM'er er softwareopdateringer bare et irritationsmoment, de kunne undvære.
Mobilsektoren er for det meste fastlåst i tankegangen om feature-telefoner. Det vil sige, hvor en enhed aldrig får nogen opdateringer. Test det én gang, send det, og se dig aldrig tilbage. Med sikkerhedsproblemerne ved moderne smartphones og den rene kompleksitet ved at køre et fuldt generelt operativsystem med hundredvis af eksterne biblioteker, er det ikke længere en mulighed. Eller i det mindste det burde ikke være. Google har taget nogle skridt i retning af at løse dette ved i det mindste at udgive sikkerhedsbulletiner og patches til eksisterende udgivelser af Android (husk, at indtil for ganske nylig var den eneste måde at få sikkerhedsopdateringer på via en ny større Android OS-version!)
Desværre er dette dog ikke rigtig nok. Selvom Google bliver ved med at udgive opdateringer, er din enheds sikkerhed stadig afhængig af SoC-producenten - da SoC-producenter er så forstenede over nogen, der opdager, hvordan de tænder et par lysdioder eller laver en lyd gennem en højttaler, sender enorme mængder af binære blobs på deres enheder. Disse klatter indeholder noget temmelig forfærdeligt usikker kode (tag et kig på tidligere Google-sikkerhedsbulletiner, hvis du synes, det er en overdrivelse!), og skal opdateres. Hvilket betyder opdaterede BSP'er er påkrævet.
Stationære computere (og i forlængelse heraf bærbare computere) er helt anderledes i arkitektur fra mobile enheder. Din mobiltelefon eller tablet er faktisk en stærkt proprietær klump silicium, designet i en fart af nogle mennesker, der mener det godt, men som ikke har nær nok tid til at lave noget godt. Markedet bevæger sig så hurtigt, at de næsten ikke er i stand til at følge med i det tempo, hvormed markedsføring kræver nye produkter lanceret.
Det betyder, at der tages genveje - du vil ikke finde din telefon understøttet af Linux-kernen, og du vil opdage, at hver telefon har en anden måde at starte op. På din bærbare eller stationære computer slog leverandørerne dog fast på nogle standardmåder at starte - tidligere var det MBR (master boot record) med en BIOS, og nu er det UEFI. Denne standardisering gør det muligt at køre den samme software på hver enhed.
Selvom der har været nogle skridt hen imod dette for nylig, især med Sonys opsøgende program og deres samlet kerne, er det ikke praktisk at køre en hovedlinjekerne på de fleste telefoner på grund af det store antal nye leverandørspecifikke hacks, der introduceres til hver enhed.
Ledet hovedtelefonstikket den forkerte vej rundt? Bare hack det i driverne! Der er ikke tid til at ordne det i produktionsdesignet.
Har produktionsteamet monteret kameramodulet på hovedet i produktionsbatch 1? Smid et hack ind for at tjekke den interne versionskode, og vend videoen rundt, hvis det er version 1!
Hacks som disse løser det umiddelbare problem, men skraber kun overfladen af de mærkelige og produktspecifikke ændringer, der foregår. For pokker, der er endda nogle gange helt forskellige chips i forskellige revisioner af den samme telefon på grund af kommercielle beslutninger. Disse fører til hacks i drivere og mærkelige beslutninger, der kun gav mening på det tidspunkt, for at få telefonen til at fungere, så den kan sendes den næste uge.
Selvom der er arbejde i gang med at understøtte mainline-understøttelse af 64-bit ARM-chips til at starte ved hjælp af UEFI, har der indtil videre været ingen klar bevægelse mod en mere standardiseret måde at starte ARM-enheder på. Og det er trist, for det betyder, at telefoner fortsat vil blive smidt ud i god tid inden udgangen af deres arbejdsliv, fordi det simpelthen er for dyrt at opretholde den tekniske gæld og byrde på deres software.
På den anden side, hvis en OEM kun vil tjene penge på salg af en enhed, behøver de så ikke sikre, at folk fortsætter med at købe nye telefoner? Ville pc-markedet flytte til denne model, hvis der ikke allerede var 30 års fremdrift og ældre software derude ved hjælp af den åbne pc-platform og standard?
Dette er et svært spørgsmål uden intern viden fra Qualcomm, som vi desværre ikke har i øjeblikket. Vi kan dog trække nogle oplysninger fra 7.0 Android driver API og CTS kravene. CTS-kravene angiver, hvad Google forventer af en enhed, der kører en given firmware. Den "store hammer", der bruges til at håndhæve disse krav, er Googles licens til at bruge deres proprietære Google Play Services-pakke - hvis du ikke overholder kravene, kan du ikke sende Google Apps på enheden. Mens dette for nogle kan ses som en fordel, dette er åbenbart ikke, hvad brugerne ønsker og forventer af en enhed.
Android 7.0 har ikke tilføjet meget i form af ændringer til HAL eller drivere (som beskrevet ovenfor), så enhver inkompatibilitet kommer sandsynligvis ikke derfra specifikt. Hvad der dog er mere tilbøjeligt til at udgøre et problem, er indførelsen af en nyt krav til enten Vulkan grafik API eller GLES 3.1, at være tilgængelig for at bestå CTS.
På nuværende tidspunkt har mange Systems-on-Chip (SoC'er) ikke haft Vulkan-understøttelse på deres grafikprocessor, inklusive MSM8974. Det er også mest sandsynligt, hvor spørgsmålet om kompatibilitet med Android 7.0 vil opstå. Men igen, uden intern viden fra Qualcomm og deres fremtidige planer, er det svært for os at give en endelig erklæring uden at kvalificere den. I øjeblikket mener vi dog, at det er sandsynligt, at dette er det "simple" tilfælde, hvor Qualcomm ophører med support til det (i deres øjne) aldrende MSM8974-chipsæt og ikke leverer en BSP (board support-pakke) til 7.0 på den platform. Hvis det var tilfældet, ville det betyde, at OEM'er næsten ville være sikre på ikke at sende 7.0 på enheden - de skulle på en eller anden måde finde Vulkan eller GLEs 3.1-understøttelse til deres GPU og GPU-kilde kode er en af de latterligt stramt beskyttede dele af de mobile stakke (uden nogen egentlig grund, vil vi tilføje - se AMD, åbner deres egen AMDGPU-driver på skrivebordet for Linux). Desværre er Vulkan og accelereret (GLES) grafik generelt en smule mere kompleks end en simpel LED, så det er ikke noget, vi kommer til at se shims for at introducere kompatibilitet til.
Da 7.0 ikke har været ude længe, er der en reel mulighed for, at andre chipsæt (bortset fra det lille antal i AOSP selv) bliver tilbage bagud på 6.0 på grund af enten hardware- og driverproblemer (dvs. ingen opdateret BSP) eller mangel på SoC-leverandørsupport med hensyn til Vulkan eller GLES 3.1 API. På nuværende tidspunkt understøtter hverken Snapdragon 800 eller 801 en af disse.
Det bedste bud er at se dette rum - udviklere på XDA gør allerede gode fremskridt med uofficielle porte til 7.0 for mange af enhederne, der ikke får officiel 7.0-support fra Google. Disse er dog uden Vulkan eller GLES 3.1-understøttelse - måske vil udviklere af spil på Android begynde at gøre det opleve frustration gennem fragmentering, hvis nok brugere begynder at køre brugerdefinerede ROM'er uden Vulkan eller GLES 3.1 support?
Apple har en tendens til at understøtte deres iPhone-serie på den seneste iOS-version i omkring 5 år - iPhone 4s blev lanceret i oktober 2011 og er blevet holdt opdateret op til iOS 9. Den modtager dog ikke den kommende iOS 10-opdatering, hvilket ville give telefonen en effektiv levetid på 5 år, forudsat at iOS 10 lanceres omkring oktober. Det er værd at bemærke, at Apple ikke altid understøtter grafik-API-understøttelse - iPhone 4s og iPhone 5 gør det ikke har Apples Metal-grafik-API, som er et noget lignende scenarie som det, man ser med Android i Vulkan. Den eneste forskel er, at Apple fortsatte med at understøtte de ældre enheder uden den nye grafik API.
Hvad synes du? Vil du flashe en brugerdefineret ROM på din telefon for at forlænge dens levetid? Har du sagt i kommentarerne nedenfor.