Hvordan Google tar kontroll over Gesture Navigation i Android 10

Google presser virkelig på den nye gestnavigasjonen i Android 10. Selv om de ikke har forbudt andre gestkontrollordninger, har de satt mange grenser.

Etter å ha eksperimentert med knappbaserte bevegelseskontroller i Android 9 Pie, gikk Google tilbake til tegnebrettet for å forbedre flyten og enhåndsbruken av Androids bevegelsesnavigering. Med Android 10 kom Google frem til en løsning som visuelt ligner iOS: en bevegelseslinje som kan sveipes opp for å gå hjem eller sveipes til venstre eller høyre for å bytte mellom apper. Siden bevegelseslinjen er mye tynnere enn den dedikerte plassen for det forrige navigasjonsskjemaet med tre knapper, gir Android 10s bevegelser apper mer plass til å vise innhold nederst på skjermen. For å håndtere mangelen på en dedikert tilbakeknapp, la Google til en innoversveip fra venstre eller høyre kant av skjermen for å utløse tilbakehandlingen. Googles nye og forbedrede bevegelser er et skritt i riktig retning, selv om noen fortsatt mener at tredjepartsalternativer er overlegne.

Android 10s nye gestnavigering. Kilde: Google.

Selv om det fortsatt er rom for å forbedre (og det er det definitivt), presser Google sine Android-partnere til å ta i bruk disse nye navigasjonsbevegelsene fordi selskapet ønsker ikke å belaste apputviklere med å ha plass til flere forskjellige bevegelsesnavigasjoner ordninger. Android-enhetsprodusenter som OnePlus, Samsung, Xiaomi, Huawei, OPPO, Vivo og ASUS er bare noen av selskapene med sine egne grep om navigering med bevegelser. Disse selskapene har allerede investert mye utviklingsinnsats i å bygge sine egne gester, så Google tvinger dem ikke til å helt forlate arbeidet sitt.

"Brukere ønsker i økende grad oppslukende opplevelser i Android, og en ting som enhetsprodusenter har gjort er å prøve å nærme seg dette fra en programvareside. Og det de har gjort er å bygge sin egen gest-navigasjon. Og hver enhetsprodusent har et annet inntrykk av hvordan bevegelsesnavigering skal fungere. Det vi kjenner igjen på en plattformside er at den slags blir gal for en utvikler. Når du tenker på N forskjellige bevegelsesnavigasjoner når du prøver å utvikle, designe, teste for appen din, blir det rett og slett galskap. Så med det i tankene, introduserte vi denne gestnavigeringen i Q, og vi kommer til å standardisere økosystemet fra og med Q på 3 knapper og vår modell fremover.» – Ronan Shah, produktsjef hos Google i Android System UI-teamet, hos Google I/O 2019.

I stedet har Google omskrevet regelsettet for Android- og Google-appkompatibilitet, noe som tvinger OEM-er til det sidelinje sine egne gester til fordel for Googles, samtidig som de begrenser funksjonaliteten til OEM bevegelser.

Android 10 Gesture-kompatibilitetskrav

Etter hver større Android-plattformutgivelse oppdaterer Google Android Compatibility Definition Document (CDD) til skissere de nye kravene som alle enheter må oppfylle for å anses som kompatible med den nyeste versjonen av Android. Dette er en av forutsetningene for å få en Android-lisens, som er nødvendig for å bruke Android-merkevaren i markedsføring. Det er også en forutsetning for å få godkjenning for å distribuere Google Mobile Services, pakken med Google-apper, -tjenester og -biblioteker som er forhåndsinstallert på de fleste Android-enheter som selges internasjonalt.

I CDD for Android 10, Google har oppdatert avsnitt 2.2.3 om programvarekravene for håndholdte enheter (AKA smarttelefoner) med ordlyden nedenfor. Disse uttalelsene informerer OEM-er om Googles forventninger til hvor stort utløserområdet skal være for navigasjonsbevegelser.

