Hvordan Android Q forbedrer privatlivs- og tilladelseskontrol over Android Pie

Android 9 Pies markedspenetration er knap en blip på radaren sammenlignet med ældre Android-versioner, men det vil ikke forsinke Googles planer om at frigive den næste version af Android, Android Q. Vi forventer, at Google afslører den første Developer Preview af Android Q engang i næste måned, men før Googles meddelelse, at vi har formået at få fingrene i en Android Q build, der sandsynligvis er ret langt i Googles udvikling cyklus. I vores første artikel, der beskriver de ændringer, der kommer til den næste dessertudgivelse, talte vi om den nye tilladelseskontrolgrænseflade. Jeg viste dog kun et par skærmbilleder af det fornyede tilladelsesstyringssystem, så jeg ville følge op med flere detaljer. Jeg har også lavet flere tests og samlet flere oplysninger om de nye tilladelser i Android Q, "roller"-funktionen, det nye pakkeinstallationsprogram og mere. Men først, her er en kort opsummering af tilladelsesstyring i Android.

En kort historie om Permission Management i Android

Android 4.3 Jelly Bean først introduceret granulær tilladelsesstyring via "App Ops"-funktionen, selvom den var skjult for brugeren. Android 4.4 KitKat introducerede endda nye brugerkontrollerbare tilladelser i App Ops-grænsefladen, selvom du havde brug for root-adgang og et Xposed-modul at få adgang til det. Endelig introducerede Android 6.0 Marshmallow det tilladelsessystem, som vi alle er bekendt med, dog med begrænsninger for, hvilke tilladelser du kan begrænse. Den ældre App Ops-funktion eksisterer stadig i Android, selvom den kun kan tilgås via kommandolinjen (cmd appops). Visse applikationer i Google Play Butik, drag fordel af App Ops' kommandolinjeimplementering for at give en mere kraftfuld grænseflade til administration af tilladelser. Google eksponerer ikke App Ops for brugere, da brugeren måske ikke ved, hvad de laver, hvilket resulterer i, at de nægter en app nogle tilladelser, som den måske virkelig har brug for for at fungere korrekt. Siden introduktionen af ​​tilladelsesstyring i Android Marshmallow har vi desværre ikke set nogen større ændringer af funktionen – det vil sige indtil Android Q.

App Ops i Android 4.3 Jelly Bean

Android 6.0 Marshmallow oplevede også en stor ændring i den måde, som visse tilladelser gives til applikationer. Før Android 6.0, alle tilladelser defineret i en appens manifestfil gives ved installation. Med Android 6.0, Google indført runtime tilladelsesstyring for visse tilladelser, de anså for farlige, såsom ekstern lageradgang, kameraadgang, lokationsadgang og mere. Kørselstilladelser gives kun efter installationen af ​​en app, og brugeren skal udtrykkeligt give sit samtykke til at give disse tilladelser ved at trykke på "tillad" på en tilladelsesdialogboks, når der anmodes om det. Indtil Google slået ned på apps, der er målrettet mod et ældre API-niveau, kunne appudviklere omgå køretidstilladelser ved at målrette mod API-niveau 22 eller derunder (Android Lollipop eller ældre). Android Q vil advare brugerne forsøger at køre en app, der er målrettet mod API-niveau 22 eller derunder, hvilket yderligere tilskynder udviklere til at opdatere deres apps for at undgå at blive skammet af OS. På det tidspunkt, hvor Android Q kommer til enheder, bør næsten hver app på en brugers enhed således være genstand for kontrol af tilladelsesstyring introduceret i Android 6.0+. Med det i tankerne rydder Google op i tilladelseskontrollerne i Android Q for at gøre det nemmere for brugerne at administrere, hvilket adgangsniveau apps har på deres enhed.

Nemmere administration af tilladelser i Android Q versus Android Pie

