Android permissions in plain English: what your test build asks for and why testers care
· 4 min read
Every Android build carries a list of permissions in its manifest: android.permission.CAMERA, READ_CONTACTS, SYSTEM_ALERT_WINDOW. Developers read them as code. Testers, clients and reviewers see them as prompts on the phone, often in the middle of a test, and a prompt nobody expected is a common reason a tester stops. This guide explains the three kinds of Android permissions, gives a plain English line for the ones testers meet most, and shows how to check what your test build asks for before you send it.
Three kinds of permissions
Granted at install
Normal permissions such as internet access or vibration are granted when the app is installed. The tester never sees a prompt. They are still worth knowing, because a store listing or a privacy review may ask about them.
Asked at runtime
Dangerous permissions, as Android calls them, such as camera, location, contacts and microphone, show a prompt the first time the app needs them. The tester can allow or deny. These are the ones that surprise people.
Special access
A few permissions are not a prompt at all: the user has to turn them on in system settings. Showing over other apps, all files access, installing other apps and exact alarms are examples. A test build that needs one of these should tell testers where to switch it on.
Common permissions in plain English
| Permission | Kind | In plain English |
|---|---|---|
| CAMERA | Runtime | Can take photos and record video with the camera. |
| RECORD_AUDIO | Runtime | Can record sound with the microphone. |
| ACCESS_FINE_LOCATION | Runtime | Can see your precise location. |
| ACCESS_COARSE_LOCATION | Runtime | Can see your approximate location. |
| ACCESS_BACKGROUND_LOCATION | Runtime | Can see your location when the app is not open. |
| READ_CONTACTS | Runtime | Can read your contacts. |
| READ_MEDIA_IMAGES | Runtime | Can see the photos on the phone. |
| READ_MEDIA_VISUAL_USER_SELECTED | Runtime | Can see the photos and videos you pick for it. |
| POST_NOTIFICATIONS | Runtime | Can show notifications. |
| BLUETOOTH_CONNECT | Runtime | Can connect to Bluetooth devices paired with the phone. |
| READ_PHONE_STATE | Runtime | Can read the phone status, such as the network and whether a call is in progress. |
| SEND_SMS | Runtime | Can send text messages. |
| SYSTEM_ALERT_WINDOW | Special | Can show its windows on top of other apps. |
| MANAGE_EXTERNAL_STORAGE | Special | Can read, change and delete all files in shared storage. |
| REQUEST_INSTALL_PACKAGES | Special | Can ask to install other apps. |
| SCHEDULE_EXACT_ALARM | Special | Can set alarms and reminders that go off at an exact time. |
| QUERY_ALL_PACKAGES | Special | Can see all apps installed on the phone. |
| INTERNET | Install | Can use the internet. |
| RECEIVE_BOOT_COMPLETED | Install | Can start when the phone turns on. |
| com.google.android.gms.permission.AD_ID | Install | Can read the advertising ID of the phone. |
These lines say what a permission allows. They do not say whether an app is safe or whether it uses the permission well; that depends on the app.
Why testers care, and why you should
- Surprise prompts stop tests. A client asked for their contacts by a shopping app demo will often stop and ask why. Telling them up front avoids the pause.
- SDKs add permissions you did not write. An analytics, ads or messaging library can add entries to the merged manifest. The advertising ID line above is a common one. Catch it on the test build, not in a store review.
- Stores ask about some of them. Google Play has declarations for sensitive permissions such as background location, SMS and call log, all files access and installing packages. A new one in a build is worth a look before release.
Check your build before you send it
Three ways, from quickest to most thorough:
- Drop the APK in a free inspector. The APK analyzer reads the file in your browser, without uploading it, and lists the permissions with the same plain words.
- Read the merged manifest. In Android Studio, open AndroidManifest.xml and the Merged Manifest tab to see which library added each entry.
- Compare with the last build. On AppForShare, the build page has a Permissions card that marks what is new since the last build, and "What changed" names new permissions with their plain label.
What testers see on AppForShare
On every AppForShare install page, on every plan and also for builds uploaded without an account, testers see what the build asks for in plain words before they tap Install: "This app asks for: camera, contacts", then one sentence per permission, in the tester's language (13 languages). The map covers about 70 Android permissions and about 35 iOS usage keys, and for iOS builds the app's own reason is shown as written. Names we have no words for are listed as they are. It is a fixed list, not AI, so it says the same thing every time and costs nothing. The CLI appforshare info and the MCP tool build_info return the same list as permissionsPlain, so a script or an AI coding tool can flag a new permission.
Common questions
Why does my build ask for a permission I never added?
A library added it to the merged manifest. Check the Merged Manifest tab, then remove it with a tools:node="remove" entry if you do not need it.
Do install time permissions show a prompt?
No. They are granted with the app. Only runtime permissions show a prompt, and special access is turned on in settings.
Does AppForShare tell testers an app is safe?
No. It only says what each permission lets the app do. It does not scan, approve or vouch for apps.