Google anbefaler at området for bevegelsesgjenkjenning for hjemmehandlingen bør være innenfor 32 dp (dp står for tetthetsuavhengig piksel) fra bunnen av skjermen, men de stiller ikke dette til et krav, slik at OEM-er fortsatt kan tilby flytende bevegelseskontroller som for eksempel EMUIs flytende navigasjonsdokk.

Hvis en OEM tilbyr en sveipebevegelse fra enten venstre eller høyre kant av skjermen, krever Google at utløserområdet er mindre enn 40 dp fra kanten (ideelt sett 24 dp i bredden.) Merk at dette gjør det mulig for OEM-er å lage forskjellige følsomhetsalternativer for sidebevegelser så lenge triggerområdet ikke overstiger 40 dp. Faktisk Google tilbyr akkurat dette i sin egen Android 10-utgivelse. Som standard er innsettingen for bakbevegelsen 24dp på Pixel, men den kan senkes til 18dp eller heves til 32dp eller 40dp.

I en senere del av CDD, spesifikt avsnitt 7.2.3 som dekker navigasjonstaster, gir Google detaljerte krav for hvordan bevegelser for baksiden, hjemmet og nylige apphandlinger skal fungere. De fleste av kravene fokuserer på å sørge for at systematferden er konsistent for apputviklere, men det er noen få bemerkelsesverdige utsagn som kan påvirke brukeropplevelsen.

Selv om Google ikke krever at et sveip opp fra bunnkanten utløser hjemmehandlingen eller et sveip opp og hold utløse den nylige appoversikten, krever Google at sveipebevegelser fra sidene utløser tilbakehandlingen. Spesielt vil dette bety at de tilpassbare bevegelsene levert av Samsungs One Hand Operation+ ville ikke være tillatt, men siden One Hand Operation+ ikke er installert rett ut av esken, kan den få bestått.

Hvis en OEM tilbyr et flytende systempanel som utløses via en sidesveipebevegelse, må OEM plassere utløseren område i den øverste 1/3 av venstre eller høyre side og må ikke tillate at panelet overskrider en størrelse på 1/3 av størrelsen på skjermen kant. OEM kan imidlertid tillate brukeren å sette utløserområdet under den øverste 1/3 av kantene. Dette språket ble sannsynligvis lagt til for å imøtekomme Samsungs Edge Panel-funksjon.

Android 10-kompatibilitetsdefinisjonsdokumentet plasseres ikke at mange begrensninger på hva OEM-er kan gjøre med gester, men som jeg nevnte før, er det bare å overholde CDD en av forutsetningene for å få en Android-lisens og godkjenning for å distribuere GMS. Google har et eget dokument som de distribuerer privat til alle sine lisensierte Android-partnere; dette dokumentet oppregner de tekniske kravene som selskaper må følge for å få lov til å distribuere GMS, og det har tilleggsbestemmelser knyttet til navigering med bevegelser i Android 10. Vi skaffet en kopi av dette dokumentet, med tittelen GMS Requirements v7, datert 3. september 2019.

Bevegelsesnavigasjonskrav for GMS-godkjenning

Google Assistant er en utrolig viktig tjeneste for Google, så Google samler den som en del av Google-appen og krever at alle Android-partnere distribuerer den som en del av pakken med GMS-apper for «vanlige» (ikke-Android Go)-enheter. Kravene slutter imidlertid ikke der. Siden Android 5.1 har Google pålagt at et langt trykk på Hjem-knappen utløser Assist-handlingen, som som standard vil påkalle Google Assistant siden Google også krever at Google-appen skal være standardbehandleren for Assist handling. Det er imidlertid ikke lenger en dedikert hjemknapp i Android 10, så Google har satt nye krav til hvordan assistenten skal utløses med en gest.

For å utløse Google Assistant med Googles bevegelsesnavigering, må du sveipe diagonalt fra nedre venstre/høyre hjørne. Google krever at denne bevegelsen er til stede på alle enheter som kjører Android 10, uavhengig av om Googles bevegelser er standard navigasjonskontroller rett ut av esken eller ikke. Hvis en OEM implementerer sine egne bevegelsesnavigasjonskontroller, kan den implementere sin egen trigger for å starte Assistant-appen, men den nøyaktige implementeringen vil bli gjenstand for vurdering fra Google. Noen OEM-er som OnePlus og Xiaomi lar deg utløse assistenten ved å trykke lenge på strømknappen, for eksempel.

