Hur Android Q förbättrar integritets- och behörighetskontroller över Android Pie

Android 9 Pies marknadspenetration är knappt en blixt på radarn jämfört med äldre Android-versioner, men det kommer inte att försena Googles planer på att släppa nästa version av Android, Android Q. Vi förväntar oss att Google kommer att avslöja den första utvecklarförhandsvisningen av Android Q någon gång nästa månad, men före Googles tillkännagivande att vi har lyckats lägga vantarna på ett Android Q-bygge som troligen är ganska långt i Googles utveckling cykel. I vår första artikel som beskriver ändringarna som kommer till nästa dessertversion, pratade vi om det nya gränssnittet för behörighetskontroll. Men jag visade bara några få skärmdumpar av det förnyade behörighetshanteringssystemet, så jag ville följa upp med mer detaljer. Jag har också gjort fler tester och samlat mer information om de nya behörigheterna i Android Q, funktionen "roller", det nya paketinstallationsprogrammet och mer. Men först, här är en kort sammanfattning av behörighetshantering i Android.

En kort historik om behörighetshantering i Android

Android 4.3 Jelly Bean först introducerades granulär behörighetshantering via funktionen "App Ops", även om den var dolt för användaren. Android 4.4 KitKat introducerade till och med nya användarkontrollerbara behörigheter i App Ops-gränssnittet, även om du behövde root-åtkomst och en Xposed-modul för att komma åt den. Slutligen introducerade Android 6.0 Marshmallow behörighetssystemet som vi alla är bekanta med, om än med begränsningar för vilka behörigheter du kan begränsa. Den äldre App Ops-funktionen finns fortfarande i Android, även om den bara kan nås via kommandoraden (cmd appops). Vissa applikationer i Google Play Butik dra fördel av App Ops kommandoradsimplementering för att ge ett kraftfullare gränssnitt för behörighetshantering. Google exponerar inte App Ops för användare eftersom användaren kanske inte vet vad de gör, vilket resulterar i att de nekar en app vissa behörigheter som den verkligen kan behöva för att fungera korrekt. Tyvärr, sedan introduktionen av behörighetshantering i Android Marshmallow, har vi inte sett några större förändringar av funktionen – det vill säga förrän Android Q.

App Ops i Android 4.3 Jelly Bean

Android 6.0 Marshmallow såg också en stor förändring i sättet att vissa behörigheter ges till applikationer. Före Android 6.0, allt behörigheter definierade i en appens manifestfil beviljas vid installation. Med Android 6.0, Google införde körningsbehörighetshantering för vissa behörigheter som de ansåg vara farliga, såsom extern lagringsåtkomst, kameraåtkomst, platsåtkomst och mer. Körtidsbehörigheter beviljas endast efter installationen av en app, och användaren måste uttryckligen samtycka till att bevilja dessa behörigheter genom att trycka på "tillåt" i en behörighetsdialogruta när så begärs. Tills Google slog ner på appar som är inriktade på en äldre API-nivå kan apputvecklare kringgå körningsbehörigheter genom att rikta in sig på API-nivå 22 eller lägre (Android Lollipop eller äldre.) Android Q kommer att varna användarna försöker köra en app som är inriktad på API-nivå 22 eller lägre, vilket ytterligare uppmuntrar utvecklare att uppdatera sina appar för att undvika att skämmas ut av operativsystemet. När Android Q gör sin väg till enheter bör alltså nästan varje app på en användares enhet utsättas för behörighetshanteringskontroller som introducerats i Android 6.0+. Med det i åtanke rensar Google upp behörighetskontrollerna i Android Q för att göra det enklare för användare att hantera vilken åtkomstnivå appar har på sin enhet.

Enklare behörighetshantering i Android Q jämfört med Android Pie

