Eddig leginkább a Beállítások között feltüntetett biztonsági frissítés dátumából próbálhattuk megítélni, mennyire naprakész egy Android telefon. A Google szerint azonban ez ma már messze nem mond el mindent. Az új AndroidX Security State rendszerrel az alkalmazások sokkal részletesebben ellenőrizhetik, milyen javítások vannak ténylegesen telepítve a készüléken, maradt-e ismert sérülékenység, illetve vár-e még telepítésre fontos rendszerfrissítés. Banki és más érzékeny alkalmazásoknál ennek komoly gyakorlati következménye lehet.
Ha valaha ellenőriztük egy Android telefon biztonsági állapotát, jó eséllyel egyetlen dátumot néztünk meg: a biztonsági javítás szintjét. Július 1., augusztus 5., szeptember 1. – minél frissebb, annál jobb. Legalábbis eddig nagyjából így gondolkodtunk.
Csakhogy a modern Android már régen nem egyetlen egységként frissül.
A telefon operációs rendszerének egy részét továbbra is a gyártó által kiadott OTA-frissítés módosítja, más komponensek viszont a Google Play rendszerfrissítéseken keresztül külön frissülhetnek. Ehhez hozzájön a Linux kernel, valamint számos olyan modul és alrendszer, amelynek biztonsági állapota nem feltétlenül követhető le pontosan abból az egyetlen dátumból, amelyet a Beállítások között látunk.
Éppen ezért vezeti be a Google az AndroidX Security State megoldását, amelynek 1.1.0-s verziója most stabil kiadásként is megjelent, a hozzá kapcsolódó Security State Provider pedig az 1.0.0-s verzióhoz érkezett.
A változás első látásra inkább fejlesztői újdonságnak tűnik, valójában azonban idővel minden androidos felhasználót érinthet.
Az alkalmazások ugyanis ezentúl jóval pontosabban ellenőrizhetik, hogy az adott telefon valóban biztonságos állapotban van-e.
Egyetlen dátum helyett három különböző kérdés
A Google új megközelítésének egyik legfontosabb eleme, hogy nem egyszerűen azt nézi, milyen biztonsági dátum jelenik meg a készüléken.
Három különálló információt képes összevetni.
Az első azt mutatja meg, hogy milyen javítások vannak ténylegesen telepítve a telefonon. Ez a készülék aktuális biztonsági állapota.
A második azt mutatja, hogy milyen javításokat publikált már hivatalosan a Google az Android biztonsági közleményeiben.
A harmadik pedig azt, hogy van-e az adott készülékhez elérhető újabb frissítés, amelyet a felhasználó még nem telepített.
Ez elsőre technikai részletnek tűnhet, pedig éppen ez teszi lehetővé, hogy egy alkalmazás különbséget tegyen két nagyon eltérő helyzet között.
Az egyik felhasználó telefonján például lehet néhány hónapos biztonsági szint azért, mert a gyártó egyszerűen még nem adott ki újabb javítást.
Egy másik készüléken viszont ugyanilyen régi javítás lehet úgy, hogy a frissítés már hetek óta ott vár telepítésre.
Biztonsági szempontból ez egyáltalán nem ugyanaz.
Az új rendszer ezt már látni fogja.
Ráadásul nemcsak a teljes Android rendszert vizsgálja. Külön ellenőrizhető a hagyományos rendszerkomponensek állapota, a Google Play rendszerfrissítésekkel érkező Mainline-modulok biztonsági szintje, valamint a Linux kernel verziója is.
Ez azért fontos, mert előfordulhat, hogy maga az Android rendszer naprakésznek tűnik, miközben valamely külön frissülő komponens még egy régebbi verziót használ.
Az eddigi egyetlen dátum ilyen esetben könnyen túlzottan egyszerű képet mutatott.
Az új Security State ennél lényegesen részletesebb.
A banki app akár azt is mondhatja: előbb frissítsd a telefonod
A változás talán a banki, pénzügyi, vállalati és más érzékeny adatokat kezelő alkalmazásoknál lesz a legfontosabb.
Egy banki alkalmazás például egy nagyobb összegű tranzakció, új bankkártya hozzáadása vagy új hitelesítési adat regisztrációja előtt ellenőrizheti a telefon biztonsági állapotát.
Ha azt látja, hogy a készüléken egy fontos javítás még nincs telepítve, miközben a frissítés már elérhető, figyelmeztetheti a felhasználót.
Szélsőséges esetben akár bizonyos érzékeny funkciókat is korlátozhat addig, amíg a javítás fel nem kerül.
Ez elsőre bosszantónak tűnhet.
Valójában azonban sokkal értelmesebb módszer lehet, mint egy egész készüléktípust vagy Android-verziót egyszerűen elavultnak minősíteni.
Az alkalmazás ugyanis nem feltétlenül azt kérdezi majd, hogy hány éves a telefonunk.
Azt kérdezheti: az a konkrét sérülékenység, amely számomra kockázatot jelent, ki van-e javítva ezen az eszközön?
És ez hatalmas különbség.
A Security State egyik API-ja ugyanis arra is használható, hogy egy alkalmazás konkrét CVE-k, vagyis ismert sérülékenységek javítási állapotát ellenőrizze.
A Google példaként NFC- és Bluetooth-hibákat említ.
Egy érintéses fizetéssel foglalkozó alkalmazás például ellenőrizheti, hogy az adott NFC-sérülékenységet valóban javították-e a készüléken, mielőtt engedélyezne egy érzékeny műveletet.
Nem kell tehát többé kizárólag abból következtetnie, hogy a telefon „2026. augusztusi biztonsági javítást” futtat.
Megnézheti a konkrét problémát.
Ez jóval precízebb megközelítés.
Az Android 17 még pontosabbá teszi a képet
Az Android 17 egy újabb fontos elemmel egészíti ki a rendszert.
A gyártók ugyanis külön jelezhetik azokat a biztonsági javításokat is, amelyeket úgy építettek be a szoftverbe, hogy közben a készülék hivatalos Security Patch Level dátuma nem változott.
Ez főként a visszaportolt javításoknál fontos.
Gyakran előfordul ugyanis, hogy egy gyártó egy konkrét hibára már elkészíti és kiadja a javítást, de nem implementálja az adott hónap összes biztonsági módosítását. Emiatt hivatalosan nem emelheti magasabb szintre a teljes biztonsági dátumot.
Az eredmény korábban az lehetett, hogy a telefon papíron rosszabb biztonsági állapotúnak látszott, mint amilyen valójában volt.
Az Android 17-től az OEM-ek úgynevezett Supplemental Patches adatokkal külön jelezhetik az ilyen javításokat.
Az alkalmazások pedig ezt is figyelembe vehetik.
Vagyis egy banki app nem feltétlenül fogja elutasítani a telefont csak azért, mert a kijelzett biztonsági dátum régebbi, ha közben a számára fontos sérülékenység javítása már ténylegesen rajta van.
Ez különösen fontos lehet az olcsóbb vagy hosszabb támogatási ciklusban lévő készülékeknél, ahol a teljes havi biztonsági csomagok ritkábban érkeznek.
A Google ezzel lényegében azt mondja: ne a dátumot nézzük, hanem azt, hogy ténylegesen mi van kijavítva.
És biztonsági szempontból ez sokkal értelmesebb megközelítés.
Nem ugyanaz, mint a Play Integrity
Fontos különbséget tenni az új Security State rendszer és a Google Play Integrity API között.
A Play Integrity többek között azt tudja ellenőrizni, hogy az alkalmazás valódi, hitelesített Android készüléken fut-e, módosították-e a rendszert, megfelelő-e az eszköz integritása, illetve bizonyos esetekben azt is, hogy kellően friss biztonsági javításokkal rendelkezik-e.
Az új Security State más problémát old meg.
Sokkal részletesebb képet ad arról, hogy milyen konkrét rendszerkomponensek és javítások vannak jelen az eszközön.
A kettő tehát kiegészítheti egymást.
Egy banki alkalmazás például a Play Integrity segítségével ellenőrizheti, hogy az eszköz hiteles és nincs-e manipulálva, a Security State alapján pedig megvizsgálhatja, hogy a számára kritikus biztonsági javítások valóban telepítve vannak-e.
Együtt ez már jóval pontosabb biztonsági képet ad, mint az a megközelítés, amikor az alkalmazás egyszerűen azt mondja, hogy „Android 13 vagy újabb szükséges”.
Nem holnaptól tiltják le a régebbi telefonokat
Az új funkció természetesen nem jelenti azt, hogy egyik napról a másikra banki alkalmazások tömege kezdi majd megtagadni a működést régebbi készülékeken.
A Google egyelőre eszközt adott a fejlesztők kezébe.
Hogy ezt hogyan használják, az már az alkalmazások készítőin múlik.
Egy bank dönthet úgy, hogy csak figyelmeztetést jelenít meg.
Más esetben kérheti a felhasználótól a frissítés telepítését egy érzékeny funkció használata előtt.
Vállalati környezetben akár szigorúbb szabályokat is bevezethetnek.
Az sem biztos, hogy minden alkalmazás azonnal átveszi a technológiát. A fejlesztőknek előbb implementálniuk kell az AndroidX Security State könyvtárat, az OEM-eknek pedig együtt kell működniük abban, hogy saját frissítési rendszerük megfelelő információkat szolgáltasson.
A Google Play rendszerfrissítések esetében az elérhető frissítési információk már biztosíthatók a Google-szolgáltatásokat használó készülékeken.
A gyártói OTA-rendszereknél azonban az OEM-eknek is támogatniuk kell az új Security State Provider mechanizmust ahhoz, hogy az alkalmazás pontosan lássa, milyen frissítés vár telepítésre.
Vagyis a rendszer ereje nagyban függ majd attól is, hogy a Samsung, Xiaomi, Honor, Motorola, vivo, Oppo és a többi gyártó milyen gyorsan építi be a saját frissítési infrastruktúrájába.
A felhasználó szempontjából ez végül jó hír lehet
Elsőre talán kissé nyugtalanítóan hangzik, hogy egy alkalmazás egyre több információt tud a telefon biztonsági állapotáról.
A másik oldalról nézve azonban ez sokkal igazságosabb rendszert is teremthet.
Ma sok szolgáltatás meglehetősen egyszerű szabályokat használ.
Ha túl régi az Android-verzió, nem működik az alkalmazás. Ha módosított a rendszer, tiltás érkezhet. Ha lejárt a gyártó hivatalos támogatása, egyes szolgáltatások automatikusan magasabb kockázatúnak tekinthetik az eszközt.
Az új megoldással elvileg sokkal pontosabb döntések születhetnek.
Nem az számít majd önmagában, hogy három- vagy ötéves-e egy telefon, hanem az, hogy az adott biztonsági probléma jelen van-e rajta.
Ez a hosszú szoftvertámogatást ígérő gyártók számára is fontos lehet.
A Samsung, a Google és egyre több más márka már hat-hét éves támogatási időszakról beszél. Ennek azonban csak akkor van valódi biztonsági értéke, ha nem egyszerűen rendszerfrissítések érkeznek, hanem a szükséges javítások ténylegesen eljutnak a készülék különböző komponenseihez.
Most ezt az alkalmazások is jobban ellenőrizhetik.
És talán ez a változás legfontosabb része.
A biztonsági frissítés dátuma nem tűnik el. Továbbra is hasznos, egyszerű jelzés marad arra, hogy körülbelül mennyire naprakész a készülékünk.
Csak éppen már nem kell úgy tekintenünk rá, mint a teljes igazságra.
A modern Android túl sok különálló komponensből épül fel ahhoz, hogy egyetlen dátummal pontosan le lehessen írni a biztonsági állapotát.
A Google most lényegében egy sokkal részletesebb műszert ad a fejlesztők kezébe.
Egy olyan rendszert, amely nem azt kérdezi, hogy mikor kapott utoljára biztonsági frissítést a telefonunk.
Hanem azt, hogy valóban kijavították-e rajta azt, amit ki kellett javítani.
És a kettő egyáltalán nem ugyanaz.