Applying Zebra MX advanced device settings via SOTI EMM

Zebra devices have a cool set of extensions called MX. It can do tons of things. But, can we expect every EMM vendor to timely implement them natively in their consoles?

SOTI EMM/MDM is one such good example, as UI there is quite limited. However, SOTI has a very powerful tool called SOTIscript. I have already covered, for example, how SOTIscript allows changing virtually any standard Android OS setting.

Similarly, we can use SOTIscript to apply MX settings on Zebra devices, extending the level of control over the device.



Changing Android device settings unavailable in AirWatch native GUI (Zebra MX)

Zebra devices have a cool set of extensions called MX. It can do tons of things. But, can we expect every EMM vendor to timely implement them natively in their consoles?

Unlike SOTI (which can use SOTIscript for advanced features), AirWatch only allows changing settings that you can see in the GUI. If it’s not in console GUI – you can’t have it. However, there are a few exceptions.

In this post we will talk about one extremely simple, yet little-known way of extending AW functionality beyond the GUI limitations. Read on if you want to know how to apply any MX setting via AirWatch to your Zebra device.


Changing Android device settings unavailable in SOTI native GUI

With most MDM/EMM solutions you are limited to whatever options are available in the GUI (I’m looking at you, AirWatch). SOTI in this regard looks weird, since the number of settings is not particularly rich, which makes it seem limited. However, SOTI has the super-awesome SOTIscript, and SOTIscript has a number of super-awesome  (but barely documented) script commands.

Today, we will take a look at how to use those commands to change (virtually) any Android OS setting available on your device via SOTI MDM.


Do non-overlapping channels overlap?

We all know the “non-overlapping” channels 1/6/11 in 2.4GHz (5GHz matter is similar). Do they really not overlap? I keep bumping into this in conversations, and would like to create a point of reference (with pictures) instead of having to repeat same old over and over.

BW- 2m away from AP
Your typical “non-overlapping” 1/6/11 setup

Since we a dealing with broadband technology, the signal is in reality not 100% contained within the allocated 20Mhz band – we only see the tip of the iceberg. Here’s the official 802.11 20-Mhz OFDM channel spectral mask. Note that the “20Mz” channel actually goes up to 30Mhz in every direction (60Mhz total width), albeit up to -45dB weaker, than the central 20Mhz flat part.

Wi-Fi Spectral Mask - Single Channel
802.11 OFDM transmit spectral mask. Power levels are relative to the signal strength in the center.

Now, let’s combine the masks for all the “non-overlapping” together and enjoy the view.

Wi-Fi Spectral Mask - 1-6-11
Spectral masks combined together in 2.4GHz space. Can someone draw me picture with three icebergs please?

Of course, if the APs are spaced far enough, the effect of side bands will be negligible: if I already hear the AP’s central frequency at -87dBm, hearing the sidebands at another 20-26dB lower will do well below the sensitivity threshold. However, if this is not adhered to, here’s a spectrum analyzer capture of channels 1 and 11. Can you see the AP in channel one? What chances are for it to be heard?

Spectrum - 24GHz Ch1 Ch11 overlap
“Non-overlapping” channels 1 and 11.


  • Even non-overlapping channels overlap
  • Maintain separation. Either calculate using tools or use 3-5m as a rule of thumb (better use tools!)
  • Stacking APs on top of each other to provide triple density seems a good idea but only works if you are Xirrus, but even they stopped doing it, as far as I know.
  • 2.4GHz is dead, move all enterprise networks to 5.

Hope this clarifies the matter enough. If this useful enough to use as a point of reference when explaining the matters to others? Let me know your thoughts!

What 802.11ax is not

I normally do not publish the “link to” posts, preferring to share on LinkedIn, but Devin Akin well deserves it. Matches my perspective 98%+, especially the point on 802.11ac stillborn MU-MIMO.

Preamble: Aerohive has released the first 802.11ax APs (the official 802.11ax standard spec is not final yet) – so expect the marketing race.

TL DR: The only good thing is OFDMA sub-carrier allocation (think sub-channels) similar to what exists in GSM/LTE/WiMAX, but it would not work w/o client support and forget 2.4GHz.

Anyway, enjoy the article: and let me know your thoughts!

Setting a package as Device Administrator with StageNow, reversing the DevAdmin class name

I had to perform a simple task recently: set up the Battery Swap application on out TC51 as a Device Administrator, so that it can do its battery swapping preparations correctly (for some reason it’s not set up as such by default). MX and StageNow allow this via the DevMgr CSP. But that CSP requires Package Name and Class Name. Let’s find out and do some more package dumping for fun and profit!


Calling Android Settings pages programmatically during Staging

In quite a few situations we need the user to input specific data during device Staging. For instance, I have been doing a job for a customer, requiring a PIN code pre-set on the device, when it comes back from repairs. This PIN code can only be set programmatically by Device Administrator class app (or MDM agent, which usually registers as one). Given the circumstances, this was not an option.

Normally, this means that you’d have to provide instruction containing lots of “tap this” and “skip that” as well as lots of screenshots to ensure that there is no way the user will be lost. However, this approach is error prone and time consuming. And for repair loop operations this means $$$. Wouldn’t it be better to just scan a barcode? But how?

Each page of the Settings app in an Activity. Thus, we can write an intent to pop it up. StageNow (via MX) allows us to run intents. The question is, how do we find, which data to populate the intent with? Let’s find out!