Android permissions exist to safeguard user privacy and restrict apps from accessing sensitive data or performing risky system operations without approval. Apps must explicitly declare required permissions using <uses-permission> tags in their AndroidManifest.xml. For example, an app needing to send SMS messages would include:

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

    <uses-permission android:name="android.permission.SEND_SMS" />
    
    <application ...>
        ...
    </application>
</manifest>

Permissions are categorized into protection levels that determine how they’re granted and enforced:

• Normal permissions cover low-risk operations like setting the time zone. They’re automatically granted at install time without user interaction.
• Dangerous permissions (e.g., accessing SMS, contacts, or camera) require explicit user approval. The approval flow varies by Android version and app’s targetSdkVersion:
  • On Android 6.0+ (API 23+) with targetSdkVersion ≥23, permissions are requested at runtime. The system shows a dialog explaining the permission group (e.g., "Contacts") when the app first needs access. If a user previous granted a permission from the same group, subsequent requests are auto-approved.
  • On Android ≤5.1.1 (API 22-) or with targetSdkVersion ≤22, all dangerous permissions are requested at install time. Rejecting any cancels installation.
• Signature permissions are only granted to apps signed with the same certificate as the one that defined the permission.
• Special permissions (e.g., SYSTEM_ALERT_WINDOW, WRITE_SETTINGS) are highly sensitive and require users to grant access via a system settings screen.

Permissions also protect app components (activities, services, broadcasts, content providers) by limiting which apps can interact with them. For example:

• An activity with android:permission restricts which apps can launch it.
• A service with android:permission controls who can start or bind to it.
• A content provider can enforce URI-specific permissions to allow temporary, user-driven access to specific data (e.g., an image attachment URI granted to an image viewer).

To access optional hardware features (e.g., camera, Bluetooth), apps must declare the feature with <uses-feature> and set android:required="false" if the feature isn’t mandatory. They should then check for the feature at runtime using PackageManager.hasSystemFeature().

<uses-feature android:name="android.hardware.camera" android:required="false" />

Android automatically adjusts permissions for older apps based on targetSdkVersion to avoid breaking them. However, developers should always update targetSdkVersion to the latest to remove unnecessary default permissions.

To view permissions:

• Open Settings → Apps → Select an app → Permissions.
• Use adb shell pm list permissions -s to list all permissions in a user-friendly format.
• Use adb shell install -g MyApp.apk to auto-grant all permissions during installation.