To manage Android app permissions across a company fleet, use the Permissions tab on each application's page in the Appaloosa console: it lists what the app requests, and you grant or deny each permission the system lets you control (location, camera, microphone, contacts) remotely. The default policy is set in the same tab. This applies to Android applications, not iOS.
What is the Permissions tab on an Android application?
An Android app asks for permissions: location, camera, microphone, contacts. Without an MDM, each user decides alone, app by app, on their own device. On a fleet of a few dozen devices, that means as many different configurations, and you don't know which one is actually in place.
On October 18, 2026, Appaloosa added a Permissions tab to the page of an Android application. It does three things:
- it lists the permissions the application requests;
- it lets you remotely grant or deny each permission that supports it;
- it holds the application's default policy, set in that same tab.
The setting is made app by app, from the console, without touching the devices.
Which permissions can you grant or deny remotely?
The ones Android lets you control. What Android doesn't allow to be granted remotely, no MDM can enforce. Sensor-related permissions are the most restricted. According to the Android documentation for Android 12 and later:
- In a work profile, the user can allow, for each app in the profile, location, camera, microphone, body sensors and physical activity, unless their IT administrator has denied them.
- On a fully managed device (device owner mode), the administrator can manage these grants or opt out of managing them during provisioning; in that second case, the user answers in the app on first use. The administrator can always deny a permission.
In practice, remote denial is the safest lever. To automatically grant a sensor permission, test first on a pilot device in your enrollment mode, then roll out.
How does the default permission policy work?
The Appaloosa help center describes four values for an Android application's permission policy:
| Value | Effect |
|---|---|
| Default | The user is prompted, unless you set a device-wide permission policy |
| Prompt | The user is asked to accept or deny each permission |
| Grant | All permissions are granted automatically |
| Deny | All permissions are denied automatically |
With no policy set, the user is prompted to allow or deny each permission. The app's policy overrides the device's, unless you leave it on "Default". For both "Grant" and "Deny", the result stays bounded by what Android allows (previous section). The Permissions tab now brings the two levels together: the application's default policy and the permission-by-permission decisions.
Explore
See the full platform
Enrollment, apps, security, remote support: all in one place.
Explore Appaloosa →Grant, deny or prompt: how to choose?
Apply least privilege: an app gets only what its job requires. A few examples, to adapt to your own apps:
| Situation | Suggested choice |
|---|---|
| Business data-entry or intranet app, no useful sensor | Deny location, camera, microphone and contacts |
| Scanning or job-site photo app | Grant camera, deny microphone and contacts |
| Route or delivery app | Grant location, deny the rest |
| Messaging or consumer app tolerated on the device | Prompt, or deny contacts access to keep the directory private |
| Device locked to a single app (kiosk mode) | Deny by default, grant only what the app uses |
Write down your choices, one line per app. When a DPO or an auditor asks why a given app can reach the microphone, you have the answer.
What this feature doesn't cover
- Other platforms. The Permissions tab is for Android. The console doesn't offer this control on iOS, iPadOS, Windows or macOS.
- Which apps get installed. Controlling what an app requests doesn't replace controlling what gets installed. For that, see mobile application management and our article on unknown sources on Android.
- What the system forbids. A permission Android doesn't let you grant remotely stays in the user's hands.
How do you try it on your fleet?
In the console, open the page of an Android application that is already deployed, then its Permissions tab. Start with a pilot group, check on one device what the app can do, then extend. For the wider Android context (work profile, company-owned devices, kiosk), our Android device management guide covers it, and the Android MDM page describes the console.
Frequently asked questions
Can you deny location or microphone access to an Android app remotely?
Yes. Android lets the administrator deny a permission, and Appaloosa's Permissions tab lets you remotely deny each permission that supports it, app by app.
Can you automatically grant camera access to an app?
It depends on the management mode. On a fully managed device, the administrator can manage sensor grants or opt out during enrollment. In a work profile, Android leaves sensor permissions to the user from Android 12 onward. Test on a pilot device before rolling out.
What happens if I don't set any permission policy?
By default, no policy is set: the user is prompted to allow or deny each permission the app requests.
Does an app's policy override the device's?
Yes, unless the app's policy stays on "Default". In that case, the policy set for the device applies.
Is this feature available on iPhone?
No. The Permissions tab is for Android applications. The console doesn't offer this control on iOS, iPadOS, Windows or macOS.
To see the Permissions tab on a few devices, the 14-day free trial starts without a credit card, and a demo lets you put your questions to the team.
Image: Vitaly Gariev via Pexels.
Ready to try Appaloosa? Start free