Google I/O: itt az Android L

Material - a flat vége

Újra fontos designváltáshoz ért az Android, a 3.0 (Honeycomb) óta csiszolt, finomított Holo téma helyére most a Material kerül. Ez az új UI első ránézésre a Holo és a weben (illetve a Google egyes appjaiban) használt "kártyás" UI szerelemgyereke, mindkettőből vesz át, a tervek szerint a cég nem csak az Androidon, hanem a weben is ezt az stílust fogja használni hamarosan.

A Material szakít az eddig divatos "flat" designiskolával, az új interfész 3D-s, árnyékokkal, fényekkel, rengeteg kisebb-nagyobb effekttel. A Material központi paradigmája, hogy a felhasználói felület egymás alatt-fölött elhelyezkedő síkokra bomlik, az adott elemek síkja pedig a felhasználó számára értékes információkat hordoz - például érintésre egy elem "kiugrik" az eredeti síkból, így jelzi vissza az interakciót. Az elemek egyébként GPU-n renderelt, valós idejű világítást kapnak, árnyékot vetnek, ami a Google szerint segít a felhasználót az appok és a rendszer használatában.

^{Gmail app Holo és Material UI-val}

Az Android felhasználói felülete ezzel már a sokadik váltást éli meg, míg a Windows Phone még mindig az eredeti, a rajtkor érvényes iskolát követi, az iOS pedig tavaly kapta meg az első átrajzolását. Az eddigi paradigmák közül ez tűnik a leginkább kifinomultnak és érettnek, míg a 2.3-as Gingerbread és a korábbi felületek az inkonzisztenciától hemzsegtek, a Holo pedig túl nyers és szigorú volt, a Material teremtheti meg az Google által hőn áhított "designparitást" az iOS-szel. Ehhez persze a fejlesztőknek is fel kell karolniuk a Materialt, ehhez a Google már idejében közzé is tette a design alapelemeit leszögező (amúgy üres, értelem nélküli mondatoktól hemzsegő) iránymutatását is.

Alapértelmezett ART

Az androidos alkalmazások futtatásáért gyakorlatilag a platform születése óta a Dalvik VM felel, ez fordítja a letöltött appokat gépi kódra, ez felel a memóriamenedzsmentért és (közvetve vagy közvetlenül) az appok teljesítményéért és a felhasználói élményért. A Dalvik születése óta azonban a mobilos világ hatalmas tempóban fejlődött, amit a VM egyszerűen nem tudott lekövetni. Tudta ezt a Google is, ezért a következő generációs, 64 bites processzorokhoz már alapoktól új futtatókörnyezetet, az ART-ot (Android RunTime) fejlesztett.

Az ART már az Android előző, 4.4.-es kiadásában is elérhető tesztkiadásban, az L-ben azonban új, végleges verzió mutatkozik be, immár alapértelmezett futtatókörnyezetként. A Google teljes Dalvik-ART kompatibilitást ígér, vagyis az összes korábban írt alkalmazás ART alatt is hibátlanul kell fusson, de az appokat érdemes az új futtatókörnyezethez újraoptimalizálni és újragondolni, a Dalvik esetében érvényes kompromisszumok és optimalizációk ugyanis vagy szükségtelenek, vagy egyenesen károsak.

A Google szerint új futtatókörnyezet hibrid paradigmát követ, keveri az AOT (ahead-of-time, telepítéskor történő), JIT (just-in-time, futásidejű) és interpreted (valós idejű) fordítás előnyeit. Emellett az ART több utasításarchitektúrát is támogat, ARM és x86 mellett (némi meglepetésre) a MIPS is teljes támogatásban részesül. Ez utóbbi a beágyazott rendszerek területén továbbra is hatalmas szereplőnek számít (és vannak ígéretek az okostelefonos visszatérésre is), elképzelhető, hogy az Androiddal a Google ebbe az irányba is terjeszkedni akar.

Az új Android már teljes támogatást nyújt az új, 64 bites utasításarchitektúrák számára, mind ARM, mind x86 platformon. Ebben fontos szerepe van a fenti ART-nak is, amely született 64 bites környezet és igyekszik maximálisan kihasználni az új utasításkészletek (ARMv8, x86-64 és MIPS64) adta lehetőségeket, a nagyobb regisztereket és a nagyobb címezhető memóriát is.

Hosszabb akkus üzemidő (Project Volta)

Az Android érett rendszerré válásával sürgetővé vált az akkus üzemidő rendszerszintű kezelése is. Ezt célozza a Project Volta, a Google kezdeményezése az androidos eszközök üzemidejének növelésére. A fejlesztők számára egy új eszköz erre a Battery Historian, amellyel az alkalmazás energiahatékonysága vizsgálható a legalacsonyabb szinten. Az eszköz segít vizualizálni az app működése és a fogyasztás közötti kapcsolatot, a kód szintjén követhető, hogy melyik hívás milyen hatással van az energiahatékonyságra. Az adatok birtokában pedig optimalizálható az app viselkedése, az eszközzel a változások összehasonlíthatóak, számszerűsíthetőek.

A Windows 8 és az OS X újabb kiadásainak nagy újdonsága volt a "timer coalescing", vagyis a processzort rendszeresen felébresztő alkalmazások aktivitásának összevonása, így a processzor kevesebbszer kerül magasabb fogyasztású állapotba. Az új JobScheduler API-val valami hasonlót hoz a Google az Androidra, például a háttérben adatot forgalmazó appok szinkronizálásával a hálózati forgalom vonható össze, így a rádiós kommunikáció fogyasztása csökkenthető. Az API-n keresztül meghatározható, hogy az alkalmazásunk bizonyos feladatokat csak bizonyos körülmények között hajtson végre (például saját állapotát csak Wi-Fi-n frissítse), ezzel viszonylag egyszerűen programozható az energiatakarékos viselkedés.

