Android 16 kommer med en af de forbedringer, der ved første øjekast virker små, men som i hverdagen kan gøre en stor forskel: Appopdateringer bliver næsten øjeblikkelige og meget mindre irriterende.Takket være en kombination af systemændringer og nye funktioner til appinstallation ønsker Google, at din telefon altid skal være opdateret, uden at du føler, at noget konstant fryser.
Bag denne mere problemfri oplevelse ligger adskillige tekniske komponenter, der arbejder i baggrunden: de nye "problemfri applikationsopdateringer", flytningen af processer som dexopt og dex2oat og den såkaldte cloud-buildAlt dette kommer oven i andre væsentlige ændringer i Android 16, der påvirker udviklere, ydeevne, sikkerhed, privatliv, digital sundhed og kompatibilitet med flere skærmformater. Lad os se klart og direkte på, præcis hvad der ændrer sig.
Hvad er problemfri appopdateringer i Android 16?
Den centrale idé bag Android 16 på dette område er klar: for at sikre, at appopdateringer har mindst mulig indflydelse på normal mobiltelefonbrugIndtil nu har systemet, hver gang en app blev opdateret, måttet "fryse" den i en kort periode, mens den udskiftede sin kode og interne ressourcer. Dette forhindrede den i at køre parallelt for at undgå fejl, datafejl eller uventede nedlukninger.
at En midlertidig fastfrysning gav mening ud fra et stabilitetssynspunkt.Men i praksis kunne det være lidt af en gene. I store eller systemkritiske apps var den adskillige sekunders frysning nok til at få andre applikationer, der var afhængige af dem, til at opføre sig mærkeligt, sidde fast i ventetid eller endda vise lejlighedsvise fejl.
Med Android 16 tager Google endnu et skridt og anvender konceptet mere aggressivt problemfri appopdateringerMålet er ikke kun at gøre opdateringen kortere, men også at reducere den tid, hvor en app er fuldstændig inaktiv, til det mindst mulige, næsten til det punkt, hvor den er umærkelig for brugeren.
Ifølge oplysninger fra Google via officielle kilder, Den periode, hvor en app forbliver fastfrossen under en opdatering, er gået fra "adskillige sekunder" til "tiere af millisekunder".I praksis taler vi om et spring fra en pause, du tydeligt bemærkede, til en flimmer, som du i mange tilfælde ikke engang opfatter.
Sådan fremskynder Android 16 appopdateringer
For at opnå denne aggressive reduktion af nedetid tyr Android 16 ikke til overfladiske tricks. Det, den gør, er at omorganisere meget tunge interne opgaver og flytte dem frem til et stadie før installationen.så den "kritiske" periode, hvor appen skal fryses, bliver meget kortere.
De to nøgleelementer her er dexopt og dex2oatDisse er værktøjer i Android Runtime (ART)-miljøet, der er ansvarlige for at optimere applikationens bytekode. Traditionelt blev noget af deres arbejde udført præcis i det interval, hvor appen var sat på pause, hvilket i nogle tilfælde forlængede frysetiden med flere sekunder.
Med Android 16, Disse processer flyttes til en tidligere fase af opdateringsflowetMed andre ord udfører systemet det meste af optimeringen, før det når det punkt, hvor det skal erstatte gamle filer med nye. Når den kritiske pause indtræffer, er alt, der er tilbage, at udføre en hurtig filudskiftning, hvilket reducerer frysetiden til blot et par ti millisekunder.
Fordelen ved denne tilgang er todelt: på den ene side, Brugeren oplever opdateringen som næsten øjeblikkelig. fordi appen næsten ikke holder op med at være tilgængelig; på den anden side opretholdes det samme niveau af sikkerhed og konsistens i dataene, da valideringer og optimeringer fortsætter med at blive udført, blot på et mindre ubelejligt tidspunkt i processen for brugeroplevelsen.
Reel effekt for brugere med mange apps og for beskedne mobiltelefoner
På en mobiltelefon med få lette applikationer kan disse ændringer gå noget ubemærket hen. Hvis du kun bruger et par apps, der opdateres lejlighedsvis og bruger få ressourcer, har du måske aldrig følt, at opdateringer var et problem.Men billedet ændrer sig betydeligt, når vi taler om enheder med snesevis af apps, tunge spil eller tjenester, der ofte opdateres.
På telefoner, hvor mange applikationer bruges intensivt, At reducere nedetiden mellem opdateringer betyder færre korte frysninger, færre mærkelige grænsefladehop og en meget mere jævn samlet oplevelse.Derudover, hvis nogen af disse apps fungerer som en central tjeneste eller leverer API'er til andre applikationer (f.eks. beskedklienter, sikkerhedsbiblioteker eller systemapps), hjælper det at minimere deres frysning under opdateringer med at sikre, at hele appkæden fortsætter med at fungere normalt.
Denne udvikling er også særligt interessant for enheder i basisklassen eller den lavere mellemklassehvor hardware kæmper med at håndtere store installationer. Google reorganiserer ikke kun lokale processer, men forbinder også denne forbedring med en anden afgørende funktion i Android 16: cloud-kompilering for at accelerere installationen af nye apps, en game-changer for mindre kraftfulde telefoner.
Cloud-kompilering: apps, der installeres hurtigere takket være skyen
Udover at fremskynde opdateringer indeholder Android 16 en funktion fokuseret på første installation af applikationer og spil, især på beskedne enhederDenne funktion er kendt som cloud-kompilering, og dens mission er klar: at overføre noget af det tunge arbejde, der tidligere udelukkende lå på telefonens processor og lagerplads, til Googles servere.
Når du installerer en app på Android, bruger systemet ART til at køre sin kode. Under installationen tager dex2oat-værktøjet APK'ens .dex-filer, som indeholder den kompilerede kode, og genererer adskillige "applikationsartefakter".Disse artefakter hjælper appen med at åbne og køre hurtigere og mere effektivt, og kan findes i forskellige formater: .vdex-filer med metadata til at validere bytekoden, .odex-filer med prækompileret kode til specifikke metoder eller .art-filer med interne repræsentationer af strenge og klasser, der fremskynder appens opstart.
På de kraftigste mobiltelefoner, Generering af disse artefakter er relativt hurtig, næsten transparentMen på billige telefoner med træge processorer og langsom hukommelse kan denne proces blive en flaskehals, især hvis APK'en indeholder mange .dex-filer eller er et meget stort spil eller en meget stor app.
Android 16's forslag er simpelt, men effektivt: I stedet for at generere alle disse artefakter på enheden, kan du downloade dem, der allerede er prækompileret, fra Google Play.I dag har de fleste brugere rimelig hurtige mobil- og Wi-Fi-forbindelser, så i mange tilfælde er det mere effektivt at bruge netværket end at tvinge telefonens processor til at arbejde i flere sekunder eller endda minutter.
SDM og prækompilerede artefakter: rollen af Secure Dex Metadata
Android 16-cloud-versionen bruger en ny filtype: SDM står for Secure Dex MetadataDisse SDM-filer, der downloades sammen med APK'en fra Play Butik, indeholder de applikationsartefakter, der allerede er genereret i Googles infrastruktur ved hjælp af dex2oat, så enheden ikke behøver at gentage dette arbejde lokalt.
En vigtig detalje er det SDM-filer signeres med den samme nøgle som APK'enDette gør det muligt for systemet at verificere, at artefakterne kommer fra en pålidelig kilde og ikke er blevet ændret, hvilket sikrer processens integritet og sikkerhed. På denne måde kan telefonen installere applikationen direkte ved hjælp af disse prækompilerede artefakter, hvilket fremskynder den indledende installation betydeligt, især på hardware af lav kvalitet.
I praksis betyder det det Android 16 kan i mange tilfælde forhindre dex2oat i at køre under installationenFordi det hårde arbejde allerede er udført på Googles servere, er resultatet mindre belastning af processoren, lavere strømforbrug under installationen og kortere ventetider ved download af store apps eller spil med betydelige mængder kode.
Hele dette system kræver dog, at Google konfigurerede Play Butik til at generere og distribuere disse SDM'er i massevis.I de indledende faser kan funktionen være til stede i systemet, men ikke fuldt aktiv, netop fordi cloud-infrastrukturen skal justeres og rulles ud gradvist. Forvent ikke øjeblikkelige mirakler på alle kompatible enheder; implementeringen vil være gradvis.
Forholdet mellem hurtige opdateringer og cloud-opbygning
Selvom de kan virke som to separate ting, Problemfri opdateringer og cloud-opbygning er tæt forbundet Fordi begge drejer sig om, hvordan og hvornår app-eksekveringsartefakter genereres og anvendes. På den ene side fremskynder Android 16 udførelsen af dexopt og dex2oat til mindre kritiske faser af opdateringsprocessen, hvilket minimerer den tid, appen forbliver frossen.
Endvidere Cloud-kompilering betyder, at dette arbejde i mange tilfælde ikke engang behøver at udføres på enheden.Dette gælder både under den første installation og i visse opdateringer. Ved at downloade brugsklare artefakter gør kombinationen af begge tilgange både den første installation og efterfølgende opdateringer hurtigere og mindre påtrængende.
Alt dette stemmer overens med et grundlæggende mål: Optimer Android til at køre problemfrit selv på beskeden hardwaresamtidig med at nedetid reduceres og de bivirkninger, som opdateringer kan have på andre apps og tjenester, afbødes.
Andre ændringer i Android 16, der påvirker ydeevne og oplevelse
Forbedringer i opdateringer og installationer kommer ikke alene. Android 16 inkluderer en lang liste af adfærdsændringer, der De påvirker både apps, der er målrettet mod den nye version (targetSdkVersion 36), og selve operativsystemet.Mange af dem er ikke direkte relateret til appopdateringer, men de påvirker stabiliteten, ydeevnen eller ensartetheden af oplevelsen.
Inden for brugeroplevelse og design, Android 16 konsoliderer engagementet i kant-til-kant-grænseflader ved at fjerne den mulighed, der tillod deaktivering af denne tilstand ved hjælp af attributten `windowOptOutEdgeToEdgeEnforcement` i apps, der er målrettet mod det nye API-niveau. Hvis en app er målrettet mod Android 16 og kører på en enhed med denne version, vil den ikke længere kunne deaktivere denne funktionsmåde, så udviklere skal tilpasse deres designs til at fungere korrekt i fuldskærm.
Der er også betydelige ændringer i navigationen: Prædiktive tilbagebevægelser er ved at blive normen for apps, der er målrettet mod Android 16På enheder med denne version kaldes `onBackPressed` ikke længere, og KEYCODE_BACK-tasten sendes heller ikke som før; systemanimationer guider nu brugeren til den ønskede placering, når der swipes tilbage (hjem, forrige aktivitet osv.). Udviklere, der har registreret tilbage-knappen, bør migrere til de nye navigations-API'er eller, som en midlertidig løsning, deaktivere funktionaliteten med attributten `android:enableOnBackInvokedCallback=false` i manifestet.
Vigtige tekniske ændringer for udviklere
Ud over den visuelle oplevelse, Android 16 introducerer justeringer af de interne funktioner i planlagte opgaver, skrifttyper og responsive layoutsFor eksempel ændrer metoden `scheduleAtFixedRate` sin adfærd: i stedet for at udføre alle mistede udførelser, når en app vender tilbage til en gyldig livscyklus, udløses kun én. Dette hjælper med at forhindre pludselige stigninger i arbejdsbyrden og forbedrer den samlede ydeevne, selvom udviklere bør kontrollere, om deres logik er påvirket.
Angående tekst og skrifttyper, Attributten elegantTextHeight har ikke længere nogen effekt på apps, der er målrettet mod Android 16De såkaldte "elegante skrifttyper" udgår, så det er nødvendigt at planlægge et ensartet typografisk design for sprog som arabisk, thai, tamil eller forskellige indiske alfabeter uden at være afhængig af denne automatiske tilpasning.
På enheder med store skærme (tablets, foldbare enheder, stationære computere, biler, tv'er...) Android 16 forstærker yderligere ideen om adaptive designsPå skærme med en minimumsbredde på 600 dp ignoreres de begrænsninger for retning, størrelsesændring og billedformat, der er angivet i manifestet. Det betyder, at appen udvides til at fylde hele vinduet uden pillarboxing eller tvungen stående eller liggende retning. Kun spil, nogle brugerkonfigurerede undtagelser og mindre skærme er undtaget fra denne regel.
Der er en midlertidig flugtvej: Egenskaben android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY kan deklareres på aktivitets- eller applikationsniveau. at bevare den gamle opførsel på store skærme. Men denne funktion vil forsvinde i fremtidige versioner (API-niveau 37), så det er tilrådeligt at begynde at tilpasse grænsefladerne nu.
Nyheder inden for sundhed, konnektivitet og sikkerhed
Android 16 styrker også kontrollen over data om sundhed og fysisk aktivitetTilladelserne BODY_SENSORS og BODY_SENSORS_BACKGROUND er erstattet af mere specifikke tilladelser under android.permissions.health-området, der er i overensstemmelse med Health Connect. Apps, der læser følsomme data såsom puls, skal anmode om detaljerede tilladelser som READ_HEART_RATE og have en synlig aktivitet til at vise deres privatlivspolitik, ellers risikerer de at få disse tilladelser tilbagekaldt af systemet.
Inden for Bluetooth-området, Nye intentioner introduceres, såsom ACTION_KEY_MISSING og ACTION_ENCRYPTION_CHANGEFor bedre at håndtere tab af parring og ændringer i kryptering kan apps, der administrerer parrede enheder, reagere mere præcist, når nøgler mistes, linket krypteres igen, eller sikkerhedsparametre ændres, og tilpasse sig dermed potentielle forskelle mellem producenter.
Derudover Alle apps, der er målrettet mod Android 16, kan nu fjerne Bluetooth-parring fra tilknyttede enheder via en offentlig API i CompanionDeviceManager.Kaldet removeBond(int) giver dig mulighed for at tilbagekalde Bluetooth-parringen, der er knyttet til en CDM-tilknytning, og appen kan lytte efter ACTION_BOND_STATE_CHANGED for at spore ændringer i parringstilstanden.
Med hensyn til sikkerhed fortsætter Android 16 med at hærde systemet. MediaStore#getVersion() returnerer nu en unik værdi pr. appDette forhindrer brugen af den streng som en fingeraftryksmekanisme mellem applikationer. Initiativet "Secure Intents" skrider også frem og har til formål at styrke systemet til løsning af intentioner: Når det aktiveres via intentMatchingFlags-attributten, kræves der eksplicitte intentioner for at matche målkomponentens filter, og intentioner uden en handling forhindres i at matche filtre, medmindre specifikke flag som allowNullAction bruges.
Denne strengere kontrol kan aktiveres på applikations- eller komponentniveau (aktivitet, tjeneste, modtager…) med flag som f.eks. håndhævIntentFilter eller ingenDen indeholder også logmeddelelser til fejlfinding af blokerede intents. Ideen er gradvist at overgå til en model, hvor denne strenge løsning i fremtidige versioner vil være standardadfærden.
Yderligere beskyttelse: Mali GPU, lokalt netværk og fotos
Et andet område, hvor Android 16 styrker sikkerheden, er i adgang til Mali GPU'en på Pixel-enhederÆldre IOCTL'er eller dem, der udelukkende er beregnet til udvikling, er blokeret, og profilering af IOCTL'er er begrænset til shell-processer eller apps, der kan fejlrettes. Dette burde ikke påvirke almindelige apps, standard grafik-API'er som Vulkan eller OpenGL eller officielle profileringsværktøjer, men det begrænser potentielle angrebsvektorer på kerneniveau. Hvis en app forsøger at bruge forbudte IOCTL'er, genererer systemet SELinux-afslag, og Google anbefaler, at problemet rapporteres til de relevante sikkerhedskanaler.
Inden for privatlivets fred tager Android 16 et meget vigtigt skridt fremad med Beskyttelse af lokale netværkI øjeblikket kan enhver app med internetadgangstilladelse få adgang til enheder på LAN'et, hvilket åbner døren for fingeraftryksteknikker eller brug af det lokale netværk som en lokationsproxy. Den nye tilgang placerer denne adgang bag en specifik runtime-tilladelse inden for gruppen af enheder i nærheden.
Udrulningen er gradvis med en aktiveringsfase (2. kvartal 25), hvor Apps kan aktivere begrænsninger via kompatibilitetsrammen og teste deres brugsscenarierNår RESTRICT_LOCAL_NETWORK-flaget er indstillet for en pakke, vil trafik til og fra lokale netværksadresser (unicast, multicast eller broadcast over TCP og UDP) generere fejl, hvis appen ikke har de nødvendige tilladelser, mens normal internettrafik fortsætter med at fungere.
I denne indledende fase, For at genvinde adgang til LAN'et skal appen blot erklære og indhente tilladelsen NEARBY_WIFI_DEVICES.Der vil dog blive introduceret en specifik tilladelse inden for gruppen af enheder i nærheden i fremtiden. Netværk som 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, lokale links 169.254.0.0/16, CGNAT-intervaller 100.64.0.0/10 og multicast-adresser (224.0.0.0/4, ff00::/8) betragtes blandt andet som "lokale".
Endelig justerer Android 16 administrationen af adgang til fotos og videoer. Når en app, der er målrettet mod SDK 36, anmoder om tilladelser til medieindhold på en enhed, der kører Android 16 Hvis brugeren vælger kun at give adgang til udvalgte elementer, vil de fotos og videoer, der genereres af den pågældende app, vises som forudvalgte i fotovælgeren. Brugeren kan fravælge dem, hvis det ønskes, hvilket tilbagekalder appens adgang til disse specifikke elementer.
Alle disse ændringer – næsten øjeblikkelige opdateringer, cloud-kompilering, nye tilladelser, større kontrol over intents, forbedret GPU- og lokal netværkssikkerhed samt forbedringer i tilstand, tilslutningsmuligheder og adaptivt design – peger mod det samme mål: at gøre Android 16 til en mere gnidningsfri, forudsigelig og sikker platform for både brugere og udviklere.
Efterhånden som flere modeller af mærker som SamsungEfterhånden som Xiaomi, Motorola, OnePlus og selvfølgelig Pixel-telefoner modtager denne version, vil det blive mere og mere almindeligt, at installation eller opdatering af en app holder op med at være et "krydsede fingre"-øjeblik og bliver en simpel procedure, som du knap nok bemærker, mens du fortsætter med at bruge din telefon normalt. Del disse oplysninger, så andre brugere kan holde sig opdateret om de nye funktioner i Android 16.