Poproś o uprawnienia czasu działania

Każda aplikacja na Androida działa w piaskownicy o ograniczonym dostępie. Jeśli aplikacja musi korzystać z dostępu zasobów lub informacji poza własną piaskownicą, możesz zadeklarować środowisko wykonawcze uprawnienia i skonfiguruj prośbę o uprawnienia który zapewnia taki dostęp. Te kroki są częścią procesu korzystania z .

Jeśli zadeklarujesz jakieś niebezpieczne uprawnienia, a jeśli aplikacja jest zainstalowana na urządzeniu z Androidem 6.0 (poziom interfejsu API 23); musisz poprosić o niebezpieczne uprawnienia w czasie działania, wykonując podane w tym przewodniku.

Jeśli nie zadeklarujesz żadnych niebezpiecznych uprawnień lub jeśli Twoja aplikacja jest zainstalowana na z Androidem 5.1 (poziom interfejsu API 22) lub niższym, uprawnienia są automatycznie przyznanych i nie musisz wykonywać żadnych pozostałych kroków na tej stronie.

Podstawowe zasady

Podstawowe zasady żądania uprawnień w czasie działania są następujące:

• Pytaj o uprawnienia w kontekście, gdy użytkownik rozpocznie interakcję funkcji, która tego wymaga.
• Nie blokuj użytkownika. Zawsze udostępniaj opcję anulowania interfejsu edukacyjnego np. procesu wyjaśniającego uzasadnienie prośby o zgodę.
• Jeśli użytkownik odmówi przyznania uprawnienia, którego potrzebuje funkcja, pogarsza działanie aplikacji, aby użytkownik mógł z niej korzystać, np. wyłączenie funkcji, która wymaga tych uprawnień.
• Nie zakładaj żadnego działania systemu. Nie zakładaj na przykład, że uprawnienia należą do tej samej grupy uprawnień. Grupa uprawnień pomaga jedynie system minimalizuje liczbę okien dialogowych wyświetlanych użytkownikowi, aplikacja wymaga ściśle powiązanych uprawnień.

Przepływ pracy związany z żądaniem uprawnień

Zanim zadeklarujesz uprawnienia w czasie działania i poproś o nie w aplikacji, oceń czy aplikacja musi to zrobić. Dostępne opcje realizować wiele zastosowań w aplikacji, takich jak robienie zdjęć, wstrzymywanie multimediów odtwarzania i wyświetlanie trafnych reklam, bez konieczności zgłaszania jakichkolwiek uprawnień.

Jeśli stwierdzisz, że aplikacja musi zadeklarować uprawnienia w czasie działania i poprosić o takie uprawnienia, wykonaj te czynności:

1. W pliku manifestu aplikacji zadeklaruj parametr uprawnienia, których może potrzebować aplikacja użytkownika.
2. Zaprojektuj aplikację tak, aby UX kojarzył się z określonymi działaniami określonych uprawnień czasu działania. Poinformuj użytkowników, które działania mogą ich wymagać , aby przyznać aplikacji uprawnienia dostępu do prywatnych danych użytkownika.
3. Poczekaj, aż użytkownik wywoła działanie w Twojej aplikacji. które wymagają dostępu do konkretnych prywatnych danych użytkownika. Od tego momentu aplikacja może zażądać uprawnień w czasie działania wymaganych do dostępu do tych danych.

4. Sprawdź, czy użytkownik przyznał już środowisko wykonawcze uprawnienia wymagane przez aplikację. Jeśli tak, aplikacja może uzyskać dostęp prywatnych danych użytkownika. Jeśli nie, przejdź do następnego.

   Musisz sprawdzić, czy masz odpowiednie uprawnienie za każdym razem, gdy wykonujesz wykonującą operację, która wymaga tych uprawnień.

