MX Logo

Auto-grant Android Dangerous Permissions on Zebra devices

Daniel Neamtu -
4 MIN READ
6
0

Overview

 

When Android Marshmallow (6.0) was released, Google introduced the runtime permission system. This change aimed to give users more control and transparency over how apps receive permissions during runtime.

Before Android 6, apps requested all permissions they needed (or claimed to need) at the time of installation. Users were presented with a list of permissions, which they had to accept to proceed with installation. But such system cam with several drawbacks:

  • Lack of Granularity: Users could not grant or deny individual permissions; it was all or nothing.
  • User Awareness: Users often granted permissions without understanding their implications, leading to privacy and security risks.
  • Over-Permissioning: Developers often declared permissions that might not always be necessary, leading to over-permissioning and increased attack surfaces.

There are multiple permission types available (In total 5) but the main 2 ones we usually focus on are these ones:

  • Normal Permissions: Low-risk permissions (e.g., accessing the internet). Automatically granted during installation.
  • Dangerous Permissions: High-risk permissions that involve user privacy (e.g., accessing the camera, location, or contacts). These require explicit user approval at runtime.

In enterprise environments, managing multiple dangerous permissions can become complex. These permissions typically need to be pre-granted automatically through an Enterprise Mobility Management (EMM) system, allowing applications to start with all necessary permissions already enabled. This automatic granting is essential because corporate applications run on company-owned devices that must be staged and configured to exact specifications.

We can see this behaviour also with other permissions like the Manage External Storage, System Alert Window or even Package Usage Stats ones which can all be granted automatically on our devices by leveraging MX APIs.

In this case we’re specifically talking about dangerous ones so the ones that I mentioned before are all special ones which normally require an extra step by the user to grant them and usually this step consists to grant it by going to the System Settings of the device.

With the introduction of MX 13.1 we’ve added a new entry over the list of Permissions/Special App Capabilities which can be granted automatically by including one that will also pre-grant all the dangerous permissions of a specific application, skipping this way the various pop-up requests dialogs coming from the OS when the application is run for the first time.

Important to note that MX13.1 is only available for Zebra Devices running on an Android 13 BSP meaning that this process will not work on older Android versions.

 

Accepted Permissions

 

There is a comprehensive list of dangerous permissions that can be granted automatically. These include the following ones (subject to change):

 

Integration

 

As we mentioned, our app needs to be authorised before using this API and it is required for any customer-developed apps or services, meaning any app not developed by Zebra.

For this, there are 3 viable ways on how we can achieve this:

  • Via StageNow
  • Via EMM with an XML which will be provisioned on the device
  • Via EMDK with Profile Manager

If you've never done this before, make sure you get yourself familiar at first with the AccessMgr CSP and how to deploy a profile via StageNow by setting up these params:

  • PermissionAccess Action: Allow
  • PermissionAccess Permission Name: ALL_DANGEROUS_PERMISSIONS
  • PermissionAccess Package Name: Enter app package name, e.g.: com.company.appname
  • PermissionAccess Signature: Select signature file that contains the app certificate

The PermissionAccess Signature refers to the signature file (for example, Keystore) used to sign your application. This needs to be exported in either BASE64 or CERT format. If you haven't done this yet, we have a tool to assist you. You can follow this guide on how to use it.

If you plan to use an EMM to grant the app on multiple devices using an XML, the profile will have to look similar this:

 

<!-- Note. CallerSignature should be changed with the CERT of the signature which you intend to use to compile your application -->
<wap-provisioningdoc>
    <characteristic type="ProfileInfo">
        <parm name="created_wizard_version" value="13.0.1" />
    </characteristic>
    <characteristic type="Profile">
        <parm name="ProfileName" value="DangerousPermissions" />
        <parm name="ModifiedDate" value="2024-11-29 15:25:51" />
        <parm name="TargetSystemVersion" value="13.1" />
        <characteristic type="AccessMgr" version="13.1">
            <parm name="emdk_name" value="" />
            <parm name="PermissionAccessAction" value="1" />
            <parm name="PermissionAccessPermissionName" value="ALL_DANGEROUS_PERMISSIONS" />
            <parm name="PermissionAccessPackageName" value="com.example" />
            <parm name="PermissionAccessSignature" value="Your App's certificate" />
        </characteristic>
    </characteristic>
</wap-provisioningdoc>

 

In case you want to manually stage devices in an offline mode you can export this configuration via StageNow which can be done by creating a new profile via “Xpert Mode”. You’ll have to select the AccessMgr Module and later follow the input of each one of the parameters as being shown from the above profile exported in XML:

 

""

 

You can also pre-grant these dangerous permissions programmatically through EMDK by processing the above XML using the ProfileManager APIs.

To learn more about this process, refer to the published documentation on TechDocs:

EMDK Setup

profile

Daniel Neamtu

Please Register or Login to post a reply

0 Replies