Hvordan Android Q forbedrer personvern- og tillatelseskontroller over Android Pie

Android 9 Pies markedspenetrasjon er knapt en blipp på radaren sammenlignet med eldre Android-versjoner, men det vil ikke forsinke Googles planer om å gi ut neste versjon av Android, Android Q. Vi forventer at Google avduker den første utviklerforhåndsvisningen av Android Q en gang neste måned, men før Googles kunngjøring at vi har klart å få tak i en Android Q-bygning som sannsynligvis er ganske langt i Googles utvikling syklus. I vår første artikkel som beskriver endringene som kommer til neste dessertutgivelse, snakket vi om det nye tillatelseskontrollgrensesnittet. Imidlertid viste jeg bare noen få skjermbilder av det fornyede tillatelsesstyringssystemet, så jeg ønsket å følge opp med flere detaljer. Jeg har også testet mer og samlet mer informasjon om de nye tillatelsene i Android Q, «roller»-funksjonen, det nye pakkeinstallasjonsprogrammet og mer. Men først, her er en kort oppsummering av tillatelsesadministrasjon i Android.

En kort historie om tillatelsesadministrasjon i Android

Android 4.3 Jelly Bean først introdusert granulær tillatelsesadministrasjon via "App Ops"-funksjonen, selv om den var skjult for brukeren. Android 4.4 KitKat introduserte til og med nye brukerkontrollerbare tillatelser i App Ops-grensesnittet, selv om du trengte root-tilgang og en Xposed-modul for å få tilgang til den. Til slutt introduserte Android 6.0 Marshmallow tillatelsessystemet som vi alle er kjent med, om enn med begrensninger på hvilke tillatelser du kan begrense. Den eldre App Ops-funksjonen eksisterer fortsatt i Android, selv om den bare kan nås via kommandolinjen (cmd appops). Visse applikasjoner i Google Play Store dra nytte av App Ops' kommandolinjeimplementering for å gi et kraftigere grensesnitt for tillatelseadministrasjon. Google eksponerer ikke App Ops for brukere siden brukeren kanskje ikke vet hva de gjør, noe som resulterer i at de nekter en app noen tillatelser som den virkelig trenger for å fungere skikkelig. Dessverre, siden introduksjonen av tillatelsesadministrasjon i Android Marshmallow, har vi ikke sett noen store endringer i funksjonen – det vil si før Android Q.

App Ops i Android 4.3 Jelly Bean

Android 6.0 Marshmallow så også en stor endring i måten visse tillatelser gis til applikasjoner. Før Android 6.0, alle tillatelser definert i en appens manifestfil gis ved installasjon. Med Android 6.0, Google introduserte administrasjon av kjøretidstillatelser for visse tillatelser de anså som farlige, for eksempel ekstern lagringstilgang, kameratilgang, plasseringstilgang og mer. Kjøretidstillatelser gis kun etter installasjon av en app, og brukeren må uttrykkelig samtykke til å gi disse tillatelsene ved å trykke på "tillat" i en tillatelsesdialogboks når det blir bedt om det. Inntil Google slått ned på apper som målretter mot et eldre API-nivå, kan apputviklere omgå kjøretidstillatelser ved å målrette mot API-nivå 22 eller lavere (Android Lollipop eller eldre.) Android Q vil advare brukere prøver å kjøre en app som er målrettet mot API-nivå 22 eller lavere, og oppmuntrer utviklere ytterligere til å oppdatere appene sine for å unngå å bli skammet av OS. Innen Android Q kommer til enhetene, bør derfor nesten hver app på en brukers enhet være underlagt kontrollene for tillatelsesadministrasjon introdusert i Android 6.0+. Med det i tankene rydder Google opp i tillatelseskontrollene i Android Q for å gjøre det enklere for brukere å administrere hvilket tilgangsnivå apper har på enheten deres.

Enklere tillatelsesadministrasjon i Android Q versus Android Pie

