Mindent a Marshmallow jogosultságkezeléséről

Az Android 6.0 Marshmallow messze legfontosabb újítása a hozzáférési modell reformja. Az alkalmazások a jövőben egészen másképp nyernek jogosultságot az eszközön tárolt személyes adatokhoz, mint eddig. Tömören: eddig a hozzáférés megadása bináris volt, a felhasználó az alkalmazás telepítése előtt áttekinthette a kért jogosultságokat és ha az összeset elfogadta, telepíthette az appot. Ez egy komoly biztonsági rés lett az évek során - gyakorlatilag annyian olvassák el a hozzáférési jogosultságok listáját, ahányan az EULA-t. Vagyis szinte senki, emiatt is szaporodhattak meg azok az alkalmazások, amelyek egyszerű hasznosságként (például zseblámpa-app) a címlistát másolják le.

A héten hivatalosan is bejelentett új Androiddal ez gyökeresen átalakul. Az appok telepítés helyett futás közben kérhetnek hozzáférést egyes adatokhoz és hardveres funkciókhoz, ezeket pedig a felhasználó elfogadhatja, vagy elutasíthatj. Ezzel alapvetően átalakul a fejlesztő-felhasználó közötti hatalmi egyensúly, nyugodtan kimondhatjuk, hogy ettől a ponttól a felhasználó teljes szabadságot élvez a jogosultságok megadása kapcsán, pontosan úgy, ahogy annak lennie kell (és kellett volna eddig is).

Hogy működik?

Az új hozzáférési rendszer nyomán persze rengeteg kérdés felmerül, érdemes ezeket gyorsan tisztázni. Az első és legfontosabb, hogy a korábbi Android-verziókat használók számára semmi nem fog változni, ők továbbra is ugyanúgy, telepítéskor (illetve újabb jogosultságok esetén frissítéskor) dönthetnek az elfogadásról-elutasításról, utóbbi esetben az eddigiekhez hasonlóan nem települ az alkalmazás. Ugyanez történik akkor is, ha Android 6.0-s telefonra telepítünk régebbi, nem frissített alkalmazást. Ezek az appok nyilván nincsenek felkészítve a hozzáférés megtagadására, így működésükhöz szükséges a korábbi rendszer megőrzése, a visszamenőleges kompatibilitás miatt.

Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.

Az új megközelítéssel így csak akkor találkozunk majd, ha új alkalmazásokat használunk az új rendszeren - ilyenkor lép működésbe a jogosultságok elemi szintű tiltása-engedélyezése. Hogy mi számít "új" és "régi" alkalmazásnak, azt a megcélzott API-verzió mondja meg. Az Android 6.0 az API level 23-nak felel meg, az olyan alkalmazások, amelyek ennél alacsonyabb verziót jelölnek meg, esetünkben réginek számítanak. Ezek az alkalmazások értelemszerűen nem vehetik igénybe a Marshmallow és a következő verziók egyéb képességeit, így a népszerűbb alkalmazások viszonylag hamar frissülni fognak majd. A régebbi appok, amelyek fejlesztése már leállt, azonban már nem fognak erre felkapaszkodni, így még nagyon sokáig lesznek velünk "rendetlen" alkalmazások is.

Fejlesztőknek tehát fontos szem előtt tartani, hogy csak akkor érdemes az API level 23-ra állítani az alkalmazást, ha azt már felkészítették az új hozzáférési rendszer kezelésére - másképp kellemetlen meglepetések érhetik a felhasználót. Ez mondjuk annyira triviális hiba, hogy alap teszteléssel kiszűrhető, így várhatóan ebbe azért végfelhasználók nem fognak belefutni.

Az Android 6.0 azonban a "régi" appok esetében is lehetővé teszi, hogy a felhasználó bizonyos jogosultságokat megvonjon a beállításokon keresztül. Ilyenkor a felület figyelmeztetést dob (így legalább a felhasználó nem a feljesztőt fogja hibáztatni - remélhetőleg), a jogosultságok azonban tényleg nem fognak működni. Az Android-fejlesztők gondolkodtak azon, hogy hogyan lehet ilyenkor az appok összeomlását minimalizálni, és ki is találtak egy áthidaló megoldást: ha az alkalmazás olyan függvényt hív, amelyhez a felhasználó visszavonta a jogosultságot, akkor nem kivételt dob a rendszer, hanem egyszerűen nem csinál semmit. Ha az app visszatérő értéket vár, akkor null vagy 0 lesz az, az app futása azonban nem áll le. Ez azonban még mindig nem ideális, hiszen hiányzik az akciót követő visszajelzés, aminek hiánya köztudottan gyorsan fel tudja húzni a felhasználókat.

