I början av varje månad släpper Google månaden Android säkerhetsbulletin och börjar skicka uppdateringar till Pixel-telefoner. Det är bra att företaget är transparent med vad som pågår och hur saker åtgärdas även om du inte är den typen av person som gillar att läsa källkoden.
Det är mycket arbete som går in i dessa patchar innan de offentliggörs, och det är ännu mer arbete inblandat innan det kommer till andra telefoner - om det alls kommer. Låt oss ta en titt på hur korven är gjord 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 5 miljoner rader kod finns det för att hjälpa företag som gör mobilprodukter att komma igång med en komplett applikationsplattform inklusive tillgång till Google Play och andra tjänster. Det är inget som kan användas som det är; dessa företag spenderar mycket tid på att försöka få Android skräddarsydd för att smälta in i den andra mjukvaran de kanske använder för att skapa ett snyggt homogeniserat operativsystem.
Google har några regler om hur detta ska göras om ett företag skulle vilja inkludera sina tjänster, men tillverkarna har ett långt koppel på hur den slutliga produkten är byggd.
Den här koden är där en säkerhetskorrigering kommer till liv. Någon, oavsett om det är en säkerhetsforskare eller bara en vanlig Joe, hittar ett fel i en telefon som kan användas för att minska enhetens säkerhetslager. Om det felet inte är något som en OEM skapat, får Android-teamet i uppdrag att 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 ett säkerhetsfel hittas och det är en del av Android-baskoden måste Google åtgärda det och sedan skicka det till alla andra.
Ofta är felet inte något Google kan åtgärda. Precis som vi 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 använda komponenterna kommer att behöva göra ändringar först. Om så är fallet vidarebefordras dessa ändringar till Google så att den kan se vad som behöver göras för att ta emot dem i Androids kod.
Dessa ändringar tar tid, särskilt om en hårdvaruleverantör är inblandad. Det finns patchning och testning och mer patchning och mer testning för varje brist som åtgärdas i en patch. När Google är övertygad om att de har en giltig lösning för ett säkerhetsbrist, kommer alla företag som tillverkar Android telefoner ges tidig åtkomst (minst 30 dagar innan patchen offentliggörs av Google) så att de kan komma till arbete.
Fas två
Det är här det mesta av arbetet görs. Google kan skriva och underhålla Android själv, men de flesta enheter som använder det är inte tillverkade av Google. De som är — Pixel-telefoner — ingår också här. Googles hårdvara är kund hos Android på samma sätt Samsung eller Motorola är.
Mobilindustrins Samsung och LG, som gör många förändringar i Android, har mycket arbete inblandat när det är dags att slå ihop en patch.
Alla dessa företag får arbeta med ett par saker så fort de har ny kod från Google. Den första - och möjligen viktigaste - delen är att bestämma vilken del av plåstret som inte behövs. Och det finns massor av saker i varje patch som ett enskilt företag fritt kan ignorera.
Till exempel om NVIDIA var tvungen att göra ändringar som trycks tillbaka till Android, inga Samsung-telefoner kommer att behöva den delen av patchen. Ett mer extremt exempel skulle vara de förä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 inte kan vara tidskrävande, särskilt när ett företag gör stora förändringar i vissa delar av operativsystemet. Google undersökte anklagelser om att OEM-tillverkare skickade säkerhetskorrigeringar som inte behandlade vissa saker de borde ha, och det här är vad de hittade.
Inte varje del av en patch behövs på varje telefon.
När det är gjort måste resten av patchen slås samman till en leverantörs anpassade Android-kod och sedan byggas och testas. Den "byggda och testade" delen kan bli en stor huvudvärk om patchen inte bara kan appliceras eftersom den rör filer som anpassad kod använder eller är beroende av. Det ser vi också mycket. Närhelst Bluetooth eller Wi-Fi patchas, oavsett om det är hårdvaran eller mjukvaran bakom dem, kommer det att göra det pekkod som har ändrats av en stor OEM som gör ett snyggare operativsystem än "lager" Android. Det finns många delar av Android som en OEM kan röra.
När ingenjörerna på Samsung eller en annan leverantör får ett operativsystem som startar upp och körs, måste det testas. Och testade lite till. Testet kan innefatta att få nätverksingenjörer från olika operatörer inblandade, samt att få Google och/eller tillverkaren av någon komponent tillbaka i mixen. Det måste vara rätt. En patch som skickas ut till tusentals och åter tusentals telefoner kan potentiellt lamslå en operatörs nätverk, äta upp varje användares datalock, eller till och med få själva telefonen att sluta fungera. Allt sådant är oacceptabelt och har att hittas innan den lämnar byggnaden.
Utrullningen
Företaget som fick din telefon, Google och kanske din operatör att samarbeta för att få en massvis uppdatering klar. Om du någonsin har sett webbadressen som används för att ladda ner en patch, kommer du att märka att den har "Google" i webbadressen. Det beror på att motorn inuti din telefon som kan hämta och bearbeta en OTA-uppdatering letar på en mycket specifik plats efter en patch. Den måste veta att patchen är 100 % korrekt och signerad med rätt digital signatur. Det kommer att kontrollera detta igen när patchen är helt nedladdad.
Om du har köpt din telefon från en operatör har den gott om input under hela en patchs livstid.
Din operatör kan ha vissa regler om när och vem som kan ladda ner en patch när den är live om deras namn står på telefonen. Företag som Samsung eller LG gör skräddarsydda versioner av sina mest populära modeller för varje operatör, vilket har massor av input till hur saker och ting görs. Det borde det eftersom namnet står på kartongen. Detta kan vara frustrerande, men det är vettigt. Om alla i Pittsburgh (till exempel) som har en Samsung Galaxy S8-telefon försöker hämta en 800MB patch samtidigt, kommer nätverket att falla sönder. 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 håll på OTA-utrullningar. 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 eller dålig upplevelse. Om allt går bra kommer ett större antal användare att få patchen i en andra våg. Detta upprepas flera gånger innan slussarna öppnas. Användare som inte vill vänta på detta slutliga test kan manuellt ladda ner en patch via sina enhetsinställningar.
När det är din tur och du gav din telefon grönt ljus för att ta den filen, laddas den ner och sedan tar din telefon kontrollen.
I dina händer
En patch laddas ner till din telefon och verifieras som den rätta. Äldre versioner av Android har en dedikerad cache, vilket är en del av ditt lagringsutrymme som har delats av för att saker som en uppdateringsfil ska kunna leva; saker som bara är tillfälligt på telefonen. Telefoner som använder Androids sömlösa uppdateringsfunktion (vilket borde vara de flesta telefoner som kör Android Nougat när de säljs) "slipa" de nedladdade filerna till det som kallas slots. I båda fallen måste du ha tillräckligt med utrymme för att OTA-filen ska extraheras och bearbetas.
Telefoner med äldre versioner av Android kan ha en dedikerad cachepartition som används under en uppdatering. Den måste vara 2,5 gånger större än OTA-filen du laddade ner.
OTA-uppdateringsprogrammet i din telefon är en del av Android. Ett skript i den nedladdade filen talar om hur det ska gå tillväga för att hitta de filer som behöver ändras och det kopierar dessa filer antingen till din enhets cache eller till den avsedda plats. Den jämför sedan originalfilerna på din telefon med filerna som har laddats ner. Vissa kan vara ett enkelt byte - ta fil X från telefonen och ta bort den, ersätt den sedan med fil X från OTA-nedladdningen. Andra är inte hela filen och innehåller bara små specifika ändringar. Uppdateraren och installationsprogrammet i din telefon vet vad du ska göra här.
Många filer i Android, särskilt applikationer och programbibliotek, är verkligen många filer komprimerade till ett speciellt arkiv. Du kan ta en APK-fil och ändra den till en .zip-fil och öppna den med Windows. Ibland måste dessa arkiv öppnas och delar av dem måste bytas ut mot nya versioner som laddats ner för säkerhetskorrigeringen. Det är därför du behöver det arbetsutrymmet i din cachepartition - 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 bearbetats och ändringar gjorts i kopior av systemfiler, är det dags att köra systemet med dem. Detta händer när telefonen ber dig att starta om efter att den har behandlat OTA du fått eftersom det ofta finns filer som behöver korrigeras men som används medan telefonen är igång. Du kan se en skärm som visar att det pågår arbete under omstarten eller så kanske du bara ser Android-logotypen. I båda fallen kontrolleras filerna, flyttas på plats och kontrolleras igen. De gamla filerna förvaras i cachen ifall det skulle uppstå ett 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 som du vill ha det, och att du har ett nyare datum för säkerhetskorrigeringsversionen i inställningarna på din telefon. Nu är du redo för nästa uppdatering!