Fra Android 6.0 Marshmallow til Android 9 Pie lar den eksisterende administrasjonen av kjøretidstillatelser bare brukeren tillate eller nekte en app visse tillatelser. Vi bemerket i vår forrige artikkel at Android Q vil tillate brukeren å begrense en tillatelse bare mens appen er i bruk. Denne funksjonen fikk mange mennesker begeistret, men vi må avklare det bare plasseringstillatelsen kan begrenses til når en app er i bruk. Det betyr at du ikke kan begrense mikrofonen eller kameraet bare mens appen er i bruk. Du bør imidlertid ikke bli skuffet over det, siden Android Pie allerede introdusert noen restriksjoner på bakgrunnsbruken av kamera og mikrofon ved å kreve at apper er i forgrunnen eller bruker en forgrunnstjeneste. I tillegg utvider Android Q det med avsløre til brukeren når en app bruker mikrofonen, kameraet eller får tilgang til enhetens plassering. Dette vises til brukeren som statuslinjeikoner i øverste høyre hjørne. Når statuslinjen utvides, forteller teksten som vises ved siden av ikonene brukeren hvilken app som for øyeblikket bruker en av disse tre sensitive tillatelsene. Til slutt, hvis brukeren trykker på dette ikonet, vises en dialogboks som forteller brukeren hvilke app(er) som bruker hvilke tillatelser. Igjen, dette gjelder bare kamera-, plasserings- og mikrofontillatelser.

Google ser ut til å oppmuntre brukere til å begrense posisjonstilgang til kun når en app er i bruk, ettersom de har bakt i en påminnelse i Android Q når brukeren har gitt en app alltid tilgang til posisjonen sin. Denne påminnelsen kommer i form av et varsel som forteller brukeren at en app har brukt posisjonen deres, og at den alltid har muligheten til å gjøre det. Ved å trykke på varselet kommer du til posisjonstillatelsessiden for den appen, slik at brukeren kan velge å begrense posisjonstillatelsen bare mens den appen er i bruk. Kudos for det, Google.

Til slutt, i bygget jeg har, er brukergrensesnittet for de spesielle apptilgangstillatelsene (som batterioptimalisering, enhetsadministrator, Ikke forstyrr-tilgang, varslingstilgang, etc.) uendret. En ny spesialtillatelse for «Financial Apps SMS Access» er lagt til listen, selv om jeg er usikker på hvordan den skiller seg fra "Premium SMS-tilgang"-tillatelsen som er det apper trenger for å sende tekstmeldinger til premium tall. Det er mulig at denne nye tillatelsen er ment for bankapper som bruker SMS for visse transaksjoner, iht Google Plays nye retningslinjer begrenser SMS- og anropsloggtillatelser.

Administrere tillatelser i Android Q

Her er et skjermbildegalleri som viser de nye endringene i tillatelsesadministrasjonsgrensesnittet i Android Q. Jeg har inkludert detaljerte beskrivelser av hver side i bildetekstene til hvert bilde.

Gi tillatelser i Android Q

Her er skjermbilder som viser administrasjon av kjøretidstillatelser i Android Q. Vi har allerede snakket om hva de to første skjermbildene viser, men det tredje skjermbildet er en helt ny Android Q-funksjon som jeg ikke har diskutert før. Muligheten for Android til å la brukeren kontrollere tillatelser før de kjører en eldre app (definert som et appmålrettings-API-nivå < 23) er noe som allerede er mulig i Android Pie med riktig konfigurasjon, men Google har endelig snudd bryteren og aktivert den i Android Q.

Sanntidsovervåking av tillatelser i Android Q

Her er skjermbilder som viser hvordan Android Q vil varsle brukeren når en app har tilgang til en av flere sensitive/farlige tillatelser, inkludert kamera, plassering og mikrofon.

Nye begrensninger på utklippstavletilgang, ekstern filtilgang

Bakgrunnsutklippstavle tilgangsbegrensninger

I min forrige artikkel la jeg merke til en ny tillatelse i Android Qs rammeverk som antydet at ikke-systemapper som kjører i bakgrunnen ikke lenger vil kunne lese systemets utklippstavle. Etter at vi fikk Google Play Store til å fungere, bestemte jeg meg for å installere noen populære apper for utklippstavlebehandling som Utklippstavlebehandler, Clipper, og Klippstabel for å teste om jeg hadde rett. På godt og vondt blokkerer Google bakgrunnstilgang til utklippstavlen i Android Q, som ingen av appene jeg testet kunne oppdage noen tekst jeg kopierte til utklippstavlen. Jeg bekreftet til og med at disse appene har "READ_CLIPBOARDtillatelse de ba om ved å bruke følgende App Ops-kommando:

adb shell cmd appops query-op --user 0 READ_CLIPBOARD allow

