Kiterjesztett Doze, adattakarékosság, biztonság
A betűméretet rendszerszinten eddig is lehetett állítani (immáron csúszka is van hozzá, négy választással), ám sokan szeretnének minden elemet kicsinyíteni vagy nagyítani (ikonok, feliratok, értesítési sáv, androidos kezelősáv, alkalmazáselemek, szöveg-buborékok, lényegében a DPI beállítások). Erre a megjelenített méret menüpontban van lehetőség, ötféle választással, amely a főoldal és a menü rácsméretét is befolyásolja. Ez mindenképpen hasznos opció a rosszabbul látóknak és azoknak a hardcore felhasználóknak, akik egy hatalmas kijelzőn a lehető legtöbb információt és opciót szeretnék látni.
A megjelenített méret állítása
A doze az Android 6.0 egyik legelőnyösebb tulajdonsága volt, mert hosszú tétlenség mellett (mondjuk éjszaka) csökkentette az alkalmazások frissítési gyakoriságát, a gyakorlatban is észrevehetően növelve a készenléti üzemidőt. A doze on the go, vagyis a „szundítás az úton” pont az, amire a név alapján gondolni lehet: menet közben is lehet az appok fogyasztásával takarékoskodni (rengeteg kéri mozgás közben például a GPS információt, többek között ezért is merül gyorsabban ilyenkor a telep). A fejlesztőknek persze előbb be kell építeniük a kapcsolódó API-t alkalmazásukba – talán ennek hiányában ezért sem tűnt fel a Doze on the go előnye egyelőre, majd ránézünk fél év múlva. Az alkalmazásszintű takarékosság mindenesetre roppant ígéretes. Egy picit egyébként az akkumulátormenü is megváltozott, több app fogyasztása látszik egyszerre és az akkumulátor-kímélő mód is könnyebben elérhető, bár nem fejlődött.
Az akkumulátormenü kicsit más, ám fontosabb a kiterjesztett Doze takarékosság [+]
Nemcsak az energiával, hanem a mobiladattal is érdemes takarékoskodni, és immáron opció ennek testreszabására az adatforgalom-csökkentőt aktiválva. Ha be van pipálva, a használatban lévő appok ritkábban frissítenek mobilneten, a nem használtak pedig egyáltalán. Nyilván lehet olyan app, amit szeretnénk éberen hagyni, ezeket a kivételek listájára tehetjük, és a megszokott gyakorisággal frissülnek. Az Android 7.0 natívan támogatja a Google virtuális valóságra kihegyezett Daydream VR platformját, bár daydreames eszközök még nem jöttek ki, hogy ezt az izgalmas fejlesztést a gyakorlatban is kipróbálhassuk. Mindenesetre, többről van szó, mint egy futtatókörnyezet a Google Cardboard tartalmakhoz. A VR mód vélhetőleg akkor lesz majd elindítható, amikor a hardveresen támogatott mobilt az ember a megfelelő Daydream kiegészítőbe csúsztatja.
Az adatforgalom-csökkentő és beállításai [+]
Az adatvédelem eddig is fontos volt a Google-nek, ezért saját referenciakészülékei egy ideje, mások pedig rövidebb ideje rendszerszintű titkosítással érkeznek. Ez azt jelenti, hogy a belső vagy rendszerhasználatra formázott tároló (adoptive storage) kódolva van, így az illetéktelenek azonosítás híján akkor sem tudnak mit kezdeni velük, ha az adathalmazhoz hozzáférnek. A 7.0 újdonsága a fájlalapú titkosítás, ami sokkal fejlettebb, mert állományonként kioszt egy biztonsági kulcsot, így a tároló belső tartalma védve van saját magától is (mondjuk egy kíváncsiskodó apptól vagy malware-től). Noha a fájlalapú titkosítás alapból csak a 7.0-val megjelenő mobilokon lesz aktív, míg másokon (így a nálunk járt Nexus 6P-n) a fejlesztői beállítások között kell aktiválni a dolgot, amely a teljes belső tároló törlésével jár, a dolognak van egy fontos előnye: a közvetlen bootolás (direct boot). Az újfajta titkosítás ugyanis két részre osztja a tárolót: felhasználói szinten titkosított partícióra (credential encrypted), amit csak azonosítással lehet elérni, és eszközszinten titkosítottra (device encrypted), amelyet bármikor, bekapcsolás után el lehet érni. A gyakorlati előnye a direct bootban mutatkozik meg, íme, egy példa.
A Nexus 5 nem kap hivatalosan nugátos frissítést, valószínűleg az alább ecsetelt okokból [+]
Előfordulhat, hogy az ember tudtán kívül (zsebében, éjjel) újraindul a telefon. Ha komolyabb védelemmel el van látva, addig nem tölt be az ébresztő, a naptár vagy az üzenetküldő, amíg a felhasználó nem azonosítja magát. Az újraindítás után viszont lemaradhat a júzer egy közelgő eseményről, friss üzenetről vagy az ébresztésről. Itt jön a képbe a direct boot: ha ez aktív, a rendszer azonosítás előtt is hozzáférhet az eszközszinten titkosított, erősen korlátozott információkhoz. Mondjuk a naptáreseményekhez, az értesítésekhez és az ébresztőhöz. Ha a fejlesztő a megfelelő API-t a szoftverébe integrálta, azok is küldhetnek értesítést direct boot módban, azonosítás előtt, és megcsörren a titokban újraindult telefon. Alighanem az újfajta titkosítás az oka, hogy számos régi ARM utasításkészletet használó mobil (pl. a Snapdragon 800/801-es Galaxy S5, az Xperia Z3, az LG G3, a Nexus 5 vagy a One M8) nem frissül 7.0-ra, mert a hardver egyszerűen nem felel meg a Google kapcsolódó alapkövetelményeinek (CTS, CDD).
A cikk még nem ért véget, kérlek, lapozz!