Från Android 6.0 Marshmallow till Android 9 Pie, den befintliga körtidsbehörighetshanteringen låter bara användaren tillåta eller neka en app vissa behörigheter. Vi noterade i vår tidigare artikel att Android Q kommer att tillåta användaren att begränsa en behörighet endast medan appen används. Den här funktionen gjorde många upphetsade, men vi måste förtydliga det endast platsbehörigheten kan begränsas till när en app används. Det betyder att du inte kan begränsa mikrofonen eller kameran bara när appen används. Du bör dock inte bli besviken över det, eftersom Android Pie redan är infördes vissa begränsningar för bakgrundsanvändningen av kamera och mikrofon genom att kräva att appar är i förgrunden eller använder en förgrundstjänst. Dessutom utökar Android Q det med avslöja för användaren när någon app använder mikrofonen, kameran eller kommer åt enhetens plats. Detta visas för användaren som statusfältikoner i det övre högra hörnet. När statusfältet expanderas, talar texten som visas bredvid ikonerna för användaren vilken app som för närvarande använder en av dessa tre känsliga behörigheter. Slutligen, om användaren trycker på den här ikonen, visas en dialogruta som talar om för användaren vilka appar som använder vilka behörigheter. Återigen, detta gäller endast kamera-, plats- och mikrofonbehörigheter.

Google verkar uppmuntra användare att begränsa platsåtkomst till endast när en app används, eftersom de har bakat in en påminnelse i Android Q när användaren har beviljat en app att alltid komma åt sin plats. Den här påminnelsen kommer i form av ett meddelande som talar om för användaren att en app har använt sin plats och att den alltid har möjlighet att göra det. Genom att trycka på aviseringen kommer du till sidan för platsbehörighet för den appen, vilket låter användaren välja att begränsa platsbehörigheten endast medan den appen används. Tack för det, Google.

Slutligen, i byggnaden som jag har, är gränssnittet för de speciella appåtkomstbehörigheterna (som batterioptimering, enhetsadministration, Stör ej-åtkomst, aviseringsåtkomst, etc.) oförändrat. En ny specialbehörighet för "Financial Apps SMS Access" har lagts till i listan, även om jag är osäker på hur det skiljer sig från behörigheten "Premium SMS access" som är vad appar behöver för att skicka textmeddelanden till premium tal. Det är möjligt att denna nya behörighet är avsedd för bankappar som använder SMS för vissa transaktioner, i enlighet med Google Plays nya policyer begränsa SMS och samtalsloggsbehörigheter.

Hantera behörigheter i Android Q

Här är ett skärmbildsgalleri som visar de nya ändringarna i gränssnittet för behörighetshantering i Android Q. Jag har inkluderat detaljerade beskrivningar av varje sida i bildtexterna till varje bild.

Bevilja behörigheter i Android Q

Här är skärmdumpar som visar körningsbehörighetshantering i Android Q. Vi har redan pratat om vad de två första skärmdumparna visar, men den tredje skärmdumpen är en helt ny Android Q-funktion som jag inte har diskuterat tidigare. Möjligheten för Android att tillåta användaren att kontrollera behörigheter innan en äldre app körs (definierad som en app som är inriktad på API-nivå < 23) är något som redan är möjligt i Android Pie med rätt konfiguration, men Google har äntligen vänt omkopplaren och aktiverat den i Android Q.

Realtidsövervakning av behörigheter i Android Q

Här är skärmdumpar som visar hur Android Q kommer att varna användaren när en app får åtkomst till en av flera känsliga/farliga behörigheter inklusive kamera, plats och mikrofon.

Nya begränsningar för åtkomst till urklipp, åtkomst till extern fil

Åtkomstbegränsningar för bakgrundsurklipp

I min tidigare artikel noterade jag en ny behörighet i Android Q: s ramverk som föreslog att appar som inte är systembaserade som körs i bakgrunden inte längre kommer att kunna läsa systemets urklipp. Efter att vi fick Google Play Store att fungera bestämde jag mig för att installera några populära appar för urklippshanterare som Urklippshanterare, Klippare, och Klippstapel för att testa om jag hade rätt. På gott och ont, Google blockerar åtkomst till urklipp i bakgrunden i Android Q, som ingen av apparna jag testade kunde upptäcka någon text som jag kopierade till urklippet. Jag bekräftade till och med att dessa appar har "READ_CLIPBOARD" tillstånd de begärde genom att använda följande App Ops-kommando:

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

