Android 6.0 Marshmallow

Közel egy hónapja kerültek piacra a Nexus új készülékei (Nexus 5X, Nexus 6P), és ez számunkra azért is fontos, hiszen most már hivatalosan is elkezdte „térhódítását” az Android új operációs rendszere (Android 6.0), amelyet Marshmallow névre kereszteltek. Az új OS-t próbálgatva, be kell látni, hogy külsőségekben nem sok változást hozott, megmaradtak a Lollipopnál is bevezetett Material designnál, ami kapott pár kiegészítő elemet. Természetesen ez nem azt jelenti, hogy az OS fejlesztői a korábbi rendszer klónjának javítását szeretnék lenyomni a torkunkon, ugyanis történtek jelentősebb változások. Ezek a fejlesztések főleg a „háttérben”, a rendszer stabilabb, biztonságosabb működésére irányultak. Ezek közül szedtem össze pár érdekesebb változtatást fejlesztők számára, amire érdemes és jó ha odafigyelsz a jövőben.

1. Alkalmazás engedélyek

Egyik legnagyobb változást az alkalmazás engedélyek módosítása hozta. Ha korábban telepítettél egy appot a Google Play-ről, telepítés előtt engedélyezni kellett az összes – az alkalmazás számára szükséges – hozzáférést, és csak ezután lehetett a telepítést folytatni. Tehát, ha a felhasználó szeretné használni az appot, eddig nem volt más választása, el kellett fogadnia az összes engedélykérést. Sajnos ez biztonsági kockázatot jelent. Főképp, ha az app a felhasználók személyes adataival dolgozik.

Az Android M-től kezdve az alkalmazás engedélyeket két csoportra bontották, normál és biztonsági szempontból veszélyes engedélyekre. A normál engedélyeket az app azonnal megkapja, ezzel szemben a biztonsági szempontból veszélyes engedélyeket, az app futása közben (az adott funkció esetén) kéri a felhasználóktól. Vagyis mostantól le kell kezelned, hogy mi történjen, ha egy implementált funkcióhoz (biztonsági szempontból veszélyes engedélyt igénylő) nem kapsz engedélyt a felhasználótól. Az Android M előtti alkalmazások esetén, ha bizonyos funkcióktól megvonunk engedélyeket, értelemszerűen az adott funkció nem megfelelő működését, bizonyos esetekben akár összeomlását is eredményezheti. Érdemes tehát felkészítened a korábbi appjaid az Android M-en való futtatásra, hiszen ha a felhasználók megvonnak olyan engedélyeket, amelyekkel veszélyeztethetik az app zökkenőmentes működését, azzal a felhasználói élményen esik csorba.

Az alkalmazás engedélyek később, bármikor módosíthatóak a készülék beállítások menüjében, így felhasználóként egy figyelmetlenségből történő elutasítást később is korrigálhatsz, ha arra a funkcióra mindenképp szükség lenne.

2. Energiatakarékosság, üzemidő javítás

Az Androidos készülékek nagy hányada szenved az egyre kisebb üzemidőtől, amely valljuk be, elég bosszantó. Ennek érdekében tettek lépést a Google fejlesztői két új energiatakarékos mód (Doze, Sandby) bevezetésével, amely nagyságrendekkel megnövelheti az eszközök készenléti idejét.

Számunkra az Doze mód az érdekes. Működését úgy képzelheted el, hogy az  Android figyeli a készülék mozgásérzékelőjét és amennyiben azt érzékeli, hogy egy ideje nem használod a készüléket, egyszerűen egy ún. „alvó módba” megy át. Valójában „lelövi” a készülék összes háttértevékenységét, vagyis erre az időre

• felfüggeszti az internet kapcsolatot,
• figyelmen kívül hagyja az összes wake lock kérelmet,
• az AlarmManagerben beállított riasztásokat elhalasztja, legalább is a következő időszakig, amíg felébred,
• nem fog WiFi kapcsolat után keresni,
• nem engedi az ún. sync adaptereket futni,
• nem engedi a JobScheduleröket futni.