A gyártók által készített Android-verzióknak egy ideje fontos kelléke az extratakarékos üzemmód (ezt a Sony Staminának, a HTC Extreme Power Savingnek, a Samsung Ultra Power Savingnek hívja), ilyenkor a rádiós forgalmat a rendszer a minimumra csökkenti, a processzor órajelét lehúzza - egy szóval mindent elkövet a készenlét elnyújtására. Ezt a módot immár a Google-féle Android is tudja, a Battery Saver üzemmódban a teljesítmény rovására megnő a készenléti idő. Ha az akku töltöttsége 20 százalék alá esik, a rendszer felajánlja ennek bekapcsolását, de a beállítások között automatikussá is tehetjük a váltást.

Új értesítések és multitask

Változik az értesítések megjelenítése az új Androidban, az L-től a feloldóképernyőn immár nagyban megjelennek a beérkezett értesítések, ezeket a "roló" lehúzása nélkül is láttamozhatjuk, közvetlenül erről a felületről. Ez a megoldás kifejezetten ősinek számít, a Windows Mobile 6.5-ben már láttunk hasonlót, szerencse, hogy a Google végre felfedezte ezt a felhasználói igényt. Az Android korábbi generációban a Google sokat kísérletezett a feloldóképernyővel, az új megoldással (szerintünk) révbe ért. Az értesítések megjelenése is változott, ha épp egy appot használunk, akkor a kijelző tetején jelenik meg az üzenet, rögtön reakcióra lehetőséget adó gombokkal együtt - eddig ezek csak az értesítési roló lehúzása után voltak elérhetőek.

Változott a futó appok közötti váltás (multitasking). Míg a KitKatig egy alkalmazás egy kártyát kapott, az új paradigmában egy alkalmazás több "ablakkal" is szerepelhet a megnyitott appok listáján, így például a Docs-ban szerkesztett dokumentumok vagy a Chrome-ban megnyitott fülek is külön-külön szerepelnek a listában. Ez utóbbi azért nagyon fontos, mert így a webes/böngészős alkalmazások gyakorlatilag teljes értékű szereplők lesznek a platformon - ezzel eltűnhet a nyomás is a weboldalakból csomagolt alkalmazások létrehozására, másrészt könnyedebbé válik a web-mobil átjárás is. Ha a bejelentést jól értettük, akkor az API más böngészők számára is elérhető, így Firefox esetében ugyanúgy működhet ez, mint Chrome alatt.

Biztonság - immár Knoxszal

Igazi meglepetést okozott a Google bejelentése, miszerint a Samsung által fejlesztett Knox biztonsági framework, amellyel a céges és a személyes adatok/appok különválaszthatóak egyetlen telefonon belül, immár a "hivatalos" Android részét képezi, a Samsung a technológiát átadta a Google és az Android-közösség számára. Ez hatalmas győzelem, a Samsung ugyanis eddig a vállalatok meggyőzésében a saját útját járta, az Androidtól függetlenül pozicionálta saját telefonjait és tabletjeit a Knoxra alapozva.

Azzal, hogy a Knox beolvad a mainline Androidba, hirtelen nagyot nőhet a teljes platform hitelessége vállalati környezetben, ezzel végső soron (mint androidos gyártó) a Samsung is jól jár. A Google rendszerének terjedése eddig csak a Samsungnál csapódott le profitként, a többi szereplő apró piaci részesedést és (jó esetben) nulla profitot tudott elérni. A dél-koreaiaknak nincs így okuk attól félni, hogy a megkülönböztető Knox feladása a versenytársakat segítené, ellenben a platform töredezettségének csökkentése és az Android nagyvállalati integrációjának megteremtése végső soron a Samsungnak is hozhat babérokat.

Az L megkapja az iOS-ben már hosszabb ideje implementált lopásgátló funkciót is. A "factory reset protection"-ként említett funkcióval hiába állítja vissza gyári alapállapotra a tolvaj a telefont vagy tabletet, a tulajdonos által távolról letiltott eszközt csak ő oldhatja fel, bejelentkezési adatai nélkül nem tudja azt más használni, az eszköz csak papírnehezékként funkcionál. A lépés iOS-en bejött, a tolvajok kedvencének számító iPhone-okat valóban kevesebben lopják a funkció bevezetése óta. A biztonság szekcióban került szóba, hogy az L-től fogva lesz egy központi adatvédelmi vezérlőpult, ahol az egyes appok jogosultságait kezelhetjük. A bejelentés ezzel kapcsolatban kissé szűkszavú, de ez jelentheti azt, hogy az appok által kért jogosultságokat telepítés után is visszavonhatjuk - ami hatalmas előrelépést jelentene a platform számára.

Van béta!

A friss Androidot eddig mindig egyszerre tett elérhetővé a Google a fejlesztők és a felhasználók számára. Az L esetében a cég változtat ezen a gyakorlaton, a "fejlesztői előnézet", a Developer Preview kiadás a mai nap folyamán letölthetővé válik Nexus 7-re és Nexus 5-re, így el lehet kezdeni a munkát a végleges ART-ra való optimalizáláson és az új UI-paradigma adoptálásán. A hivatalos kiadás időpontját még nagy vonalakban sem lőtte be a Google, az "év folyamán" az egyetlen vállalt időintervallum az L rajtjára. Hasonlóképp nincs információ a támogatott Nexus- és Google Play Edition eszközök listájáról sem, a léc a 2012-es Nexus 7 alatt rezeghet, a többi jó eséllyel támogatott lesz/marad.

A Google I/O keynote egészében itt látható: