Hoe Android Q de privacy- en toestemmingscontroles via Android Pie verbetert

De marktpenetratie van Android 9 Pie is nauwelijks een vlekje op de radar vergeleken met oudere Android-versies, maar dat zal de plannen van Google om de volgende versie van Android, Android Q, uit te brengen, niet vertragen. We verwachten dat Google ergens volgende maand de eerste Developer Preview van Android Q zal onthullen, maar vóór die van Google aankondiging dat we erin zijn geslaagd een Android Q-build te bemachtigen die waarschijnlijk behoorlijk ver in de ontwikkeling van Google is fiets. In ons eerste artikel, waarin we de wijzigingen voor de volgende dessertrelease beschrijven, hebben we het gehad over de nieuwe interface voor toestemmingscontrole. Ik liet echter slechts een paar schermafbeeldingen zien van het vernieuwde toestemmingsbeheersysteem, dus ik wilde meer details geven. Ik heb ook meer tests gedaan en meer informatie verzameld over de nieuwe rechten in Android Q, de functie "rollen", het nieuwe pakketinstallatieprogramma en meer. Maar eerst volgt hier een korte samenvatting van het toestemmingsbeheer in Android.

Een korte geschiedenis van machtigingsbeheer in Android

Android 4.3Jelly Bean voor het eerst geïntroduceerd gedetailleerd rechtenbeheer via de "App Ops" -functie, hoewel deze voor de gebruiker verborgen was. Android 4.4 KitKat introduceerde zelfs nieuwe, door de gebruiker bestuurbare machtigingen in de App Ops-interface, hoewel jij dat ook deed benodigde root-toegang en een Xposed-module om er toegang toe te krijgen. Ten slotte introduceerde Android 6.0 Marshmallow het machtigingssysteem waar we allemaal bekend mee zijn, zij het met beperkingen op welke machtigingen je kunt beperken. De oudere App Ops-functie bestaat nog steeds in Android, hoewel deze alleen toegankelijk is via de opdrachtregel (cmd appops). Bepaalde toepassingen in de Google Play Store profiteer van de opdrachtregelimplementatie van App Ops om een ​​krachtigere interface voor toestemmingsbeheer te bieden. Google stelt App Ops niet bloot aan gebruikers, omdat de gebruiker mogelijk niet weet wat hij doet, waardoor hij een app bepaalde rechten ontzegt die deze mogelijk echt nodig heeft om correct te functioneren. Helaas hebben we sinds de introductie van toestemmingsbeheer in Android Marshmallow geen grote veranderingen in de functie gezien, dat wil zeggen tot Android Q.

App-bewerkingen in Android 4.3 Jelly Bean

Android 6.0 Marshmallow zag ook een grote verandering in de manier waarop bepaalde rechten aan applicaties worden verleend. Vóór Android 6.0 allemaal machtigingen gedefinieerd in een manifestbestand van de app worden toegekend bij installatie. Met Android 6.0, Google runtime-toestemmingsbeheer geïntroduceerd voor bepaalde machtigingen die ze gevaarlijk achtten, zoals toegang tot externe opslag, cameratoegang, locatietoegang en meer. Runtime-machtigingen worden alleen verleend na de installatie van een app, en de gebruiker moet expliciet toestemming geven voor het verlenen van deze machtigingen door op "toestaan" te tikken in een toestemmingsdialoogvenster wanneer daarom wordt gevraagd. Tot Googlen gekraakt voor apps die een ouder API-niveau targeten, konden app-ontwikkelaars runtime-rechten omzeilen door API-niveau 22 of lager te targeten (Android Lollipop of ouder). Android Q zal gebruikers waarschuwen proberen een app uit te voeren die zich richt op API-niveau 22 of lager, waardoor ontwikkelaars nog meer worden gestimuleerd hun apps bij te werken om te voorkomen dat ze door het besturingssysteem worden beschaamd. Dus tegen de tijd dat Android Q zijn weg vindt naar apparaten, zou bijna elke app op het apparaat van een gebruiker moeten worden onderworpen aan controles op het gebied van toestemmingsbeheer die zijn geïntroduceerd in Android 6.0+. Met dat in gedachten ruimt Google de toestemmingscontroles in Android Q op, zodat gebruikers gemakkelijker kunnen beheren welk toegangsniveau apps op hun apparaat hebben.