5. Sprawdź, czy aplikacja powinna mieć uzasadnienie. wyjaśniając, dlaczego aplikacja potrzebuje określonego uprawnienia w czasie działania aplikacji. Jeśli system uzna, że aplikacja nie powinna wyświetlać uzasadnienia, przejdź do: przejście od razu do następnego kroku, bez wyświetlania żadnego elementu interfejsu.

   Jeśli jednak system ustali, że aplikacja powinna podać uzasadnienie, przedstawić użytkownikowi uzasadnienie w elemencie interfejsu. W ramach tego rozumowania wyjaśnić, do jakich danych chce uzyskać dostęp aplikacja i jakie są jej korzyści; które aplikacja może udostępnić użytkownikowi, jeśli przyzna uprawnienia w czasie działania aplikacji. Po użytkownik potwierdza uzasadnienie, przejdź do następnego kroku.

6. Poproś o uprawnienia w czasie działania, których wymaga Twoja aplikacja. uzyskać dostęp do prywatnych danych użytkownika. System wyświetla środowisko wykonawcze o uprawnieniach, np. w przeglądzie uprawnień .

7. Sprawdź odpowiedź użytkownika – czy przyznał on, czy odrzucił uprawnień w czasie działania.

8. Jeśli użytkownik przyznał Twojej aplikacji odpowiednie uprawnienia, możesz korzystać z prywatnego danych użytkownika. Jeśli użytkownik odmówił przyznania uprawnień, zgrabnie obniż poziom uprawnień jak w aplikacji, dzięki czemu oferuje ona funkcje bez ujawniania informacji chronionych tym uprawnieniem.

Ilustracja 1 przedstawia przepływ pracy i zbiór decyzji związanych z tym proces:

Sprawdzanie, czy aplikacja otrzymała już to uprawnienie

Aby sprawdzić, czy użytkownik przyznał już Twojej aplikacji określone uprawnienie, prześlij i udostępnienie danych ContextCompat.checkSelfPermission() . Ta metoda zwraca jeden z elementów: PERMISSION_GRANTED lub PERMISSION_DENIED w zależności od tego, czy aplikacja ma odpowiednie uprawnienia.

Wyjaśnij, dlaczego Twoja aplikacja potrzebuje tych uprawnień

Okno uprawnień wyświetlane przez system podczas wywoływania requestPermissions() mówi, jakich uprawnień potrzebuje Twoja aplikacja, ale nie informuje o tym dlaczego. W niektórych przypadkach użytkownicy mogą zauważyć łamigłówkę. Dobrym pomysłem jest wyjaśnij użytkownikowi, dlaczego aplikacja potrzebuje uprawnień, zanim do niego zadzwonisz. requestPermissions()

Badania pokazują, że użytkownicy znacznie lepiej radzą sobie z prośbami o przyznanie uprawnień, wiedzą, do czego aplikacja ich potrzebuje – czy może na przykład obsługiwać główną funkcję aplikacji lub wyświetlać reklamy. W związku z tym, jeśli tylko przy użyciu części wywołań interfejsu API należących do grupy uprawnień, pomaga jasno określić, których uprawnień używasz i dlaczego. Dla: Jeśli używasz tylko przybliżonej lokalizacji, poinformuj o tym użytkownika w w opisie aplikacji lub w artykułach pomocy na jej temat.

W pewnych okolicznościach warto też poinformować użytkowników o dostępu do danych wrażliwych w czasie rzeczywistym. Na przykład, jeśli masz dostęp do kamery czy mikrofonu warto poinformować o tym użytkownika za pomocą w dowolnym miejscu aplikacji lub na pasku powiadomień (jeśli aplikacja działa w tle), więc to nie wygląda na to, ukradkowe zbieranie danych.

Podsumowując, jeśli musisz poprosić o zgodę na tworzenie czegoś w aplikacji działają, ale ich powód nie jest jasny dla użytkownika, znajdź sposób, aby do czego są Ci potrzebne najbardziej wrażliwe uprawnienia.

Jeśli metoda ContextCompat.checkSelfPermission() zwraca PERMISSION_DENIED, zadzwoń do: shouldShowRequestPermissionRationale(). Jeśli ta metoda zwraca wartość true, wyświetl użytkownikowi interfejs edukacyjny. W tym interfejsie wyjaśnij, dlaczego funkcja, którą użytkownik chce włączyć, wymaga uprawnienia.

Poza tym, jeśli aplikacja prosi o uprawnienia związane z lokalizacją, mikrofonem lub aparatowi, możesz wyjaśnić, dlaczego aplikacja dostępu do tych informacji.

Poproś o uprawnienia

Gdy użytkownik wyświetli interfejs edukacyjny lub zwróci wartość Wartość shouldShowRequestPermissionRationale() oznacza, że nie musisz wyświetlać reklam. interfejs edukacyjny, poproś o uprawnienia. Użytkownicy widzą system z oknami uprawnień, gdzie można określić, czy aplikacji.

Aby to zrobić, skorzystaj z funkcji RequestPermission Google, która jest dostępna w bibliotece AndroidaX, która pozwala systemowi zarządzać kod prośby o uprawnienia. Ponieważ używanie umowy RequestPermission upraszcza logikę, jest to zalecane gdy tylko jest to możliwe. W razie potrzeby możesz też zarządzać kodem żądania , jak również umieść ten kod żądania w logice wywołań zwrotnych uprawnień.

Zezwalaj systemowi na zarządzanie kodem prośby o uprawnienia

Aby umożliwić systemowi zarządzanie kodem żądania powiązanym z żądania uprawnień, dodaj zależności od następujących bibliotek w plik build.gradle modułu:

• androidx.activity wersja 1.2.0 lub nowsza
• androidx.fragment wersja 1.3.0 lub nowsza

Następnie możesz używać jednej z tych klas:

• Aby poprosić o jedno uprawnienie, użyj RequestPermission
• Aby poprosić o wiele uprawnień jednocześnie, użyj RequestMultiplePermissions

Poniżej znajdziesz instrukcje korzystania z umowy RequestPermission. w przypadku umowy RequestMultiplePermissions proces jest niemal taki sam.

1. W logice inicjowania aktywności lub fragmentu przekaż implementację z ActivityResultCallback w wywołanie do registerForActivityResult() ActivityResultCallback określa, w jaki sposób aplikacja obsługuje odpowiedź użytkownika na o przyznanie uprawnień.

   Zapisz odwołanie do wartości zwracanej przez funkcję registerForActivityResult(), która jest typu ActivityResultLauncher

2. Aby w razie potrzeby wyświetlić okno uprawnień systemowych, wywołaj metodę launch() w instancji ActivityResultLauncher zapisanej w poprzedniego kroku.

   Po wywołaniu funkcji launch() pojawi się okno uprawnień systemowych. Gdy użytkownik dokona wyboru, system asynchronicznie wywoła implementację ActivityResultCallback, która została określona w poprzednim kroku.

   Uwaga: aplikacja nie może dostosować wyświetlonego okna gdy dzwonisz na numer launch(). Aby podać więcej informacji lub do kontekstu użytkownika, zmień UI aplikacji, aby ułatwić użytkownikom zrozumieć, dlaczego funkcja aplikacji wymaga określonych uprawnień. Dla: możesz np. zmienić tekst na przycisku, który włącza funkcję funkcji.

   Dodatkowo tekst w oknie uprawnień systemu odwołuje się do uprawnienia grupę powiązaną z uprawnieniami, o które prosisz. Ten grupowanie uprawnień zostało zaprojektowane z myślą o łatwości obsługi systemu, a aplikacja nie powinny polegać na uprawnieniach znajdujących się w określonym grupę uprawnień.

Ten fragment kodu pokazuje, jak obsługiwać odpowiedź dotyczącą uprawnień:

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher. You can use either a val, as shown in this snippet,
// or a lateinit var in your onAttach() or onCreate() method.
val requestPermissionLauncher =
    registerForActivityResult(RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    }

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher, as an instance variable.
private ActivityResultLauncher<String> requestPermissionLauncher =
    registerForActivityResult(new RequestPermission(), isGranted -> {
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    });

Ten fragment kodu przedstawia zalecany proces sprawdzania uprawnienia, a w razie potrzeby – poproszenie użytkownika o zgodę:

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        // The registered ActivityResultCallback gets the result of this request.
        requestPermissionLauncher.launch(
                Manifest.permission.REQUESTED_PERMISSION)
    }
}

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    // The registered ActivityResultCallback gets the result of this request.
    requestPermissionLauncher.launch(
            Manifest.permission.REQUESTED_PERMISSION);
}

