Innehållsförteckning:
I början av varje månad släpper Google den månatliga säkerhetsbulletinen för Android och börjar skicka uppdateringar till Pixel-telefoner. Det är fantastiskt att företaget är transparent om vad som händer och hur saker fixas även om du inte är den typ av person som gillar att läsa källkoden.
Det finns mycket arbete som går in i dessa korrigeringar innan de offentliggörs, och det är ännu mer arbete involverat innan det kommer till andra telefoner - om det alls kommer. Låt oss ta en titt på hur korven tillverkas och försöka få en bättre förståelse för varför tidslinjen för säkerhetslappar är lite suddig.
Först fixar du Android
Android är ett komplicerat odjur. Över fem miljoner kodrader finns det för att hjälpa företag som får mobilprodukter att komma igång med en komplett applikationsplattform inklusive åtkomst till Google Play och andra tjänster. Det är inte något som kan användas som det är; dessa företag tillbringar mycket tid på att försöka få Android skräddarsydda för att smälta in i den andra programvaran de kan använda för att skapa ett trevligt homogeniserat operativsystem.
Google har några regler om hur detta ska göras om ett företag vill inkludera sina tjänster, men tillverkarna har en lång koppel på hur slutprodukten byggs.
Denna kod är där en säkerhetsuppdatering kommer till liv. Någon, vare sig det är en säkerhetsforskare eller bara en genomsnittlig Joe, hittar en brist i en telefon som kan användas för att minska enhetens säkerhetslager. Om den bristen inte är något som en OEM skapat, får Android-teamet ta reda på vad som händer, varför det händer och hur man fixar det på det minst störande sättet.
Om det finns en säkerhetsfel och det är en del av bas Android-koden måste Google fixa den och sedan skicka den till alla andra.
Ofta är bristen inte något som Google kan fixa. Liksom oss har Google inte tillgång till firmware från företag som tillverkar hårdvara som Qualcomm eller LG. Om felet måste åtgärdas på hårdvarunivå finns det en god chans att företaget som levererar några av de komponenter som används måste göra ändringar först. Om så är fallet vidarebefordras dessa ändringar till Google så att det kan se vad som behöver göras för att anpassa dem till Android: s kod.
Dessa ändringar tar tid, särskilt om en hårdvaruförsäljare är involverad. Det finns lappning och testning och mer lappning och mer testning för varje fel som behandlas i en lapp. När Google är säker på att de har en giltig korrigering för en säkerhetsbrist får varje företag som tillverkar Android-telefoner tidig åtkomst (minst 30 dagar innan korrigeringen offentliggörs av Google) så att de kan börja arbeta.
Fas två
Det är här de flesta av arbetena görs. Google kan skriva och underhålla Android själv, men huvuddelen av enheter som använder den tillverkas inte av Google. De som är - Pixel-telefoner - ingår också här. Googles maskinvara är kund hos Android på samma sätt som Samsung eller Motorola.
Samsungs och LG: s inom mobilindustrin, som gör en hel del förändringar i Android, har mycket arbete involverat när det är dags att slå samman en patch.
Alla dessa företag kommer att arbeta med ett par saker så snart de har ny kod från Google. Den första - och kanske viktigaste delen - är att bestämma vilken del av lappen som inte behövs. Och det finns många saker i varje patch som ett enda företag fritt kan ignorera.
Om NVIDIA till exempel måste göra ändringar som skjuts tillbaka till Android kommer inga Samsung-telefoner att behöva den delen av korrigeringen. Ett mer extremt exempel skulle vara de ändringar som BlackBerry eller Samsung gjorde som redan åtgärdar problemet på ett annat sätt. Att ta reda på vad som behövs och vad som inte är kan vara tidskrävande, särskilt när ett företag gör stora förändringar av vissa delar av operativsystemet. Google undersökte anklagelser om att OEM: er skickade säkerhetspatcher som inte behandlade vissa saker de borde ha, och det är vad den hittade.
Inte varje del av en lapp behövs på varje telefon.
När detta är gjort måste resten av korrigeringen slås samman till en leverantørs anpassade Android-kod och sedan byggas och testas. Den "inbyggda och testade" delen kan bli en stor huvudvärk om korrigeringen inte bara kan appliceras eftersom den rör vid filer som anpassad kod använder eller beror på. Det ser vi också mycket. När Bluetooth eller Wi-Fi korrigeras, oavsett om det är hårdvaran eller programvaran bakom dem, kommer det att beröra koden som har förändrats av en stor OEM som gör ett smartare operativsystem än "lager" Android. Det finns många delar av Android som en OEM kan röra.
När ingenjörerna hos Samsung eller en annan leverantör har fått ett operativsystem som startar upp och körs måste det testas. Och testade lite mer. Testningen kan inkludera att få nätverksingenjörer från olika operatörer involverade, samt att ha Google och / eller tillverkaren av någon komponent tillbaka i blandningen. Det måste vara rätt. En lapp som skickas till tusentals och tusentals telefoner kan potentiellt lamslå en operatörs nätverk, äta upp varje användares datakapsel eller till och med få telefonen att sluta fungera. Allt sådant är oacceptabelt och måste hittas innan det lämnar byggnaden.
Utrullningen
Företaget som gjorde din telefon, Google och kanske din operatör arbetar tillsammans för att få en massa uppdatering klar. Om du någonsin har sett URL: en som används för att ladda ner en patch, kommer du att märka att den har "Google" på webbadressen. Det beror på att motorn inuti din telefon som kan hämta och bearbeta en OTA-uppdatering letar efter ett mycket specifikt ställe för en patch. Det måste veta att korrigeringen är 100% korrekt och signerad med rätt digital signatur. Det kommer att kontrollera detta igen när patch har laddats ner.
Om du köpte din telefon från en transportör har den massor av input under hela en patch.
Din operatör kan ha några regler om när och vem kan ladda ner en patch när den är live om deras namn finns på telefonen. Företag som Samsung eller LG gör anpassade versioner av sina mest populära modeller för varje operatör, som har gott om input till hur saker och ting görs. Det borde eftersom namnet finns i rutan. Detta kan vara frustrerande, men det är meningsfullt. Om alla i Pittsburgh (till exempel) som har en Samsung Galaxy S8-telefon försöker hämta en 800MB-lapp på samma gång kommer nätverket att smulas in i fläckar. Din operatör kommer att göra allt den behöver göra för att hålla nätverket vid liv.
Google lägger också ett slags grepp om OTA-lanseringar. Ett specifikt antal användare kommer att få en patch, och efter en viss tid avgör Google om dessa användare hade en bra upplevelse eller en dålig. Om allt går bra kommer ett större antal användare att få korrigeringen i en andra våg. Detta upprepas flera gånger innan översvämningsportarna öppnas. Användare som inte vill vänta på den slutliga testen kan ladda ner en patch manuellt via sina enhetsinställningar.
När det är din tur och du gav din telefon grönt ljus för att ta tag i den filen, laddas den ner och sedan tar din telefon kontroll.
I dina händer
En lapp laddas ner till din telefon och verifieras som rätt saker. Äldre versioner av Android har en dedicerad cache, som är en del av din lagring som har delats upp för att saker som en uppdateringsfil ska leva; saker som bara är tillfälligt på telefonen. Telefoner som använder Android: s sömlösa uppdateringsfunktion (som borde vara de flesta telefoner som kör Android Nougat när de säljs) "glider" de nedladdade filerna i det som kallas slots. I båda fallen måste du ha tillräckligt med utrymme för att OTA-filen ska kunna extraheras och bearbetas.
Telefoner med äldre versioner av Android kan ha en dedicerad cache-partition som används under en uppdatering. Den måste vara 2, 5 gånger större i storlek än OTA-filen som du laddade ner.
OTA-uppdateringsprogramvaran i din telefon är en del av Android. Ett skript i den nedladdade filen berättar hur det går till att hitta de filer som behöver förändras och det kopierar dessa filer antingen till din enhetscache eller i det angivna kortplatsen. Därefter jämförs originalfilerna på din telefon med filerna som har laddats ner. Vissa kan vara en enkel byte - ta fil X från telefonen och ta bort den och ersätt den sedan med fil X från OTA-nedladdningen. Andra är inte hela filen och innehåller bara små specifika förändringar. Uppdaterings- och installationsprogramvaran i din telefon vet vad du ska göra här.
Många filer i Android, särskilt applikationer och programvarubibliotek, är verkligen många filer som komprimeras till ett speciellt arkiv. Du kan ta en APK-fil och ändra den till en.zip-fil och öppna den med Windows. Ibland behöver dessa arkiv öppnas och delar av dem måste bytas ut med nya versioner som laddas ner för säkerhetsuppdateringen. Det är därför du behöver det arbetsutrymmet i din cache-partition - det är där dessa filer extraheras.
Många filer på din telefon är verkligen arkiv som innehåller många filer - inklusive andra arkiv med filer. Det är komplicerat.
När varje fil i OTA-uppdateringen har behandlats och ändringar gjorts i kopior av systemfiler är det dags att köra systemet med dem. Detta händer när telefonen ber dig starta om efter att den behandlar OTA som du fick eftersom det ofta finns filer som måste lappas men som används medan telefonen körs. Du kan se en skärm som visar att det pågår arbete under omstarten, eller så kan du se Android-logotypen. I båda fallen kontrolleras filer, flyttas på plats och kontrolleras igen. De gamla filerna förvaras i cachen för att det skulle vara något problem och du inte kan starta med de nya filerna.
Allt som återstår är för dig att se till att allt fortfarande är precis hur du gillar det, och att du har ett nyare datum för versionen av säkerhetspatch i telefonens inställningar. Nu är du redo för nästa uppdatering!
