Google I/O: ilyen irányba fejlődik az Android

Android N(évtelen)

A legnagyobb várakozás természetesen az idei Android-főverziót előzi meg, amelyet szokás szerint a fejlesztői konferencián szokott megkeresztelni a Google. Ez most elmaradt, továbbra is az "N" kódnéven fut a fejlesztés, a név megtalálására pedig közösségi kezdeményezést indított a vállalat - és külön kérte, ne a Namey McNameface legyen.

A rendszer (a szokásostól eltérően) idén nem a konferencián mutatkozott be, a Google még március 10-én lerántotta a leplet a mobilos rendszer következő kiadásáról. Emiatt most viszonylag kevés újdonság maradt a konferenciára, a Google mérnökei inkább a már bejelentett funkciókat részletezték. Az "N" egyébként új nyilvános előnézeti kiadást is kapott, az előzetes terméktervnek megfelelően most az első, "béta minőségű" kiadást tölthetik le a tesztelők.

A rendszer alapvetően három fő területen újul majd meg. Az első a teljesítmény, ami a Vulkan grafikus API implementálásában és egy vadonatúj Android N JIT fordító fejlesztésében merül ki. Előbbi az Apple Metal és a DirectX 12 mintájára egy új, alacsony szintű grafikus API, mely a jelenleg használt OpenGL-hez képest sokkal kevésbé terheli a processzort - ez jobb teljesítményt, alacsonyabb fogyasztást, szebb grafikát jelent majd, dióhéjban.

