How do Android permissions work, and what changed with runtime permissions?

Permissions are declared in the manifest, but how they are granted depends on their protection level.

• Normal permissions — low risk, such as internet access or vibration. Granted automatically at install; the user is never asked.
• Dangerous permissions — access to private data or sensitive hardware: camera, location, contacts, microphone, and certain storage access. Since Android 6 (API 23) these must be requested at runtime, and the user can deny or later revoke them.
• Signature permissions — granted only to apps signed with the same certificate.

The runtime flow: check with ContextCompat.checkSelfPermission, request through the Activity Result API, and handle the result. Critically, you must handle all three outcomes — granted, denied, and permanently denied — and the app must remain usable when a permission is refused. Requesting everything at launch is the pattern most likely to get an app uninstalled.

What tightened since:

• Android 10 — background location became a separate, harder-to-obtain permission, and scoped storage restricted filesystem access.
• Android 11 — one-time permissions, and auto-revocation for unused apps.
• Android 13 — granular media permissions replacing broad storage access, and a runtime permission for notifications.
• Android 14 — partial photo and video access, letting users share only selected items.

Note: Explain why you need a permission in context, immediately before requesting it. Requesting without context is the main cause of denial.