Put the declaration in the correct place
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<uses-permission android:name="android.permission.INTERNET" />
<application android:label="Example" />
</manifest>This minimal XML illustrates declaration placement; retain the real application attributes and components when editing an existing project. Check the manifest reference and inspect the merged manifest for the variant you actually install.
Diagnose the error instead of adding permissions blindly
| Symptom | First investigation |
|---|---|
| Cleartext traffic rejected | HTTP URL or redirect and network security configuration |
| Unknown host | DNS, host spelling and device connectivity |
| Certificate failure | Certificate chain, hostname and device time |
| Timeout | Endpoint reachability, firewall or server responsiveness |
| Main-thread exception | Move blocking network work off the UI thread |
ACCESS_NETWORK_STATE can support connectivity-related APIs, but it does not replace INTERNET. Neither declaration fixes an incorrect URL or authorizes a server request.
Check the development environment
On a physical device, localhost points to that device. On an emulator, reaching a development server can require the emulator's documented host mapping or a controlled reverse-port setup. Ensure the server listens on the intended interface and that the device can reach it.
Do not broaden production cleartext access to compensate for a development networking mistake. Use HTTPS or a debug-only, narrowly scoped exception where necessary.
Verify the packaged configuration
Inspect the release manifest and Network Security Configuration. A library, flavor or source-set override can change the effective rules. Test at least one successful request and one expected failure so a permissive workaround is not mistaken for a correct configuration.
Use APKLint for the manifest check
The Manifest Checker can catch placement and declaration issues in pasted XML. It cannot contact your private server or prove that its certificate and authorization are correct. Keep manifest validation and endpoint diagnosis as separate steps.
Separate Android network access from server authorization
An app can declare INTERNET correctly and still receive HTTP 401 from its service. The permission allows the application's network operation at the platform level; it does not provide a valid user session, API entitlement or permission to read a particular server resource. Preserve the response status and authentication state in the diagnosis instead of asking the user to approve a permission dialog that this normal permission does not use.
The network connection guide explains the manifest requirements and network execution model. A missing network-state declaration can affect APIs that inspect connectivity, while DNS failure or a certificate mismatch needs its own investigation. Keep these error categories visible in the app's development diagnostics.
Test the endpoint from the device's point of view
Suppose a developer configures the service URL as localhost because the server runs on the same computer as Android Studio. On the phone, that name refers to the phone. Choose the documented emulator host mapping or a deliberately configured development connection appropriate to the device. Verify the listening port, server interface and local firewall without changing unrelated production transport rules.
Use a small known response from the intended test endpoint, then test an unavailable endpoint and an expected authorization denial. A UI that labels every failure as no internet makes those cases unnecessarily difficult to distinguish. Avoid exposing raw tokens, internal server details or complete response bodies in public error messages.
Inspect the release variant's merged manifest and any network security configuration after the fix. Debug-only trust or cleartext allowances should not accidentally become a production-wide exception. Test the same release's HTTPS path with a valid hostname and certificate, including redirects used by the service. Keep blocking network work away from the main thread and preserve cancellation so leaving the screen does not later display an obsolete response. The minimal manifest example establishes placement only; a functioning network feature also depends on reachable infrastructure, valid transport, correct authorization and deliberate user-visible failure handling.
Sources and further reading
- Android Developers: App manifest overview
- Android Developers: Manifest.permission reference
- Android Developers: Network security configuration
Reference review: 29 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
