With MobiControl v15.x, you have the new options in Add-Devices rule to choose some of the app permission(s) to be automatically granted during device enrollment.

Whether or not this works may vary with your devices' platforms/modes/firmwares/agent-versions and availability of the device AE plug-ins.

If you are using earlier MobiControl server version or the above doesn't work for any reason,  you can send the following script commands to prompt device end-user to manually grant the corresponding permission:

  request_appops_permission WRITE_SETTINGS                                        (for v13.7.0+ device agents)

  request_appops_permission PACKAGE_USAGE_STATS                              (for  v13.6.1+ device agents)

  request_appops_permission BIND_NOTIFICATION_LISTENER_SERVICE     (for v13.6.1+ device agents)

 No prompt will be shown on the device screen if the permission has already been granted.

Hello Raymond,

thank you for the quick answer. But the permission in the add device rule are set like you descript. But no matter Mobicontrol ask for permissions.

And the point is that i dont wont that the user need to confirm the administrative installation.

And we use:

Client:14.3.0.1000 / 14.4.1.1064

Mobicontrol:

Version: 15.0.1.1181

As I understand it, Zebra is no longer signing the OEM Plugin for SOTI so any hope of an updated plugin that would help to grant these permissions silently and automatically is gone.

Zebra is aligning heavily with Google's way of doing things now that Google is more focused on the Android Enterprise. This means more focus on OEM exposed configuration settings through tools like MX and OEMConfig instead of Secure System Settings. This is quite unfortunate as writesecuresetting scripting still can perform things that MX has yet to expose and works on other manufacturers like Honeywell. 

Given that there were gaps between what writesecuresetting supported relative to Zebra's MX layer, we started collecting a wish list of features here, before the thread was inexplicably locked. 

https://discussions.soti.net/thread/wish-list-for-zebra-ae-functionality/

Some of our requested features have actually made it into recent MX versions, which indicates that Zebra is actually listening to this problem. The issue with this approach however is that there are now minimum MX versions that are required for the device before you can take advantage of these configurations. To get to a higher MX level you need to firmware update the device, which in and of itself is a disruptive procedure that needs careful planning and coordination, in addition to a fair amount of validation that you're not breaking something else in the process. Even then, there aren't necessarily firmware updates available for every device to even be able to take advantage of these features. In other words, to control a simple setting like display orientation that was easily administered via writesecuresetting in the past, you now have to wait for a firmware update to become available for your device model to bring it up to a minimum MX level like 10.2 just to be able to configure the exact same setting again with MX. 

You would have to update your devices to the latest Oreo BSP + a very recent LG8 just to be able to leverage these newly exposed MX 10.2 configurations:

The migration to Android Enterprise with Zebra devices has honestly been relatively frustrating because we were not at parity in configurability when abruptly forced to start using AE with SOTI in A8, despite the DA APIs still being available. Now that A10 is here and MX is finally catching up, we're still not completely at parity with a lot of features relative to the control we had under DA for these dedicated devices. 

There was an ongoing discussion on this topic here:

https://discussions.soti.net/thread/how-to-accept-write-settings-permission-programatically/

Long story short, I would at a minimum uncheck the modify system settings permission from your enrollment rule if you are enrolling Zebra Android Enterprise devices because the permission will have to be manually granted and then it won't necessarily even support the same configuration settings that you may have been used to under DA. The other permissions should in most cases be granted automatically.