Google skubber virkelig den nye gestusnavigation i Android 10. Selvom de ikke har forbudt andre gestuskontrolordninger, har de sat en masse grænser.
Efter at have eksperimenteret med knapbaserede bevægelseskontroller i Android 9 Pie, gik Google tilbage til tegnebrættet for at forbedre smidigheden og enhåndsbrugen af Androids gestusnavigation. Med Android 10 nåede Google frem til en løsning, der visuelt ligner iOS: en bevægelseslinje, der kan stryges op for at gå hjem eller stryges til venstre eller højre for at skifte mellem apps. Da bevægelseslinjen er meget tyndere end den dedikerede plads til det tidligere navigationsskema med tre knapper, giver Android 10s bevægelser apps mere plads til at vise indhold nederst på skærmen. For at håndtere manglen på en dedikeret tilbage-knap tilføjede Google et indadgående stryg fra venstre eller højre kant af skærmen for at udløse tilbagehandlingen. Googles nye og forbedrede bevægelser er et skridt i den rigtige retning, selvom nogle stadig mener, at tredjepartsalternativer er overlegne.
Selvom der stadig er plads til at forbedre (og det er der bestemt), presser Google sine Android-partnere til at vedtage disse nye navigationsbevægelser, fordi virksomheden ønsker ikke at belaste app-udviklere med at skulle rumme flere forskellige gestusnavigation ordninger. Android-enhedsproducenter som OnePlus, Samsung, Xiaomi, Huawei, OPPO, Vivo og ASUS er blot nogle af virksomhederne med deres egne bud på gestusnavigation. Disse virksomheder har allerede investeret en masse udviklingsindsats i at bygge deres egne gestus, så Google tvinger dem ikke til helt at opgive deres arbejde.
"Brugere ønsker i stigende grad fordybende oplevelser i Android, og en ting, som enhedsproducenter har gjort, er at forsøge at nærme sig dette fra en softwareside. Og det, de har gjort, er at bygge deres egen gestus-navigation. Og hver enhedsproducent har et forskelligt indtryk af, hvordan gestusnavigation skal fungere. Det, vi genkender på en platformsside, er, at den slags bliver sindssyg for en udvikler. Når du tænker på N forskellige gestus-navigationer, når du forsøger at udvikle, designe, teste for din app, bliver det bare lidt vanvittigt. Så med det i tankerne introducerede vi denne gestus nav i Q, og vi vil standardisere økosystemet fra og med Q på 3 knapper og vores model på vej frem." – Ronan Shah, produktchef hos Google på Android System UI-teamet, hos Google I/O 2019.
I stedet har Google omskrevet sit regelsæt for Android- og Google-appkompatibilitet, hvilket tvinger OEM'er til det sideline deres egne gestus til fordel for Googles, mens de også begrænser funktionaliteten af OEM fagter.
Android 10 Gesture-kompatibilitetskrav
Efter hver større Android-platformsudgivelse opdaterer Google Android Compatibility Definition Document (CDD) til skitsere de nye krav, som alle enheder skal opfylde for at blive betragtet som kompatible med den seneste version af Android. Dette er en af forudsætningerne for at få en Android-licens, som er nødvendig for at bruge Android-brandingen i markedsføringen. Det er også en forudsætning for at opnå godkendelse til at distribuere Google Mobile Services, pakken af Google-apps, -tjenester og -biblioteker, der er forudinstalleret på de fleste Android-enheder, der sælges internationalt.
I CDD til Android 10, Google har opdateret afsnit 2.2.3 om softwarekravene til håndholdte enheder (AKA smartphones) med nedenstående ordlyd. Disse udtalelser informerer OEM'er om Googles forventninger til, hvor stort triggerområdet skal være for navigationsbevægelser.
Google anbefaler, at bevægelsesgenkendelsesområdet for hjemmehandlingen skal være inden for 32 dp (dp står for tæthedsuafhængig pixel) fra bunden af skærmen, men de stiller ikke dette til et krav, så OEM'er kan stadig tilbyde flydende bevægelseskontroller såsom EMUIs flydende navigationsdockingstation.
Hvis en OEM tilbyder en swipe-in-bevægelse fra enten venstre eller højre kant af skærmen, kræver Google, at triggerområdet er mindre end 40 dp fra kanten (ideelt set 24 dp i bredden.) Bemærk, at dette giver OEM'er mulighed for at skabe forskellige følsomhedsindstillinger for sidebevægelser, så længe triggerområdet ikke overstiger 40 dp. Faktisk Google tilbyder netop dette i sin egen Android 10-udgivelse. Som standard er indsættelsen for bagbevægelsen 24dp på Pixel, men den kan sænkes til 18dp eller hæves til 32dp eller 40dp.
I et senere afsnit af CDD'en, specifikt afsnit 7.2.3, der dækker navigationstaster, giver Google detaljerede krav til, hvordan bevægelser til bagsiden, hjemmet og de seneste apps handlinger skal fungere. De fleste af kravene fokuserer på at sikre, at systemets adfærd er konsistent for app-udviklere, men der er et par bemærkelsesværdige udsagn, der kan påvirke brugeroplevelsen.
Selvom Google ikke påbyder, at et swipe op fra den nederste kant udløser hjemmehandlingen eller et swipe op og hold udløse den seneste apps-oversigt, kræver Google, at strygebevægelser fra siderne udløser tilbagehandlingen. Dette vil især betyde, at de tilpassede bevægelser leveret af Samsungs One Hand Operation+ ville ikke være tilladt, men da One Hand Operation+ ikke er installeret ud af boksen, kan den muligvis få en godkendelse.
Hvis en OEM leverer et flydende systempanel, der udløses via en sidebevægelse, skal OEM placere udløseren område i den øverste 1/3 af venstre eller højre side og må ikke tillade panelet at overstige en størrelse på 1/3 af skærmens størrelse kant. OEM kan dog tillade brugeren at indstille triggerområdet under den øverste 1/3 af kanterne. Dette sprog blev sandsynligvis tilføjet for at imødekomme Samsungs Edge Panel-funktion.
Android 10-kompatibilitetsdefinitionsdokumentet placeres ikke at mange begrænsninger for, hvad OEM'er kan gøre med gestus, men som jeg nævnte før, er det bare at overholde CDD'en en af forudsætningerne for at opnå en Android-licens og godkendelse til at distribuere GMS. Google har et separat dokument, som de distribuerer privat til alle dets licenserede Android-partnere; dette dokument opregner de tekniske krav, som virksomheder skal følge for at få lov til at distribuere GMS, og det har yderligere bestemmelser vedrørende gestusnavigation i Android 10. Vi har fået en kopi af dette dokument med titlen GMS Requirements v7, dateret 3. september 2019.
Bevægelsesnavigationskrav til GMS-godkendelse
Google Assistant er en utrolig vigtig tjeneste for Google, så Google samler den som en del af Google-appen og kræver, at alle Android-partnere distribuerer det som en del af pakken af GMS-apps til "Almindelige" (ikke-Android Go) enheder. Kravene slutter dog ikke der. Siden Android 5.1 har Google påbudt, at et langt tryk på Hjem-knappen udløser Assist-handlingen, som som standard vil påberåbe sig Google Assistant, da Google også kræver, at Google-appen skal være standardbehandleren for Assisten handling. Der er dog ikke længere en dedikeret startknap i Android 10, så Google har sat nye krav til, hvordan man udløser assistenten med en gestus.
For at udløse Google Assistant med Googles gestusnavigation skal du stryge diagonalt fra nederste venstre/højre hjørne. Google kræver, at denne bevægelse er til stede på alle enheder, der kører Android 10, uanset om Googles bevægelser er standard navigationskontroller ud af kassen eller ej. Hvis en OEM implementerer sine egne gestus-navigationskontroller, kan den implementere sin egen trigger for at starte Assistant-appen, men den nøjagtige implementering vil blive gennemgået fra Google. Nogle OEM'er som OnePlus og Xiaomi lader dig udløse assistenten ved for eksempel at trykke længe på tænd/sluk-knappen.
Google definerer tre typer referencenavigationsmodeller:
- Klassiske navigationsknapper med tre knapper. Disse kan være knapper på skærmen eller hardware, men de skal have en vis afstand imellem dem. De tre knapper udløser hjem, tilbage og seneste apps.
- Android 9 Pie's navigationsknapper med to knapper. Disse kan ikke være hardwareknapper, selvom de to knapper stadig skal have en vis afstand mellem dem. Tilbage- og hjem-knapperne udløser henholdsvis tilbage- og hjem-handlingerne, selvom knappen seneste apps er blevet slået sammen med hjem-knappen, således at et swipe-op af hjem-knappen udløser de seneste apps oversigt.
- Android 10s nye gestusnavigation.
Alle enheder, der lanceres med Android 10, skal implementere A og C, selvom det er op til OEM'en at beslutte, hvilken der er standard. B er ikke længere understøttet og kan ikke tillades som en brugervalgbar mulighed.
Så hvor efterlader det alternative navigationskontroller fra OEM'er? Google siger, at mens Android-partnere kan tilbyde deres egne navigationskontroller, kan deres alternativer ikke være det præsenteres for brugeren under opsætningen, og de kan heller ikke annonceres for brugeren gennem meddelelser eller på skærmen pop ups. Mens A og C skal vises på det øverste niveau af navigationsindstillinger, skal alle alternative navigationsmuligheder placeres én indgang dybere i Indstillinger.
Dette betyder effektivt, at alternative, velsagtens bedre bevægelser kun vil blive fundet af superbrugere, der graver gennem indstillinger eller læser artikler online om deres enhed. Vi noterede i vores OnePlus 7T anmeldelse at OnePlus ikke tilbyder sine OxygenOS fuldskærmsbevægelser, og det vil sandsynligvis være tilfældet med andre enheder, der lanceres med Android 10, da der ikke er nogen mening i at tilbyde en alternativ gestus ordning. Den sandsynlige årsag til, at OnePlus 7 og OnePlus 7 Pro stadig har de gamle OxygenOS-bevægelser, er, at Google anbefaler på det kraftigste, at OEM'er ikke fjerner eksisterende navigationsmuligheder, når de opgraderer enheder til Android 10.
Endelig anbefaler Google kraftigt, at OEM'er ikke skifter brugeren til en anden navigationstilstand, når de indstiller en tredjeparts launcher som standard. Ironisk nok er det præcis, hvad der sker, når du prøv at indstille en tredjeparts launcher som standard i Android 10 til Google Pixel. Google har lovet, at de vil udrulle en rettelse for at gøre Android 10s bevægelser kompatible med tredjeparts launchers, så det er sandsynligt, at de tilføjede denne særlige erklæring, så brugerne ikke vil bebrejde tredjeparts launchers for gestus uforenelighed. Gør som jeg siger, ikke som jeg gør.
Sammenfattende har Google endelig taget skridt til at forene gestusnavigation i Android, og de bruger CDD- og GMS-godkendelsesprocessen til at få OEM'er til at spille med. Det er dog ikke en dårlig ting, da fragmentering i navigationskontrol er problematisk for app-udviklere. Google har klart sagt en masse eftertanke og forskning i anvendeligheden af de nye gestus. Da Google ved, at ikke alle vil være tilfredse med deres bevægelser, giver de stadig OEM'er et vist spillerum ved at tillade dem at lave deres egne bevægelser, så længe disse bevægelser følger visse regler.
I fremtidige versioner af Android vil Google muligvis helt forbyde alternative navigationstilstande. OnePlus kan allerede se skriften på væggen, hvilket ville forklare, hvorfor de ikke længere giver deres gamle bevægelser på OnePlus 7T, selvom vi bliver nødt til at vente på, at flere enheder lanceres med Android 10 for at se, om dette er en enkeltstående eller en ny industri tendens.