Permissions Issue with Android Enterprise Agent 13.6.0 Build 1662

Permissions Issue with Android Enterprise Agent 13.6.0 Build 1662

I have an enterprise B2B application that I distribute to devices via SOTI Package in a Profile. SOTI is properly installing the APK and is also now automatically granting the required permission (just storage) which is a nice feature recently introduced in this agent version. The issue that I'm now facing is that the app itself will no longer launch and I get a permissions related toast message error as soon as I try to launch it. The same version of the application works under the following circumstances:

AEDO Managed Zebra MC33 running Android O (8.1.0) with LifeGuard 12 on SOTI server 14.1.3.1587 and the 13.6.0.1567 Android Enterprise Agent.- App runs correctly

AEDO managed Zebra VC80x running Android O (8.1.0) with LifeGuard 12 on SOTI server 14.2.2.1170 and the 13.6.0.1622 Android Enterprise Agent - App crashes on launch with permissions error. 

I'm trying to isolate my variables as much as possible to identify the root cause of this problem but I'm starting to think that it has to do with the automatic permission granting of the new agent version. Is there any way to disable this feature so that I can manually enable the app permissions? The forced upgrade to a newer agent version seems like a pretty frustrating side effect of leveraging Android Enterprise with a Play Store distributed agent. Is there any way to lock in a specific agent version for AEDO enrollment if it does end up being the Agent causing the problem?

 

24 Answers

Order By:   Standard | Newest | Votes
Matt Dermody | posted this 20 February 2019

I finally managed to get the devices re-enrolled with the older AE agent 13.6.0.1567 using the Zebra StageNow AEDO enrollment method and the older agent, which does not grant permissions automatically, allowed the application to run. Granted, I had to grant the permissions manually when prompted with the older version, but the app still worked. 

Thankfully the StageNow based DO enrollment was available as I otherwise don't know how I would have been able to enroll in a DO mode using any of the Google Setup Wizard based enrollment methods that only pull the latest (bad) version from the Play Store. 

In my troubleshooting I did try to leverage another app that utilizes the same Storage permission and it seemed to work perfectly fine with the automatic permission granting. It is for this reason I think there still might be some work that could be done to the B2B app so that it could work better with the automatic permission granting process but still, had this been a B2B app that is not being maintained anymore and had there not been an option to leverage an older AE agent with StageNow based enrollment then I don't know what I could have done. 

  • 0
  • 0
Ross , Hathaway | posted this 20 February 2019

Hi Matt

 

Use the below script this will allow permissions on applications automatically

 

afw_set_permission_grant_state PACKAGE NAME android.permission.WRITE_EXTERNAL_STORAGE allow

afw_set_permission_grant_state PACKAGE NAME android.permission.READ_EXTERNAL_STORAGE allow

  • 1
  • 0
Shabaz Badshah | posted this 20 February 2019

Hey Matt,

The AE silent permissions policy modification that was made to the AE Agent in the latest release modifies the default behaviour of how we handle application permissions.  Prior, an app requesting certain permissions would prompt the end User for what permission(s) it required, but with the recent change we will now grant all permissions required, silently and by default.

 

How does the feature work?

Under the hood we are using the "afw_set_permission_policy" script, prior the default behaviour for this script on devices was "afw_set_permission_policy prompt" which would prompt the end user for all permissions related to the app. A plethora of Customer however did not want end user interacting with application permissions or did not want to manually grant all permissions via script.

With the new update, we are similarly sending down the following modified script "afw_set_permission_policy grant". This will grant all app permissions silently.

 

How to switch back to the old behaviour of handling permissions?

If the Admin would like to modify their existing permissions at a more granular level, they can still send down "afw_set_permission_grant_state" script to deny certain permissions.

 

You can use the following script to revert back to the default behaviour of handling permissions (which will prompt the end User).

"afw_set_permission_policy clear"

You can also use the following script if the one above does not work:

"afw_set_permission_policy prompt"

 

Please let me know if you need more information

  • 1
  • 1
Shabaz Badshah | posted this 20 February 2019

Hey Matt,

The AE silent permissions policy modification that was made to the AE Agent in the latest release modifies the default behaviour of how we handle application permissions.  Prior, an app requesting certain permissions would prompt the end User for what permission(s) it required, but with the recent change we will now grant all permissions required, silently and by default.

 

How does the feature work?

Under the hood we are using the "afw_set_permission_policy" script, prior the default behaviour for this script on devices was "afw_set_permission_policy prompt" which would prompt the end user for all permissions related to the app. A plethora of Customer however did not want end user interacting with application permissions or did not want to manually grant all permissions via script.

With the new update, we are similarly sending down the following modified script "afw_set_permission_policy grant". This will grant all app permissions silently.

 

How to switch back to the old behaviour of handling permissions?

If the Admin would like to modify their existing permissions at a more granular level, they can still send down "afw_set_permission_grant_state" script to deny certain permissions.

 

You can use the following script to revert back to the default behaviour of handling permissions (which will prompt the end User).

"afw_set_permission_policy clear"

You can also use the following script if the one above does not work:

"afw_set_permission_policy prompt"

 

Please let me know if you need more information

  • 1
  • 1
Matt Dermody | posted this 20 February 2019

Thank you for the thorough response Shabaz! I have tried to revert back to the previous method using this script and yet I still get the same error:

afw_set_permission_policy clear

I see that the permission still appears the same in the Settings app, meaning it does not have a toggle switch like I would expect after sending this script. 

 

 

 

  • 0
  • 0