Fra Android 6.0 Marshmallow til Android 9 Pie lader den eksisterende runtime-tilladelsesstyring kun brugeren tillade eller nægte en app visse tilladelser. Vi bemærkede i vores tidligere artikel, at Android Q kun giver brugeren mulighed for at begrænse en tilladelse, mens appen er i brug. Denne funktion fik mange mennesker begejstrede, men vi er nødt til at afklare det kun placeringstilladelsen kan begrænses til, når en app er i brug. Det betyder, at du ikke kun kan begrænse mikrofonen eller kameraet, mens appen er i brug. Du bør dog ikke blive skuffet over det, da Android Pie allerede er indført nogle begrænsninger på baggrundsbrugen af kamera og mikrofon ved at kræve, at apps er i forgrunden eller bruger en forgrundstjeneste. Derudover udvider Android Q det ved afsløre til brugeren, når en app bruger mikrofonen, kameraet eller får adgang til enhedens placering. Dette vises for brugeren som statuslinjeikoner i øverste højre hjørne. Når statuslinjen er udvidet, fortæller tekst vist ved siden af ​​ikonerne brugeren, hvilken app der i øjeblikket bruger en af ​​disse 3 følsomme tilladelser. Til sidst, hvis brugeren trykker på dette ikon, vises en dialogboks, der fortæller brugeren, hvilke app(er) der bruger hvilke tilladelse(r). Igen gælder dette kun for kamera-, placerings- og mikrofontilladelser.

Google ser ud til at opfordre brugere til kun at begrænse placeringsadgang til, når en app er i brug, da de har bagt i en påmindelse i Android Q, når brugeren har givet en app til altid at få adgang til deres placering. Denne påmindelse kommer i form af en notifikation, der fortæller brugeren, at en app har brugt deres placering, og at den altid har mulighed for at gøre det. Hvis du trykker på meddelelsen, kommer du til siden med placeringstilladelser for den pågældende app, hvilket lader brugeren vælge kun at begrænse placeringstilladelsen, mens den pågældende app er i brug. Tak for det, Google.

Til sidst, i den build, jeg har, er brugergrænsefladen for de særlige app-adgangstilladelser (såsom batterioptimering, enhedsadministrator, Forstyr ikke-adgang, meddelelsesadgang osv.) uændret. En ny særlig tilladelse til "Financial Apps SMS Access" er blevet tilføjet til listen, selvom jeg er usikker på hvordan den adskiller sig fra "Premium SMS-adgang", som er, hvad apps har brug for for at sende tekstbeskeder til premium tal. Det er muligt, at denne nye tilladelse er beregnet til bankapps, der bruger SMS til visse transaktioner i overensstemmelse med Google Plays nye politikker begrænsning af SMS- og Opkaldslog-tilladelser.

Håndtering af tilladelser i Android Q

Her er et skærmbilledegalleri, der viser de nye ændringer i grænsefladen til administration af tilladelser i Android Q. Jeg har inkluderet detaljerede beskrivelser af hver side i billedteksterne til hvert billede.

Tildeling af tilladelser i Android Q

Her er skærmbilleder, der viser administration af runtime-tilladelser i Android Q. Vi har allerede talt om, hvad de to første skærmbilleder viser, men det tredje skærmbillede er en helt ny Android Q-funktion, som jeg ikke har diskuteret før. Evnen for Android til at give brugeren mulighed for at kontrollere tilladelser, før de kører en ældre app (defineret som en app, der målretter API-niveau < 23) er noget, der allerede er muligt i Android Pie med rigtige konfiguration, men Google har endelig vendt kontakten og aktiveret den i Android Q.

Realtidsovervågning af tilladelser i Android Q

Her er skærmbilleder, der viser, hvordan Android Q vil advare brugeren, når en app har adgang til en af ​​flere følsomme/farlige tilladelser, herunder kamera, placering og mikrofon.

Nye begrænsninger på udklipsholderadgang, ekstern filadgang

Baggrundsudklipsholderens adgangsbegrænsninger

I min tidligere artikel bemærkede jeg en ny tilladelse i Android Q's framework, der foreslog, at ikke-systemapps, der kører i baggrunden, ikke længere vil være i stand til at læse systemets udklipsholder. Efter at vi fik Google Play Butik til at fungere, besluttede jeg at installere et par populære klippebordshåndteringsapps som Udklipsholder, Clipper, og Klip stak for at teste om jeg havde ret. På godt og ondt blokerer Google baggrundsudklipsholderadgang i Android Q, som ingen af ​​de apps, jeg testede, kunne registrere nogen tekst, jeg kopierede til udklipsholderen. Jeg har endda bekræftet, at disse apps har "READ_CLIPBOARD" tilladelse, de anmodede om ved at bruge følgende App Ops-kommando:

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