Heldigvis fungerer det fortsatt å kopiere og lime inn tekst til og fra en hvilken som helst app, men apper som kjører i bakgrunnen kan ikke lenger lese teksten som blir kopiert. Det er for tidlig å si om denne endringen vil drepe utklippstavlebehandlingsapper fordi det er en mulighet for at Google kan introdusere et nytt API for å gjøre en app til en standard "utklippstavlebehandling"-behandler. Jeg ser imidlertid ingen bevis for at det skjer i Android Q.

Tilgang til ekstern lagringsfil

Jeg dekket stort sett alt om denne endringen i min tidligere artikkel, men her er et sammendrag av hva Google endrer i Android Q med hensyn til tilgang til ekstern lagringsfil. Først må vi definere hva "ekstern lagring" betyr. I Android er ekstern lagring stedet der alle filene og mappene du kan se når du kobler telefonen til en datamaskin, som nedlastinger, DCIM, musikk, filmer og bilder, er lagret. Apper skal bare lagre filer i ekstern lagring som andre apper kanskje vil ha tilgang til, som musikk, bilder, videoer, dokumenter, etc.

For at en app skal få tilgang til filer på ekstern lagring, må appen holde READ_EXTERNAL_STORAGE og/eller WRITE_EXTERNAL_STORAGE tillatelser, som begge er kjøretidstillatelser. Når en app har disse tillatelsene, er det ingen begrensninger på hvilke filer på ekstern lagring den kan lese eller endre. I Android Q deler Google opp disse to tillatelsene til mer detaljerte tillatelser, slik at brukeren kan begrense en app slik at den bare kan lese eller skrive bestemte filtyper. Spesielt vil de nye tillatelsene i Android Q la brukeren begrense en app slik at den bare kan:

• Les plasseringene fra media.
• Les eller skriv musikkfiler.
• Les eller skriv bilder/bildefiler.
• Les eller skriv videofiler.

En app som allerede har fått READ_EXTERNAL_STORAGE-tillatelsen før brukeren oppgraderte til Android Q vil automatisk bli gitt "lese"-tillatelsene som er oppført ovenfor, men ikke "skrive" tillatelser.

Bakgrunn Location Access

I fjor en rapport fra New York Times kastet lys over hvor omfattende apper sporer brukernes plassering for å selge til annonsører. Feil posisjonssporing er et problem som Google er godt klar over etter å ha vært anklaget for det selv. Android 8.0 Oreo introdusert begrensninger om hvor ofte apper som kjører i bakgrunnen kan få tilgang til en enhets plassering. Plasseringsforespørsler fra apper som kjører i bakgrunnen er sterkt begrenset, så hvis en app ønsker å spore posisjonen din med noen grad av presisjon, må den avsløre at den gjør det med en synlig aktivitet eller en forgrunnstjeneste og en vedvarende melding.

Men hver gang Google endrer måten kjerne-API-ene for Android fungerer på, påvirkes utviklere hvis apper legitimt brukte disse APIene etter hensikten. Vi har sett dette spille ut nylig med Google Plays begrensninger på SMS- og anropsloggtillatelser, noe som har resultert i mange populære apper mister nøkkelfunksjonalitet. Den samme situasjonen skjedde da Google begrenset tilgang til bakgrunnsposisjon, med brukere av en populær golf appklagende at de ikke lenger kunne bruke den til å spore skuddene deres. Heldigvis legger Android Q til en ny "ACCESS_BACKGROUND_LOCATION" tillatelse som, når den er gitt, alltid lar en app ha tilgang til en enhets plassering, selv når appen kjører i bakgrunnen. Dermed vil den nye Android-versjonen ikke bare fortsette å beskytte brukere mot uønsket posisjonstilgang i bakgrunnen, men vil også gi en mekanisme for brukere å tillate apper etter eget valg for å overvåke deres plassering i bakgrunnen.

Tilføyelsen av "roller" i Android Q

