Google: az Android jövője kontextuális

Bemutatta androidos fejlesztéseit, közte az új, "M" kódnéven futó rendszert a Google a most zajló Google I/O fejlesztői konferencián. A tavalyi Android frissítés, a Lollipop rengeteg újdonságot hozott, többek között egy vadonatúj UI-paradigmát is, a Material Designt. Idén a Google nem nyúlt ilyen markánsan a rendszerhez - legalábbis látszólag. A motorház alatt azonban nagyon fontos változások jönnek, amelyek alapvetően változtatják meg, hogy hogyan használjuk a telefonunkat. Ezek nem mind kötődnek az Android M-hez, de mobilos fejlesztések révén ide szedtük össze. Akinek felkelteti az érdeklődését az új rendszer, és rendelkezik Nexus 5, 6, 9 vagy Nexus Player készülékkel, már most kipróbálhatja a Developer Preview verziót. A hivatalos megjelenés őszre várható.

App Permissions - végre, végre, végre.

Végre. Mély levegő: a Google gyakorlatilag teljesen átvette az iOS jogosultság-modelljét. Ez persze nem baj, sőt, a lehető legjobb dolog, ami ezen a területen történhetett. A legfontosabb változás, hogy a felhasználónak beleszólása van, hogy az alkalmazás által kért hozzáférések közül melyeket adja meg, és melyeket utasítja el. Ha nem látja szükségét, hogy mondjuk a Facebooknak hozzáférést adjon a pontos GPS-koordinátákhoz, akkor egy kattintással megvonható ez a jogosultság, ettől a ponttól az app nem kapja meg ezt az információt a rendszertől.

Az iOS-től "nyúlás" nem is ebben, hanem a jogosultságok felvezetésében van. Telepítéskor ugyanis nem önti rá a Play Store az összes jogosultságot a felhasználóra, hogy azonnal döntsön, mihez járul hozzá, hanem az iPhone-os alkalmazásokhoz hasonlóan akkor dobja fel az igényt, amikor az alkalmazás először kér hozzáférést. Így a felhasználó pont ott, pont akkor dönthet erről, amikor az appot már használja, és várhatóan pontosan tisztában van azzal, hogy milyen funkció megvalósításához kér például kamerát, lokációt, vagy bármilyen egyéb jogosultságot az app. Ennek a menet közbeni engedélyezésnek van egy pozitív mellékhatása is, az automatikus frissítések nem akadnak fenn, ha az app egy új jogosultságot kér - eddig mérhető arányban akasztotta a friss verziók terjesztését, ha manuálisan le kellett okézni az új jogosultság megadását.

A Gitlab mint DevSecOps platform (x) Gyere el Radovan Baćović (Gitlab, Data Engineer) előadására a november 7-i DevOps Natives meetupon.

Az App Permissions szépséghibája, hogy visszafelé nem kompatibilis. A Google bejelentése szerint kizárólag olyan alkalmazások esetén működik a fent leírt módon, amelyek már az Android M SDK-val készülnek - jó eséllyel tehát egy évekig tartó folyamat lesz az átállás, a régi, elhagyott alkalmazások pedig soha nem fogják támogatni az új paradigmát.

Külső böngésző vagy WebView? Van kompromisszumos megoldás!

Komoly gondnak látja a natív appok és a web együttélését a Google (egyébként nem csak a Google, a Facebook Instant Articles pontosan erre a problémára ad egy ellenkező irányú választ). A probléma röviden: ha alkalmazásból szeretnénk külső linket elérni, akkor a fejlesztőnek választania kell, vagy az appon belül jeleníti meg, WebView-t használva, vagy megnyitja a linket az alapértelmezett böngészőben. Mindkettőnek komoly előnyei és hátrányai is vannak: a WebView-val az appon belül tartja a felhasználót, viszont nem használhatja annak böngészős kontextusát (például bejelentkezéseit). Ha a böngészőbe dobja át a felhasználót, akkor az elhagyja az alkalmazást (ahová manuálisan kell később visszatérnie).

A Google szerint van megoldás, ami a kettőt ötvözni tudja, ez a Chrome custom tabs. Ezzel a natív alkalmazások úgy nyithatnak meg webes tartalmat a Chrome-ban (annak teljes kontextusával), hogy a felhasználót még mindig az alkalmazáshoz kötik. Például testre szabható a megnyíló tab színe és a megjelenő gombok, egyedi átvezető animációk definiálhatóak, és a legfontosabb: a vissza gomb pedig visszadobja a felhasználót az appba. Hogy egy kicsit izgalmasabb legyen a fejlesztőknek ez a megoldás, a Chrome custom tabs képes a háttérben előtölteni az oldal tartalmait, így tényleg natív-közeli élményt lehet elérni a használatával.