Lyckligtvis fungerar det fortfarande att kopiera och klistra in text till och från valfri app, men appar som körs i bakgrunden kan inte längre läsa texten som kopieras. Det är för tidigt att säga om denna förändring kommer att döda urklippshanterarens appar eftersom det finns en möjlighet att Google kan introducera ett nytt API för att göra en app till en standardhanterare för urklippshanteraren. Jag ser dock inga bevis för att det skulle hända i Android Q.

Tillgång till extern lagringsfil

Jag täckte i stort sett allt om denna förändring i min tidigare artikel, men här är en sammanfattning av vad Google förändrar i Android Q med avseende på åtkomst till extern lagringsfil. Först måste vi definiera vad "extern lagring" betyder. I Android är extern lagring platsen där alla filer och mappar som du kan se när du ansluter din telefon till en dator, som nedladdningar, DCIM, musik, filmer och bilder, lagras. Appar ska bara lagra filer i extern lagring som andra appar kanske vill komma åt, som musik, bilder, videor, dokument, etc.

För att en app ska få åtkomst till filer på extern lagring måste appen hålla READ_EXTERNAL_STORAGE och/eller WRITE_EXTERNAL_STORAGE behörigheter, som båda är körtidsbehörigheter. När en app har dessa behörigheter finns det inga begränsningar för vilka filer på extern lagring den kan läsa eller ändra. I Android Q delar Google upp dessa två behörigheter i mer detaljerade behörigheter, vilket gör att användaren kan begränsa en app så att den bara kan läsa eller skriva vissa filtyper. Specifikt kommer de nya behörigheterna i Android Q att låta användaren begränsa en app så att den bara kan:

• Läs platserna från dina media.
• Läs eller skriv musikfiler.
• Läs eller skriv foton/bildfiler.
• Läs eller skriv videofiler.

En app som redan har beviljats ​​READ_EXTERNAL_STORAGE behörighet innan användaren uppgraderar till Android Q kommer automatiskt att beviljas "läs"-behörigheterna som anges ovan, men inte "skriva" behörigheter.

Tillgång till bakgrundsplats

Förra året en rapport från The New York Times sken på hur omfattande appar är som spårar användarnas platser för att sälja till annonsörer. Felaktig platsspårning är ett problem som Google är väl medvetet om, efter att ha varit det anklagade för det själva. Android 8.0 Oreo introduceras restriktioner om hur ofta appar som körs i bakgrunden kan komma åt en enhets plats. Platsförfrågningar från appar som körs i bakgrunden är kraftigt begränsade, så om en app vill spåra din plats med någon grad av precision måste den avslöja att den gör det med en synlig aktivitet eller en förgrundstjänst och en ihållande underrättelse.

Men varje gång Google ändrar hur grundläggande Android API: er fungerar, påverkas utvecklare vars appar legitimt använde dessa API: er som avsett. Vi har sett detta spela ut nyligen med Google Plays begränsningar för SMS och samtalsloggsbehörigheter, vilket resulterat i många populära appar förlorar nyckelfunktioner. Samma situation inträffade när Google begränsade bakgrundsposition åtkomst, med användare av en populär golf appklagar att de inte längre kunde använda den för att spåra sina skott. Lyckligtvis lägger Android Q till en ny "ACCESS_BACKGROUND_LOCATION" behörighet som, när den beviljas, alltid tillåter en app att ha åtkomst till en enhets plats, även när appen körs i bakgrunden. Således kommer den nya Android-versionen inte bara att fortsätta att skydda användare från oönskad platsåtkomst i bakgrunden, utan kommer också att tillhandahålla en mekanism för användare att tillåta appar efter eget val för att övervaka deras plats i bakgrunden.

Tillägget av "roller" i Android Q

Hos Daniel praktisk video för vår XDA TV YouTube-kanal, du kanske har hört honom nämna ett nytt avsnitt "Roller" i inställningarna för standardappar (Inställningar --> Appar och aviseringar --> Standardappar). De enda "rollerna" som visades i videon var för webbläsare, telefon och meddelanden, vilket verkade överflödigt eftersom det redan finns standardappkategorier för webbläsare, telefonappar och SMS-appar. Efter att ha tillbringat lite mer tid med Android Q på Pixel 3 XL upptäckte jag en "roll"-tjänst som jag kunde dumpa staten för via 'dumpsys role’ kommando. Efter att ha gjort det hittade jag flera "roller" som inte matchar någon av standardappkategorierna som redan finns: CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, och PROXY_CALLING_APP. Efter att ha installerat några av Googles förstapartsapplikationer lyckades jag få "Car mode phone app" och "Call screening app" att dyka upp på sidorna "roller", som visas nedan.

