Dynamiczna obsługa pozwoleń w Android Marshmallow

Każda aplikacja potrzebuje od użytkownika pozwoleń na używanie sieci, dostępu do czujników, czy pamięci urządzenia. Od API 23, czyli Androida w wersji 6.0 powstał nowy model obsługi pozwoleń. Dotąd przy instalacji użytkownik musiał bezwzględnie zatwierdzić listę pozwoleń, o które prosi aplikacja. Obecnie na żywo w aplikacji pojawiać się mogą prośby tylko o konkretne, potrzebne w danej chwili pozwolenia.

Stare vs. nowe

Jeśli ustawimy targetSdkVersion na 22 lub niżej, wszystko będzie po staremu, więc nie musimy specjalnie martwić się o starsze aplikacje odpalane na nowym systemie. Standardowo zostaniemy zapytani o wszystkie pozwolenia przy instalacji. Są jednak pewne wyjątki związane z przeorganizowaniem grup pozwoleń. Przykładowo, aby móc w pełni użyć bluetooth nie wystarczą już pozwolenia z nim związane. Do skanowania urządzeń i łączenia konieczne jest teraz pozwolenie na dostęp do lokalizacji. Tutaj możemy o tym przeczytać więcej: wyjaśnienie. W starych aplikacjach wykorzystujących bluetooth konieczne będzie dodanie pozwolenia na ACCESS_COARSE_LOCATION pomimo, że wszystko było projektowane pod API starsze niż w wersji 23! Wystarczy jednak dodać jedną linijkę do manifestu i działanie wróci do normy.

Bezpieczeństwo

Ustawiając targetSdkVersion na 23 lub wyżej, jesteśmy zmuszeni do wywołania okienka systemowego z zapytaniem o konkretne pozwolenie. Niezależnie od wersji wszystkie pozwolenia muszą być wypisane w pliku manifestu, jednak od API 23, należy pokazać użytkownikowi w trakcie działania aplikacji okienko systemowe z zapytaniem o dostęp do newralgicznych danych. Na szczęście nie wszystkie pozwolenia potrzebują specjalnego przerywania użytkownikowi pracy z aplikacją. Istnieje grupa pozwoleń niebezpiecznych, które muszą być w ten sposób obsługiwane i można je znaleźć tutaj: grupa pozwoleń niebezpiecznych. Warto też dodać, że bezpośrednio w ustawieniach systemowych można w dowolnym momencie cofnąć lub przyznać niebezpieczne pozwolenie.

Aby wywołać okienko z zapytaniem o pozwolenie, potrzebny będzie prosty kod wywołany w dowolnej aktywności:

ActivityCompat.requestPermissions(this, new String[]{permission}, requestCode);

Odpowiedź przyjdzie w nadpisanej metodzie aktywności:

@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
}

Nie musimy jednak robić tego przed każdym użyciem funkcji wymagającej danego pozwolenia. Najpierw należy sprawdzić czy pozwolenie zostało już przyznane. Prawidłowy kod może wyglądać następująco:

public static final int REQUEST_PERMISSION_CAMERA = 12;

public void checkCameraPermission() {
   requestPermission(Manifest.permission.CAMERA, REQUEST_PERMISSION_CAMERA);
}

private void requestPermission(String permission, int requestCode) {
   int hasPermission = ActivityCompat.checkSelfPermission(this, permission);
   if (hasPermission == PackageManager.PERMISSION_GRANTED) {
       onPermissionCameraGranted();
       return;
   }
   ActivityCompat.requestPermissions(this, new String[]{permission}, requestCode);
}

@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
   switch (requestCode) {
       case REQUEST_PERMISSION_CAMERA:
           if (grantResults.length == 1 && grantResults[0] == PackageManager.PERMISSION_GRANTED){
               onRequestCameraGranted();
           } else {
               onRequestCameraDenied();
           }
           break;
   }
}

Wywołując metodę checkCameraPermission, otrzymamy odpowiedź i przekierowanie do funkcji onRequestCameraGranted lub onRequestCameraDenied. Możemy wywołać kilka zapytań jednocześnie, ponieważ metoda requestPermissions przyjmuje tablicę nazw Stringów z nazwami pozwoleń. Nie jest to jednak zalecane o czym w następnym akapicie.

Dobre praktyki

Jedną z ważniejszych rzeczy, o których należy pamiętać jest pytanie o pozwolenie tylko w momencie, kiedy aplikacja faktycznie go potrzebuje. Nie powinno się pytać o wszystko na raz, a już na pewno nie o wszystko na samym starcie chyba, że taka jest specyfika aplikacji. Przykładowo, jeśli potrzebujemy dostępu do aparatu, zapytajmy o pozwolenie dopiero, kiedy użytkownik wybierze funkcję robienia zdjęcia. Nie można bombardować użytkownika powiadomieniami co chwilę, dlatego też musimy zawsze być gotowi na odmowę.

Nie wolno wywoływać zapytania kolejny raz, jeśli użytkownik go nie zaakceptuje. Powinniśmy wtedy krótko poinformować użytkownika, że takie pozwolenie jest konieczne do dalszego działania oraz, że można je w każdej chwili zmienić w ustawieniach. Dobrym przykładem może być pokazanie Snackbaru z informacją, który sam po chwili zniknie, ale będzie miał przycisk, który włączy ekran ustawień. Dobrze jest zapamiętać wybór użytkownika i w razie odmowy pokazywać już tylko tę informację z możliwością szybkiego włączenia pożądanego pozwolenia.

Użytkownik po pierwszej odmowie będzie miał domyślnie możliwość zaznaczenia opcji, że nie życzy sobie tego pytania ponownie. Wtedy na próbę wywołania pytania z miejsca otrzymamy rezultat negatywny. Musimy pamiętać o tym, żeby aplikacja działała możliwie dobrze nawet bez niektórych pozwoleń. Odmawiając pozwolenia na dostęp do kontaktów użytkownik sam skazywać się będzie na brak możliwości importu kontaktów itd. To jego wybór, który musimy uszanować i uwzględnić. Jeśli funkcja jest krytyczna dla działania całej aplikacji jedyne, co nam pozostaje, to informacja, że bez tego aplikacja nie może działać.

Zmiana na lepsze?

Nowy model pozwoleń, to na pewno krok w dobrą stronę i odpowiedź na wiele próśb i sugestii doświadczonych użytkowników. Zapewnia większe bezpieczeństwo oraz przejrzystość działania aplikacji w ekosystemie Androida. Przede wszystkim nie musimy z miejsca zgadzać się na wszystko, o co aplikacja prosi, pod groźbą braku możliwości zainstalowania wybranego produktu. Możemy zaakceptować tylko niektóre rzeczy lub po prostu najpierw przetestować, w którym momencie i co będzie potrzebne, aby lepiej zrozumieć cel przyznawania danego pozwolenia. Zmiany zostały wprowadzone z głową, niosąc wiele dobrego. Oby tak dalej Google!