Samodzielne zarządzanie kodem prośby o uprawnienia

Zamiast zezwalania systemowi na zarządzanie prośbą o uprawnienia , możesz zarządzać prośbą o uprawnienia zakodować go samodzielnie. Aby to zrobić, umieść kod żądania w wywołaniu funkcji requestPermissions()

Fragment kodu poniżej pokazuje, jak zażądać uprawnień za pomocą kod żądania:

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
        performAction(...)
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        requestPermissions(CONTEXT,
                arrayOf(Manifest.permission.REQUESTED_PERMISSION),
                REQUEST_CODE)
    }
}

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    requestPermissions(CONTEXT,
            new String[] { Manifest.permission.REQUESTED_PERMISSION },
            REQUEST_CODE);
}

Gdy użytkownik odpowie na okno dialogowe uprawnień systemu, wywołuje implementację onRequestPermissionsResult() w Twojej aplikacji. System przekazuje dane użytkownika odpowiedź na okno z prośbą o uprawnienia, a także zdefiniowany przez Ciebie kod żądania, Jak widać w tym fragmencie kodu:

override fun onRequestPermissionsResult(requestCode: Int,
        permissions: Array<String>, grantResults: IntArray) {
    when (requestCode) {
        PERMISSION_REQUEST_CODE -> {
            // If request is cancelled, the result arrays are empty.
            if ((grantResults.isNotEmpty() &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED)) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            } else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return
        }

        // Add other 'when' lines to check for other
        // permissions this app might request.
        else -> {
            // Ignore all other requests.
        }
    }
}

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions,
        int[] grantResults) {
    switch (requestCode) {
        case PERMISSION_REQUEST_CODE:
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0 &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            }  else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return;
        }
        // Other 'case' lines to check for other
        // permissions this app might request.
    }
}

Poproś o dostęp do lokalizacji

Gdy prosisz o dostęp do lokalizacji, postępuj zgodnie z tymi samymi sprawdzonymi metodami, dla wszystkich innych uprawnień środowiska wykonawczego. Ważna różnica w dostępie do lokalizacji jest taka, system oferuje wiele pozwoleń związanych z lokalizacją. Które uprawnienia i to, jak o nie poprosisz, zależą od wymagań dotyczących lokalizacji do konkretnego przypadku użycia.

Lokalizacja na pierwszym planie

Jeśli aplikacja zawiera funkcję, która udostępnia lub otrzymuje tylko informacje o lokalizacji raz lub przez określony czas, obiekt wymaga pierwszego planu dostęp do lokalizacji. Oto kilka przykładów:

• Funkcja w aplikacji do nawigacji umożliwia użytkownikom uzyskanie szczegółowych informacji wskazówek dojazdu.
• Funkcja w aplikacji do obsługi wiadomości umożliwia użytkownikom udostępnianie bieżącej lokalizacji. z innym użytkownikiem.

System uznaje aplikację za używaną lokalizację na pierwszym planie, jeśli funkcja aplikacja uzyskuje dostęp do bieżącej lokalizacji urządzenia w jednym z tych miejsc w sytuacjach:

• Widoczna jest aktywność należąca do Twojej aplikacji.

• Twoja aplikacja działa na pierwszym planie. Gdy usługa na pierwszym planie jest system zwiększa świadomość użytkowników, wyświetlając trwałe powiadomienie. Aplikacja zachowuje dostęp, gdy jest uruchomiona w tle, np. użytkownik naciska przycisk ekranu głównego na urządzeniu lub obraca ekran urządzenia wyłączone.

  W Androidzie 10 (poziom interfejsu API 29) i nowszych musisz zadeklarować pierwszy plan typ usługi location, jak widać w tym fragmencie kodu. We wcześniejszych wersjach Androida, zalecamy zadeklarowanie tego typu usługi na pierwszym planie.

  <!-- Recommended for Android 9 (API level 28) and lower. -->
  <!-- Required for Android 10 (API level 29) and higher. -->
  <service
      android:name="MyNavigationService"
      android:foregroundServiceType="location" ... >
      <!-- Any inner elements go here. -->
  </service>
  

Deklarujesz potrzebę dostępu do lokalizacji na pierwszym planie, gdy aplikacja wysyła żądanie ACCESS_COARSE_LOCATION lub ACCESS_FINE_LOCATION zgodnie z tym fragmentem:

<manifest ... >
  <!-- Include this permission any time your app needs location information. -->
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

  <!-- Include only if your app benefits from precise location access. -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
</manifest>

Lokalizacja w tle

Aplikacja wymaga dostępu do lokalizacji w tle, jeśli jakaś jej funkcja stale udostępnia swoją lokalizację innym użytkownikom lub korzysta z funkcji geofencingu API. Oto kilka przykładów:

• Funkcja w aplikacji do udostępniania lokalizacji w grupie rodzinnej pozwala użytkownikom udostępniać lokalizację członkom rodziny.
• W aplikacji IoT dostępna jest funkcja umożliwiająca użytkownikom konfigurowanie urządzeń domowych, takich jak które wyłączają się, gdy użytkownik wychodzi z domu, i włączają ponownie, gdy użytkownik wraca do strony głównej.

System uznaje, że aplikacja używa lokalizacji w tle, jeśli uzyskuje dostęp do bieżącej lokalizacji urządzenia poza sytuacjami opisanymi w lokalizacji na pierwszym planie. Dokładność lokalizacji w tle jest taka sama jak dokładność lokalizacji na pierwszym planie, która zależy od uprawnienia dostępu do lokalizacji deklarowane przez aplikację.

W Androidzie 10 (poziom interfejsu API 29) i nowszych musisz zadeklarować ACCESS_BACKGROUND_LOCATION uprawnienia w pliku manifestu aplikacji dotyczące żądania dostępu do lokalizacji w tle dostęp w czasie działania aplikacji. We wcześniejszych wersjach Gdy aplikacja uzyska dostęp do lokalizacji na pierwszym planie, automatycznie również aplikacja uzyskuje dostęp do lokalizacji w tle.

<manifest ... >
  <!-- Required only when requesting background location access on
       Android 10 (API level 29) and higher. -->
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>

Obsługa odmowy uprawnień

Jeśli użytkownik odmówi przyznania uprawnień, aplikacja powinna pomagać użytkownikom zrozumieć, konsekwencji odmowy przyznania uprawnień. W szczególności aplikacja powinna użytkownicy wiedzą o funkcjach, które nie działają z powodu braku uprawnień. Podczas wykonywania tych czynności pamiętaj o tych sprawdzonych metodach:

• Kieruj uwagę użytkownika. Wyróżnianie konkretnej części interfejsu aplikacji gdy aplikacja ma ograniczoną funkcjonalność, ponieważ nie ma wymaganych uprawnienia. Oto co możesz zrobić:

  • Pokaż komunikat, w którym pojawiły się wyniki lub dane obiektu.
  • Wyświetl inny przycisk z ikoną i kolorem błędu.

• Unikaj ogólników. Nie wyświetlaj ogólnego komunikatu. Zamiast tego jasno określ, Funkcje są niedostępne, ponieważ Twoja aplikacja nie ma wymaganych uprawnień.

• Nie blokuj interfejsu użytkownika. Innymi słowy, nie wyświetlaj pełnoekranowe ostrzeżenie, które uniemożliwia użytkownikom dalsze korzystanie z Twojej aplikacji .

Jednocześnie aplikacja powinna uwzględniać decyzję użytkownika o odrzuceniu uprawnienia. Od Androida 11 (poziom interfejsu API 30), jeśli użytkownik kliknie Odmów w przypadku przyznania danego uprawnienia więcej niż raz w trakcie instalacji aplikacji na urządzeniu, użytkownik nie zobaczy okna uprawnień systemowych, jeśli aplikacja ponownie prosi o uprawnienie. Działanie użytkownika oznacza „nie pytaj ponownie”. Wł. w poprzednich wersjach użytkownicy widzieli okno uprawnień systemowych za każdym razem, aplikacja prosi o uprawnienia, chyba że wybrała wcześniej opcję „Nie pytaj” ponownie”. pola wyboru lub opcji.