A Chrome custom tab használatához érdekes módon nincs feltétlenül szükség Android M-re, sőt, Lollipopra sem, az a Chrome 44-es kiadásával együtt lesz elérhető a fejlesztők számára (a dev channelben pedig már most is kipróbálható a funkció), a minimum követelmény a Jelly Bean.

App Links - intents, tovább gondolva

Az Android a kezdetektől fogva úttörőnek számít az appok közötti megosztás dolgában, a telepített alkalmazások adatokat (szöveget, képet, linket, stb.) tudnak egymásnak átadni, így például tudunk cikket megosztani Feedlyből Telegramba. Ez a képesség azonban egy ponton komoly problémába ütközik, mégpedig a webes linkek megnyitásánál. Az appok ugyan be tudják magukat regisztrálni, hogy az adott doménhez tartozó webes linket inkább a natív alkalmazásban nyitnák meg, a rendszer akkor is feldobja a felhasználónak, hogy böngészőben vagy a natív alkalmazásban szeretné a tartalmat megnézni.

Ezzel szakít az új App Links, a jövőben a fejlesztőnek lehetősége van arra, hogy a saját doménjére mutató linkeket a saját alkalmazásában mutassa, minden köztes lépések nélkül. A lépés persze komoly biztonsági kérdést is felvet, mi van, ha egy fejlesztő nem csak a saját doménjeire szeretné rátenni a kezét - erre a megoldás frappáns, az adott weboldal gyökerében kell elhelyezni egy parányi igazoló dokumentumot, amely a Google felé igazolja, hogy a domén tulajdonosa és az app fejlesztője azonos.

Android Pay

Azt már régóta tudjuk, hogy újra megpróbálkozik a mobilfizetéssel a Google, a Wallet helyett/mellett indul az Android Pay szolgáltatás. A cég ígérete szerint a rendszer minden olyan terminállal kompatibilis, amely támogatja az NFC-s fizetést, de emellett in-app vásárlásokra is alkalmas. A bemutató alapján nem világos, hogy a Pay funkcionalitását tekintve miben tér el az előd Wallettől vagy épp az Apple-féle Pay rendszertől. A támogatott képességek nagyjából megegyeznek: ha a fejlesztő implementálja, akkor alkalmazáson belül úgy fizethetünk az Android Pay-jel, hogy semmilyen kártyaadatot nem kell megadnunk. A cég ígérete szerint az Android Pay nyílt rendszer lesz, amelybe más vállalatok fizetési megoldásai is integrálhatóak - nagy kérdés, hogy mit szólnak ehhez az igazi versenytársak, a Visa és a MasterCard.

A Google bejelentése szerint az Android Pay egyelőre az Egyesült Államokra fókuszál, a nagy mobilszolgáltatókkal már megegyezett a szükséges app előtelepítéséről az értékesített telefonokra, a rendszer pedig induláskor mintegy 700 ezer ponton lesz használható fizetésre. Használatához KitKatre lesz szükség.

USB-C és ujjlenyomatolvasó-támogatás

Android M specifikus fejlesztés, hogy a rendszer immár alapból támogat két új hardvert is, egyrészt az USB-C portok, másrészt az ujjlenyomatolvasók kaptak saját driver modellt. Kezdjük az előbbivel: az USB-C nem csak formájában hoz újdonságot, az átvitt adatok típusa (sima USB forgalom mellett például videó is küldhető) is módosul, illetve az áram is két irányba folyhat. A rendszerszintű implementáció azt jelenti, hogy ezeket nem a gyártóknak kell egyenként belefejleszteni a rendszerbe, az új Android már alapból tudja majd kezelni ezeket a képességeket - és ha például egy másik USB-C-s eszközt kötünk a tabletünkre, akkor megmondhatjuk, hogy melyik eszköz viselkedjen töltőként és melyik vegye fel a töltést.

Hasonló a logika az ujjlenyomat-olvasókkal, ezt eddig a gyártók fejlesztették bele a rendszerbe, ezért viszonylag kevesen vállalkoztak rá, a külső fejlesztők pedig egyedi API-kon keresztül érhették el az érzékelőt. Az Android M-ben már hivatalos lesz a támogatás, az appok pedig standard API-kat hívhatnak, ha a felhasználót szeretnék azonosítani - ez az előbb említett Android Pay miatt is fontos, a fizetés nyugtázása így egyszerűen egy tapintás lehet, pont mint az iPhone-on.

Doze - még jobb energiahatékonyság