Hos Daniel praktisk video for vår XDA TV YouTube-kanal, har du kanskje hørt ham nevne en ny «Roller»-seksjon i innstillingene for standardapper (Innstillinger --> Apper og varsler --> Standardapper). De eneste "rollene" som ble vist i videoen var for nettleser, telefon og meldinger, noe som virket overflødig siden det allerede er standard appkategorier for nettleser, telefonapper og SMS-apper. Etter å ha brukt litt mer tid med Android Q på Pixel 3 XL, oppdaget jeg en "rolle"-tjeneste som jeg kunne dumpe staten for via 'dumpsys role' kommando. Etter å ha gjort det fant jeg flere "roller" som ikke samsvarer med noen av standard appkategoriene som allerede eksisterer: CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, og PROXY_CALLING_APP. Etter å ha installert noen av Googles førstepartsapplikasjoner, klarte jeg å få «Bilmodus-telefon-appen» og «Anropskontroll-appen» til å vises på «rollene»-sidene, som vist nedenfor.

Jeg dekompilerte den nye system-APK-en som er ansvarlig for Android Qs tillatelsesadministrasjonsgrensesnitt, en ny app kalt «PermissionController», og fant en roles.xml-fil som antyder hva «rolles» vil gjøre i neste Android versjon. Jeg skal ikke lime inn hele XML-en her, men jeg vil dele et utdrag av en av rollene som skal hjelpe deg å forstå hva roller vil gjøre.

La oss si at jeg velger en app for å ha rollen "galleri". For at en app skal vises som en gyldig galleriapp, må den ha én nødvendig komponent: en aktivitet som starter med handlings- og kategorihensiktsfiltrene android.intent.action.MAIN og android.intent.category.APP_GALLERY hhv. Hvis det er sant og appen får rollen "galleri" av brukeren, vil appen automatisk bli gitt tillatelser i «media_visual»-tillatelsessettet, som jeg tror refererer til den nye lyd-, video- og bildetillatelsen jeg beskrev Tidligere. Faktisk den nye WRITE_MEDIA_VIDEO og WRITE_MEDIA_IMAGES tillatelser er eksplisitt tillatt for en app med "galleri"-rullen. Til slutt blir appen den foretrukne behandleren når en annen app sender en intensjon om å ringe en galleriapp.

I utgangspunktet vil enhver app som har gitt en viss "rolle" og har de nødvendige komponentene og tillatelsene erklært, automatisk gis andre tillatelsessett som er relevante for deres brukstilfeller. I eksemplet jeg la ut ovenfor, får en app med galleri-"rollen" automatisk tillatelse til å arkivere tilgangsrelaterte tillatelsessett som den trenger for å fungere. Antagelig betyr dette at en app som har fått gallerirollen av brukeren, ikke trenger å spørre brukeren om tillatelse til å lese eller skrive bilde- eller videofiler.

Etter navnene å dømme CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, og PROXY_CALLING_APP roller lar brukeren velge en annen oppringingsapp når de kjører, en app for å utføre ulike funksjoner mens brukeren er i en telefonsamtale, en app for å skjerme telefonsamtaler før brukeren svarer, og en app for å gjøre det lettere å ringe med et mellomnummer, hhv. Vi tror ikke samtalescreeningsrollen er direkte relatert til Google Pixel Ringeskjerm funksjon, etter det vi har sett i AOSP. Snarere er det ment for apper som ønsker å fungere som en spretter for spam-anrop, som et anropsfilter.

Fornyet pakkeinstallasjonsprogram

Androids standardpakkeinstallasjonsprogram (applikasjonen som håndterer installasjonen av nye apper) får en redesign. I stedet for å vise en fullskjermaktivitet når du vil installere en ny app, viser det oppdaterte pakkeinstallasjonsprogrammet i Android Q en liten dialogboks midt på skjermen. Dette minipakkeinstallasjonsgrensesnittet har blitt brukt for Android-nettbrett i lang tid, men dette er det første vi ser det på Android-smarttelefoner.

I Android Q vil kjøring av apper som målretter API-nivå 22 eller lavere (Android 5.0 Lollipop) vise en advarsel om at appen er utdatert. Denne advarselen, mistenker jeg, er nok til å avskrekke de fleste brukere fra å plage med apper som er rettet mot pre-Android Marshmallow-versjoner. Koble det til det faktum at Google vil kreve at alle apper som sendes inn til Play-butikken etter august 2019, skal målrettes API-nivå 28, kan du se hvordan utviklere med utdaterte apper blir tvunget til å omarbeide appene sine for å målrette mot et nyere API nivå. Hvordan forholder alt dette seg til det nye pakkeinstallasjonsprogrammet? Vel, siden Android 5.0 Lollipop er det siste API-nivået uten obligatoriske forespørsler om kjøretidstillatelser for visse sensitive tillatelser, vil apper som målretter seg til slutt dør. API-nivå 22 og lavere betyr at Google ikke lenger trenger å gjøre plass i pakkens installasjonsmelding for å vise en lang liste med tillatelser som en app er gitt på installasjon.

