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.

Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.

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ó: