Comprehensive Guide to Android Permissions: Types, Groups, Dynamic Mechanisms and Compatibility Solutions

01 Permission Introduction & Classification – Android’s security model grants no permissions by default; apps must declare required permissions in AndroidManifest.xml . Permissions are divided into four classes: normal (low‑risk), dangerous (runtime‑granted), signature, and signatureOrSystem.

02 Permission Groups & Dynamic Permissions – Permissions can belong to groups; only dangerous permissions trigger runtime dialogs. Starting with Android 6.0 (API 23), requesting a dangerous permission shows a group‑level dialog, and subsequent permissions in the same group are granted automatically.

03 Permission History & Common Permissions – By Android Pie (API 28) the framework defines 455 permissions, of which 151 are exposed via the SDK. Some permissions become deprecated or removed in later API levels, requiring version‑aware handling.

04 Dynamic Permission Mechanism & Usage – For API 23+ apps must request dangerous permissions at runtime using checkSelfPermission , shouldShowRequestPermissionRationale , requestPermissions , and handle results in onRequestPermissionsResult . Special permissions like SYSTEM_ALERT_WINDOW and WRITE_SETTINGS are granted via settings screens launched with startActivityForResult . Location permissions also require the device’s GPS to be enabled.

05 Custom Permission Groups – Applications can define their own permission groups and permissions, declared in the manifest and merged into the system’s permission list at install time.

06 Compatibility Issues & Solutions

Pre‑Android M (API 19‑22) devices use AppOpsManager.checkOp via reflection to detect permissions.

OEM custom ROMs (e.g., Xiaomi, Huawei, Vivo, Oppo, Meizu) may hide or alter permission dialogs, require separate handling for special permissions, or present non‑standard request flows.

Some manufacturers expose permissions that are not defined in AOSP (e.g., reading installed apps), leading to unexpected dialogs.

Normal permissions can be manually disabled in manufacturer settings, causing runtime failures; apps should check with checkSelfPermission and guide users to the appropriate settings page.

07 Dynamic Permission Design Solution – A unified PermissionUtils API abstracts single‑permission requests, batch requests, permission checks, and customizable flow (detection → request → prompt → settings navigation). This isolates compatibility logic from business code, improving development efficiency and reducing error‑prone handling.

The article concludes with diagrams illustrating the permission flow and encourages developers to adopt the encapsulated solution for consistent behavior across Android versions and OEM customizations.