Du vil sannsynligvis ikke se dette forenklede pakkeinstallasjonsprogrammet på alle Android Q-enheter. Huawei, for eksempel, tilpasser pakkeinstallasjonsprogrammet med en innebygd virus- og skadevareskanner (noe jeg hater) samt en innebygd tillatelsesbehandling (noe jeg elsker.) EMUI 10 vil derfor trolig holde seg til fullskjermpakkeinstallasjonsprogrammet vi alle er pleide å.

Nye alternativer for anropsblokkering

Et trekk vi trodde skulle komme i Android Pie tok seg faktisk inn i Android Q, og viser deg hvor nær vi faktisk er ferdigstillelsen av Android Q kjernefunksjoner. Funksjonen vi fant den gang ville la deg blokkere anrop fra ukjente, private, betalingstelefonnumre eller numre som ikke er i kontaktlisten din. Her er et skjermbilde av funksjonen fra AOSP dialer-appen. Google Phone-appen har ikke blitt oppdatert med denne funksjonen ennå, men vi antar at den får den snart.

Alle installerte apper viser nå startikoner (mulig feil?)

De fleste apper på enheten din har oppstartsikoner fordi de er ment å være inngangsporter til brukergrensesnittet. Imidlertid har ikke alle apper et brukergrensesnitt, i så fall kan en utvikler velge å ikke erklære en aktivitet med handlings- og kategorihensiktsfiltrene android.intent.action.MAIN og android.intent.category.LAUNCHER hhv. Jeg er ikke sikker på om dette bare er en feil, men i Android Q vil alle apper, selv de som prøver å skjule startikonene sine på måten beskrevet ovenfor, vise ikoner i startprogrammet. Jeg testet dette på AOSP Launcher, Pixel Launcher og Nova Launcher på en Google Pixel 3 XL som kjører den lekkede Android Q-bygningen, og sammenlignet den med en Google Pixel 2 XL som kjører den nyeste Android 9 Pie bygge. Når du trykker på et av disse ikonene, bringer det deg ganske enkelt til appens informasjonsside i Innstillinger.

Hvis dette ikke bare er en feil, vil dette være en måte for brukere å raskt finne ut om en ny app er installert, selv om den appen prøver å skjule seg for brukeren.

Hurtiginnstillinger-flisen "Sensorer av".

Det er en ny hurtiginnstillinger-brikke kalt "sensorer av" som ikke bare slår på flymodus, men også deaktiverer alle sensoravlesninger på enheten. Jeg bekreftet dette ved å installere DevCheck fra XDA Recognized Developer flar2 og sammenligne utdataene fra sensoravlesningene med og uten "sensorer av"-bryteren. Når "sensorer av"-flisen er slått på, slutter enheten å rapportere fra alle sensorer på enheten. Jeg er ikke sikker på om denne hurtiginnstillingsflisen bare er for Google-ingeniører å feilsøke, men dette ville være en nyttig funksjon for alle som virkelig er bekymret for hvilke data enhetene deres samler inn om deres miljø.

---

Mer om Android Q

Det er alt personvern- og tillatelsesrelatert som jeg har funnet så langt i Android Q. Følg med på den siste artikkelen min som dekker alle de mindre UI- og UX-justeringene. Følg vår Android Q-tag for flere artikler som dette. Her er en lenke til noen av artiklene som jeg refererte tilbake til oftere, samt noen andre jeg synes du bør lese:

• Eksklusivt: Tidlig Android Q-bygging har et systemomfattende mørkt tema, tillatelsesfornyelse, hint om en "Desktop Mode" og mer
• Eksklusivt: Google jobber med en Face ID-lignende funksjon for Android Q
• Android Q kan blokkere bakgrunnsutklippstavlelesing, beskytte mediefilene dine bedre, støtte nedgraderingsapper og mer
• Android Q kan leveres med nye font-, ikonform- og aksentfargeoverlegg
• "Dynamisk Android" kan la utviklere teste en AOSP GSI på hvilken som helst Android Q-enhet
• Android Qs mørke modus: Hvordan Googles neste Android OS vil takle blendende lette temaer