Eenvoudiger machtigingsbeheer in Android Q versus Android Pie

Van Android 6.0 Marshmallow tot Android 9 Pie laat het bestaande beheer van runtime-rechten de gebruiker alleen bepaalde rechten toestaan ​​of weigeren aan een app. We hebben in ons vorige artikel opgemerkt dat Android Q de gebruiker alleen toestaat een toestemming te beperken terwijl de app in gebruik is. Deze functie heeft veel mensen enthousiast gemaakt, maar dat moeten we verduidelijken alleen de locatietoestemming kan worden beperkt tot wanneer een app in gebruik is. Dat betekent dat je de microfoon of camera niet alleen kunt beperken terwijl de app in gebruik is. Daar moet je echter niet teleurgesteld over zijn, aangezien Android Pie al bestaat geïntroduceerd enkele beperkingen op het achtergrondgebruik van de camera En microfoon door te vereisen dat apps op de voorgrond staan ​​of een voorgrondservice gebruiken. Bovendien breidt Android Q daarop uit door het aan de gebruiker bekendmaken wanneer een app de microfoon of camera gebruikt of toegang heeft tot de locatie van het apparaat. Dit wordt aan de gebruiker getoond als statusbalkpictogrammen in de rechterbovenhoek. Wanneer de statusbalk is uitgevouwen, vertelt de tekst naast de pictogrammen de gebruiker welke app momenteel een van deze drie gevoelige machtigingen gebruikt. Als de gebruiker ten slotte op dit pictogram tikt, wordt een dialoogvenster weergegeven waarin de gebruiker wordt geïnformeerd welke app(s) welke toestemming(en) gebruiken. Nogmaals, dit is alleen van toepassing op de camera-, locatie- en microfoonrechten.

Google lijkt gebruikers aan te moedigen locatietoegang alleen te beperken tot wanneer een app in gebruik is, zoals ze hebben ingebakken herinnering in Android Q wanneer de gebruiker een app toestemming heeft gegeven om altijd toegang te hebben tot zijn locatie. Deze herinnering komt in de vorm van een melding die de gebruiker vertelt dat een app zijn locatie heeft gebruikt en dat deze altijd de mogelijkheid heeft om dit te doen. Als u op de melding tikt, gaat u naar de locatietoestemmingspagina voor die app, waar de gebruiker ervoor kan kiezen de locatietoestemming alleen te beperken terwijl die app in gebruik is. Complimenten daarvoor, Google.

Ten slotte is in de build die ik heb de gebruikersinterface voor de speciale app-toegangsrechten (zoals batterijoptimalisatie, apparaatbeheer, toegang tot niet storen, toegang tot meldingen, enz.) ongewijzigd. Er is echter een nieuwe speciale toestemming voor "Financiële apps SMS-toegang" aan de lijst toegevoegd, hoewel ik niet zeker weet hoe het verschilt van de toestemming "Premium SMS-toegang", wat apps nodig hebben om sms-berichten naar premium te sturen cijfers. Het is mogelijk dat deze nieuwe toestemming bedoeld is voor bankapps die bij bepaalde transacties gebruik maken van sms, conform Het nieuwe beleid van Google Play het beperken van sms- en oproeplogrechten.

Machtigingen beheren in Android Q

Hier is een screenshotgalerij die de nieuwe wijzigingen in de interface voor toestemmingsbeheer in Android Q laat zien. Ik heb gedetailleerde beschrijvingen van elke pagina opgenomen in de bijschriften van elke afbeelding.

Machtigingen verlenen in Android Q