Heldigvis fungerer kopiering og indsættelse af tekst til og fra enhver app stadig, men apps, der kører i baggrunden, kan ikke længere læse den tekst, der kopieres. Det er for tidligt at sige, om denne ændring vil dræbe clipboard manager-apps, fordi der er en mulighed, at Google introducerer en ny API for at gøre en app til en standard "clipboard manager"-behandler. Jeg kan dog ikke se nogen beviser for, at det sker i Android Q.

Ekstern lagerfiladgang

Jeg dækkede stort set alt om denne ændring i min tidligere artikel, men her er en oversigt over, hvad Google ændrer i Android Q med hensyn til ekstern lagerfiladgang. Først skal vi definere, hvad "ekstern opbevaring" betyder. I Android er eksternt lager det sted, hvor alle de filer og mapper, som du kan se, når du tilslutter din telefon til en computer, såsom downloads, DCIM, musik, film og billeder, er gemt. Apps formodes kun at gemme filer i eksternt lager, som andre apps måske vil have adgang til, såsom musik, billeder, videoer, dokumenter osv.

For at en app kan få adgang til filer på eksternt lager, skal appen holde READ_EXTERNAL_STORAGE og/eller WRITE_EXTERNAL_STORAGE tilladelser, som begge er kørselstilladelser. Når først en app har disse tilladelser, er der ingen begrænsninger for, hvilke filer på eksternt lager den kan læse eller ændre. I Android Q opdeler Google disse to tilladelser i mere detaljerede tilladelser, hvilket giver brugeren mulighed for at begrænse en app, så den kun kan læse eller skrive bestemte filtyper. Specifikt vil de nye tilladelser i Android Q lade brugeren begrænse en app, så den kun kan:

• Læs placeringerne fra dine medier.
• Læs eller skriv musikfiler.
• Læs eller skriv fotos/billedfiler.
• Læs eller skriv videofiler.

En app, der allerede har fået READ_EXTERNAL_STORAGE-tilladelsen før brugeren opgraderer til Android Q tildeles automatisk de "læse"-tilladelser, der er angivet ovenfor, men ikke "skrive" tilladelser.

Baggrund Location Access

Sidste år en beretning fra New York Times kastet lys over den udbredte anvendelse af apps, der sporer brugernes placeringer for at sælge til annoncører. Ukorrekt placeringssporing er et problem, som Google er godt klar over, efter at have været det selv anklaget for det. Android 8.0 Oreo introduceret restriktioner om, hvor ofte apps, der kører i baggrunden, kan få adgang til en enheds placering. Placeringsanmodninger fra apps, der kører i baggrunden, er stærkt droslede, så hvis en app ønsker at spore din placering med evt. grad af præcision skal den afsløre, at den gør det med en synlig aktivitet eller en forgrundstjeneste og en vedvarende notifikation.

Men hver gang Google ændrer den måde, som kerne Android API'er fungerer på, påvirkes udviklere, hvis apps lovligt brugte disse API'er efter hensigten. Vi har set dette udspille sig for nylig med Google Plays begrænsninger for sms- og opkaldslog-tilladelser, hvilket resulterer i mange populære apps mister nøglefunktionalitet. Den samme situation skete, da Google begrænsede baggrundsplacering adgang, med brugere af en populær golf appklager at de ikke længere kunne bruge det til at spore deres skud. Heldigvis tilføjer Android Q en ny "ACCESS_BACKGROUND_LOCATION" tilladelse, som, når den er givet, altid giver en app adgang til en enheds placering, selv når appen kører i baggrunden. Den nye Android-version vil således ikke kun fortsætte med at beskytte brugere mod uønsket placering i baggrunden, men vil også give brugere en mekanisme til at tillade apps efter deres valg at overvåge deres placering i baggrunden.

Tilføjelsen af ​​"roller" i Android Q

Hos Daniel hands-on video for vores XDA TV YouTube-kanal, har du måske hørt ham nævne en ny "Roller"-sektion i standardapps-indstillingerne (Indstillinger --> Apps & notifikationer --> Standardapps). De eneste "roller", der blev vist i videoen, var for browser, telefon og meddelelser, hvilket virkede overflødigt, da der allerede er standardappkategorier for browser, telefonapps og SMS-apps. Efter at have brugt noget mere tid med Android Q på Pixel 3 XL, opdagede jeg en "rolle"-tjeneste, som jeg kunne dumpe staten for via 'dumpsys role’ kommando. Efter at have gjort det, fandt jeg adskillige "roller", der ikke matcher nogen af ​​standardappkategorierne, der allerede eksisterer: CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, og PROXY_CALLING_APP. Efter at have installeret et par af Googles førstepartsapplikationer, lykkedes det mig at få "Car mode phone app" og "Call screening app" til at blive vist på "roller" siderne, som vist nedenfor.

