Read the two declarations as different contracts
<uses-permission android:name="android.permission.CAMERA" />
This declares that the application may need camera access. It does not define the camera permission or grant it automatically when a runtime grant is required.
<permission
android:name="com.example.app.permission.INTERNAL_SYNC"
android:protectionLevel="signature" />
This illustrative custom permission defines a capability in your namespace. A component must also reference the permission where enforcement is intended; defining it alone does not protect every app action.
Protect the correct boundary
| Situation | Relevant declaration |
|---|---|
| App reads a protected platform resource | uses-permission plus the required runtime flow |
| App exposes a service to trusted companion apps | Define an appropriate custom permission and apply it to the service |
| App consumes another app's protected provider | Request that provider's permission and satisfy its protection level |
| App has only internal components | Prefer avoiding unnecessary exported interfaces |
Consult the manifest documentation and permission reference for exact attribute behavior.
Choose a custom protection level deliberately
A signature-level permission can be appropriate for a controlled family of apps sharing a trusted signing relationship. It is not a generic way to authorize arbitrary third-party partners. Consider key rotation, distribution and the actual caller identities before designing the interface.
A normal custom permission should not be treated as a strong security boundary for sensitive operations. Enforce business authorization where the protected data or operation is accessed.
Inspect merged declarations
Dependencies can add requests or definitions. Use the merged manifest to identify the source and ensure that permission names are fully qualified and do not accidentally collide with another component's contract.
Test both allowed and denied callers
Exercise the component from an authorized test app and an unauthorized one. Confirm that legitimate use still works and that untrusted callers cannot perform the protected action.
APKLint's Manifest Checker helps review the XML, but it cannot validate your signing relationships or backend authorization. Preserve runtime evidence alongside the declaration review.
Sources and further reading
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.
Android inspection tools and practical release guides. About APKLint · Report a correction