Hier zijn schermafbeeldingen die het runtime-toestemmingsbeheer in Android Q laten zien. We hebben het al gehad over wat de eerste twee screenshots laten zien, maar de derde screenshot is een geheel nieuwe Android Q-functie die ik nog niet eerder heb besproken. De mogelijkheid voor Android om de gebruiker toestemming te geven de rechten te beheren voordat een verouderde app wordt uitgevoerd (gedefinieerd als een app die zich richt op API-niveau < 23) is iets dat al mogelijk is in Android Pie met de juiste configuratie, maar Google heeft eindelijk de schakelaar omgedraaid en ingeschakeld in Android Q.

Realtime monitoring van rechten in Android Q

Hier zijn schermafbeeldingen die laten zien hoe Android Q de gebruiker waarschuwt wanneer een app toegang heeft tot een van de verschillende gevoelige/gevaarlijke machtigingen, waaronder camera, locatie en microfoon.

Nieuwe beperkingen voor toegang tot het klembord en toegang tot externe bestanden

Toegangsbeperkingen op het achtergrondklembord

In mijn vorige artikel merkte ik een nieuwe toestemming op in het Android Q-framework die suggereerde dat niet-systeemapps die op de achtergrond draaien, het systeemklembord niet langer kunnen lezen. Nadat we de Google Play Store werkend hadden gekregen, besloot ik een paar populaire klembordbeheer-apps te installeren, zoals Klembordbeheerder, Klipper, En Clipstapel om te testen of ik gelijk had. Hoe het ook zij, Google blokkeert toegang tot het klembord op de achtergrond in Android Q, zoals geen van de apps die ik heb getest, kon tekst detecteren die ik naar het klembord had gekopieerd. Ik heb zelfs bevestigd dat deze apps de "READ_CLIPBOARD"toestemming die ze hebben aangevraagd met behulp van de volgende App Ops-opdracht:

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

Gelukkig werkt het kopiëren en plakken van tekst van en naar elke app nog steeds, maar apps die op de achtergrond draaien, kunnen de tekst die wordt gekopieerd niet meer lezen. Het is nog te vroeg om te zeggen of deze wijziging apps voor klembordbeheer zal vernietigen, omdat de mogelijkheid bestaat dat Google een nieuwe API introduceert om van een app een standaard "klembordbeheer"-handler te maken. Ik zie echter geen enkel bewijs dat dit gebeurt in Android Q.

Toegang tot externe opslagbestanden

Ik heb vrijwel alles over deze wijziging besproken in mijn eerdere artikel, maar hier is een samenvatting van wat Google verandert in Android Q met betrekking tot toegang tot externe opslagbestanden. Eerst moeten we definiëren wat "externe opslag" betekent. In Android is externe opslag de locatie waar alle bestanden en mappen worden opgeslagen die u kunt zien wanneer u uw telefoon op een computer aansluit, zoals downloads, DCIM, muziek, films en afbeeldingen. Het is de bedoeling dat apps alleen bestanden opslaan in externe opslag waartoe andere apps mogelijk toegang willen hebben, zoals muziek, afbeeldingen, video's, documenten, enz.

Als een app toegang wil krijgen tot bestanden op externe opslag, moet de app de LEES_EXTERNAL_STORAGE en/of SCHRIJF_EXTERNAL_STORAGE machtigingen, die beide runtime-machtigingen zijn. Zodra een app deze machtigingen heeft, zijn er geen beperkingen voor welke bestanden op externe opslag deze kan lezen of wijzigen. In Android Q splitst Google deze twee machtigingen op in meer gedetailleerde machtigingen, waardoor de gebruiker een app kan beperken zodat deze alleen bepaalde bestandstypen kan lezen of schrijven. Met de nieuwe machtigingen in Android Q kan de gebruiker een app beperken, zodat deze alleen het volgende kan doen:

• Lees de locaties uit uw media.
• Muziekbestanden lezen of schrijven.
• Foto's/afbeeldingsbestanden lezen of schrijven.
• Videobestanden lezen of schrijven.

Een app waaraan al de machtiging READ_EXTERNAL_STORAGE is verleend voordat de gebruiker een upgrade naar heeft uitgevoerd Android Q krijgt automatisch de hierboven genoemde "lees"-rechten, maar niet de "schrijf"-rechten rechten.

Toegang tot achtergrondlocatie