Első hallásra brutális megkötés, hiszen sok app épül arra, hogy a háttérben szinkronizálja magát egy központi adattárral, vagy riasztja a felhasználóját egy beállított dátum előtt stb. Szerencsére a Doze módot úgy alakították ki, hogy bizonyos időszakonként egy rövid időre a rendszer kilép a Doze módból. Ilyenkor minden függőben lévő munkát elvégez, legyen szó akár riasztásról, akár háttérben történő adatszinkronizációról. Viszont ez az időablak, ahogy haladunk előre az időben, mindig egyre távolabb és távolabb helyeződik. Nagyon jól szemlélteti az időablakok elhelyezkedését az következő ábra.

Mostantól nem építhetsz arra, hogy egy frissítés például 5 percenként le fog futni, ami nem feltétlenül lehet probléma, hiszen ezzel értékes időt nyerünk a készülék készenléti idejének, és valjuk be, amíg a telefon az asztalon hever, nem foglalkozol azzal, hogy vajon frissültek az adatok a készüléken. Vannak esetek, ahol sajnos nem kedvező a Doze mód, lásd riasztások. Az Android se szeretné a fejlesztők kezét teljesen megkötni, így például az említett riasztások esetén is biztosít számodra kiskapukat. Érdemes a funkciód Doze módra történő felkészítése esetén ránézni az Android devportálra, hátha ajánlanak valamilyen megoldást az adott problémára.

Nem maradt más hátra, mint a kilépés a Doze módból, ami értelemszerűen akkor történik, ha a felhasználó ismét elkezdi használni a készülékét, például megmozdítja, vagy feloldja a képernyőzárat, esetleg csatalkoztatja hálózati töltőhöz. Ilyenkor minden alkalmazás végleg kiugrik a Doze módból és újra a normális, korábban megszokott módban működhetnek, mindenféle korlátok nélkül.

Érdekesség, hogy a Google csinált egy kísérletet két Nexus 9-es készülékkel. Az egyik készüléken Android L, a másik készüléken Android M operációs rendszert futtattak. A kísérlet végeredményeként azt tapasztalták, hogy az Android M-es készülék üzemideje kétszer akkora volt, mint az Android L-es társáé, tehát van potenciál az Android M Doze módjában.

A másik energiatakarékos mód (Standby) esetén, az Android a felhasználói szokásokat figyeli, azaz a felhasználó az egyes alkalmazásokat mennyire gyakran használja az adott készüléken. A továbbiakban ezeknek az adatoknak a birtokában dönti el, hogy egyes alkalmazásokat mennyire korlátoz le. A Doze mód esetén említett időablakot itt is használja a rendszer, annyi különbséggel, hogy ebben az esetben csak napi egy ilyen időablak létezik, és az is csak akkor, ha egy alkalmazás elég régóta van már Standby módban. Ebben az esetben az alkalmazások csak hálózati töltő csatlakozását követően léphetnek ki Standby módból.

3. Megszűnik az Apache HTTPClient támogatása

Érdemes elgondolkodni azon, hogy hálózati kommunikációra milyen segéd osztályt is használj a jövőben, ugyanis Android M-től kezdve megszüntetik a HTTPClient támogatását. Helyette a HttpURLConnection osztályt favorizálja az Android, mivel sokkal hatékonyabb az Apache megoldásánál, mind a forgalom – lásd válaszok cachelése stb. –, mind pedig energiatakarékosság szempontjából. Ha ezzel mégsem győztek volna meg téged, vagy csak túl nagy meló lenne átírni a korábbi alkalmazásaid, elég csak kiegészíteni a projekted build.gradle álományát az alábbi függőséggel, és mintha mi sem történt volna, továbbra is használhatod az Apache HTTPClient osztályát.