Jeg dekompilerede den nye system-APK, der er ansvarlig for Android Q's tilladelsesstyringsgrænseflade, en ny app kaldet "PermissionController," og fandt en roles.xml-fil, der antyder, hvad "roller" vil gøre i den næste Android version. Jeg har ikke tænkt mig at indsætte hele XML her, men jeg deler et uddrag af en af ​​rollerne, der skal hjælpe dig med at forstå, hvad roller vil gøre.

Lad os sige, at jeg vælger en app til at have rollen "galleri". For at en app skal vises som en gyldig galleriapp, skal den have én påkrævet komponent: en aktivitet, der starter med handlings- og kategorihensigtsfiltrene android.intent.action.MAIN og android.intent.category.APP_GALLERY henholdsvis. Hvis det er sandt, og appen får rollen "galleri" af brugeren, vil appen automatisk få tilladelser i tilladelsessættet "media_visual", som jeg mener henviser til den nye lyd-, video- og billedtilladelse, jeg beskrev tidligere. Faktisk det nye WRITE_MEDIA_VIDEO og WRITE_MEDIA_IMAGES tilladelser er eksplicit tilladt for en app med rullen "galleri". Endelig bliver appen den foretrukne handler, når en anden app sender en hensigt om at kalde en galleri-app.

Grundlæggende tildeles enhver app, der har tildelt en bestemt "rolle" og har de krævede komponenter og tilladelser erklæret, automatisk andre tilladelsessæt, der er relevante for deres brugssager. I eksemplet, jeg postede ovenfor, får en app med galleriet "rolle" automatisk tilladelse til at arkivere adgangsrelaterede tilladelsessæt, som den skal bruge for at fungere. Det betyder formentlig, at en app, der har fået tildelt gallerirollen af ​​brugeren, ikke behøver at bede brugeren om tilladelse til at læse eller skrive billed- eller videofiler.

Efter navnene at dømme CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, og PROXY_CALLING_APP roller vil lade brugeren vælge en anden opkaldsapp, når de kører, en app til at udføre forskellige funktioner, mens brugeren er i en telefonopkald, en app til at screene telefonopkald, før brugeren besvarer, og en app til at lette opkald med et mellemnummer, henholdsvis. Vi mener ikke, at opkaldsscreeningsrollen er direkte relateret til Google Pixel Opkaldsskærm funktion, at dømme efter hvad vi har set i AOSP. Det er snarere beregnet til apps, der ønsker at fungere som en udsmider for spam-opkald, som et opkaldsfilter.

Fornyet pakkeinstallationsprogram

Androids standardpakkeinstallationsprogram (applikationen, der håndterer installationen af ​​nye apps) får et redesign. I stedet for at vise en fuldskærmsaktivitet, når som helst du vil installere en ny app, viser det opdaterede pakkeinstallationsprogram i Android Q en lille dialogboks midt på skærmen. Denne mini-pakkeinstallationsbrugergrænseflade er blevet brugt til Android-tablets i lang tid, men dette er den første, vi ser den på Android-smartphones.

I Android Q vil en app, der er målrettet mod API-niveau 22 eller derunder (Android 5.0 Lollipop), vise en advarsel om, at appen er forældet. Denne advarsel formoder jeg er nok til at afholde de fleste brugere fra at genere apps, der er rettet mod præ-Android Marshmallow-versioner. Kombiner det med det faktum, at Google vil kræve, at alle apps, der sendes til Play Butik efter august 2019, skal målrettes API-niveau 28, kan du se, hvordan udviklere med forældede apps er tvunget til at omarbejde deres apps for at målrette mod en nyere API niveau. Hvordan hænger alt dette sammen med det nye pakkeinstallationsprogram? Nå, da Android 5.0 Lollipop er det sidste API-niveau uden obligatoriske anmodninger om runtime-tilladelser for visse følsomme tilladelser, vil apps, der målretter mod API-niveau 22 og derunder betyder, at Google ikke længere behøver at gøre plads i pakkeinstallationsmeddelelsen for at vise en lang liste over tilladelser, som en app er givet til installation.

