Manifest & Permissions

WRITE_SECURE_SETTINGS: Why Ordinary Apps Cannot Request It Normally

WRITE_SECURE_SETTINGS is not an ordinary permission that a Play-distributed app can obtain through a normal runtime dialog. It protects sensitive system settings and belongs to a different access model from camera, location or notification grants.

By Updated 2 min read

Confirm the actual requirement

The permission reference documents the protection attached to this capability. Before adding it, identify the precise setting your feature wants to change and whether Android exposes a user-mediated or managed-device API for that action.

Do not confuse it with WRITE_SETTINGS, which has its own special-access behavior. Similar names do not imply equivalent privileges.

Avoid designing around development privileges

A capability available through an authorized development shell, system image or managed-device environment does not automatically exist for an ordinary installed app. Tests performed on a rooted or specially configured device can conceal this difference.

Environment Review question
Normal consumer install Is there a documented user-facing API?
Enterprise managed device Does the management role permit this exact operation?
Platform/system app Does the signing and privilege configuration satisfy platform rules?
Development test device Is the result dependent on temporary privileged setup?

Do not instruct ordinary users to weaken device security merely to make an optional feature work.

Provide a user-controlled alternative

Where a system settings screen is the intended interface, explain the change and let the user make it. Detect the actual state afterward instead of assuming that opening the screen changed anything.

For features that cannot be implemented through supported consumer APIs, state the limitation clearly. A manifest entry cannot manufacture platform authority.

Handle failure explicitly

A protected-setting write may throw a security exception or fail under the API's contract. Do not catch every error and report success. Keep the UI consistent with the actual state and avoid repeatedly retrying a prohibited operation.

Use APKLint to flag the design issue

The Dangerous Permissions Checker can identify this declaration for review. It cannot grant the permission, bypass Android restrictions or establish enterprise eligibility. Treat the finding as a prompt to revisit the feature's access model, not as a missing runtime-dialog implementation.

Sources and further reading

  1. Android Developers: Manifest.permission reference
  2. Android Developers: Request special permissions

Reference review: 22 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.

APKLint

Android inspection tools and practical release guides. About APKLint · Report a correction