Android 16 kommer med en av de där förbättringarna som vid första anblicken verkar små, men som i vardagen kan göra stor skillnad: Appuppdateringar blir nästan omedelbara och mycket mindre irriterande.Tack vare en kombination av systemändringar och nya funktioner för appinstallation vill Google att din telefon alltid ska vara uppdaterad utan att du känner att något ständigt fryser.
Bakom denna smidigare upplevelse finns flera tekniska komponenter som arbetar i bakgrunden: de nya "sömlösa applikationsuppdateringarna", flytten av processer som dexopt och dex2oat, och den så kallade molnbyggnationenAllt detta kommer utöver andra betydande förändringar i Android 16 som påverkar utvecklare, prestanda, säkerhet, integritet, digital hälsa och kompatibilitet med fler skärmformat. Låt oss ta en tydlig och direkt titt på exakt vad som förändras.
Vad är sömlösa appuppdateringar i Android 16?
Den centrala idén med Android 16 på detta område är tydlig: för att säkerställa att appuppdateringar har minsta möjliga påverkan på normal mobiltelefonanvändningFram tills nu har systemet, varje gång en app uppdaterades, varit tvunget att "frysa" den under en kort tidsperiod medan den ersatte sin kod och interna resurser, vilket förhindrade att den kördes parallellt för att undvika fel, datafel eller oväntade avstängningar.
Ese En tillfällig frysning var vettig ur stabilitetssynpunkt.Men i praktiken kunde det vara lite av en olägenhet. I stora eller systemkritiska appar var den där frysningen på flera sekunder tillräckligt för att få andra applikationer som var beroende av dem att bete sig konstigt, fastna i väntan eller till och med visa enstaka fel.
Med Android 16 tar Google ytterligare ett steg och anammar konceptet mer aggressivt. sömlösa appuppdateringarMålet är inte bara att uppdateringen ska ta kortare tid, utan också att minska den tid då en app är helt obrukbar till ett minimum, nästan till den grad att den är omärklig för användaren.
Enligt information från Google via officiella källor, Perioden under vilken en app förblir fryst under en uppdatering har gått från "några sekunder" till "tiotals millisekunder"I praktiken talar vi om ett hopp från en paus du tydligt märkte till ett flimmer som du i många fall inte ens uppfattar.
Hur Android 16 snabbar upp appuppdateringar
För att uppnå denna aggressiva minskning av driftstopp använder sig inte Android 16 av ytliga knep. Vad den gör är att omorganisera mycket tunga interna uppgifter och flytta dem fram till ett stadium före installationen.så den "kritiska" sträckan där appen måste frysas blir mycket kortare.
De två viktigaste delarna här är dexopt och dex2oatDet här är verktyg inom Android Runtime (ART)-miljön som ansvarar för att optimera applikationers bytekod. Traditionellt sett utfördes en del av deras arbete just under det intervall då appen var pausad, vilket i vissa fall förlängde frystiden med flera sekunder.
Med Android 16, Dessa processer flyttas till en tidigare fas av uppdateringsflödetMed andra ord utför systemet det mesta av optimeringen innan det når den punkt där det behöver ersätta gamla filer med nya. När den kritiska pausen inträffar är allt som återstår att utföra ett snabbt filbyte, vilket minskar frystiden till bara några tiotals millisekunder.
Fördelen med detta tillvägagångssätt är tvåfaldig: å ena sidan, Användaren uppfattar uppdateringen som nästan omedelbar. eftersom appen knappt slutar vara tillgänglig; å andra sidan bibehålls samma säkerhetsnivå och konsekvens i data, eftersom valideringar och optimeringar fortsätter att göras, bara vid en mindre obekväm tidpunkt i processen för användarupplevelsen.
Verklig effekt för användare med många appar och för enkla mobiltelefoner
På en mobiltelefon med få lättviktiga applikationer kan dessa förändringar gå något obemärkt förbi. Om du bara använder ett fåtal appar som uppdateras då och då och förbrukar få resurser, kanske du aldrig har känt att uppdateringar var ett problem.Men bilden förändras avsevärt när vi pratar om enheter med dussintals appar, tunga spel eller tjänster som uppdateras ofta.
På telefoner där många applikationer används intensivt, Att minska driftstoppet mellan uppdateringar innebär färre korta frysningar, färre konstiga gränssnittshopp och en mycket smidigare helhetsupplevelse.Dessutom, om någon av dessa appar fungerar som en central tjänst eller tillhandahåller API:er till andra applikationer (till exempel meddelandeklienter, säkerhetsbibliotek eller systemappar), hjälper det att minimera deras frysning under uppdateringar till att hela appkedjan fortsätter att fungera normalt.
Denna utveckling är också särskilt intressant för enheter i instegs- eller mellansegmentetdär hårdvaran kämpar för att hantera stora installationer. Google omorganiserar inte bara lokala processer, utan kopplar också denna förbättring till en annan viktig funktion i Android 16: molnkompilering för att påskynda installationen av nya appar, vilket är revolutionerande för mindre kraftfulla telefoner.
Molnkompilering: appar som installeras snabbare tack vare molnet
Förutom att snabba upp uppdateringar innehåller Android 16 en funktion fokuserad på första installationen av applikationer och spel, särskilt på enkla enheterDen här funktionen kallas molnkompilering och dess uppdrag är tydligt: att överföra en del av det tunga arbete som tidigare helt och hållet låg på telefonens processor och lagring till Googles servrar.
När du installerar en app på Android använder systemet ART för att köra sin kod. Under installationen tar dex2oat-verktyget APK:ns .dex-filer, som innehåller den kompilerade koden, och genererar flera "applikationsartefakter".Dessa artefakter hjälper appen att öppnas och köras snabbare och mer effektivt, och kan finnas i olika format: .vdex-filer med metadata för att validera bytekoden, .odex-filer med förkompilerad kod för specifika metoder, eller .art-filer med interna representationer av strängar och klasser som påskyndar appens start.
På de kraftfullaste mobiltelefonerna, Att generera dessa artefakter är relativt snabbt, nästan transparent.Men på billiga telefoner, med tröga processorer och långsamt minne, kan den här processen bli en flaskhals, särskilt om APK-filen innehåller många .dex-filer eller är ett mycket stort spel eller en mycket stor app.
Android 16:s förslag är enkelt men effektivt: Istället för att generera alla dessa artefakter på enheten, ladda ner dem redan förkompilerade från Google PlayIdag har de flesta användare någorlunda snabba mobil- och Wi-Fi-anslutningar, så i många fall är det mer effektivt att använda nätverket än att tvinga telefonens processor att arbeta i flera sekunder eller till och med minuter.
SDM och förkompilerade artefakter: rollen för Secure Dex Metadata
Android 16-molnversionen använder en ny filtyp: SDM står för Secure Dex MetadataDessa SDM-filer, som laddats ner tillsammans med APK-filen från Play Store, innehåller de applikationsartefakter som redan genererats i Googles infrastruktur med hjälp av dex2oat, så enheten behöver inte upprepa det arbetet lokalt.
En viktig detalj är det SDM-filer signeras med samma nyckel som APK:nDetta gör det möjligt för systemet att verifiera att artefakterna kommer från en betrodd källa och inte har ändrats, vilket säkerställer processens integritet och säkerhet. På så sätt kan telefonen installera applikationen direkt med hjälp av dessa förkompilerade artefakter, vilket avsevärt påskyndar den initiala installationen, särskilt på avancerad hårdvara.
I praktiken betyder det det Android 16 kan i många fall förhindra att dex2oat körs under installationen.Eftersom det hårda arbetet redan har gjorts på Googles servrar blir resultatet mindre belastning på processorn, lägre strömförbrukning under installationen och kortare väntetider vid nedladdning av stora appar eller spel med betydande mängder kod.
Hela detta system kräver dock att Google konfigurerade Play Store för att generera och distribuera dessa SDM:er i massor.I de inledande faserna kan funktionen finnas i systemet men inte helt aktiv, just för att molninfrastrukturen behöver justeras och rullas ut gradvis. Förvänta dig inte omedelbara mirakel på alla kompatibla enheter; implementeringen kommer att ske gradvis.
Sambandet mellan snabba uppdateringar och molnbyggande
Även om de kan verka som två separata saker, Sömlösa uppdateringar och molnbyggande är nära besläktade Eftersom båda kretsar kring hur och när app-exekveringsartefakter genereras och tillämpas. Å ena sidan tidigarelägger Android 16 exekveringen av dexopt och dex2oat till mindre kritiska faser av uppdateringsprocessen, vilket minimerar den tid appen förblir fryst.
Vidare, Molnkompilering innebär att detta arbete i många fall inte ens behöver göras på enheten.Detta gäller både under den första installationen och vid vissa uppdateringar. Genom att ladda ner färdiga artefakter gör kombinationen av båda metoderna både den första installationen och efterföljande uppdateringar snabbare och mindre påträngande.
Allt detta överensstämmer med ett grundläggande mål: Optimera Android för att fungera smidigt även på blygsam hårdvarasamtidigt som driftstopp minskas och de biverkningar som uppdateringar kan ha på andra appar och tjänster mildras.
Andra förändringar i Android 16 som påverkar prestanda och upplevelse
Förbättringar i uppdateringar och installationer kommer inte ensamma. Android 16 innehåller en lång lista med beteendeförändringar som De påverkar både appar som riktar sig mot den nya versionen (targetSdkVersion 36) och själva operativsystemet.Många av dem är inte direkt relaterade till appuppdateringar, men de påverkar stabiliteten, prestandan eller konsekvensen av upplevelsen.
Inom området användarupplevelse och design, Android 16 befäster engagemanget för kant-till-kant-gränssnitt genom att ta bort alternativet som tillät inaktivering av detta läge med attributet `windowOptOutEdgeToEdgeEnforcement` i appar som riktar sig mot den nya API-nivån. Om en app riktar sig mot Android 16 och körs på en enhet med den här versionen kommer den inte längre att kunna inaktivera detta beteende, så utvecklare måste anpassa sina designer för att fungera korrekt i helskärm.
Det finns också betydande förändringar i navigeringen: Förutsägande bakåtgester blir normen för appar som riktar sig till Android 16På enheter med den här versionen anropas inte längre `onBackPressed`, och KEYCODE_BACK-tangenten skickas inte längre som tidigare. Systemanimationer vägleder nu användaren till önskad plats när användaren sveper tillbaka (hem, tidigare aktivitet etc.). Utvecklare som har sparat bakåtknappen bör migrera till de nya navigerings-API:erna eller, som en tillfällig lösning, inaktivera beteendet med attributet `android:enableOnBackInvokedCallback=false` i manifestet.
Viktiga tekniska förändringar för utvecklare
Utöver den visuella upplevelsen, Android 16 introducerar justeringar av hur schemalagda uppgifter, teckensnitt och responsiva layouter fungerar.Till exempel ändrar metoden `scheduleAtFixedRate` sitt beteende: istället för att köra alla missade körningar när en app återgår till en giltig livscykel, utlöses bara en. Detta hjälper till att förhindra plötsliga toppar i arbetsbelastningen och förbättrar den totala prestandan, även om utvecklare bör kontrollera om deras logik påverkas.
Angående text och typsnitt, Attributet elegantTextHeight har inte längre någon effekt på appar som riktar sig mot Android 16De så kallade "eleganta typsnitten" håller på att utgå, så det är nödvändigt att planera för en konsekvent typografisk design för språk som arabiska, thailändska, tamilska eller olika indiska alfabet utan att förlita sig på denna automatiska justering.
På enheter med stora skärmar (surfplattor, vikbara enheter, stationära datorer, bilar, TV-apparater...), Android 16 förstärker ytterligare idén om adaptiva designerPå skärmar med en minsta bredd på 600 dp ignoreras begränsningar för orientering, storleksändring och bildförhållande som deklarerats i manifestet. Det betyder att appen expanderar för att fylla hela fönstret, utan pillarboxing eller tvingande stående eller liggande orientering. Endast spel, vissa användarkonfigurerade undantag och mindre skärmar är undantagna från denna regel.
Det finns en tillfällig flyktväg: Egenskapen android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY kan deklareras på aktivitets- eller applikationsnivå. för att bibehålla det gamla beteendet på stora skärmar. Men den här funktionen kommer att försvinna i framtida versioner (API-nivå 37), så det är lämpligt att börja anpassa gränssnitten nu.
Nyheter inom hälsa, uppkoppling och säkerhet
Android 16 stärker också kontrollerna över hälso- och fysisk aktivitetsdataBehörigheterna BODY_SENSORS och BODY_SENSORS_BACKGROUND ersätts av mer specifika behörigheter under android.permissions.health-området, i linje med Health Connect. Appar som läser känslig data som puls måste begära detaljerade behörigheter som READ_HEART_RATE och ha en synlig aktivitet för att visa sin integritetspolicy, annars riskerar de att få dessa behörigheter återkallade av systemet.
Inom Bluetooth-området, Nya intentioner introduceras, såsom ACTION_KEY_MISSING och ACTION_ENCRYPTION_CHANGEFör att bättre hantera parkopplingsförlust och krypteringsändringar kan appar som hanterar parade enheter reagera mer exakt när nycklar förloras, länken krypteras om eller säkerhetsparametrar ändras, och anpassa sig till potentiella skillnader mellan tillverkare.
Dessutom, Alla appar som riktar sig mot Android 16 kan nu ta bort Bluetooth-parning från associerade enheter via ett offentligt API i CompanionDeviceManager.Anropet removeBond(int) låter dig återkalla Bluetooth-parkopplingen som är länkad till en CDM-association, och appen kan lyssna efter ACTION_BOND_STATE_CHANGED för att spåra förändringar i parkopplingstillståndet.
Säkerhetsmässigt fortsätter Android 16 att hårdgöra systemet. MediaStore#getVersion() returnerar nu ett unikt värde per appDetta förhindrar att den strängen används som en fingeravtrycksmekanism mellan applikationer. Initiativet "Secure Intents" fortskrider också, och syftar till att stärka systemet för avsiktsupplösning: när det aktiveras via attributet intentMatchingFlags krävs explicita avsikter för att matcha målkomponentens filter, och avsikter utan en åtgärd förhindras från att matcha filter om inte specifika flaggor som allowNullAction används.
Denna striktare kontroll kan aktiveras på applikations- eller komponentnivå (aktivitet, tjänst, mottagare…), med flaggor som enforceIntentFilter eller ingenDen innehåller även loggmeddelanden för felsökning av blockerade intents. Tanken är att gradvis övergå till en modell där denna strikta lösning i framtida versioner kommer att vara standardbeteendet.
Ytterligare skydd: Mali GPU, lokalt nätverk och foton
Ett annat område där Android 16 stärker säkerheten är inom åtkomst till Mali GPU på Pixel-enheterÄldre IOCTL:er eller de som enbart är avsedda för utveckling blockeras, och profilering av IOCTL:er är begränsade till skalprocesser eller felsökningsbara appar. Detta bör inte påverka vanliga appar, standardgrafik-API:er som Vulkan eller OpenGL, eller officiella profileringsverktyg, men det begränsar potentiella attackvektorer på kärnnivå. Om en app försöker använda förbjudna IOCTL:er genererar systemet SELinux-avslag, och Google rekommenderar att problemet rapporteras till lämpliga säkerhetskanaler.
Inom integritetsområdet tar Android 16 ett mycket viktigt steg framåt med Lokala nätverksskyddFör närvarande kan alla appar med internetåtkomstbehörighet komma åt enheter på det lokala nätverket, vilket öppnar dörren för fingeravtryckstekniker eller användning av det lokala nätverket som platsproxy. Den nya metoden placerar den åtkomsten bakom en specifik körtidsbehörighet inom gruppen för närliggande enheter.
Utrullningen sker gradvis, med en aktiveringsfas (Q2 25) där Appar kan aktivera begränsningar genom kompatibilitetsramverket och testa sina användningsfallNär flaggan RESTRICT_LOCAL_NETWORK är inställd för ett paket, kommer trafik till och från lokala nätverksadresser (unicast, multicast eller broadcast över TCP och UDP) att generera fel om appen inte har rätt behörigheter, medan normal internettrafik fortsätter att fungera.
I denna inledande fas, För att återfå åtkomst till LAN-nätet behöver appen helt enkelt deklarera och hämta behörigheten NEARBY_WIFI_DEVICES.En specifik behörighet kommer dock att införas inom gruppen för närliggande enheter i framtiden. Nätverk som 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, lokala länkar 169.254.0.0/16, CGNAT-intervall 100.64.0.0/10 och multicast-adresser (224.0.0.0/4, ff00::/8), bland andra, betraktas som "lokala".
Slutligen justerar Android 16 hanteringen av åtkomst till foton och videor. När en app som riktar sig mot SDK 36 begär behörigheter för medieinnehåll på en enhet som kör Android 16 Om användaren väljer att endast ge åtkomst till utvalda objekt kommer foton och videor som genereras av den appen att visas förvalda i fotoväljaren. Användaren kan avmarkera dem om så önskas, vilket återkallar appens åtkomst till just dessa objekt.
Alla dessa förändringar – nästan omedelbara uppdateringar, molnkompilering, nya behörigheter, större kontroll över avsikter, förbättrad GPU- och lokal nätverkssäkerhet samt förbättringar av hälsa, anslutning och adaptiv design – pekar mot samma mål: för att göra Android 16 till en smidigare, mer förutsägbar och säkrare plattform för både användare och utvecklare.
Allt eftersom fler modeller av märken som SamsungI takt med att Xiaomi, Motorola, OnePlus och naturligtvis Pixel-telefoner får den här versionen kommer det att bli allt vanligare att installation eller uppdatering av en app slutar vara ett "håll fingrarna korsade" ögonblick och blir en enkel procedur som du knappt märker medan du fortsätter att använda din telefon normalt. Dela den här informationen så att andra användare kan hålla sig uppdaterade om de nya funktionerna i Android 16.