android {  
    useLibrary ‘org.apache.http.legacy’  
}

Újdonságok, érdekességek

A változtatások melletr természetesen jöttek újdonságok is az új verzióba. Itt is pár érdekesebb feature-t gyűjtöttem ki, amelyek egyes esetekben érdekesek lehetnek számodra és a felhasználók számára is egyaránt.

1. Ujjlenyomattal történő azonosítás támogatása

Végre az Android M-től bekerült egy rég várt funkció, amely a fejlesztők számára számtalan új fejlesztési lehetőséget rejt. Képzeld el a szituációt, hogy akár biometrikus adat segítségével is authetnikálhatod a felhasználóid, hiszen felhasználhatod alkalmazásaidban a készülék ujjlenyomat olvasó funkcióját. Nyilván, hogy ezt kipróbálhasd, a készülékednek támogatnia kell az ujjlenyomat olvasást. A jövőbe egyre több és több ilyen készülék fog megjelenni, köszönhetően a Google elég erőteljes lobbijának és támogatásának. Addig is kipróbálhatod az Android devportálon található mintakód segítségével, már ha van hozzá olyan készüléked, amely hardveresen is támogatja az ujjlenyomat olvasást.

2. Direkt Megosztás

Aki korábban már használt megosztást saját alkalmazásaiban, azok számára érdekességnek számíthat, hogy bevezettek egy új megosztási formát. Android M-től olyan alkalmazásokat is készíthetsz, amelyekből kijelölhetsz más alkalmazásokat, például közösségi alkalmazások (Facebook, Google+, Linkedin, twitter stb.), ahol tartalmakat oszthatsz meg. A megosztás nem a hagyományos módon a felhasználó hírfolyamára történik, hanem direkten egy közösségi partnerének.  A példa kedvéért képzelj el egy egy olyan alkalmazást, amely dokumentumokkal dolgozik. Ezen dokumentumokat a felhasználók megoszthatják egy, vagy több ismerősükkel. Erre egy példát is készített az Android, nézd meg.

3. App Linking

Nagyon hasznos, ha egy webes tartalmat mobilon próbálunk elérni és az egy jól ismert alkalmazáson belül tekinthető meg, a webes böngésző helyett. Ez nem egy újkeletű dolog, ugyanis az említett metológia (deep link) korábban is beállítható volt az alkalmazásokban. Ezt a sztorit továbbpörgette az Android és egy sokkal hatékonyabb megoldást kínálnak a fejlesztők számára, webes tartalmak linkelésére. Igaz még nem sikerült kipróbálnom, de első ránézésre nagy a hasonlóság a Facebook App Links megoldásával. Bővebb leírás a Facebook App Links-ről, olvasd.

4. Alkalmazás adatainak biztonsági mentése

Végül a kedvencem, hogy bekerült egy olyan funkció, amivel a rendszer biztonsági mentéseket készít az adott alkalmazás adatairól, beállításairól. Hogy miről készül mentés, az beállítás kérdése. Ezeket a backupokat a rendszer teljes egészében a felhőben tárolja méghozzá úgy, hogy az adatokat a felhasználó Google fiókjához párosítja. Így ha a felhasználó készüléket cserél és újratelepíti az appot, megkímélheted egy újrakonfigurációtól, hiszen a felhőből letölti az app korábbi beállításait, és lényegében ugyanott folyathatja, ahol a másik készüléken abbahagyta. Erről bővebb információ az android dev portálján, olvasd.

Összegezve, az új rendszerrel szemmel láthatóan a stabilitás irányába ment el a Google. Mindenki maga döntse el, hogy mennyire szerethető, vagy sem. Úgy gondolom, hosszabb távon mindenképpen hasznosabb egy stabilabb rendszer, még ha az a korábbiakhoz képest plusz munkával is jár, lásd alkalmazás engedélyek, vagy energiatakarékos mód.