Application Configurations not working

[Martos]

Hello, i trying to define an app restriction of type string, but the bundle return empty. I used this guide to create a listener https://developer.android.com/work/managed-configurations

[Martos]

[h-mdm]

Headwind MDM cannot use managed configurations API because it's not a certified Google EMM provider.

Here's how Application Settings work: https://qa.h-mdm.com/1121/

[nktnet1]

Hey @h-mdm,

I saw from the chroniclejournal article that

Headwind MDM, an open-source mobile device management system, has become a certified Samsung Knox partner

Does this have any implications on using Android Enterprise's managed configurations (specifically app restrictions via the RestrictionManager API), or is it completely unrelated?

---

I also tried looking for documentation on the requirement of being a Certified Google EMM Provider in order to apply Managed Configurations/App Restrictions to applications, but couldn't find much on it apart from:

• https://support.google.com/work/android/answer/16694822#zippy=%2Cwhy-does-android-enterprise-verify-and-approve-dpcs%2Cdeveloper-and-emm-guide-for-dpc-approval-process%2Chow-can-i-appeal-this-decision

  Only DPCs verified and approved by Android Enterprise are permitted to install apps during enterprise device enrollment provisioning. The installation of any non-approved DPCs or app installation attempts not on the allowlist will be blocked during enrollment installation.

Is this what's stopping Headwind from using this feature? Are there plans to eventually support it (i.e. become a Google-certified EMM provider)?

---

Also, from this Stack Overflow answer:

You can use Google's new Android Management API to manage Android devices without building a DPC or registering as an EMM.

which happens to have documentation for the Managed Configurations iframe:

• https://developers.google.com/android/management/managed-configurations-iframe

Just in theory (purely hypothetical), would Headwind be able to support this, or are there other challenges regarding certification?

Thank you!

[h-mdm]

Partnership with Samsung Knox is not related to Android Enterprise or Google EMM Provider, so the Android Enterprise SDK is still not available, sorry about that.

[nktnet1]

Thanks @h-mdm.

Something I don't understand is that apps such as

1. OwnDroid: https://github.com/BinTianqi/OwnDroid

   • code: https://github.com/BinTianqi/OwnDroid/commit/4bcd2d8150c7371c228b3125437c96dfb4e7959f

2. Test DPC: https://github.com/googlesamples/android-testdpc

   • code: https://github.com/googlesamples/android-testdpc/blob/305c86d36e9b7c85e41e9e01fbf2d648fa4970fb/src/main/java/com/afwsamples/testdpc/ShellCommand.java#L1204-L1229

Are all able to set managed configurations (app restrictions) simply by being the Device Owner.

Given that the headwind android app can be set as the device owner, is there any other limitations I'm unaware of?

Would the Headwind team be open to pull requests that implements this feature?

[h-mdm]

You are right, this feature is definitely worth being implemented - we were misleaded by the method name "setApplicationRestrictions" whereas it is used to configure (not restrict) third party apps, so a device owner app indeed can manage third party app configurations!

However, we have to think how to integrate this option in the application settings so the existing application settings scheme won't be broken.

If you already implemented this feature and want to push your update as a pull request, that would be helpful for our dev team, so we'd be happy to get it. Don't worry if there will be no direct acceptance of the pull request, your contribution will be acknowledged and processed anyway.

An alternative would be to wait until this feature is implemented.

[nktnet1]

Thank you for re-opening the issue @h-mdm!

I haven't started any real work yet - will leave it to the dev team in that case :).

I think the linked code above from OwnDroid (kotlin) and Google's Test DPC (java) could come in handy.

However, we have to think how to integrate this option in the application settings so the existing application settings scheme won't be broken.

Yeah, I did notice headwind has its own application properties - perhaps that can take precedence over managed configurations (or vice versa) if the same key for both exists.