Normal Permission w Android — co to jest, poziomy ochrony i zasada działania

Co to jest Normal Permission w Android

Normal Permission — typ systemowych uprawnień Android z ProtectionLevel normal, przyznawany aplikacji automatycznie w momencie instalacji. Deweloper nie musi pisać kodu do zapytania — wystarczy wskazać uprawnienie w AndroidManifest.xml. Użytkownik nie widzi okien dialogowych i nie może cofnąć normal permission osobno, tylko usuwając całą aplikację.

System Android klasyfikuje normalne uprawnienia jako niskiego ryzyka — nie dają dostępu do danych osobowych, kamery ani mikrofonu. Typowe przykłady: dostęp do internetu, zarządzanie wibracją, odczyt stanu Wi-Fi. Według Android Security Model (2024), około 40 procent wszystkich uprawnień systemowych należy do kategorii normal.

Ważna właściwość — normalne uprawnienia nie są cofane w runtime przez Settings. Jeśli użytkownik chce zabronić dostępu, jedyny sposób to usunąć aplikację. Deweloperzy powinni uwzględniać to w architekturze, ale dla użytkowników takie podejście upraszcza interakcję: żadnych okien dialogowych przy pierwszym uruchomieniu.

Historia pojawienia się kategorii

Podział na normalne i niebezpieczne uprawnienia pojawił się w Android 6.0 Marshmallow (API 23). Do tej wersji wszystkie uprawnienia były pytane przy instalacji — użytkownik widział jedną listę i akceptował ją lub odrzucał w całości. Normal Permission zachował ten model dla operacji niskiego ryzyka, a Dangerous przeszedł na zapytanie runtime. Ta zmiana poprawiła doświadczenie użytkownika i jednocześnie zwiększyła bezpieczeństwo.

Jakie API wymagają Normal Permission

Wiele systemowych API Android wymaga jawnego wskazania normalnego uprawnienia, nawet jeśli dostęp jest automatyczny. Na przykład klasa ConnectivityManager wymaga ACCESS_NETWORK_STATE, VibratorService wymaga VIBRATE, WifiManager wymaga ACCESS_WIFI_STATE. Bez deklaracji odpowiedniego uses-permission wywołanie tych API spowoduje SecurityException.

Jak działa ProtectionLevel normal

ProtectionLevel normal — minimalny poziom ochrony w Android Permission System. Uprawnienia z tym poziomem deklaruje się w manifeście, a system sprawdza deklarację podczas instalacji, przyznając dostęp bez ingerencji użytkownika. Żadne elementy UI nie są wyświetlane, żadne callbacki nie są wywoływane.

Mechanizm sprawdzania działa na poziomie PackageManager. Podczas instalacji APK system skanuje wszystkie tagi uses-permission, określa poziom ochrony każdego uprawnienia przez porównanie z definicjami systemowymi w plikach permissions.xml i dla normal-level po prostu rejestruje dostęp. Proces trwa milisekundy i nie wymaga interakcji z interfejsem użytkownika.

Algorytm przyznawania wygląda następująco:

• System czyta manifest w momencie instalacji aplikacji
• Porównuje protectionLevel w /etc/permissions/ na urządzeniu
• Przy wartości normal — automatycznie przyznaje dostęp
• Uprawnienie pozostaje aktywne do całkowitego usunięcia aplikacji

Użytkownik nie może cofnąć normalnego uprawnienia przez interfejs. W ustawieniach aplikacji w sekcji Uprawnienia wyświetlane są tylko niebezpieczne uprawnienia. Kontrastuje to z iOS, gdzie każde uprawnienie wymaga osobnego potwierdzenia niezależnie od poziomu wrażliwości funkcji.

Normal Permission vs Dangerous Permission

Normal i Dangerous Permission — dwie przeciwstawne kategorie ochrony w Android. Główna różnica — w sposobie przyznawania: normalne są dawane automatycznie przy instalacji, niebezpieczne wymagają jawnej zgody przez okno runtime. Ta różnica jest wbudowana w architekturę bezpieczeństwa Android od wersji 6.0 Marshmallow.

Porównanie kluczowych cech:

Różnica w zapytaniu użytkownika

Użytkownik nie widzi żadnych okien dialogowych przy zapytaniu Normal Permission. Jeśli aplikacja potrzebuje INTERNET — otrzymuje go po cichu. Dla Dangerous Permission system wyświetla modalne okno z opisem żądanego dostępu. Użytkownik naciska Allow lub Deny, a później może cofnąć uprawnienie w każdej chwili przez Settings. To kluczowa różnica UX, określająca strategię rozwoju interfejsu.

Kiedy wybierać Normal

Normal należy używać we wszystkich przypadkach, gdy dostęp nie dotyczy wrażliwych danych. ACCESS_NETWORK_STATE do sprawdzania połączenia, VIBRATE do sprzężenia zwrotnego, INTERNET do zapytań HTTP — to wszystko normalne uprawnienia. Stosowanie poziomu dangerous tam, gdzie wystarczy normal, to zła praktyka, tworząca zbędne okna i zmniejszająca zaufanie użytkownika do aplikacji.

Lista normalnych uprawnień w Android

Android definiuje kilkadziesiąt normalnych uprawnień, każde odpowiadające określonej funkcji systemowej. Wszystkie są dostępne przez stałe klasy Manifest.permission. Poniżej znajduje się wykaz najczęściej używanych w programowaniu aplikacji.

Grupy normalnych uprawnień

Normalne uprawnienia nie są grupowane w Permission Group do celów wyświetlania w UI. Grupy w Android są przeznaczone dla ekranu ustawień, gdzie pokazywane są tylko niebezpieczne uprawnienia. Jednak logicznie normal permissions można podzielić na kategorie: sieciowe (INTERNET, ACCESS_NETWORK_STATE), sprzętowe (VIBRATE, WAKE_LOCK), systemowe (SET_ALARM) i Bluetooth.

Niektóre stałe z Manifest.permission mogą zmieniać poziom ochrony na różnych wersjach Android. Na przykład BLUETOOTH_CONNECT na Android 12+ stał się niebezpiecznym uprawnieniem z zapytaniem runtime, chociaż w starszych wersjach był normal. Deweloperzy powinni sprawdzać aktualny protectionLevel dla docelowego API przez dokumentację.

Sprawdzanie Normal Permission przez PackageManager

Deweloper może programowo sprawdzić, czy uprawnienie jest normalne, przez PackageManager. Metoda getPermissionInfo zwraca PermissionInfo, którego pole protectionLevel zawiera flagę PermissionInfo.PROTECTION_NORMAL. Jest to przydatne do dynamicznego przetwarzania i debugowania.

fun isNormalPermission(permission: String): Boolean {
    val pm = packageManager
    val info = pm.getPermissionInfo(
        permission,
        PackageManager.GET_META_DATA
    )
    return info.protectionLevel ==
        PermissionInfo.PROTECTION_NORMAL
}

Jak zadeklarować Normal Permission w manifeście

Deklaracja Normal Permission w AndroidManifest.xml — najprostsza operacja, wymagająca jednego tagu uses-permission. Dodatkowa konfiguracja protectionLevel nie jest wymagana, ponieważ poziom ochrony jest określany przez definicję systemową, a nie manifest aplikacji. Deweloper po prostu podaje pełną nazwę stałej.

<!-- AndroidManifest.xml -->
<uses-permission
    android:name="android.permission.INTERNET" />
<uses-permission
    android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission
    android:name="android.permission.VIBRATE" />

System podczas instalacji przetwarza wszystkie deklaracje. Jeśli choć jedno ze wskazanych uprawnień ma protectionLevel inny niż normal, wymagane będzie zapytanie runtime. INTERNET — najpopularniejsze normalne uprawnienie, obecne w większości aplikacji Android, szczególnie tych wykonujących zapytania HTTP lub pobierających treści z sieci.

Przykład pełnego manifestu

Pełny przykład AndroidManifest.xml z normalnymi i niebezpiecznym uprawnieniem pokazuje różnicę: składniowo tagi uses-permission są takie same, ale na etapie wykonania INTERNET i VIBRATE zostaną przyznane automatycznie, a CAMERA będzie wymagać okna dialogowego.

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.VIBRATE" />

    <!-- Dangerous permission -->
    <uses-permission
        android:name="android.permission.CAMERA" />
</manifest>

Manifest Merger a Normal Permission

Przy korzystaniu z bibliotek — Google Play Services, Firebase, Glide — mogą one dodawać własne uses-permission do końcowego manifestu przez Manifest Merger. Niektóre z nich są normalne (INTERNET dla Firebase), inne niebezpieczne (ACCESS_FINE_LOCATION dla Google Maps). Deweloper powinien sprawdzać końcowy merged manifest w build/outputs/logs/manifest-merger-report.txt przed publikacją.

Ograniczenia Normal Permission

Normal Permission ma dwa zasadnicze ograniczenia: brak możliwości cofnięcia przez użytkownika i brak UI do zarządzania. Jeśli użytkownik nie ufa aplikacji, ale normalne uprawnienie zostało już wydane automatycznie — jedynym wyjściem jest usunięcie aplikacji. Stwarza to pewne ryzyko, ponieważ normal permissions nie są blokowane standardowymi środkami Android.

Dodatkowe ograniczenie występuje na urządzeniach z wieloma profilami (Work Profile, Multiple Users). Normal Permission jest przyznawane natychmiast dla wszystkich profili — aplikacja nie może ograniczyć uprawnienia tylko do jednego. W scenariuszach korporacyjnych rozwiązuje się to przez Managed Configurations.

Nie można sprawdzić, czy aplikacja używa Normal Permission w danym momencie. Systemowa metoda checkSelfPermission działa tylko dla niebezpiecznych uprawnień. Dla normal zawsze zwraca PERMISSION_GRANTED, co nie odzwierciedla rzeczywistej aktywności. Należy to uwzględniać przy audycie bezpieczeństwa i analizie zachowania aplikacji.

Warto również pamiętać, że niektórzy producenci urządzeń (Xiaomi, Huawei, Samsung) modyfikują standardowe zachowanie uprawnień. Na ich firmware Normal Permission może wymagać dodatkowych zezwoleń w autorskiej powłoce MIUI lub EMUI. Deweloperzy powinni testować działanie na rzeczywistych urządzeniach różnych producentów.