Vorig jaar verscheen een rapport van De New York Times scheen licht op de alomtegenwoordigheid van apps die de locaties van gebruikers volgen om aan adverteerders te verkopen. Onjuiste locatietracking is een probleem waarvan Google zich terdege bewust is er zelf van beschuldigd. Android 8.0 Oreo geïntroduceerd beperkingen over hoe vaak apps die op de achtergrond draaien toegang hebben tot de locatie van een apparaat. Locatieverzoeken van apps die op de achtergrond worden uitgevoerd, worden zwaar beperkt, dus als een app uw locatie wil volgen mate van nauwkeurigheid moet het bekendmaken dat het dit doet met een zichtbare activiteit of een voorgrondservice en een persistent kennisgeving.

Telkens wanneer Google de manier verandert waarop de kern-API's van Android werken, worden ontwikkelaars wier apps deze API's op legitieme wijze gebruikten zoals bedoeld, hierdoor getroffen. We hebben dit onlangs zien gebeuren met de beperkingen van Google Play op sms- en oproeplogrechten, wat resulteerde in veel populaire apps verliezen belangrijke functionaliteit. Dezelfde situatie deed zich voor toen Google de toegang tot locatie op de achtergrond beperkte, met gebruikers van een populaire golf-appklagen dat ze het niet langer konden gebruiken om hun schoten te volgen. Gelukkig voegt Android Q een nieuwe "ACCESS_BACKGROUND_LOCATION"-toestemming die, indien verleend, een app altijd toegang geeft tot de locatie van een apparaat, zelfs als de app op de achtergrond draait. De nieuwe Android-versie zal dus niet alleen gebruikers blijven beschermen tegen ongewenste toegang tot locatie op de achtergrond, maar zal ook een mechanisme bieden waarmee gebruikers apps kunnen toestaan van hun keuze om hun locatie op de achtergrond te controleren.

De toevoeging van "Rollen" in Android Q

Bij Daniël hands-on filmpje voor onze XDA TV YouTube-kanaal, heb je hem misschien een nieuwe sectie 'Rollen' horen noemen in de standaardapps-instellingen (Instellingen --> Apps en meldingen --> Standaardapps). De enige “rollen” die in de video werden getoond waren voor Browser, Telefoon en Berichten, wat overbodig leek omdat er al standaard app-categorieën zijn voor browser, telefoonapps en sms-apps. Na wat meer tijd met Android Q op de Pixel 3 XL te hebben doorgebracht, ontdekte ik een ‘rol’-service waarvoor ik de status kon dumpen via de ‘dumpsys role’ commando. Nadat ik dit had gedaan, vond ik verschillende "rollen" die niet overeenkomen met de standaard app-categorieën die al bestaan: CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, En PROXY_CALLING_APP. Nadat ik een paar van Google's first-party applicaties had geïnstalleerd, slaagde ik erin om de "Automodus telefoon-app" en "Oproepscreening-app" te laten verschijnen op de "rollen" -pagina's, zoals hieronder weergegeven.

Ik heb de nieuwe systeem-APK gedecompileerd die verantwoordelijk is voor de toestemmingsbeheerinterface van Android Q, een nieuwe app genaamd "PermissionController", en vond een Roles.xml-bestand dat aangeeft wat "Roles" zal doen in de volgende Android versie. Ik ga niet de hele XML hier plakken, maar ik zal een fragment van een van de rollen delen, zodat u beter begrijpt wat rollen zullen doen.

Stel dat ik een app selecteer die de rol 'galerij' heeft. Om ervoor te zorgen dat een app wordt weergegeven als een geldige galerij-app, moet deze één vereist onderdeel hebben: een activiteit die wordt gestart met de actie- en categorie-intentiefilters android.intent.action.MAIN En android.intent.category.APP_GALLERY respectievelijk. Als dat waar is en de app de rol 'galerij' krijgt van de gebruiker, krijgt de app automatisch machtigingen in de machtigingenset "media_visual", die volgens mij verwijst naar de nieuwe toestemming voor audio, video en afbeeldingen die ik heb beschreven eerder. Sterker nog, het nieuwe WRITE_MEDIA_VIDEO En WRITE_MEDIA_IMAGES machtigingen zijn expliciet toegestaan ​​voor een app met de rol 'galerij'. Ten slotte wordt de app de voorkeurshandler wanneer een andere app een intentie verzendt om een ​​galerij-app aan te roepen.

