Ezért működik jobban a Nova Launcher a Google Pixel telefonokon

A Google hozzáadott egy API-t, amely lehetővé teszi, hogy a harmadik féltől származó indítók, például a Nova Launcher gördülékenyebb átmeneti animációkat jelenítsenek meg. Jelenleg csak a Pixel telefonokon van.

Korábban a harmadik féltől származó indítóalkalmazások gyakran jobb élményt nyújtottak, mint a legtöbb Android-telefonon található készletindító. A legutóbbi alkalmazások képernyőjének megújulásával és a gesztusok bevezetésével az Android 9 Pie rendszerben azonban A harmadik féltől származó indítók hátrányba kerültek, mivel ezek az új tapasztalatok beépültek az állományba indító alkalmazás. Az idő múlásával a Google arra törekedett, hogy a harmadik féltől származó indítói élményt ne olyan szörnyű legyen gesztusok használatakor, és ez mostanában kezdett sikeres lenni.

Ha az elmúlt néhány hónapban a Nova Launcher bétaverzióját használta Google Pixel telefonon, akkor észrevehette a gördülékeny animációkat a kézmozdulatokkal történő navigáció használatakor. Sajnos ugyanazokat az animációkat nem fogja látni, ha a Nova Launchert más eszközön használja, legalábbis egyelőre. Ahhoz, hogy megértsük, miért kell először röviden elmagyaráznunk, mi különbözteti meg a harmadik féltől származó indítókat, például a Nova Launchert az olyan készletindítóktól, mint a Google Pixel Launcher.

A Google először vezette be a gesztusos navigációt Android 9 Pie rendszerben. Annak érdekében, hogy a gesztusok a lehető legfolyékonyabbak legyenek, a Google-nak zökkenőmentessé kellett tennie az alkalmazások átmeneteit. Azt is lehetővé akarták tenni, hogy a felhasználók hozzáférjenek a teljes alkalmazáslistájukhoz a legutóbbi alkalmazások képernyőjéről. Mindkettő érdekében a Google úgy döntött, hogy áthelyezi a legutóbbi alkalmazások képernyőjét kezelő kódot az Androidról SystemUI to Launcher3, az Android nyílt forráskódú indítóalkalmazása, amelyből a legtöbb OEM-készletindító ki van építve. Így a Gyors lépés komponens született, és kiváltságos természete miatt az Android csak az előre telepített indítóalkalmazást teszi lehetővé a legutóbbi alkalmazások szolgáltatójaként. Ez lehet root hozzáféréssel felülírva ha a harmadik féltől származó indító támogatja, de a legtöbb felhasználó számára ez azt jelenti, hogy a harmadik féltől származó indítóalkalmazások mindig a részvényindítóra támaszkodnak a gesztusok és a legutóbbi alkalmazások képernyőjének kezelésében. Az eredmény, amint azt valószínűleg a legtöbben tapasztaltad, kissé ideges lehet, olyan átmenetekkel, amelyek nem tűnnek gördülékenynek és zökkenőmentesnek. Hacsak nem Google Pixel telefont használ.

A legtöbb Google Pixel telefonon létezik egy API, amellyel a harmadik féltől származó indítók sokkal natívabbnak tűnhetnek az alkalmazásról a kezdőképernyőre való visszaálláshoz. Néhány harmadik féltől származó indítóalkalmazás, mint például Niagara Launcher és a fent említett Nova Launcher kihasználja ezt az API-t, bár az utóbbi csak az fejlesztésen belüli v7 buildek. Amikor ezt az API-t használják, a harmadik féltől származó indítóalkalmazás szándékot és visszahívást kap a QuickSteptől, amikor a felhasználó egy csúsztatással hazamegy. A harmadik féltől származó indító ezután tanácsot adhat a gesztusrendszernek, hogyan animálja az ablakot, miközben az alkalmazásikonra kicsinyíti.

Íme egy példa, hogy néz ki ez a Niagara Launcherben, az indító fejlesztőjének jóvoltából 8 bitpit:

És itt van egy összehasonlítás, amely megmutatja, hogyan néz ki az animáció egy ASUS ROG telefon 5 és Google Pixel 4, mindkettő Nova Launcher v7.0.25-öt (a közzététel időpontjában a legújabb béta-kiadást) és Android 11-et futtat:

\r\n https://www.youtube.com/watch? v=equ-8yDw_Do\r\n

Most talán azon töprenghet, hogy ez az API kizárólag a Google Pixel telefonokhoz használható? A válasz: nem, nem. Az API a Launcher3/QuickStep és a megtalálható az AOSP-ben, vagyis bármely OEM indítóalkalmazás számára nyitva áll. Míg az API elkötelezte magát a Launcher3 mellett belsőleg 2020. július 21-én úgy tűnik, hogy az volt beolvadt az AOSP fő ágába az Android R QPR1 decemberi kiadásával.

