Share
Før M-utgaven har Android-tillatelsesmodellen vært en all-or-nothing-beslutning for brukere på installasjonstidspunktet. Dette betydde at hvis en bruker ønsket å bruke en app, måtte de først akseptere alle tillatelser som er inkludert i programmet, eller velge å ikke installere det i det hele tatt. Dette førte til at mange utviklere mistet ut på appinstallasjoner, en tillit koble fra brukere og utviklere, og andre personvernproblemer.
Under den nye tillatelsesmodellen kan brukerne godkjenne tillatelser ved kjøring som de trengs, og kan nekte disse tillatelsene når som helst. I denne artikkelen vil du lære hvordan denne endringen i håndteringsrettigheter vil påvirke deg som utvikler og hvordan brukerne vil oppleve dine applikasjoner.
Det skal bemerkes at denne artikkelen ble skrevet før den offisielle utgivelsen av Android M, slik at noen opplysninger kan endres med den offisielle utgivelsen.
Mens Android M fortsatt krever tillatelser som skal erklært i AndroidManifest.xml, Brukerne vil nå bli pålagt å godkjenne eller nekte bruken av den tillatelsen ved kjøring. En viktig endring i den nye versjonen av Android er det android.permission.INTERNET og android.permission.WRITE_EXTERNAL_STORAGE har blitt nedgradert fra en vurdering av farlig til normal. Dette betyr at du ikke trenger å spørre brukeren før bruk.
Når du ber om tillatelse godkjenning, blir brukeren bedt om å basere seg på tillatelsens gruppe, i stedet for å bli bedt om å godkjenne hver eneste tillatelse i en gruppe. Dette betyr at hvis din søknad må både sende og motta SMS-meldinger, blir brukeren din bare bedt om å godkjenne SMS-tillatelsesgruppen. Nedenfor er en liste over de godkjente gruppene som støttes for øyeblikket, i Android M Developer Preview 2, sett fra systeminnstillingene.
Det bør også bemerkes at Android har en robust Intent system, som tillater utviklere å be om data fra andre applikasjoner. I stedet for å måtte be om kameratillatelse og utvikle et program som bruker Kamera-APIer fra begynnelsen, kan du be om at brukeren tar et bilde ved hjelp av et allerede klarert kameraprogram for å få et bilde i appen din. Tillatelsene som involverer kameraet, håndteres av kameraprogrammet.
Når du trenger å bruke en funksjon som krever tillatelse, er det en generell strøm av hendelser som vil skje. Du må først se om tillatelsen allerede er godkjent av brukeren din.
Hvis brukeren ikke har godkjent tillatelsen, kan du presentere dem med en forespørsel om tillatelsesforespørsel. Første gang du presenterer dette for brukeren, må de enten nekte eller godkjenne tillatelsen.
Men hvis de tidligere har nektet tillatelsen og blir spurt igjen, vil de ha muligheten til å velge bort fra å bli bedt om tillatelsen igjen.
Du kan sjekke om en tillatelse tidligere har blitt gitt ved å ringe checkSelfPermission før du bruker en funksjon som krever den tillatelsen. Denne metoden returnerer en int verdi basert på hvorvidt tillatelsen er gitt eller ikke.
Hvis det er lik PackageManager.PERMISSION_GRANTED, så kan du fortsette som forventet. Men hvis den tillatelsen ikke har blitt gitt tidligere, kan du be om det med requestPermissions, passerer i en rekke tillatelsesstrenger og en egendefinert int forespørselskode for å holde oversikt over appens logikkflyt.
int hasLocationPermission = checkSelfPermission (Manifest.permission.ACCESS_FINE_LOCATION); int hasSMSPermission = checkSelfPermission (Manifest.permission.SEND_SMS); Listepermissions = ny ArrayList (); hvis (hasLocationPermission! = PackageManager.PERMISSION_GRANTED) permissions.add (Manifest.permission.ACCESS_FINE_LOCATION); hvis (hasSMSPermission! = PackageManager.PERMISSION_GRANTED) permissions.add (Manifest.permission.SEND_SMS); hvis (! permissions.isEmpty ()) requestPermissions (permissions.toArray (new String [permissions.size ()]), REQUEST_CODE_SOME_FEATURES_PERMISSIONS);
En gang requestPermissions kalles, blir brukeren presentert med en forespørseldialog for hver tillatelsesgruppe som søknaden din ber om tillatelse til. Det er best å bare be om tillatelser etter behov, i stedet for i bulk når brukeren først starter søknaden din.
Når brukeren er ferdig med dialogene, onRequestPermissionsResult kalles og kan nås i din Aktivitet. Her starter du enten din funksjon eller håndterer situasjonen der brukeren har nektet en eller flere tillatelser.
Et eksempel på hvordan du sjekker om en tillatelse er gitt eller nektet, vises nedenfor. Hvis brukeren har nektet noen nødvendige tillatelser for funksjonen din, bør du deaktivere denne funksjonen og la brukeren få vite hvorfor det ikke fungerer i søknaden din.
@Override public void onRequestPermissionsResult (int requestCode, String [] tillatelser, int [] grantResults) switch (requestCode) tilfelle REQUEST_CODE_SOME_FEATURES_PERMISSIONS: for (int i = 0; i < permissions.length; i++ ) if( grantResults[i] == PackageManager.PERMISSION_GRANTED ) Log.d( "Permissions", "Permission Granted: " + permissions[i] ); else if( grantResults[i] == PackageManager.PERMISSION_DENIED ) Log.d( "Permissions", "Permission Denied: " + permissions[i] ); break; default: super.onRequestPermissionsResult(requestCode, permissions, grantResults);
Mens apper som er bygget målrettet mot Android M, kreves for å implementere de nye tillatelsesdialogene og metodene, vil apper som er bygget for tidligere versjoner av Android, fremdeles presentere brukere med en liste over tillatelser på installasjonstidspunktet. Selv om tillatelser godtas før brukere kan bruke appen din, kan de til enhver tid tilbakekalles.
Siden infrastrukturen for håndtering av tilbakekalte tillatelser ikke vil være tilgjengelig i applikasjoner som er rettet mot mindre enn Android M, vil eventuelle funksjoner som vil ha nødvendige tillatelser returnere null, 0, eller en tom verdi når tillatelser ikke er gitt. Dette kan føre til uventet oppførsel i apper, så det anbefales at utviklere forbereder seg på å oppgradere sine apper for å støtte den nye Android M-tillatelsesmodellen så snart som mulig.
I denne artikkelen har du lært om den nye Android M-tillatelsesmodellen og hvordan du støtter oppdaterte tillatelser i programmene dine. Vi har også dekket hvordan apper vil svare på den nye versjonen av Android når de er bygget for tidligere versjoner. Ved hjelp av denne informasjonen, bør du kunne få applikasjonene dine klar for den offisielle utgivelsen av neste oppdatering til Android.
Accentsconagua