A Google évek óta fókuszban tartja, hogy az Android rendszerszinten is energiahatékony maradjon - ez érthető, a rendszer szinte kizárólag olyan eszközökön fut, amelyek akkuról üzemelnek. A Lollipopban a Project Volta célozta ezt a területet, amely egyrészt a fejlesztőknek adott jobb analitikát a saját alkalmazásaik optimalizálásához, másrészt rendszerszinten is tett a spórlásért. Ez utóbbit vitte tovább a Google a Doze funkcióval, azonban kérdéses, hogy ez nem megy-e a használhatóság rovására.

Az androidos eszközök használaton kívül is dolgoznak, az appok a háttérben rendszeresen felébresztik a rendszert és frissítik állapotukat. A Google szerint ez energiapazarló és nem is mindig szükséges. A Doze folyamatosan figyeli, hogy mikor használjuk az eszközt, használaton kívül pedig exponenciálisan növeli az ilyen frissítések között eltelő időt. Az aktivitást a rendszer több paraméterből, például a mozgásból állapítja meg, ha nincs aktivitás, akkor az appokat gyakorlatilag levágja az internetről. A push üzenetek és a riasztások ilyenkor is átmennek, a háttérben futó szinkronizációt azonban letiltja rendszerszinten az Android. A spórlás kézzel fogható: a korlátozott szinkronizációval a készenléti idő megduplázódik, igaz, ezért az alkalmazások kegyetlen megregulázásával kell fizetni.

A fentieken túl persze a Google még rengeteg ponton nyúlt hozzá a rendszerhez, átrajzolta például a másolás-beillesztés és a hangerőkezelés UI-t (végre és végre), lesz betűrendes app listázás (végre-végre) és átalakul a megosztás menü is, amely a leggyakrabban használt app-célpont kombinációkat dobja fel (például főnök-Gmail vagy barátnő-Hangouts).

Now on Tap

A tegnap délutáni bejelentéscunami teteje azonban nem az Android M, hanem egy külön bejelentett újdonság, a Now on Tap volt. A Google Now ígérete 2012-ben az volt, hogy (a személyes adatainkért cserébe) releváns, kontextuális információkat és tippeket dobál fel. Ezt három év alatt sem sikerült elhozni, az ezerszer mutogatott reptéri információktól eltekintve igen szegényes volt a Now szolgáltatáskínálata, amely ráadásul relevanciában sem nyújtott kiemelkedőt.

A Now továbbgondolása azonban igazi áttörésnek ígérkezik, amely tényleg képes megváltoztatni azt, ahogyan a telefonunkat jelenleg használjuk. A kontextuális kereső ugyanis külső alkalmazásokkal is képes együttműködni, az éppen a képernyőn található információt értelmezve pedig egészen különleges kereséseket végezhetünk. A Now on Tap rendszerszintű integrációja tényleg rendkívül gazdag interakciókat tud megvalósítani, függetlenül attól, hogy milyen alkalmazásból indítjuk.

^{Szavakban nehéz, jöjjön a videó.}

A Now on Tap alatt szolgáló gépi tanulási technológia talán a legizgalmasabb fejlesztés, amely a kontextus alapján képes értelmezni és újraértelmezni szavakat, kifejezéseket - legalábbis a cég ígérete szerint. A demóban a rendszer fel tudta ismerni az étterem nevét és a teendőt (to do) egy Viber-üzenetből, a mozifilmet egy emailből, az előadót a Spotify kliensből - pusztán a kontextus alapján. A sima keresésnél pedig nem áll meg a Now on Tap, a felismert entitástól függően a releváns következő lépést is felajánlja, ráadásul mobilos kontextushoz illeszkedő módon: a teendőhöz emlékeztetőt rendel, az étteremhez kritikát és asztalfoglalást kínál, a mozihoz pedig IMDB és jegyvásárlás ugrik fel. Ez a natív appok, a gépi tanulás (természetes nyelv feldolgozása) és a Google piacvezető keresőjének olyan kombinációja, amire eddig nem láttunk példát - és frappánsan átvágja a Google natív vs web dilemmájának gordiuszi csomóját is. Az új képességekhez módosítani kell a meglévő androidos alkalmazásokat, szükséges az App Indexing for Google search implementálása.

A megcsillantott tudás persze az ideális eseteket mutatja, nem tudni, hogy valós használatban (és pláne más nyelveken) hogyan teljesít majd a Now on Tap - de ha a felvázolt jövőkép akár néhány éves távlatban megvalósulna, már az is hatalmas váltás lenne a mobiltelefonok használatában. Az igazán izgalmas pedig az, hogy ebben a jövőben a Google gyakorlatilag egyedül lesz: az Apple-nek marginális a jelenléte a gépi tanulásban, a Microsoftnak pedig releváns mobil operációs rendszere nincs, e kettő jelenleg csak a Google-nél fut össze - a cég pedig nem fél ezt használni.