In principe krijgt elke app waaraan een bepaalde "rol" is toegekend en waarvan de vereiste componenten en machtigingen zijn gedeclareerd, automatisch andere machtigingensets die relevant zijn voor hun gebruiksscenario's. In het voorbeeld dat ik hierboven heb gepost, krijgt een app met de "rol" van de galerij automatisch toestemming om toegang te krijgen tot bestanden die de app nodig heeft om te werken. Vermoedelijk betekent dit dat een app die door de gebruiker de galerijrol heeft gekregen, de gebruiker niet om toestemming hoeft te vragen om afbeeldings- of videobestanden te lezen of te schrijven.

Afgaande op de namen is de CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, En PROXY_CALLING_APP Met rollen kan de gebruiker tijdens het rijden een andere dialer-app kiezen, een app die verschillende functies uitvoert terwijl de gebruiker zich in een auto bevindt telefoongesprek, een app om telefoongesprekken te screenen voordat de gebruiker opneemt, en een app om het bellen met een tussennummer te vergemakkelijken, respectievelijk. We geloven niet dat de rol van oproepscreening rechtstreeks verband houdt met die van de Google Pixel Oproepscherm functie, te oordelen naar wat we in AOSP hebben gezien. Het is eerder bedoeld voor apps die willen fungeren als uitsmijter voor spamoproepen, zoals een oproepfilter.

Vernieuwd pakketinstallatieprogramma

Het standaardpakketinstallatieprogramma van Android (de applicatie die de installatie van nieuwe apps afhandelt) krijgt een nieuw ontwerp. In plaats van een activiteit op volledig scherm weer te geven wanneer u een nieuwe app wilt installeren, geeft het bijgewerkte pakketinstallatieprogramma in Android Q een klein dialoogvenster in het midden van het scherm weer. Deze gebruikersinterface voor het installeren van minipakketten wordt al lange tijd gebruikt voor Android-tablets, maar dit is de eerste die we zien op Android-smartphones.

In Android Q wordt bij het uitvoeren van apps die zich richten op API-niveau 22 of lager (Android 5.0 Lollipop) een waarschuwing weergegeven dat de app verouderd is. Ik vermoed dat die waarschuwing voldoende is om de meeste gebruikers ervan te weerhouden zich bezig te houden met apps die zich richten op pre-Android Marshmallow-versies. Koppel dat aan het feit dat Google vereist dat alle apps die na augustus 2019 bij de Play Store worden ingediend, worden getarget API-niveau 28, je kunt zien hoe ontwikkelaars met verouderde apps gedwongen worden hun apps te herwerken om zich op een nieuwere API te richten niveau. Hoe verhoudt dit alles zich tot het nieuwe pakketinstallatieprogramma? Omdat Android 5.0 Lollipop het laatste API-niveau is zonder verplichte runtime-toestemmingsverzoeken voor bepaalde gevoelige machtigingen, zal de uiteindelijke dood van apps die zich richten op API-niveau 22 en lager betekent dat Google niet langer ruimte hoeft te maken in het pakketinstallatiebericht om een ​​lange lijst met machtigingen weer te geven waarvoor een app is verleend installatie.

U zult dit vereenvoudigde pakketinstallatieprogramma waarschijnlijk niet op alle Android Q-apparaten zien. Huawei past het pakketinstallatieprogramma bijvoorbeeld aan met een ingebouwde virus- en malwarescanner (iets waar ik een hekel aan heb) en een ingebouwde toestemmingsbeheerder (iets waar ik dol op ben). EMUI 10 zal daarom waarschijnlijk vasthouden aan het installatieprogramma voor pakketten op volledig scherm, we zijn allemaal gewend om.

Nieuwe opties voor het blokkeren van oproepen