Jeśli użytkownik kilka razy odrzuci prośbę o uprawnienie, taka prośba zostanie uznana za trwałą zaprzeczanie. Bardzo ważne jest, aby prosić użytkowników o uprawnienia tylko wtedy, gdy jest to potrzebne dostępu do konkretnej funkcji, w przeciwnym razie możesz przypadkiem utracić możliwość ponownie poprosić o uprawnienia.

W niektórych sytuacjach zezwolenie może zostać odrzucone automatycznie, bez użytkownik nie wykonał żadnej czynności. (Uprawnienie może zostać przyznane także automatycznie). Nie należy zakładać, że funkcje automatyczne zachowanie użytkownika. Za każdym razem, gdy aplikacja potrzebuje dostępu do funkcji, które wymagają sprawdź, czy Twoja aplikacja nadal je otrzymuje.

Aby zadbać o wygodę użytkowników, gdy proszą o aplikację zapoznaj się też ze sprawdzonymi metodami dotyczącymi uprawnień aplikacji.

Sprawdź stan odmowy podczas testowania i debugowania

Sprawdzanie, czy aplikacja otrzymała trwałą odmowę uprawnień (na potrzeby debugowania i testowania), użyj tego polecenia:

adb shell dumpsys package PACKAGE_NAME

Gdzie PACKAGE_NAME to nazwa pakietu do sprawdzenia.

Wynik polecenia zawiera sekcje podobne do tych:

...
runtime permissions:
  android.permission.POST_NOTIFICATIONS: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.ACCESS_FINE_LOCATION: granted=false, flags=[ USER_SET|USER_FIXED|USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.BLUETOOTH_CONNECT: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
...

Uprawnienia, które użytkownik odmówił raz, mają oznaczenie USER_SET. Uprawnienia, które zostały trwale odrzucone, klikając dwukrotnie Odmów, są nadal zgłoszone przez: USER_FIXED.

Aby mieć pewność, że testerzy podczas testowania zobaczą okno z prośbą, zresetuj te flagi po zakończeniu debugowania aplikacji. Aby to zrobić, użyj polecenia:

adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed

PERMISSION_NAME to nazwa uprawnienia, które chcesz przyznać .

Aby zobaczyć pełną listę uprawnień aplikacji na Androida, odwiedź interfejs API uprawnień stronie referencyjnej.

Jednorazowe zezwolenia

Od Androida 11 (poziom interfejsu API 30) zawsze wtedy, gdy aplikacja prosi o uprawnienia związane z lokalizacją, mikrofonem lub aparatem, widoczne dla użytkownika okno uprawnień zawiera opcję Tylko tym razem, jak pokazano na rysunku 2. Jeśli użytkownik wybierze tę opcję w aplikacja otrzyma tymczasowe jednorazowe uprawnienia.

Aplikacja będzie miała wtedy dostęp do powiązanych danych przez czas zależny od zachowanie aplikacji i działania użytkownika:

• Aktywność w aplikacji jest widoczna, ale aplikacja ma dostęp do danych.
• Jeśli użytkownik wyśle Twoją aplikację do działania w tle, będzie ona miała do niej dostęp danych w krótkim czasie.
• Jeśli uruchomisz usługę na pierwszym planie, gdy aktywność jest widoczna, a aplikacja zostanie przeniesiona do tła, aplikacja nadal będzie miała dostęp do danych aż do chwili, gdy usługa na pierwszym planie przestanie działać.

Proces aplikacji kończy się po anulowaniu uprawnień

Jeśli użytkownik cofnie jednorazowe uprawnienia, np. w ustawieniach systemu, aplikacja nie ma dostępu do danych niezależnie od tego, czy uruchomiono pierwszy plan posprzedażna. Tak jak w przypadku innych uprawnień, jeśli użytkownik anuluje jednorazowy dostęp aplikacji proces aplikacji się zakończy.

Gdy użytkownik następnym razem otworzy aplikację i jakaś funkcja w niej poprosi o dostęp do dostęp do lokalizacji, mikrofonu lub aparatu, użytkownik zostanie ponownie poproszony o przyznanie uprawnień.

Zresetuj nieużywane uprawnienia

Android udostępnia kilka sposobów resetowania nieużywanych uprawnień czasu działania domyślny, stan odmowy:

• Interfejs API, do którego możesz aktywnie odebrać dostęp aplikacji do nieużywanego uprawnienia w czasie działania.
• Mechanizm systemowy, który automatycznie resetuje uprawnienia nieużywanych aplikacji.

Usuń dostęp aplikacji

Na urządzeniu z Androidem 13 (poziom interfejsu API 33) i nowszym możesz usunąć dostęp aplikacji do: uprawnień w czasie działania, których Twoja aplikacja już nie wymaga. Gdy zaktualizujesz aplikację, Wykonaj ten krok, by użytkownicy z większym prawdopodobieństwem zrozumieli, dlaczego Twoja aplikacja nadal prosi o określone uprawnienia. Ta wiedza pomaga budować zaufanie użytkowników w aplikacji.

Aby usunąć dostęp do uprawnień w czasie działania, przekaż nazwę tego uprawnienia w revokeSelfPermissionOnKill() Aby jednocześnie usunąć dostęp do grupy uprawnień w czasie działania aplikacji, przekaż zbiór nazw uprawnień w revokeSelfPermissionsOnKill() Proces usuwania uprawnień odbywa się asynchronicznie i zabija wszystkie procesy powiązany z identyfikatorem UID aplikacji.

Aby system usunął dostęp aplikacji do uprawnień, wszystkie musi zostać zatrzymana przez procesy związane z aplikacją. Po wywołaniu interfejsu API system określa, kiedy można bezpiecznie zakończyć te procesy. Zwykle system czeka, dopóki aplikacja nie długo działa w tle; a nie na pierwszym planie.

Poinformuj użytkownika, że Twoja aplikacja nie wymaga już dostępu do określonego środowiska wykonawczego uprawnienia, pokaż okno, gdy użytkownik uruchomi Twoją aplikację. To okno może zawierać listę uprawnień.

Automatyczne resetowanie uprawnień nieużywanych aplikacji

Jeśli Twoja aplikacja jest kierowana na Androida 11 (poziom interfejsu API 30) lub nowszego i nie jest używana przez kilka system chroni dane użytkowników, automatycznie resetując poufne dane, uprawnienia w czasie działania przyznane aplikacji przez użytkownika. Więcej informacji znajdziesz w przewodniku o hibernacji aplikacji.

W razie potrzeby poproś, aby została domyślnym modułem obsługi

Niektóre aplikacje zależą od dostępu do poufnych danych użytkownika związanych z rejestrami połączeń i SMS-y. Jeśli chcesz poprosić o uprawnienia dotyczące rejestrów połączeń lub wiadomości SMS oraz opublikować aplikację w Sklepie Play, ustawić aplikację jako domyślny moduł obsługi podstawowej funkcji systemu przed z żądaniem tych uprawnień w czasie działania.

Więcej informacji o domyślnych modułach obsługi, w tym wskazówki na temat wyświetlania domyślny moduł obsługi, zapoznaj się z przewodnikiem na temat uprawnień używanych tylko w z domyślnymi modułami obsługi.

Przyznaj wszystkie uprawnienia czasu działania na potrzeby testowania

Aby automatycznie przyznawać wszystkie uprawnienia czasu działania podczas instalowania aplikacji w emulatorze lub urządzeniu testowym, użyj opcji -g dla adb shell install zgodnie z poniższym fragmentem kodu:

adb shell install -g PATH_TO_APK_FILE

Dodatkowe materiały

Dodatkowe informacje o uprawnieniach znajdziesz w tych artykułach:

• Przegląd uprawnień
• Sprawdzone metody dotyczące uprawnień aplikacji

Aby dowiedzieć się więcej o wysyłaniu próśb o uprawnienia, zapoznaj się z przykłady uprawnień

Możesz też wykonać to ćwiczenie z programowania, które najlepiej demonstruje ochronę prywatności .