Az új fordító megint teljes hátraarcnak tűnik első látásra: az Android eredetileg JIT-fordítót használt, amely az alkalmazások Java kódját futás közben fordítja és optimalizálja, ezt 2014-ben cserélte AOT (ahead-of-time) fordítóra (pontosabban egy fura JIT-AOT-interpretált hibridre a Google, amely telepítéskor készíti el az adott telefonhoz optimalizált gépi kódot. Ez utóbbi energiatakarékosabb és magasabb sebességet hoz, azonban a telepítést nagyon megnyújtja.

Az Android N-ben megint generációt vált az Android Runtime, a Java kód fordításáért és futtatásáért felelős réteg. A fordító által előállított kód újra nagyot gyorsul, a Google másfélszeres-hétszeres gyorsulást ígér, kódtól függően. Az AOT kidobásával a telepítési idő is jelentősen, negyedére rövidül. Meglepő, hogy a fordítandó metódusok jobb válogatásával a fordított kód mérete felére esik, vagyis jelentősen visszaeshet a memóriafoglalás. A hibrid megközelítést azért megtartja az Android Runtime, a JIT által előállított optimalizált kódot ki is írja a háttértárra, az app következő futtatásakor pedig ezt, és nem az eredeti nyers kódot veszi elő.

Biztonság-biztonság-biztonság

Biztonságban is nagyot lép előre az Android - ígéri a Google. A rétegzett mélységi védekezés újabb apró erősítéseket kap. Elsőként a háttértár titkosítása vált finomabb szemcsézettségre, immár az egyes fájlokat külön-külön titkosítja a rendszer. Ez lehetővé teszi, hogy az egyes fájlok tartalmához is differenciált hozzáférést tudjon adni az operációs rendszer a jelenlegi fekete-fehér megközelítés helyett. Mindez előrevetíti a többfelhasználós forgatókönyvet, melyben az egyes userek még akkor sem tudnak hozzáférni egymás adataihoz, ha a rendszerszintű védelmet meg tudják kerülni.

Komolyan megerősíti a beépített multimédiás framework biztonságát a Google, a Stagefright-sebezhetőség hozadékaként. A cég ugyanis rájött (csak most?), hogy e könyvtár például webes tartalommal vagy kéretlenül küldött fájlokkal is meghívható, ezzel pedig ugyanúgy ki van téve támadásoknak mint a böngésző, így hasonló biztonsági funkciókkal kell rendelkeznie. Ennek megfelelően a frameworköt az alapoktól átdolgozták a fejlesztők, a feldolgozás különszálazott, SELinux-erősített folyamatokban zajlik, így az esetleges sebezhetőségek kihasználási lehetősége sokkal kisebb.

^{Na ezt soha nem látjuk majd többé. (kép)}

A harmadik fejlesztés talán a legérdekesebb - a rendszer képes lesz a háttérben szoftvert frissíteni, pontosan úgy, mint a Chromebookok. Ehhez a telefonon vagy tableten két rendszerkép lesz, és míg az egyik éppen fut, a másik frissülhet. A telepítést követően a rendszer értesíti a felhasználót, újraindulás után pedig már a frissebb verziót indítja. Ezzel a sokszor hosszúra nyúló frissítési folyamatot egy standard újraindulásra lehet rövidíteni, így a hosszas, akár fél órára nyúló rendszerfrissítés körülbelül egy percre rövidül a felhasználó szemszögéből. A változásra szükség is van, ha a havi biztonsági frissítések elterjednek, akkor nem lenne ideális, ha a felhasználók fejében a Windows-féle frissítési hercehurca maradna meg - az egyszerű újraindítás és a dupla rendszerpartíció ebben segíthet.

UI-donságok

A harmadik kiemelt terület a felhasználói felületet (UI) érinti. Nagy újrarajzolásra most nem került sor, a Google hagyta a helyén a Lollipoppal bevezetett Material Design formai nyelvet. Néhány apró fejlesztés azért bekerült az N-be, például az értesítési sávok új funkciókkal gazdagodtak - de ebben a márciusi bejelentéshez képest nem volt újdonság.

CI/CD-vel folytatódik az AWS hazai online meetup-sorozata! A sorozat december 12-i, ötödik állomásán bemutatjuk az AWS CodeCatalyst platformot, és a nyílt forráskódú Daggert is.

A korábbiakhoz képest viszont részletesebben beszélt a Google a multitask megoldásról, vagyis az appok párhuzamos futtatásának lehetőségéről. Sajnos a várva-várt szabad ablakos megközelítés kimarad, csupán osztottképernyős lehetőség kerül be az N-be, illetve a tévék kapnak egy PiP (picture-in-picture) módot is. A produktivitás jegyében a cég módosította az alkalmazásváltó képernyő működését, amely ezentúl csak a hét utolsó appot mutatja, az appváltó gomb dupla érintésére pedig a két utolsó app között ugrálhatunk oda-vissza.

Instant Apps

A végére hagytuk talán a legérdekesebb és legfontosabb újdonságot, amit a Google csak Android Instant Apps névre keresztelt. A névnek megfelelően ezek olyan natív (!) alkalmazások, amelyek hosszas letöltés-telepítés nélkül futtathatóak a telefonon - gyakorlatilag úgy viselkednek tehát mint a weblapok, de egészében natív androidos alkalmazások.

A funkcióhoz az szükséges, hogy a fejlesztő kisebb, önállóan is működni képes részekre szeletelje az alkalmazását, ez a töredék pedig villámgyorsan le tud töltődni és el tud indulni a felhasználó telefonján. Az indításhoz csupán egy standard URL-re kell kattintani, amely a Google szerverein lévő binárisra mutat, és néhány tizedmásodperc múlva indul is az app. Fontos megjegyezni, hogy a rendszer kizárólag a hivatalos forrásból származó binárist fogja lefuttatni, így elvben a felhasználó védve van a támadás ellen. És az igazán nagy csavar: az Instant Apps futtatásához nem szükséges az Android N, sőt, Lollipop sem, a megoldás egészen Android 4.0-ig kompatibilis visszafelé - ami azt jelenti, hogy a telepített bázis mintegy 98 százaléka elérhető az új megközelítéssel.

Az Instant Apps hatása egyelőre felmérhetetlen - minden olyan esetben, ahol a webes alkalmazás valamiért nem elegendő és natív alkalmazásra lenne szükség, de csak ritkán (vagy egyetlen egyszer) van szükségünk rá, kiválthatja a teljes alkalmazást. A Google egyik példája a parkoló app, amellyel fizethetünk a parkolásért - a natív app elérhetővé teszi az Android Pay-t, a felhasználói élmény kiváló, de az app nem marad a telefonon, hanem kilépés után teljesen törlődik.

Ezen egyelőre csupán néhány meghívott fejlesztővel dolgozik együtt a Google, a funkció pedig a következő hónapokban lesz elérhető.