Google definerer tre typer referansenavigasjonsmodeller:

  1. Klassiske navigasjonskontroller med tre knapper. Disse kan være knapper på skjermen eller maskinvare, men de må ha litt avstand mellom dem. De tre knappene utløser hjem, tilbake og nylige apper.
  2. Android 9 Pie sine navigasjonskontroller med to knapper. Disse kan ikke være maskinvareknapper, selv om de to knappene fortsatt må ha en viss avstand mellom dem. Tilbake- og hjem-knappene utløser henholdsvis tilbake- og hjem-handlingene, selv om knappen nylige apper har blitt slått sammen med hjem-knappen slik at et sveip opp av hjem-knappen utløser de siste appene oversikt.
  3. Android 10s nye gestusnavigasjon.

Alle enheter som lanseres med Android 10 må implementere A og C, selv om det er opp til OEM å bestemme hvilken som er standard. B støttes ikke lenger og kan ikke tillates som et brukervalgbart alternativ.

Så hvor etterlater det alternative navigasjonskontroller fra OEM-er? Google sier at mens Android-partnere kan tilby sine egne navigasjonskontroller, kan ikke alternativene deres være det presentert for brukeren under oppsett, og de kan heller ikke annonseres for brukeren gjennom varsler eller på skjermen popup-vinduer. Mens A og C må vises på toppnivået av navigasjonsinnstillingene, må eventuelle alternative navigasjonsalternativer plasseres én oppføring dypere i Innstillinger.

Dette betyr effektivt at alternative, uten tvil bedre bevegelser, bare vil bli funnet av avanserte brukere som graver gjennom innstillinger eller leser artikler på nettet om enheten deres. Vi noterte i vår OnePlus 7T anmeldelse at OnePlus ikke tilbyr sine OxygenOS fullskjermbevegelser, og det kommer sannsynligvis til å være tilfelle med andre enheter som lanseres med Android 10, siden det er liten vits i å tilby en alternativ gest ordningen. Den sannsynlige grunnen til at OnePlus 7 og OnePlus 7 Pro fortsatt har de gamle OxygenOS-bevegelsene er at Google anbefaler på det sterkeste at OEM-er ikke fjerner eksisterende navigasjonsalternativer når de oppgraderer enheter til Android 10.

Til slutt anbefaler Google på det sterkeste at OEM-er ikke bytter brukeren til en annen navigasjonsmodus når de angir en tredjeparts launcher som standard. Ironisk nok er det akkurat dette som skjer når du prøv å sette en tredjeparts launcher som standard i Android 10 for Google Pixel. Google har lovet at de vil lansere en løsning for å gjøre Android 10s bevegelser kompatible med tredjeparts lanseringer, så det er sannsynlig at de har lagt til denne spesielle uttalelsen, slik at brukere ikke vil klandre tredjeparts lanseringer for bevegelser inkompatibilitet. Gjør som jeg sier, ikke som jeg gjør.


Oppsummert har Google endelig tatt skritt for å forene bevegelsesnavigering i Android, og de bruker CDD- og GMS-godkjenningsprosessen for å få OEM-er til å spille med. Det er imidlertid ikke en dårlig ting, siden fragmentering i navigasjonskontroller er problematisk for apputviklere. Google har klart sagt mye omtanke og forskning på brukervennligheten til de nye gestene. Siden Google vet at ikke alle vil være fornøyd med bevegelsene deres, gir de fortsatt OEM-er har et spillerom ved å la dem gjøre sine egne bevegelser, så lenge disse bevegelsene følger visse regler.

I fremtidige versjoner av Android kan Google fullstendig nekte alternative navigasjonsmoduser. OnePlus kan allerede se skriften på veggen som vil forklare hvorfor de ikke lenger gir sine gamle bevegelser på OnePlus 7T, selv om vi må vente på at flere enheter lanseres med Android 10 for å se om dette er en engangsindustri eller en ny bransje trend.