Een kenmerk we dachten dat het in Android Pie zou komen daadwerkelijk zijn weg gevonden naar Android Q, en laat zien hoe dicht we daadwerkelijk zijn bij de afronding van de kernfuncties van Android Q. Met de functie die we toen ontdekten, kun je oproepen blokkeren van onbekende, privé-, betaaltelefoonnummers of nummers die niet in je contactenlijst staan. Hier is een screenshot van de functie van de AOSP-dialer-app. De Google Phone-app is nog niet bijgewerkt met deze functie, maar we gaan ervan uit dat deze binnenkort beschikbaar zal zijn.

Alle geïnstalleerde apps tonen nu Launcher-pictogrammen (mogelijke bug?)

De meeste apps op uw apparaat hebben opstartpictogrammen omdat ze bedoeld zijn als toegangspoort tot hun gebruikersinterface. Niet elke app heeft echter een gebruikersinterface, in welk geval een ontwikkelaar ervoor kan kiezen een activiteit niet aan te geven met de actie- en categorie-intentiefilters android.intent.action.MAIN En android.intent.category.LAUNCHER respectievelijk. Ik weet niet zeker of dit slechts een bug is, maar in Android Q zullen alle apps, zelfs degenen die hun opstartpictogrammen proberen te verbergen op de hierboven beschreven manier, pictogrammen in het opstartprogramma weergeven. Ik heb dit getest op de standaard AOSP Launcher, Pixel Launcher en Nova Launcher op een Google Pixel 3 XL met de gelekte Android Q-build en vergeleek deze met een Google Pixel 2 XL met de nieuwste Android 9 Pie bouwen. Wanneer u op een van deze pictogrammen tikt, gaat u eenvoudigweg naar de informatiepagina van die app in Instellingen.

Als dit niet alleen maar een bug is, dan zou dit voor gebruikers een manier zijn om snel te zien of er een nieuwe app is geïnstalleerd, zelfs als die app zichzelf voor de gebruiker probeert te verbergen.

Tegel Snelle instellingen "Sensoren uit".

Er is een nieuwe tegel voor snelle instellingen genaamd "sensoren uit", die niet alleen de vliegtuigmodus inschakelt, maar ook schakelt alle sensormetingen op het apparaat uit. Ik heb dit bevestigd door te installeren OntwikkelaarCheck van XDA Recognized Developer flar2 en vergelijkt de uitvoer van de sensormetingen met en zonder de schakelaar "sensoren uit". Wanneer de tegel 'sensoren uit' is ingeschakeld, stopt het apparaat met het rapporteren van alle sensoren op het apparaat. Ik weet niet zeker of deze tegel met Snelle instellingen alleen bedoeld is voor foutopsporing door Google-technici, maar dit zou een Handige functie voor iedereen die zich echt zorgen maakt over welke gegevens hun apparaat over hen verzamelt omgeving.

---

Meer over Android Q

Dat is alles wat met privacy en toestemming te maken heeft dat ik tot nu toe in Android Q heb gevonden. Houd ons in de gaten voor mijn laatste artikel over alle kleinere UI- en UX-aanpassingen. Volg onze Android Q-tag voor meer artikelen zoals deze. Hier is een link naar enkele van de artikelen waar ik vaker naar verwees, evenals een paar andere die je volgens mij zou moeten lezen:

• Exclusief: vroege Android Q-build heeft een systeembreed donker thema, toestemming vernieuwd, hints naar een “Desktop-modus” en meer
• Exclusief: Google werkt aan een Face ID-achtige functie voor Android Q
• Android Q kan lezingen op het klembord op de achtergrond blokkeren, uw mediabestanden beter beschermen, het downgraden van apps ondersteunen en meer
• Android Q wordt mogelijk geleverd met nieuwe lettertype-, pictogramvorm- en accentkleuroverlays
• Met “Dynamic Android” kunnen ontwikkelaars een AOSP GSI testen op elk Android Q-apparaat
• De donkere modus van Android Q: hoe het volgende Android-besturingssysteem van Google verblindend lichte thema’s zal aanpakken