I denne artikkelen utforsker vi sannheten om hvorfor Snapdragon 801-enheter ikke får Android Nougat. Fra brikkesettprodusenter til leverandører, problemene er mange!
Oppdatert for å gjenspeile enten-eller Vulkan eller OpenGL ES 3.1-kravet for Android 7.0
I det siste har det vært skrevet mange artikler om versjonsoppdateringer, interaksjonene mellom leverandør og brikkesettprodusent, og hva dette betyr for enheter fremover. Hvorfor har dette kommet opp denne uken?
Vel, det dukket opp denne uken gitt at den ærverdige Nexus 5 ikke vil motta oppdateringen til Android 7.0 (Nougat), og Qualcomm kunngjorde at den ikke vil bli det gir støtte for MSM8974 (mer kjent som Snapdragon 801) på 7.0. Denne artikkelen ble skrevet som et samarbeid med XDA Recognized Utvikler humle.
Emnet har tiltrukket seg en del interesse fra forskjellige nyhetssider, men mange går glipp av de subtile nyansene av hva som egentlig skjer bak scenens. Denne artikkelen vil forklare litt mer om hvordan programvareoppdateringer fungerer, ved å bruke vår erfaring med å jobbe med OEM-er på deres offisielle fastvareoppdateringer. Vi vil lede deg gjennom hva som skjer bak kulissene (og hvorfor), og hvorfor du kanskje ikke ender opp med å få den nyeste programvaren på telefonen.
Det første trinnet i livet til en Android-fastvareoppdatering er oppstrømsoppdateringen. Det er dette Google jobber med internt. I motsetning til "åpne arbeidsflyter", er Android utviklet ved hjelp av en lukket arbeidsflyt, med kildekode kastet over veggen hvert år eller så, når en ny utgivelse kommer ut. Opprinnelig sa Google at dette var for å forhindre fragmentering fra folk som kjører avanserte versjoner mens ting utviklet seg raskt i de første dagene, men de ser ut til å ha holdt denne politikken inne plass.
På et tidspunkt, vanligvis før den offentlige kunngjøringen av en oppdatering (selv om med den nylige introduksjonen av offentlige betaer, endrer disse tidsskalaene seg), OEM-er vil bli gjort oppmerksom på en kommende oppdatering. De vil da motta kildekoden på et annet tidspunkt for den endelige oppdateringen (tidligere var det noen ganger litt før lanseringen, selv om vi også er klar over tilfeller der det ikke er tidlig utgivelse).
Oppstrøms AOSP-lagrene inneholder enhetsstøtte for bare et begrenset antall enheter. Dette er vanligvis Nexus-enhetene dine. Av årsaker som imidlertid vil bli klart snart, er det viktig å merke seg at Google ikke har fullstendig maskinvarekontroll over disse enhetene; enhetene er produsert av en OEM, og at OEM vil kjøpe en System-on-Chip (SoC) fra en brikkesettprodusent.
Når kildekoden er utgitt, vil OEMs fastvareteam (figurativt sett) lene seg tilbake og sette føttene opp. Hovedkildetreet for Android har ikke maskinvarestøtte for mylderet av brikkesett som brukes i fraktenheter. Qualcomm-brikkesettet ditt støttes mest sannsynlig ikke innenfor AOSP, for eksempel. Din Exynos er definitivt ikke det. Mediatek eller HiSilicon? Glem det!
BSP-en inneholder driverne og maskinvareabstraksjonslagene (HALs) som trengs for å få Android til å kjøre
Det som trengs nå er en Board Support Package (BSP). Dette er en superkonfidensiell pakke med proprietære komponenter, levert av en brikkesettprodusent til en OEM. BSP-en inneholder den nødvendige kildekoden for å la OEM-er bygge Android og de nødvendige driverne for enheten deres.
Det er verdt å merke seg her at OEM-er som Qualcomm ikke nødvendigvis stoler fullt ut på sine OEM-partnere - BSP-en er gjort tilgjengelig på en "need to know"-basis. OEM-er får vanligvis ikke tilgang til kildekoden for noen av de superhemmelige delene av enheten (for eksempel programvaren som kjører på basebåndet). Å ha denne delen lukket har absolutt også potensielle problemer, som vist av de nære rikelig og tilbakevendende ASN.1 analysere sårbarheter.
BSP-en inneholder driverne og maskinvareabstraksjonslagene (HALs) som trengs for å få Android til å kjøre på enheten din. AOSP inneholder et sett med HAL-er, som fungerer som definisjoner av hva operativsystemet forventer at driverne dine skal implementere. For å bruke et latterlig forenklet (og oppdiktet, for demonstrasjonsformål) eksempel, la oss forestille oss lommelykten på telefonen din.
Et eksempel HAL - lommelykten din
La oss forestille oss at enheten din har en lommelykt på baksiden (hvis du har en Nexus 7 2013, må du tenke litt mer enn alle andre – beklager!). Dette styres av en sjåfør. For vårt vanvittig enkle eksempel, la oss anta at v1 HAL sier at du bør ha en funksjon kalt "setLED" som tar en enkelt parameter, lysets tilstand. Det er en boolsk - sant eller usant. I C vil dette se omtrent slik ut:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Denne funksjonen er definert i BSP-kildekoden. BSP-en kompileres deretter av OEM under byggingen av ROM-en, og dette blir et av de proprietære ".so"-bibliotekene på leverandørpartisjonen eller -området på enheten din. Dette lar en OEM holde visse deler av hvordan enheten fungerer hemmelig. For nå, la oss anta at de vil stoppe alle fra å se hvordan de slår den LED-en av og på.
Tenk deg nå at Google slipper en oppdatert versjon av deres HAL-er i en fremtidig versjon av Android. De bestemmer nå at det ville være fint å la deg oppdatere lysstyrken til LED-en din, i stedet for å bare slå den på eller av. Kanskje dette er for adaptiv flash, eller kanskje det bare er for å tvinge frem en HAL-oppdatering, og holde brikkesettprodusentene i gang? Vi lar deg som leser komme til din egen mening om den. Noen HAL-oppdateringer har klare fordeler (som den nye Camera HAL som eksponerer råopptak og lignende), mens andre er noe mindre tydelige i hensikten.
Med denne nye (fiktive) HAL for lysstyrke, la oss anta at Google sier at du igjen må eksponere en funksjon kalt setLED, men denne gangen med et heltall som er gitt inn for lysstyrke. Nå vil 0 slå den av, og 255 vil sette den på full.
Hvis du er OEM, kan du ta den superhemmelige koden din for å slå på den LED-en og sette den inn i denne nye funksjonen. Du kan til og med bruke pulsbreddemodulering for å justere lysstyrken på LED-en basert på tallet. Du endrer funksjonen til å se slik ut nå:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Hva så? Vel, nå er denne nye versjonen av Android inkompatibel med eksisterende "blobs". OEM-en din må bruke disse nye blobene, fordi Android OS forventer å se den nye funksjonsdefinisjonen, og vil ikke "finne" den gamle når den leter etter en måte å stille inn LED-en.
På dette tidspunktet, la oss ta en kort pause for å se på hvordan tilpassede ROM-er (bygget fra kilden) klarer seg her. Det er det den kloke blant dere kommer til å rope på skjermen din akkurat nå - tross alt er vi XDA, hjemmet til HTC HD2, den lengst holdbare telefonen i verden... (bare for ordens skyld, de sprø geniene der borte løper Android 6.0 på HD2 i disse dager! Ikke verst for en telefon som opprinnelig ble levert med Windows Mobile 6.5 i 2009)
Det er forskjellige tilnærminger her – noen ganger hacker utviklere rundt i ROM-en og ber OS-et bruke de gamle funksjonsdefinisjonene. Det er litt rotete, og gjør mange endringer å vedlikeholde. Den andre tilnærmingen er å "shim" OEM-binæren.
"Shim"-tilnærmingen er å skrive og bygge et lite nytt bibliotek selv, som inneholder den forventede funksjonsdefinisjonen - for eksempelet vårt ville vi støtte heltall for lysstyrke. Deretter, innenfor shim, er dette oversatt til å oppfylle kravene til den gamle HAL. Så for vårt eksempel vil vi kanskje si at enhver lysstyrke som er forespurt over 128 vil slå på LED-en, og alt under som vil slå den av. Eller du kan si at alt som ikke er null vil slå det på. Det er opp til utvikleren. De kompilerer mellomlegget, og får Android til å bruke det i stedet for det opprinnelige. Mellomlegget kaller deretter OEM-klatten.
Et raskt «adb-push» og omstart bør få shim-en i gang, og la deg kontrollere den fiktive LED-en, selv om du bare har den gamle HAL-en.
Problemet er at dette helt klart er en ufullkommen prosess. Du vil nå få særheter - denne enheten vil ha en ganske grusom blits, som enten er helt på eller helt av. Det er ikke ideelt - operativsystemet tror det gir et veldig mildt lys, men den faktiske LED-en blir fortalt at den konkurrerer i en kunstig solkonkurranse, og prøver å blende deg. Men hei, livet er ikke perfekt, og du har nå en fungerende LED på den gamle telefonen din!
(Ja, dette er en av grunnene til at det er finurligheter og feil når XDA-brukere og utviklere klarer sine sprø og vanvittige bragder med porteringsdyktighet. Jeg mener pokker Galaxy S II er toting en tilsynelatende brukbar Android 6.0 ROM nå. Mange telefoner utgitt i fjor har fortsatt ikke 6.0!)
La oss hoppe tilbake til OEMs perspektiv. Dessverre jobber de fleste OEM-er allerede minst én telefon foran der vi er akkurat nå. Fokuset deres er på den neste telefonen de er i ferd med å selge – du kan egentlig ikke klandre dem, siden de kun tjener penger på enheter de selger. De tjener ingen penger på enheter de solgte for et eller to år siden, så de må fortsette å gi ut nye enheter for å eksistere. Dette er en av grunnene til at HTC og Blackberry er i trøbbel - det spiller ingen rolle hvor mange ledere som beholder et dødsgrep om sin gamle Blackberry Curve, siden de ikke får salg av nye enheter der.
Hvis OEM ikke får en BSP, kommer de ikke til å gå ned på XDA-tilnærmingen med å hacke sammen en build. Hvorfor? Vi vil, de må støtte denne fastvaren for kundene sine. Hvis de slipper en firmware som er halvarbeidende, vil brukerne hate dem, og rave og rave, og holde støttelinjene deres i gang i flere dager.
OEM-er må også kjempe med transportører, i hvert fall i ikke-europeiske markeder. Operatører vil ikke at kunder skal ha problemer med programvareoppdateringer. Faktisk vil operatører ofte heller ikke gi ut programvareoppdateringer.
For å forstå dette, se for deg din store tante Alice. Det er hun som ringer deg til upraktiske tider på dagen for å be om hjelp med "den datamaskin-tingen". Du beskriver deretter hvordan du klikker på "Start-menyen", og må identifisere det som det "store flagget nederst i venstre hjørne", og blir møtt med forvirring. Omtrent 45 minutter (og mye frustrasjon) senere kommer det frem at tante Alice har dratt startmenyen til høyre skjermkant, og bare trengte å dra den tilbake. Ja, med venstre museknapp!
Tenk deg nå at du har tusen tante Alice. De ringer alle til kundestøtten din, kan ikke finne Candy Crush på telefonen, bekymret for at en hacker har slettet den fra telefonen. Åh, og ikonene ser litt annerledes ut nå - kanskje hackeren fortsatt er i telefonen deres?
Ja, dette er ment å være litt letthjertet humor, men før du opplever årsakene til at folk vil ringe opp operatøren sin for å få støtte, vil du ikke tro på problemene de har. En programvareoppdatering som endrer hvordan telefonen fungerer, eller hvor ting er, vil føre til en betydelig støtteoverhead. Som et minimum krever det omopplæring av støttepersonell (fordi de fleste av dem ikke er din ivrige XDA-leser, dessverre).
Når OEM får BSP-en, overfører de ROM-en og bruker alle endringene på ROM-en. De vil legge i seg bloatware og legge til et forferdelig tegneserieaktig skinn som ville se mer hjemme i en tenårings anime. Så vil de teste det.
Mye.
Det er alle slags krav telefonen din må overholde. Mobilnettene er laget for å stole på at brukerutstyret (det vi kaller telefonen) oppfører seg riktig. Dette betyr at det er mye testing som trengs for å få enheten godkjent. Programvareoppdateringer risikerer å endre atferd, så ting må testes på nytt. Dette er grunnen til at du ofte vil se informasjon om kommende Sony-programvareoppdateringer fra eksterne testtjenester, som bekrefter at fastvaren er i samsvar med testkravene.
Nå... hva skjer etter en oppdatering eller to (eller i noen tilfeller ingen)? SoC-produsenten vil ikke gi OEM en oppdatert BSP. Tross alt vil ikke SoC-produsenten få mye ut av dette. OEM tjener ikke mer penger på telefonen din siden den ble solgt. Og på dette tidspunktet får ikke telefonen flere større versjonsoppdateringer.
Å kutte ned på antall BSP-er som OEM ønsker levert er en fin måte å spare penger på - hvis du bare trenger den nåværende, og ikke har tenkt å levere noen større versjoner øker, vil dette spare penger på det første SoC-kjøpet og lisensieringen, men på bekostning av noen få sinte nerder på XDA, som lurer på hvorfor de ikke fikk en Oppdater.
Oppdateringer er komplekse. Det er mange forskjellige personer involvert i kjeden. Ingenting av dette unnskylder OEM-er fra den nåværende mangelfulle og patetiske tilstanden til oppdateringer på Android. Likevel er det noen reelle utfordringer her.
Mange OEM-er har skylden for over-lovende, og uunngåelig underlevering som vi nå forbinder. Den triste virkeligheten er at for de fleste OEM-er er programvareoppdateringer bare et irritasjonsmoment de kunne vært uten.
Mobilsektoren sitter stort sett fast i tankegangen til funksjonstelefoner. Det vil si hvor en enhet aldri får noen oppdateringer. Test den en gang, send den og se deg aldri tilbake. Med sikkerhetsproblemene til moderne smarttelefoner, og den rene kompleksiteten ved å kjøre et fullstendig generellt operativsystem, med hundrevis av eksterne biblioteker, er det ikke lenger et alternativ. Eller i det minste det burde ikke være. Google har tatt noen skritt for å fikse dette, ved i det minste å publisere sikkerhetsbulletiner og oppdateringer for eksisterende utgivelser av Android (husk at inntil helt nylig var den eneste måten å få sikkerhetsoppdateringer på via en ny større Android OS-versjon!)
Akk, men dette er egentlig ikke nok. Selv om Google fortsetter å gi ut oppdateringer, er enhetens sikkerhet fortsatt avhengig av SoC-produsenten – siden SoC-produsenter er så forsteinede for noen som oppdager hvordan de slår på et par lysdioder eller lager en lyd gjennom en høyttaler, sender enorme mengder binære blobs på deres enheter. Disse klattene inneholder ganske forferdelig usikker kode (bare ta en titt på tidligere Googles sikkerhetsbulletiner hvis du tror dette er en overdrivelse!), og trenger oppdatering. Det betyr at oppdaterte BSP-er kreves.
Stasjonære datamaskiner (og i forlengelsen, bærbare datamaskiner) er helt annerledes i arkitektur fra mobile enheter. Mobiltelefonen eller nettbrettet ditt er faktisk en tungt proprietær klump silisium, designet i et rush av noen mennesker som mener det godt, men ikke har i nærheten av nok tid til å lage noe godt. Markedet beveger seg så raskt at de knapt klarer å holde tritt med tempoet som markedsføring krever at nye produkter skal lanseres i.
Dette betyr at snarveier er tatt - du vil ikke finne telefonen din støttet av hovedlinjen Linux-kjernen, og du vil finne at hver telefon har en annen måte å starte opp. På den bærbare datamaskinen eller stasjonære datamaskinen, men leverandørene slo seg på noen standard måter å starte opp - tidligere var det MBR (master boot record) med en BIOS, og nå er det UEFI. Denne standardiseringen gjør det mulig å kjøre samme programvare på hver enhet.
Selv om det har vært noen skritt mot dette nylig, spesielt med Sonys oppsøkende program og deres enhetlig kjerne, er det ikke praktisk å kjøre en hovedlinjekjerne på de fleste telefoner, på grunn av det store antallet nye leverandørspesifikke hacks introdusert til hver enhet.
Har du koblet hodetelefonkontakten feil vei? Bare hack det i driverne! Det er ikke tid til å fikse det i produksjonsdesignet.
Produksjonsteamet har montert kameramodulen opp ned i produksjonsbatch 1? Kast et hack inn for å sjekke den interne versjonskoden, og snu videoen om det er versjon 1!
Hacks som disse løser det umiddelbare problemet, men skraper bare overflaten av de rare og produktspesifikke endringene som skjer. Pokker, det er til og med noen ganger helt forskjellige brikker i forskjellige revisjoner av den samme telefonen, på grunn av kommersielle beslutninger. Disse fører til hacks i drivere og rare beslutninger som bare ga mening på det tidspunktet, for å få telefonen til å fungere slik at den kan sendes neste uke.
Selv om det pågår arbeid med hovedlinjestøtte for 64-biters ARM-brikker for å starte opp med UEFI, har det så langt vært ingen tydelig bevegelse mot en mer standardisert måte å starte ARM-enheter på. Og det er trist, for det betyr at telefoner vil fortsette å bli kastet ut i god tid før slutten av deres arbeidsliv, fordi det rett og slett er for dyrt å opprettholde den tekniske gjelden og byrden på deres programvare.
På den annen side, hvis en OEM bare vil tjene penger på salg av en enhet, trenger de ikke å sikre at folk fortsetter å kjøpe nye telefoner? Ville PC-markedet flyttet til denne modellen hvis det ikke var 30 år med fart og eldre programvare der ute allerede ved bruk av den åpne PC-plattformen og standarden?
Dette er et vanskelig spørsmål uten innsidekunnskap fra Qualcomm, som vi dessverre ikke har for øyeblikket. Vi kan imidlertid trekke noe informasjon fra 7.0 Android driver API og CTS kravene. CTS-kravene spesifiserer hva Google forventer av en enhet som kjører en gitt fastvare. Den "store hammeren" som brukes til å håndheve disse kravene er Googles lisens til å bruke deres proprietære Google Play Services-pakke - hvis du ikke overholder kravene, kan du ikke sende Google Apps på enheten. Mens, for noen, dette kan ses på som en fordel, dette er åpenbart ikke hva brukerne ønsker og forventer av en enhet.
Android 7.0 har ikke lagt til mye i form av endringer i HAL eller drivere (som beskrevet ovenfor), så det er usannsynlig at inkompatibilitet kommer derfra spesifikt. Det som er mer sannsynlig å utgjøre et problem, er imidlertid introduksjonen av en nytt krav for enten Vulkan graphics API eller GLES 3.1, å være tilgjengelig for å bestå CTS.
For tiden har mange Systems-on-Chip (SoCs) ikke hatt Vulkan-støtte på grafikkprosessoren, inkludert MSM8974. Det er også mest sannsynlig her problemet med kompatibilitet med Android 7.0 vil oppstå. Men igjen, uten innsidekunnskap fra Qualcomm, og deres fremtidige planer, er det vanskelig for oss å gi en definitiv uttalelse uten å kvalifisere den. For øyeblikket tror vi imidlertid det er sannsynlig at dette er det "enkle" tilfellet med at Qualcomm slutter å støtte for det (i deres øyne) aldrende MSM8974-brikkesett, og ikke gir en BSP (kortstøttepakke) for 7.0 på den plattformen. Hvis det var tilfelle, ville det bety at OEM-er nesten ville være sikre på ikke å sende 7.0 på enheten - de måtte på en eller annen måte finne Vulkan eller GLEs 3.1-støtte for GPUen og GPU-kilden deres koden er en av de latterlig tett bevoktede delene av mobilstablene (uten egentlig grunn, vil vi legge til - se AMD, åpner deres egen AMDGPU-driver på skrivebordet for Linux). Dessverre er imidlertid Vulkan og akselerert (GLES) grafikk generelt litt mer kompleks enn en enkel LED, så dette er ikke noe vi kommer til å se shims å introdusere kompatibilitet for.
Siden 7.0 ikke har vært ute på lenge, er det en reell mulighet for at andre brikkesett (annet enn det lille antallet i AOSP selv) blir igjen bak på 6.0, på grunn av enten maskinvare- og driverproblemer (dvs. ingen oppdatert BSP) eller mangel på SoC-leverandørstøtte med hensyn til Vulkan eller GLES 3.1 API. Foreløpig støtter verken Snapdragon 800 eller 801 en av disse.
Det beste alternativet er å se denne plassen – Utviklere på XDA gjør allerede gode fremskritt med uoffisielle porter til 7.0 for mange av enhetene som ikke får offisiell 7.0-støtte fra Google. Disse er imidlertid uten Vulkan eller GLES 3.1-støtte - kanskje utviklere av spill på Android vil begynne å gjøre det oppleve frustrasjon gjennom fragmentering hvis nok brukere begynner å kjøre tilpassede ROM-er uten Vulkan eller GLES 3.1 Brukerstøtte?
Apple har en tendens til å støtte iPhone-serien deres på den nyeste iOS-versjonen i rundt 5 år - iPhone 4s ble lansert i oktober 2011, og har blitt holdt oppdatert til iOS 9. Den vil imidlertid ikke motta den kommende iOS 10-oppdateringen, noe som vil gi telefonen en effektiv levetid på 5 år, forutsatt at iOS 10 lanseres rundt oktober. Det er verdt å merke seg at Apple ikke alltid støtter grafikk-API-støtte – iPhone 4s og iPhone 5 gjør det ikke har Apples Metal graphics API, som er et noe lignende scenario som det man ser med Android i Vulkan. Den eneste forskjellen er at Apple fortsatte å støtte de eldre enhetene uten den nye grafikk-APIen.
Hva tror du? Vil du flashe en tilpasset ROM på telefonen for å forlenge levetiden? Har du sagt i kommentarfeltet nedenfor.