Du vil sandsynligvis ikke se dette forenklede pakkeinstallationsprogram på alle Android Q-enheder. Huawei tilpasser for eksempel pakkeinstallationsprogrammet med en indbygget virus- og malware-scanner (noget jeg hader) samt en indbygget permission manager (noget jeg elsker.) EMUI 10 vil derfor sandsynligvis holde sig til fuldskærmspakkeinstallationsprogrammet, som vi alle er plejede.

Nye opkaldsblokeringsmuligheder

En funktion vi troede ville komme i Android Pie fandt faktisk vej til Android Q og viser dig, hvor tæt vi faktisk er på færdiggørelsen af ​​Android Q-kernefunktioner. Funktionen, vi fandt dengang, ville lade dig blokere opkald fra ukendte, private, betalingstelefonnumre eller numre, der ikke er på din kontaktliste. Her er et skærmbillede af funktionen fra AOSP dialer-appen. Google Phone-appen er ikke blevet opdateret med denne funktion endnu, men vi antager, at den snart får den.

Alle installerede apps viser nu startikoner (mulig fejl?)

De fleste apps på din enhed har launcher-ikoner, fordi de er beregnet til at være gateways til deres brugergrænseflade. Men ikke alle apper har en brugergrænseflade, i hvilket tilfælde en udvikler kan vælge ikke at erklære en aktivitet med handlings- og kategorihensigtsfiltrene android.intent.action.MAIN og android.intent.category.LAUNCHER henholdsvis. Jeg er ikke sikker på, om dette kun er en fejl, men i Android Q vil alle apps, selv dem, der forsøger at skjule deres launcher-ikoner på den måde, der er beskrevet ovenfor, vise ikoner i launcheren. Jeg testede dette på AOSP Launcher, Pixel Launcher og Nova Launcher på en Google Pixel 3 XL, der kører den lækkede Android Q build, og sammenlignede den med en Google Pixel 2 XL, der kører den nyeste Android 9 Pie bygge. Når du trykker på et af disse ikoner, bringer det dig blot til appens informationsside i Indstillinger.

Hvis dette ikke bare er en fejl, så ville dette være en måde for brugere hurtigt at se, om en ny app er blevet installeret, selvom den app forsøger at skjule sig for brugeren.

Flisen "Sensorer fra" Hurtigindstillinger

Der er en ny flise med hurtige indstillinger kaldet "sensorer slukket", som ikke kun aktiverer flytilstand, men også deaktiverer alle sensoraflæsninger på enheden. Jeg bekræftede dette ved at installere DevCheck fra XDA Recognized Developer flar2 og sammenligne output fra sensoraflæsningerne med og uden "sensorer slukket"-knappen. Når feltet "sensorer fra" er slået til, stopper enheden med at rapportere fra alle sensorer på enheden. Jeg er ikke sikker på, om denne hurtigindstillingsbrikke kun er til Google-ingeniører til at fejlfinde, men dette ville være en nyttig funktion for alle, der virkelig er bekymrede over, hvilke data deres enhed indsamler om deres miljø.

---

Mere om Android Q

Det er alt relateret til privatliv og tilladelser, som jeg hidtil har fundet i Android Q. Hold øje med min sidste artikel, der dækker alle de mindre UI- og UX-tweaks. Følg vores Android Q-tag for flere artikler som denne. Her er et link til nogle af de artikler, som jeg henviste til oftere, samt et par andre, som jeg synes, du bør læse:

• Eksklusivt: Tidlig Android Q build har et systemdækkende mørkt tema, Permission Revamp, hints til en "Desktop Mode" og mere
• Eksklusivt: Google arbejder på en Face ID-lignende funktion til Android Q
• Android Q kan blokere baggrundsudklipsholderlæsning, bedre beskyttelse af dine mediefiler, understøtte nedgradering af apps og mere
• Android Q leveres muligvis med nye skrifttype-, ikonform- og accentfarveoverlays
• "Dynamisk Android" kan lade udviklere teste en AOSP GSI på enhver Android Q-enhed
• Android Qs mørke tilstand: Hvordan Googles næste Android OS vil tackle blændende lette temaer