Matt Dermody | posted this 20 February 2019

Thank you Ross, that did the trick!

  • 0
  • 0
Saro | posted this 20 February 2019

Use the below script this will allow permissions on applications automatically

afw_set_permission_grant_state PACKAGE NAME android.permission.WRITE_EXTERNAL_STORAGE allow

afw_set_permission_grant_state PACKAGE NAME android.permission.READ_EXTERNAL_STORAGE allow

 

How the hell did you know about those afw_* commands? There's zero mention of them in the MobiControl 14.2 docs, and the release notes for the agent never mention anything useful. Is there some sort of secret source of information for these script commands that only the privileged are aware of, or have I not been looking hard enough?

 

  • 1
  • 1
Jason Klotz | posted this 20 February 2019

This did the trick for the same issue I was having with Samsungs and email.

 

Now I find out Skype for business is having the same issue. 

  • 0
  • 0
Matt Dermody | posted this 20 February 2019

I have had this same complaint for a while now Saro, there are apparently a lot of secret sauce scripts out there that are not well documented. Another emerging issue is the differentiation between scripts supported by AEDO vs. Android+ as that is not clearly spelled out in the documentation either. Best bet is to monitor the forms and stash away any useful scripts that you encounter. 

  • 1
  • 0
Jason Klotz | posted this 20 February 2019

I agree. What I have been doing is keeping every one they throw at my devices. I think they have a big "book"

  • 1
  • 0
Jamie Lee | posted this 25 February 2019

Did you manage to fix the issue within Skype for Business? I am banging my head against a wall right now!

  • 0
  • 0
Matt Dermody | posted this 25 February 2019

Do you know what permissions the app needs? I would suggest leveraging the same script format provided by Ross, replacing the relevant sections with the relevant package name and permission property:

afw_set_permission_grant_state PACKAGE NAME android.permission.PERMISSION allow

  • 0
  • 0
Jason Klotz | posted this 25 February 2019

Not yet Jamie. I have been all over on the scripts and Skype is just being a pain. I have a case open with SOTI.

  • 0
  • 0
Jamie Lee | posted this 25 February 2019

Let me know if you get anywhere, ill do the same. I am having a nightmare with it.

  • 0
  • 0
Ross , Hathaway | posted this 25 February 2019

If you open the application for the first time which permissions does it request the full list or screen shot of the device?

  • 0
  • 0
Jamie Lee | posted this 25 February 2019

It requests that all apps are enabled but wont allow them even though i have enforced them through the AE Setup.

Also i am able to use Outlook for email but as soon as i try to sync contacts its as if something is blocking it. I wonder if they are linked?

 

 

 

  • 0
  • 0
Jason Klotz | posted this 25 February 2019

Same thing I am seeing on my devices. Still no update from SOTI yet.

  • 0
  • 0
Saro | posted this 25 February 2019

It requests that all apps are enabled but wont allow them even though i have enforced them through the AE Setup.

Also i am able to use Outlook for email but as soon as i try to sync contacts its as if something is blocking it. I wonder if they are linked?

While this is a shot in the dark, I believe Skype may also request the Modify System Settings permission, which MobiControl may not necessarily grant. Perhaps toggling that switch under Android Settings might do the trick.

  • 0
  • 0
John Aiston | posted this 26 March 2019

I am seeing this on several devices now with managed apps since updating the mobicontrol agent :(

SOTI should turned this new feature off until a managed solution can be implemented.

 

(unable to turn on contact syncing in Outlook app for example)

  • 0
  • 0
Matt Dermody | posted this 26 March 2019

You could try to leverage this script that was suggested earlier in the thread for restoring the old permissions handling model, but I didn't have any success with it myself.

 

afw_set_permission_policy clear

 

  • 0
  • 0
John Aiston | posted this 26 March 2019

script to restore old handling model doesn't work, had to send these instead to restore contact syncing.  SOTI really need to undo this new feature until they provide documention and create options (profiles) to manage this new feature :(

afw_set_permission_grant_state com.microsoft.office.outlook android.permission.READ_CONTACTS allow
afw_set_permission_grant_state com.microsoft.office.outlook android.permission.WRITE_CONTACTS allow

John.

  • 2
  • 0
Matt Dermody | posted this 26 March 2019

Agreed! Paging Shabaz. This "feature" had great intentions but it is causing more harm than good at present. 

  • 1
  • 0
Sean McFadden | posted this 27 March 2019

That was my experience, as well.  SOTI needs to deal with this ASAP, as admin's can't be expected to be pushing scripts to allow permissions per-app for any and all users.  

 

Additionally, I noticed that the Google backup is greyed out.  Does anyone know of a script to enable this, as it's not being disabled by Policy?

 

"script to restore old handling model doesn't work, had to send these instead to restore contact syncing.  SOTI really need to undo this new feature until they provide documention and create options (profiles) to manage this new feature :(

afw_set_permission_grant_state com.microsoft.office.outlook android.permission.READ_CONTACTS allow
afw_set_permission_grant_state com.microsoft.office.outlook android.permission.WRITE_CONTACTS allow

John."

  • 0
  • 0
Ross , Hathaway | posted this 28 March 2019

The way that script works is you need to delete and re-install the app for it to take affect...

The latest version of the enterprise agent has now completely broken that as you get a error in logs script not supported

  • 0
  • 0
Give us your feedback
Give us your feedback
Feedback