Jag dekompilerade den nya system-APK som ansvarar för Android Q: s behörighetshanteringsgränssnitt, en ny app som heter "PermissionController" och hittade en roles.xml-fil som tipsar om vad "roller" kommer att göra i nästa Android version. Jag tänker inte klistra in hela XML här, men jag delar med mig av ett utdrag av en av rollerna som borde hjälpa dig att förstå vad roller kommer att göra.

Låt oss säga att jag väljer en app som ska ha rollen "galleri". För att en app ska visas som en giltig galleriapp måste den ha en obligatorisk komponent: en aktivitet som startar med filtren för åtgärd och kategoriavsikt android.intent.action.MAIN och android.intent.category.APP_GALLERY respektive. Om det är sant och appen får rollen "galleri" av användaren, kommer appen automatiskt att beviljas behörigheter i behörighetsuppsättningen "media_visual", som jag tror hänvisar till den nya ljud-, video- och bildbehörighet som jag beskrev tidigare. Faktum är att det nya WRITE_MEDIA_VIDEO och WRITE_MEDIA_IMAGES behörigheter är uttryckligen tillåtna för en app med rullen "galleri". Slutligen blir appen den föredragna hanteraren när en annan app skickar en avsikt att anropa en galleriapp.

I grund och botten, alla appar som har beviljats ​​en viss "roll" och har de nödvändiga komponenterna och behörigheterna deklareras automatiskt beviljas andra behörighetsuppsättningar som är relevanta för deras användningsfall. I exemplet jag postade ovan får en app med galleriets "roll" automatiskt tillstånd att spara åtkomstrelaterade behörighetsuppsättningar som den behöver för att fungera. Förmodligen betyder detta att en app som har beviljats ​​gallerirollen av användaren inte skulle behöva be användaren om tillåtelse att läsa eller skriva bild- eller videofiler.

Av namnen att döma CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, och PROXY_CALLING_APP roller låter användaren välja en annan uppringningsapp när de kör, en app för att utföra olika funktioner medan användaren är i en telefonsamtal, en app för att kontrollera telefonsamtal innan användaren svarar och en app för att underlätta samtal med ett mellanhandsnummer, respektive. Vi tror inte att samtalsscreeningsrollen är direkt relaterad till Google Pixels Samtalsskärm funktion, att döma av vad vi har sett i AOSP. Snarare är den avsedd för appar som vill fungera som en studsare för spamsamtal, som ett samtalsfilter.

Förnyat paketinstallationsprogram

Androids standardpaketinstallationsprogram (applikationen som hanterar installationen av nya appar) får en omdesign. Istället för att visa en helskärmsaktivitet när du vill installera en ny app, visar det uppdaterade paketinstallationsprogrammet i Android Q en liten dialogruta i mitten av skärmen. Detta minipaketinstallationsgränssnitt har använts för Android-surfplattor under lång tid, men det här är det första vi ser det på Android-smarttelefoner.

Om du kör valfri app som är inriktad på API-nivå 22 eller lägre (Android 5.0 Lollipop) i Android Q visas en varning om att appen är föråldrad. Den varningen, misstänker jag, är tillräckligt för att avskräcka de flesta användare från att störa sig på appar som är inriktade på pre-Android Marshmallow-versioner. Kombinera det med det faktum att Google kommer att kräva att alla appar som skickas till Play Butik efter augusti 2019 ska riktas in API nivå 28, du kan se hur utvecklare med föråldrade appar tvingas omarbeta sina appar för att rikta in sig på ett nyare API nivå. Hur hänger allt detta ihop med det nya paketinstallationsprogrammet? Tja, eftersom Android 5.0 Lollipop är den sista API-nivån utan obligatoriska förfrågningar om körningstillstånd för vissa känsliga behörigheter, kommer appar som riktar sig till slut att dö. API-nivå 22 och lägre innebär att Google inte längre behöver göra plats i paketinstallationsmeddelandet för att visa en lång lista med behörigheter som en app beviljas installation.