További könnyítés, hogy a Google a hozzáférési jogosultságokat két szintre bontotta, a normál és a veszélyes hozzáférésre. A normálhoz a rendszer automatikusan hozzáférést biztosít, ezeket csupán deklarálni kell, a felhasználói élményt ez nem befolyásolja. A veszélyes hozzáféréseket pedig csoportokba rendezte, így a "telefonhoz" szerzett engedély egyúttal hozzáférést ad a hívásindításhoz, a hívásnaplóhoz, a kimenő hívások kezeléséhez, stb. Ez azt jelenti, hogy a kilenc fő csoporthoz maximum kilencszer kell engedélyezést kérni.

Hogyan érdemes elkérni?

"A jogosultságok lényege, hogy megvédje a felhasználó magánéletét (személyes adatait). Amikor jogosultságot kér az alkalmazás, akkor azt kéri, hogy a felhasználó adja fel a magánélete egy kis részét - ezért nagyon fontos, hogy az alkalmazás pontosan tisztázza, a hozzáférésért cserébe milyen előnyt biztosít" - fogalmaz a Google. Gyakorlatba ültetve ez azt jelenti, hogy a jogosultság elkérése előtt meg kell teremteni ehhez a feltételeket: kialakítani azt a kontextust, hogy a felhasználó értse, miért szükséges a jogosultság, és következtetni tudjon arra is, hogy mit veszít az elutasítással. Erre a rendszer dialógusablakja nem ad amúgy lehetőséget, így érdemes ezt a magyarázó kontextust még az appon belül megteremteni.

A rendszer védi a felhasználót a spam ellen is, így az elutasított jogosultság-kérés után a második kérelemnél már le lehet tiltani az újbóli megkérdezést. Fontos, hogy az app az elutasításról értesül, ilyenkor indíthat egy olyan ágat, amely tovább "győzködi", informálja a felhasználót, mielőtt újra elkérné a hozzáférést. Abban az esetben, ha a felhasználó bejelöli, hogy több hozzáférési kérést nem kíván látni, csak a Beállítások menüből lehet újra engedélyezni azt.

Újratervezés!

Az új jogosultságkezelés a fejlesztők számára sokkal több feladatot ad, mint néhány kivétel kezelése - a legtöbb esetben a UX, a folyamatok jelentős részét alaposan át kell tervezni. Erre pontosan azért van szükség, hogy a hozzáférés kérése a megfelelő, magát magyarázó kontextusban történjen - a Google példájában a hangos jegyzet készítésekor jöhet a mikrofonhoz való hozzáférés elkérése, így a felhasználó fejében is tiszta lesz, hogy mire akarja azt az app használni.

A UX-guruknak az adja majd fel a leckét, ha nem ennyire triviális a hozzáférés és a kontextus közötti kapcsolat. Ilyenkor szükségessé válhat a felület újratervezése, magyarázó szövegek beiktatása is, illetve a folyamatot is érdemes úgy alakítani, hogy kicsit logikusabb legyen a hozzáférés elkérése. A Google felhívja a figyelmet, hogy a jogosultságért cserébe kapott funkciót ilyenkor azonnal érdemes biztosítani a felhasználónak, kvázi megnyugtatva, hogy működik az alkalmazás, működik a hozzáférés, és tényleg az zajlik a háttérben, amit várt. Szerencsére ezekhez az évek alatt már elegendő tapasztalat gyűjt össze a legtöbb mobilos fejlesztőcsapatnál - az iOS-ben (és a BB 10-ben is) ugyanis a kezdetektől fogva így működik a hozzáférés szabályozása.

Fejlesztők számára ennél komolyabb fejfájást jelent, hogy az eddig adottnak vett hozzáféréseket futás közben folyamatosan ellenőrizni kell kódszinten. Ráadásul mivel a felhasználó a korábban megadott jogosultságot a beállításokból bármikor meg is vonhatja, tovább szigorodik ez a feltétel. Ez rengeteg helyen komoly áttervezését igényli a kódnak, ami semmiképp nem ígérkezik egyszerűnek.

Komolyabb feladat az alkalmazást úgy megtervezni, hogy bizonyos jogosultságok hiányában részleges funkcionalitást továbbra is nyújtani tudjon. Ehhez sok belső függőséget fel kell bontani, és létre kell hozni egy egyszerűbb, butított UX-et. Ennek kitalálása, implementálása és tesztelése már komolyabb erőforrást igényel, ezt mindenképp érdemes egy app fejlesztésébe belekalkulálni.