Android 16 kommer med en av de forbedringene som ved første øyekast virker små, men som i hverdagen kan utgjøre en stor forskjell: Appoppdateringer blir nesten umiddelbare og mye mindre irriterende.Takket være en kombinasjon av systemendringer og nye funksjoner for appinstallasjon, ønsker Google at telefonen din alltid skal være oppdatert uten at du føler at noe fryser konstant.
Bak denne smidigere opplevelsen er det flere tekniske komponenter som jobber i bakgrunnen: de nye «sømløse applikasjonsoppdateringene», flyttingen av prosesser som dexopt og dex2oat, og den såkalte skybyggingenAlt dette kommer i tillegg til andre viktige endringer i Android 16 som påvirker utviklere, ytelse, sikkerhet, personvern, digital helse og kompatibilitet med flere skjermformater. La oss ta en klar og direkte titt på nøyaktig hva som endres.
Hva er sømløse appoppdateringer i Android 16?
Hovedideen bak Android 16 på dette området er klar: for å sikre at appoppdateringer har minst mulig innvirkning på normal mobiltelefonbrukFrem til nå har systemet måttet «fryse» en app i en kort periode hver gang den ble oppdatert mens den erstattet kode og interne ressurser. Dette forhindret at den kjørte parallelt for å unngå feil, datafeil eller uventede nedstengninger.
Ese En midlertidig frysing var fornuftig fra et stabilitetssynspunkt.Men i praksis kunne det være litt av en plage. I store eller systemkritiske apper var den frysingen på flere sekunder nok til å føre til at andre apper som var avhengige av dem, oppførte seg merkelig, ble sittende fast i venting eller til og med viste sporadiske feil.
Med Android 16 tar Google et nytt steg og tar i bruk konseptet mer aggressivt. sømløse appoppdateringerMålet er ikke bare å gjøre oppdateringen kortere, men også å redusere tiden en app er helt inaktiv til et minimum som mulig, nesten til det punktet at den er umerkelig for brukeren.
Ifølge informasjon fra Google gjennom offisielle kilder, Perioden en app forblir frossen under en oppdatering har gått fra «flere sekunder» til «titalls millisekunder»I praksis snakker vi om et hopp fra en pause du tydelig la merke til, til en flimring som du i mange tilfeller ikke engang oppfatter.
Hvordan Android 16 fremskynder appoppdateringer
For å oppnå denne aggressive reduksjonen i nedetid, tyr ikke Android 16 til overfladiske triks. Det den gjør er å omorganisere svært tunge interne oppgaver og flytte dem frem til et stadium før installasjonen.så den «kritiske» perioden der appen må fryses blir mye kortere.
De to viktigste delene her er dexopt og dex2oatDette er verktøy i Android Runtime (ART)-miljøet som er ansvarlige for å optimalisere applikasjonsbytekode. Tradisjonelt ble noe av arbeidet deres utført nettopp i løpet av intervallet da appen var satt på pause, noe som i noen tilfeller forlenget frysetiden med flere sekunder.
Med Android 16, Disse prosessene flyttes til en tidligere fase av oppdateringsflytenMed andre ord utfører systemet mesteparten av optimaliseringen før det når punktet der det må erstatte gamle filer med nye. Når den kritiske pausen inntreffer, er alt som gjenstår å utføre en rask filbytte, noe som reduserer frysetiden til bare noen få titalls millisekunder.
Fordelen med denne tilnærmingen er todelt: på den ene siden, Brukeren oppfatter oppdateringen som nesten umiddelbar. fordi appen knapt slutter å være tilgjengelig; på den annen side opprettholdes det samme sikkerhetsnivået og konsistensen i dataene, siden valideringene og optimaliseringene fortsetter å bli gjort, bare på et mindre ubeleilig tidspunkt i prosessen for brukeropplevelsen.
Reell effekt for brukere med mange apper og for beskjedne mobiltelefoner
På en mobiltelefon med få lette applikasjoner kan disse endringene gå noe ubemerket hen. Hvis du bare bruker noen få apper som oppdateres av og til og bruker få ressurser, har du kanskje aldri følt at oppdateringer var et problem.Men bildet endrer seg betraktelig når vi snakker om enheter med dusinvis av apper, tunge spill eller tjenester som oppdateres ofte.
På telefoner der mange apper brukes intensivt, Å redusere nedetiden mellom oppdateringer betyr færre korte frysinger, færre rare grensesnitthopp og en mye jevnere helhetsopplevelse.Videre, hvis noen av disse appene fungerer som en sentral tjeneste eller tilbyr API-er til andre applikasjoner (for eksempel meldingsklienter, sikkerhetsbiblioteker eller systemapper), hjelper det å minimere frysing av dem under oppdateringer med at hele appkjeden fortsetter å fungere normalt.
Denne utviklingen er også spesielt interessant for enheter i inngangsklassen eller lavere mellomklasseder maskinvaren sliter med å håndtere store installasjoner. Google omorganiserer ikke bare lokale prosesser, men kobler også denne forbedringen til en annen viktig funksjon i Android 16: skykompilering for å akselerere installasjonen av nye apper, noe som revolusjonerer mindre kraftige telefoner.
Skykompilering: apper som installeres raskere takket være skyen
I tillegg til å øke hastigheten på oppdateringer, har Android 16 en funksjon fokusert på første installasjon av applikasjoner og spill, spesielt på beskjedne enheterDenne funksjonen er kjent som skykompilering, og dens oppgave er klar: å overføre noe av det tunge arbeidet som tidligere falt utelukkende på telefonens prosessor og lagring til Googles servere.
Når du installerer en app på Android, bruker systemet ART til å kjøre koden. Under installasjonen tar dex2oat-verktøyet APK-filenes .dex-filer, som inneholder den kompilerte koden, og genererer flere "applikasjonsartefakter".Disse artefaktene hjelper appen med å åpne og kjøre raskere og mer effektivt, og kan komme i forskjellige formater: .vdex-filer med metadata for å validere bytekoden, .odex-filer med forhåndskompilert kode for spesifikke metoder, eller .art-filer med interne representasjoner av strenger og klasser som fremskynder appens oppstart.
På de kraftigste mobiltelefonene, Generering av disse artefaktene er relativt raskt, nesten transparent.Men på billige telefoner, med trege prosessorer og tregt minne, kan denne prosessen bli en flaskehals, spesielt hvis APK-en inneholder mange .dex-filer eller er et veldig stort spill eller en veldig stor app.
Android 16s forslag er enkelt, men effektivt: I stedet for å generere alle disse artefaktene på enheten, last dem ned som allerede er forhåndskompilert fra Google Play.I dag har de fleste brukere rimelig raske mobil- og Wi-Fi-tilkoblinger, så i mange tilfeller er det mer effektivt å bruke nettverket enn å tvinge telefonens prosessor til å jobbe i flere sekunder eller til og med minutter.
SDM og forhåndskompilerte artefakter: rollen til Secure Dex Metadata
Android 16-skybygget er avhengig av en ny filtype: SDM står for Secure Dex MetadataDisse SDM-filene, som lastes ned sammen med APK-en fra Play Store, inneholder applikasjonsartefaktene som allerede er generert i Googles infrastruktur ved hjelp av dex2oat, slik at enheten ikke trenger å gjenta dette arbeidet lokalt.
En viktig detalj er det SDM-filer er signert med samme nøkkel som APK-enDette lar systemet bekrefte at artefaktene kommer fra en pålitelig kilde og ikke har blitt endret, noe som sikrer integriteten og sikkerheten til prosessen. På denne måten kan telefonen installere applikasjonen direkte ved hjelp av disse forhåndskompilerte artefaktene, noe som øker hastigheten på den første installasjonen betydelig, spesielt på avansert maskinvare.
I praksis betyr dette det Android 16 kan i mange tilfeller forhindre at dex2oat kjører under installasjonFordi det harde arbeidet allerede er gjort på Googles servere, blir resultatet mindre belastning på prosessoren, mindre strømforbruk under installasjon og kortere ventetider ved nedlasting av store apper eller spill med betydelige mengder kode.
Hele dette systemet krever imidlertid at Google konfigurerte Play-butikken til å generere og distribuere disse SDM-ene i massevis.I de innledende fasene kan funksjonen være tilstede i systemet, men ikke fullt aktiv, nettopp fordi skyinfrastrukturen må justeres og rulles ut gradvis. Ikke forvent umiddelbare mirakler på alle kompatible enheter; adopsjonen vil være progressiv.
Forholdet mellom raske oppdateringer og skybygging
Selv om de kan virke som to separate ting, Sømløse oppdateringer og skybygging er nært knyttet sammen Fordi begge dreier seg om hvordan og når apputførelsesartefakter genereres og brukes. På den ene siden fremskynder Android 16 kjøringen av dexopt og dex2oat til mindre kritiske faser av oppdateringsprosessen, noe som minimerer tiden appen forblir frossen.
Videre Skykompilering betyr at dette arbeidet i mange tilfeller ikke engang trenger å gjøres på enheten.Dette gjelder både under den første installasjonen og i visse oppdateringer. Ved å laste ned bruksklare artefakter, gjør kombinasjonen av begge tilnærmingene både den første installasjonen og påfølgende oppdateringer raskere og mindre påtrengende.
Alt dette er i tråd med et grunnleggende mål: Optimaliser Android for å kjøre problemfritt selv på moderat maskinvaresamtidig som nedetid reduseres og bivirkningene oppdateringer kan ha på andre apper og tjenester reduseres.
Andre endringer i Android 16 som påvirker ytelse og opplevelse
Forbedringer i oppdateringer og installasjoner kommer ikke alene. Android 16 inkluderer en lang liste med atferdsendringer som De påvirker både apper som er rettet mot den nye versjonen (targetSdkVersion 36) og selve operativsystemet.Mange av dem er ikke direkte relatert til appoppdateringer, men de påvirker stabiliteten, ytelsen eller konsistensen av opplevelsen.
Innen brukeropplevelse og design, Android 16 befester satsingen på kant-til-kant-grensesnitt ved å fjerne alternativet som tillot deaktivering av denne modusen ved hjelp av attributtet `windowOptOutEdgeToEdgeEnforcement` i apper som er rettet mot det nye API-nivået. Hvis en app er rettet mot Android 16 og kjører på en enhet med denne versjonen, vil den ikke lenger kunne deaktivere denne oppførselen, så utviklere må tilpasse designene sine for å fungere riktig i fullskjerm.
Det er også betydelige endringer i navigasjonen: Prediktive tilbakebevegelser blir normen for apper som er rettet mot Android 16På enheter med denne versjonen kalles ikke lenger `onBackPressed`, og KEYCODE_BACK-tasten sendes heller ikke som før. Systemanimasjoner veileder nå brukeren til ønsket sted når man sveiper tilbake (hjem, forrige aktivitet osv.). Utviklere som har fanget opp tilbake-knappen, bør migrere til de nye navigasjons-API-ene, eller som en midlertidig løsning deaktivere virkemåten med `android:enableOnBackInvokedCallback=false`-attributtet i manifestet.
Viktige tekniske endringer for utviklere
Utover den visuelle opplevelsen, Android 16 introduserer justeringer av den interne funksjonen til planlagte oppgaver, fonter og responsive oppsettFor eksempel endrer metoden `scheduleAtFixedRate` oppførselen sin: i stedet for å utføre alle tapte kjøringer når en app går tilbake til en gyldig livssyklus, utløses bare én. Dette bidrar til å forhindre plutselige topper i arbeidsmengden og forbedrer den generelle ytelsen, selv om utviklere bør sjekke om logikken deres er påvirket.
Når det gjelder tekst og fonter, Attributtet elegantTextHeight har ikke lenger noen effekt på apper som er rettet mot Android 16De såkalte «elegante skrifttypene» blir avviklet, så det er nødvendig å planlegge for en konsistent typografisk design for språk som arabisk, thai, tamil eller diverse indiske alfabeter uten å være avhengig av denne automatiske justeringen.
På enheter med store skjermer (nettbrett, sammenleggbare enheter, stasjonære datamaskiner, biler, TV-er…), Android 16 forsterker ideen om adaptive design ytterligerePå skjermer med en minimumsbredde på 600 dp ignoreres retnings-, størrelses- og sideforholdsbegrensninger som er deklarert i manifestet. Dette betyr at appen utvides til å fylle hele vinduet, uten pillarboxing eller tvungen stående eller liggende retning. Bare spill, noen brukerkonfigurerte unntak og mindre skjermer er unntatt fra denne regelen.
Det finnes en midlertidig rømningsvei: Egenskapen android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY kan deklareres på aktivitets- eller applikasjonsnivå. å opprettholde den gamle oppførselen på store skjermer. Men denne funksjonen vil forsvinne i fremtidige versjoner (API-nivå 37), så det er lurt å begynne å tilpasse grensesnittene nå.
Nyheter innen helse, tilkobling og sikkerhet
Android 16 styrker også kontrollene over helse- og fysisk aktivitetsdataTillatelsene BODY_SENSORS og BODY_SENSORS_BACKGROUND er erstattet av mer spesifikke tillatelser under android.permissions.health-området, i tråd med Health Connect. Apper som leser sensitive data som puls må be om detaljerte tillatelser som READ_HEART_RATE og ha en synlig aktivitet for å vise personvernreglene sine, ellers risikerer de å få disse tillatelsene tilbakekalt av systemet.
Innen Bluetooth-feltet, Nye intensjoner introduseres, som ACTION_KEY_MISSING og ACTION_ENCRYPTION_CHANGEFor å bedre håndtere tap av paring og endringer i kryptering, kan apper som administrerer parede enheter reagere mer presist når nøkler går tapt, koblingen krypteres på nytt eller sikkerhetsparametere endres, og tilpasse seg potensielle forskjeller mellom produsenter.
Videre Alle apper som er rettet mot Android 16 kan nå fjerne Bluetooth-paring fra tilknyttede enheter via et offentlig API i CompanionDeviceManager.Kallet removeBond(int) lar deg oppheve Bluetooth-paringen som er koblet til en CDM-tilknytning, og appen kan lytte etter ACTION_BOND_STATE_CHANGED for å spore endringer i paringsstatusen.
Når det gjelder sikkerhet, fortsetter Android 16 å herde systemet. MediaStore#getVersion() returnerer nå en unik verdi per appDette forhindrer bruk av den strengen som en fingeravtrykksmekanisme mellom applikasjoner. Initiativet «Secure Intents» er også på vei fremover, og har som mål å styrke systemet for intent-oppløsning: når det aktiveres via intentMatchingFlags-attributtet, kreves det eksplisitte intensjoner for å matche målkomponentens filter, og intensjoner uten en handling forhindres fra å matche filtre med mindre spesifikke flagg som allowNullAction brukes.
Denne strengere kontrollen kan aktiveres på applikasjons- eller komponentnivå (aktivitet, tjeneste, mottaker…), med flagg som håndhevIntentFilter eller ingenDen inkluderer også loggmeldinger for feilsøking av blokkerte intensjoner. Tanken er å gradvis gå over til en modell der denne strenge løsningen vil være standardoppførselen i fremtidige versjoner.
Ekstra beskyttelse: Mali GPU, lokalt nettverk og bilder
Et annet område der Android 16 styrker sikkerheten er i tilgang til Mali GPU på Pixel-enheterEldre IOCTL-er eller de som utelukkende er ment for utvikling er blokkert, og profilering av IOCTL-er er begrenset til skallprosesser eller feilsøkbare apper. Dette skal ikke påvirke vanlige apper, standard grafikk-API-er som Vulkan eller OpenGL, eller offisielle profileringsverktøy, men det begrenser potensielle angrepsvektorer på kjernenivå. Hvis en app prøver å bruke forbudte IOCTL-er, genererer systemet SELinux-avslag, og Google anbefaler at du rapporterer problemet til de aktuelle sikkerhetskanalene.
Innen personvernområdet tar Android 16 et svært viktig skritt fremover med Lokale nettverksbeskyttelserI dag kan enhver app med internettillatelse få tilgang til enheter på LAN-et, noe som åpner døren for fingeravtrykksteknikker eller bruk av det lokale nettverket som en lokasjonsproxy. Den nye tilnærmingen plasserer denne tilgangen bak en spesifikk kjøretidstillatelse innenfor gruppen for enheter i nærheten.
Utrullingen skjer gradvis, med en aktiveringsfase (2. kvartal 25) der Apper kan aktivere begrensninger gjennom kompatibilitetsrammeverket og teste brukstilfellene sineNår RESTRICT_LOCAL_NETWORK-flagget er satt for en pakke, vil trafikk til og fra lokale nettverksadresser (unicast, multicast eller kringkasting over TCP og UDP) generere feil hvis appen ikke har de nødvendige tillatelsene, mens normal internettrafikk fortsetter å fungere.
I denne innledende fasen, For å få tilbake tilgang til LAN-et, trenger appen bare å deklarere og innhente NEARBY_WIFI_DEVICES-tillatelsen.En spesifikk tillatelse vil imidlertid bli introdusert i gruppen for enheter i nærheten i fremtiden. Nettverk som 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, lokale lenker 169.254.0.0/16, CGNAT-områder 100.64.0.0/10 og multicast-adresser (224.0.0.0/4, ff00::/8), blant andre, regnes som "lokale".
Til slutt justerer Android 16 administrasjonen av tilgang til bilder og videoer. Når en app som er rettet mot SDK 36 ber om tillatelser for medieinnhold på en enhet som kjører Android 16 Hvis brukeren velger å gi tilgang kun til utvalgte elementer, vil bildene og videoene som genereres av den appen vises forhåndsvalgt i bildevelgeren. Brukeren kan fjerne valget av dem om ønskelig, noe som opphever appens tilgang til disse spesifikke elementene.
Alle disse endringene – nesten umiddelbare oppdateringer, skykompilering, nye tillatelser, større kontroll over intensjoner, forbedret GPU- og lokal nettverkssikkerhet og forbedringer i helse, tilkobling og adaptiv design – peker mot det samme målet: å gjøre Android 16 til en smidigere, mer forutsigbar og sikrere plattform for både brukere og utviklere.
Etter hvert som flere modeller av merker som SamsungEtter hvert som Xiaomi, Motorola, OnePlus og selvfølgelig Pixel-telefoner mottar denne versjonen, vil det bli stadig vanligere at installering eller oppdatering av en app slutter å være et «kryssede fingre»-øyeblikk og blir en enkel prosedyre som du knapt legger merke til mens du fortsetter å bruke telefonen din normalt. Del denne informasjonen slik at andre brukere kan holde seg oppdatert på de nye funksjonene i Android 16.