Indholdsfortegnelse:
I begyndelsen af hver måned frigiver Google den månedlige Android Security Bulletin og begynder at sende opdateringer til Pixel-telefoner. Det er dejligt, at virksomheden er gennemsigtig over, hvad der foregår, og hvordan tingene løses, selvom du ikke er den type person, der kan lide at læse kildekoden.
Der er meget arbejde, der går i disse programrettelser, før de offentliggøres, og der er endnu mere arbejde involveret, inden det kommer til andre telefoner - hvis det overhovedet kommer. Lad os tage et kig på, hvordan pølsen er lavet, og prøv at få en bedre forståelse af, hvorfor tidslinjen for sikkerhedsrettelser er lidt sløret.
Først fikser du Android
Android er et kompliceret udyr. Over 5 millioner kodelinjer findes for at hjælpe virksomheder, der får mobilprodukter til at komme i gang med en komplet applikationsplatform, herunder adgang til Google Play og andre tjenester. Det er ikke noget, der kan bruges som det er; disse virksomheder bruger en masse tid på at få Android skræddersyet til at smelte sammen med den anden software, de muligvis bruger til at skabe et dejligt homogeniseret operativsystem.
Google har nogle regler om, hvordan dette skal gøres, hvis et firma ønsker at inkludere sine tjenester, men producenterne har en lang snor over, hvordan det endelige produkt bygges.
Denne kode er der, hvor en sikkerhedspatch kommer til live. En person, det være sig en sikkerhedsforsker eller bare en gennemsnitlig Joe, finder en fejl i en telefon, der kunne bruges til at mindske enhedens sikkerhedslag. Hvis denne fejl ikke er noget, en OEM har oprettet, får Android-teamet til opgave at finde ud af, hvad der sker, hvorfor det sker, og hvordan man løser det på den mindst forstyrrende måde.
Hvis der findes en sikkerhedsfejl, og det er en del af Android-basiskoden, er Google nødt til at rette den og derefter sende den til alle andre.
Ofte er fejlen ikke noget, som Google kan løse. Ligesom os har Google ikke adgang til firmware fra virksomheder, der fremstiller hardware som Qualcomm eller LG. Hvis fejlen skal løses på hardniveau, er der en god chance for, at det firma, der leverer nogle af de anvendte komponenter, skal foretage ændringer først. Hvis dette er tilfældet, videresendes disse ændringer til Google, så det kan se, hvad der skal gøres for at imødekomme dem i Android's kode.
Disse ændringer tager tid, især hvis en hardwareleverandør er involveret. Der er patchning og test og mere patching og mere test for hver eneste fejl, der adresseres i en patch. Når Google er overbevist om, at de har en gyldig rettelse af en sikkerhedsfejl, får ethvert firma, der laver Android-telefoner, tidlig adgang (mindst 30 dage før opdateringen offentliggøres af Google), så de kan komme på arbejde.
Fase to
Det er her det meste af arbejdet udføres. Google skriver og vedligeholder Android selv, men hovedparten af enheder, der bruger den, er ikke oprettet af Google. De der er - Pixel-telefoner - er også inkluderet her. Google-hardware er en kunde hos Android på samme måde som Samsung eller Motorola.
Samsungs og LGs fra mobilbranchen, der foretager en masse ændringer til Android, har meget arbejde involveret, når det er tid til at flette en patch.
Alle disse virksomheder begynder at arbejde på et par ting, så snart de har en ny kode fra Google. Den første - og muligvis vigtigste - del er at bestemme, hvilken del af plasteret der ikke er behov for. Og der er masser af ting i hver patch, som et enkelt firma frit kan ignorere.
Hvis NVIDIA f.eks. Skulle foretage ændringer, der skubbes tilbage til Android, har ingen Samsung-telefoner brug for den del af patch'en. Et mere ekstremt eksempel ville være de ændringer, som BlackBerry eller Samsung foretaget, og som allerede løser problemet på en anden måde. Find ud af, hvad der er nødvendigt, og hvad der ikke er, kan være tidskrævende, især når et firma foretager store ændringer til visse dele af operativsystemet. Google undersøgte beskyldninger om, at OEM'er sendte sikkerhedsrettelser, der ikke adresserede nogle ting, de skulle have, og det var, hvad den fandt.
Ikke hver del af en patch er nødvendig på enhver telefon.
Når det er gjort, skal resten af patch'en slås sammen til en sælgers tilpassede Android-kode og derefter bygges og testes. Den "indbyggede og testede" del kan blive en stor hovedpine, hvis programrettelsen ikke bare kan anvendes, fordi den berører filer, som brugerdefineret kode bruger eller afhænger af. Det ser vi også meget. Hver gang Bluetooth eller Wi-Fi er rettet, uanset om det er hardware eller softwaren bag dem, vil det berøre kode, der er ændret af et stort OEM, der gør et mere avanceret operativsystem end "lager" Android. Der er mange dele af Android, som en OEM kan røre ved.
Når ingeniørerne hos Samsung eller en anden leverandør har fået et operativsystem, der starter op og kører, skal det testes. Og testet noget mere. Testingen kan omfatte at få netværksingeniører fra forskellige luftfartsselskaber involveret, samt at have Google og / eller producenten af en hvilken som helst komponent tilbage i blandingen. Det skal være rigtigt. Et program, der sendes til tusinder og tusinder af telefoner, kan potentielt ødelægge et luftfartsselskabs netværk, spise op for enhver brugers datahætte eller endda få telefonen til at stoppe med at fungere. Noget af den slags er uacceptabelt og skal findes, før det forlader bygningen.
Udrullingen
Virksomheden, der gjorde din telefon, Google og måske din operatør sammen for at få en masse over-the-air-opdatering klar. Hvis du nogensinde har set den URL, der bruges til at downloade en patch, vil du bemærke, at den har "Google" på webadressen. Det skyldes, at motoren inde i din telefon, der kan hente og behandle en OTA-opdatering, leder efter et meget specifikt sted for en programrettelse. Det skal vide, at programrettelsen er 100% korrekt og underskrevet af den rigtige digitale signatur. Det kontrolleres igen, når patch'en er fuldt downloadet.
Hvis du har købt din telefon fra en transportør, har den masser af input i hele en patch-levetid.
Din operatør har muligvis nogle regler om, hvornår og hvem der kan downloade en patch, når den er live, hvis deres navn er på telefonen. Virksomheder som Samsung eller LG fremstiller brugerdefinerede versioner af deres mest populære modeller til hver operatør, som har masser af input til, hvordan tingene gøres. Det skal da navnet er på kassen. Dette kan være frustrerende, men det giver mening. Hvis alle i Pittsburgh (for eksempel), der har en Samsung Galaxy S8-telefon, forsøger at hente en 800MB-patch på samme tid, vil netværket smuldre i pletter. Din operatør vil gøre alt, hvad den skal gøre for at holde netværket i live.
Google placerer også en slags hold på OTA-rollouts. Et specifikt antal brugere vil modtage en programrettelse, og efter en bestemt tidsperiode bestemmer Google, om disse brugere havde en god oplevelse eller en dårlig enhed. Hvis alt går godt, får et større antal brugere patch i en anden bølge. Dette gentages flere gange, før oversvømmelseshullerne åbnes. Brugere, der ikke ønsker at vente på denne endelige test, kan manuelt downloade en patch gennem deres enhedsindstillinger.
Når det er din tur, og du gav din telefon grønt lys for at få fat i den fil, downloades den, og derefter tager din telefon kontrol.
I dine hænder
En patch downloades til din telefon og bekræftes som den rigtige ting. Ældre versioner af Android har en dedikeret cache, som er en del af dit lager, der er blevet delt fra, så ting som en opdateringsfil kan leve; ting, der kun er midlertidigt på telefonen. Telefoner, der bruger Android's problemfri opdateringsfunktion (som burde være de fleste telefoner, der kører Android Nougat, når de sælges) "glider" de downloadede filer i det, der kaldes slots. I begge tilfælde skal du have plads nok til, at OTA-filen kan udvindes og arbejdes på.
Telefoner med ældre versioner af Android har muligvis en dedikeret cache-partition, der bruges under en opdatering. Den skal være 2, 5 gange større i størrelse end den OTA-fil, du har downloadet.
OTA-opdateringssoftwaren på din telefon er en del af Android. Et script i den downloadede fil fortæller det, hvordan man finder ud af, hvilke filer der skal ændres, og det kopierer disse filer enten til enhedens cache eller i det angivne slot. Derefter sammenligner de originale filer på din telefon med de filer, der er blevet downloadet. Nogle kan være et simpelt swap - tag fil X fra telefonen og slet den, og erstatt den derefter med fil X fra OTA-download. Andre er ikke den fulde fil og indeholder kun små specifikke ændringer. Opdaterings- og installationssoftwaren på din telefon ved hvad de skal gøre her.
Mange filer i Android, især applikationer og softwarebiblioteker, er virkelig en masse filer komprimeret til et specielt arkiv. Du kan tage en APK-fil og ændre den til en.zip-fil og åbne den med Windows. Nogle gange skal disse arkiver åbnes, og dele af dem skal udskiftes med nye versioner, der er downloadet til sikkerhedsrettelsen. Derfor har du brug for det arbejdsområde i din cache-partition - det er her, disse filer udvindes.
En masse filer på din telefon er virkelig arkiver, der indeholder mange filer - inklusive andre arkiver med filer. Det er kompliceret.
Når hver fil i OTA-opdateringen er behandlet og ændringer foretaget til kopier af systemfiler, er det tid til at køre systemet med dem. Dette sker, når telefonen beder dig om at genstarte, efter at den behandler OTA, du har modtaget, fordi der ofte er filer, der skal lappes, men er i brug, mens telefonen kører. Du kan muligvis se en skærm, der viser, at der er arbejde, der foregår under genstart, eller du kan muligvis bare se Android-logoet. I begge tilfælde kontrolleres filer, flyttes på plads og kontrolleres igen. De gamle filer opbevares i cachen, hvis der er et problem, og du kan ikke starte med de nye filer.
Alt, hvad der er tilbage, er for dig at sikre dig, at alt stadig er, hvordan du kan lide det, og du har en nyere dato for versionen af Security Patch i indstillingerne på din telefon. Nu er du klar til næste opdatering!