Du kommer förmodligen inte att se detta förenklade paketinstallationsprogram på alla Android Q-enheter. Huawei, till exempel, anpassar paketinstallationsprogrammet med en inbyggd virus- och skadlig programvara (något jag hatar) samt en inbyggd behörighetshanterare (något jag älskar.) EMUI 10 kommer därför förmodligen att hålla sig till installationsprogrammet för helskärmspaket som vi alla är brukade.

Nya samtalsblockeringsalternativ

En funktion vi trodde skulle komma i Android Pie tog sig faktiskt in i Android Q, och visar hur nära vi faktiskt är slutförandet av Android Qs kärnfunktioner. Funktionen vi hittade då skulle låta dig blockera samtal från okända, privata, betaltelefonnummer eller andra nummer som inte finns i din kontaktlista. Här är en skärmdump av funktionen från AOSP dialer-appen. Google Phone-appen har inte uppdaterats med den här funktionen ännu, men vi antar att den kommer att få den någon gång snart.

Alla installerade appar visar nu startikoner (möjlig bugg?)

De flesta appar på din enhet har startikoner eftersom de är tänkta att vara portar till deras användargränssnitt. Men inte alla appar har ett användargränssnitt, i vilket fall en utvecklare kan välja att inte deklarera en aktivitet med filtren för åtgärd och kategoriavsikt android.intent.action.MAIN och android.intent.category.LAUNCHER respektive. Jag är inte säker på om detta bara är en bugg, men i Android Q kommer alla appar, även de som försöker dölja sina startikoner på det sätt som beskrivs ovan, att visa ikoner i startprogrammet. Jag testade detta på AOSP Launcher, Pixel Launcher och Nova Launcher på en Google Pixel 3 XL som körs det läckta Android Q-bygget och jämförde det med en Google Pixel 2 XL som kör den senaste Android 9 Pie bygga. När du trycker på en av dessa ikoner kommer du helt enkelt till appens informationssida i Inställningar.

Om detta inte bara är en bugg, skulle detta vara ett sätt för användare att snabbt se om en ny app har installerats, även om den appen försöker gömma sig för användaren.

"Sensorer av" Snabbinställningar bricka

Det finns en ny snabbinställningar som kallas "sensorer av" som inte bara aktiverar flygplansläge utan också inaktiverar alla sensoravläsningar på enheten. Jag bekräftade detta genom att installera DevCheck från XDA Recognized Developer flar2 och jämför utdata från sensoravläsningarna med och utan växeln "sensorer av". När panelen "sensorer av" är aktiverade slutar enheten att rapportera från alla sensorer på enheten. Jag är inte säker på om denna snabbinställning bara är för Googles ingenjörer att felsöka, men det här skulle vara en användbar funktion för alla som verkligen bryr sig om vilken data deras enhet samlar in om deras miljö.

---

Mer om Android Q

Det är allt sekretess- och behörighetsrelaterat som jag hittills har hittat i Android Q. Håll utkik efter min sista artikel som täcker alla mindre UI- och UX-tweaks. Följ vår Android Q-tagg för fler artiklar som denna. Här är en länk till några av de artiklar som jag hänvisade till oftare, samt några andra som jag tycker du borde läsa:

• Exklusivt: Tidig Android Q-byggnad har ett systemomfattande mörkt tema, Permission Revamp, tips om ett "Skrivbordsläge" och mer
• Exklusivt: Google arbetar på en Face ID-liknande funktion för Android Q
• Android Q kan blockera urklipp i bakgrunden, skydda dina mediefiler bättre, stödja nedgradering av appar och mer
• Android Q kan levereras med nya teckensnitt, ikonform och accentfärgöverlägg
• "Dynamic Android" kan låta utvecklare testa en AOSP GSI på vilken Android Q-enhet som helst
• Android Q: s mörka läge: Hur Googles nästa Android OS kommer att hantera bländande lätta teman