I think this is shaping up to be one of the bigger issues that we'll all be facing over the next year. 

From what I've been able to gather, the SOTI agent, and all EMM agents for that matter, do not have access to scoped storage on Android 11+. This came as a bit of a surprise to me as I assumed that DO privilege would have granted that access despite the other restrictions to scoped storage that have been introduced. Since this issue is technically bigger than SOTI I posted on the AE forums about this and have yet to get a response:

https://support.google.com/work/android/thread/127125505/a11-scoped-storage-access-for-device-owner?msgid=127238694

You can see evidence of other folks running into this issue a few months ago. Samsung devices were the tip of the spear with this and a lot of us are only now realizing this problem after A11 has become available for the Zebra devices:

https://discussions.soti.net/thread/android-11-scoped-storage-blocking-package-and-file-sync-rules/

Darryn Campbell of Zebra does a great job explaining the impact here and what options are available for developers moving forward.

https://developer.zebra.com/blog/scoped-storage-enterprise-applications

For the applications that I manage I will be moving back out of scoped storage and into shared storage again for configuration files. I will then be requesting the manage_external_storage permission in order to get that access and will use MX to silently grant it. For other applications, they will either need to be redeveloped to do something similar, or they will potentially have to migrate to managed configurations and away from external configuration files. We can see that Zebra Enterprise Browser is moving away from scoped storage and into shared storage to support Android 11:

This is actually quite ironic considering that A11 was supposed to be moving more applications to scoped storage and it seems to be having the opposite effect on the enterprise use case. 

I would imagine that Velocity would have to do something similar, although as an app on the Public Play Store, they're ineligible to request the manage_external_storage permission in A11. 

For now I'd recommend that you downgrade those devices back to A10 and wait as long as possible to migrate them to A11. There are no compelling enterprise features of A11 that you really need and A10 is still being patched with LifeGuard security updates so there is no rush to get to A11. Where you'll run into trouble is buying the MC3300ax or TC52ax which ship with A11 and can't be downgraded. 

Thank you for this detailes comment Matt.
It's sad to hear, that theres no solution.

I will downgrade the devices and hope that Wavelink will update their app or maybe google will improve the Android.

Thanks for your help!

Hi Julian, 

A very interesting article is available to have the solution here :

 https://supportcommunity.zebra.com/s/article/000021277?language=en_US

Kind regard,

Laurent

It's really unfortunate the insane lengths you have to go to just to get a device configured under those circumstances. The process outlined in that guide is creative but also maddening considering we previously could put files directly on the device via the EMM. Google is making so much of this worse for the EMM admin. The enterprise use case still seems to be largely ignored. I honestly can't think of any great enterprise benefits that we're getting out of A11 in exchange for the pain being introduced by it. I'm not aware of any customers clamoring for A11 because of some new great feature that they're getting, its the opposite. Each subsequent version of Android is making it harder and harder for us despite Googles best efforts. It won't be long until custom DPCs are deprecated and we're all forced to AMAPI. 

<A11

• Upload app configuration file(s) directly into SOTI via File Sync rule or Package
• SOTI distributes the file(s) directly down to the correct directory on the devices, including scoped storage up to A10. 

A11+

• Upload app configuration file(s) into a separate FTP or file server
  •    This now assumes the devices have network access to the file server
• Create a manifest config file referencing the configuration files and upload it to the same FTP server
• Approve the application via Managed Play and assign it to the devices via an App Catalog Rule
  •    This now assumes the devices are enrolled under AE with service accounts and have external access to Google Play
• Create a Managed Configuration payload for the application that points the app to the download location for the manifest
• Wait for Google Play Servers to slowly disseminate that App and Managed Config out to the devices 
• App installs and processes the Managed Config which directs it to the FTP server to download a manifest
• Reads the manifest and then reaches back out to FTP server to download the config files into its config directory. 

In this new world the MDM server isn't even really doing much of anything at all. The majority of the "config" is setup through the Managed Play iFrame and then installed on the devices from a separate FTP server that the business app has to be designed to pull from. Neat that someone came up with this process to get around all of the various restrictions that Google has implemented but this is a joke that it has to be this way. 

What does making a minor change to that configuration payload now entail? New uploads to the FTP server, new manifest, new managed play config, long wait for managed play to actually do its job, etc. etc. Versus the prior method of a quick Package revision or File Sync Rule update. 

Thanks for this interesting solution Laurent.

It's incredible what an massiv work is to be done only for a config file.

That's only one more potential point of failure.

Nice to see that Zebra is working on the problem, but i hope Google will give us an easier solution.

So long I prefer to stay at Android 10.

A11 Velocity Zebra SOTI

copy /sdcard/profile.wldep /enterprise/usr/profile.wldep
sleep 1
__chmod 777 /enterprise/usr/profile.wldep