Had a good discussion with Zebra development and they confirmed for me that submitting MX XML will not be going away as was previously intimated, at least for the foreseeable future. They recognize that OEMConfig has a looong way to go.
What WILL be going away is public documentation and "external support" of newer CSP changes in deference to Managed Configs. As long as MobiControl continues to provide the mxconfig command we should be able to export from stagenow and submit via mx xml though with no issues.
Also, they said that using/managing/applying OEMConfig outside of the google playstore would very likely become a reality at some point. It's just not top priority for them right now.
Feeling much better now...
OEMConfig relies on Managed Configs which as far as I'm aware, only work through the Play Store architecture right now. It would be great to remove the reliance on Google Play so that we can administer Managed Configs directly from EMM but I don't think Google is going to be too keen on that. I hope EMM providers figure out a way to do it anyway!
Hi hope the OEMConfig plugin will be included in mobicontrol directly in the future....
Let's think to all those customer who don't want GMS enabled on their devices, without GMS and a managed google account it will not be possible to install OEMConfig plugin and configure the device...
Let's cross fingers
That was pulled directly from Zebra's EMMTK documentation.
That site also includes the following graphic indicating that the XML MX delivery method would no longer be supported by Zebra starting with Android P.
The term supported is an important distinction here. I have reached out to Zebra on the matter and have confirmed that the functionality is not being discontinued or removed in their Android P builds, but they will no longer be supporting any issues related to XML based MX delivery. Zebra Managed Configurations (ZMC) delivered via OEMConfig is all they will be supporting for Android P and beyond. I have already confirmed on an early P build for the Helios class devices that the XML delivery mechanism is at least still working, so that is a good sign. We should be able to continue to leverage the XML option for the Android P builds from Zebra, unless they decide to discontinue that functionality later.
I guess we also will rely on SOTI to not discontinue support either. We know that the current Zebra plugin for AE supports MX and removing support would have to come in the form of a new plugin in the future. Therefore, if they do remove support in a future plugin we could probably continue to leverage the older plugin.
Where did you find the graphic above? This does cause some real concern. Particularly with Pie being released for all the new Zebra gear and customers desire to be on the latest OS. After initial testing this seems very cumbersome way to manage device settings that often change, need to be tested individually and applied on the fly. Like you said previously, after using MX XML for years. It becomes so modular and easy to apply via MDM. Here's hoping this will evolve more before depreciation of tried and true methods of management.
We’ve waited almost 2 years for this feature after it was first announced and the novelty has already worn off. I previously saw this as maybe one of the only seriously compelling reasons to move to AEDO for dedicated device deployments and now I’m not so sure. We have had it so good with DA + mxconfig on Zebra devices. I hate to see that were kind of sliding backwards now that Google has put more focus on the enterprise, forcing the Play architecture into the mix. Long live the MX XML support!
That's exactly what I thought when I looked at it. How the heck are you supposed to exercise any level of granular control? Maybe I'm missing something here but this model seems entirely unworkable. "Settings" shouldn't be tied with a specific apk unless there is a separate "config" instance similar to how the SOTI Settings Manager works. If mxconfig is TRULY deprecated after O we DEFINITELY won't go to P until something more workable is in place...
Yep! Got my hands on a 14.4 instance yesterday and was able to confirm that I can pull and render the schema. Still trying to work through the comparisons with the standard mxconfig XML. At this point, while I have been excited about OEMConfig in the past, I'm now relatively skeptical. I worry that I'm going to have to have multiple variations of OEMConfig assigned to different groups of devices, manually configuration each setting within each permutation. With the XML however, its a lot easier to break things up into separate XML files so that you can have more control in applying them to different groups of devices. We also have instituted a fair amount of version control over our MX configuration settings and it doesn't look like that is going to be much of an option with OEMConfig. I also worry about the Play Store dependence and how that results an invariable amount of time for the settings to be configured. So far, I'm not impressed and I'm really hoping Zebra or SOTI doesn't deprecate support for the EMMTK based MX approach that works with mxconfig. In short, it feels like OEMConfig was built for the use case of an individual IT team managing one fleet of devices. It's going to be a lot more challenging for managed service providers who manage 50+ different environments to institute version control and standardization. I see a lot of manual check box clicking in my future.
I have a dev server running 14.4 and looks like there is stuff there...