Az API, amely révén a Nova Launcher és a Niagara Launcher natívabbnak érzi magát a Google Pixel telefonokon.

Kevin Barry, a Nova Launcher fejlesztője és az egyik első, aki észrevette ezt az API-t, elmondta nekünk, hogy gyanítja, hogy Az ok, amiért az OEM-ek nem használják ezt az API-t a Launcher3 fork-jaiban, az az, hogy kissé későn jelent meg az Android 11 kiadásában ciklus. Nem kevés erőfeszítést igényel a nagy AOSP-módosítások összevonása, és az Android R QPR1 frissítése ezekből határozottan sokat tartalmazott. Az elmúlt években ezeket a kódledobásokat "karbantartási kiadásnak" neveztük, de a Google már nem teszi meg ezeket az OEM-ek visszautasítása után (vagyis így hallottam). Ezért a LineageOS, a népszerű Android egyéni ROM a legújabb kiadását "LineageOS 18.1" a "LineageOS 18" helyett, ami azt jelzi, hogy a ROM a legújabb Android 11 kódbázison alapul, nem pedig a kezdeti Android 11 kiadáson.

Azt is érdemes megjegyezni, hogy ez az API csak a Google Pixel telefonokon érhető el a December Pixel Feature Drop, amely egybeesik a nyilvános Android R QPR1 kiadással. És annak ellenére, hogy a Pixel 2 megkapta utolsó frissítés decemberben, ez a frissítés nem tartalmazta az Android R QPR1 kódbázist, ezért a Nova Launcher v7-et futtató Pixel 2 tulajdonosok nem rendelkeznek ugyanazokkal a tapasztalatokkal, mint a többi Pixel. (A Pixel 2-tulajdonosok oldalra tölthetik a Pixel Launcher egy újabb verzióját, amely az API-val rendelkezik egy újabb Pixel eszközről, de felhasználói jelentések mutatják az animáció még akkor is bugos, ha időnként működik is. Emlékeztetőül: a Pixel Launcher a legtöbb tőzsdeindítóhoz hasonlóan a Launcher3 tetejére épül, de tartalmaz néhány Pixel-exkluzív funkciót is.)

Tehát mi kell ahhoz, hogy ezt az API-t hozzáadják más Android-eszközökhöz? Sajnos erre nincs egyszerű válasz, mert nem tudjuk pontosan, hogyan fejlesztik az egyes OEM-ek indítóalkalmazásait. Adott hogyan A Google szigorúan szabályozza a teljes képernyős kézmozdulatokkal történő navigációt, gyanítjuk, hogy a legtöbb OEM nem módosítja erősen a gesztusokhoz és/vagy a QuickStephez kapcsolódó kódot. Kivéve, ha egy OEM mindent megtesz a véglegesítés visszavonása, a kód feltörése vagy a frissítés megtagadása érdekében Launcher3, akkor látnunk kell, hogy ez az API hozzáadódik az OEM-indítókhoz, amikor azok a közelgő Android 12 kiadás. Valójában az egyik OEM-gyártó, akivel beszéltünk, az ASUS, azt mondta nekünk, hogy azt tervezik, hogy bevezetik ezt az API-t az Android 12 frissítésébe. Nem tudjuk, hogy a Google közölte-e ezt a változást az OEM-ekkel, de reméljük, hogy több OEM veszi észre ezt a változást. és úgy döntenek, hogy beépítik az API-t a Launcher3 forkjába, hogy javítsák a harmadik felek használatának élményét hordozórakéták.

A munka azonban ezzel nem ér véget. Még ennek az API-nak a beépítése után is még több munkát kell végezni a harmadik féltől származó indítók és az OEM indítók közötti paritás elérése érdekében. Például egyes OEM-eszközök villognak, amikor a felhasználó megérinti a képernyőt, mielőtt megjelenik egy animáció a kezdőképernyőre. Néha a rendszerindító alkalmazás jelenik meg a kiválasztott harmadik féltől származó indítóalkalmazás helyett (néhányszor előfordult már velem). A továbbfejlesztett átmeneti animáció jó, de senki sem akar foglalkozni a hibákkal sem az indítóalkalmazásban, sem a legutóbbi alkalmazások képernyőjén, ezért a gesztuskód állóképek tisztításra és/vagy szabványosításra szorulnak.

Köszönjük Kevin Barrynek és Peter Hubernek, hogy segítettek ebben a cikkben!