VMware Launcher on Android Enterprise – nuances

I regularly get questions from customers and partners who used kiosk mode on older Device Admin devices with VMware (then AirWatch) Launcher, and have issues since they had migrated to Android Enterprise and Launcher 4.0+.

In this post you will learn how to:

  • Solve the most frequent (and annoying) issue when migrating Launcher setups to AE
  • Find further settings for Launcher, which are not exposed in the GUI, and apply them via custom XML
  • Control Launcher versions per OG using Settings and Inheritance.

A case of Status Bar not showing up

The Launcher profile allows status bar, but the device (pre-Android 9, where there were special APIs just for that) comes up with a blank space in place of one. In addition, there is an annoying floating button with the Home key, that is not strictly necessary. Why?

Launcher 4.0 uses new(er) native Android Enterprise APIs, while many settings in the profile still address the Device Admin mode. These new APIs fall under the umbrella of Corporate-Owned Single-Use (COSU) use case and are known as “COSU Mode” internally. When in COSU mode, some features are disabled by default in order to provide max security. These include:

  • Notification / Status Bar at the top of the screen
  • Home & Recent Task soft keys at the bottom of the screen. As a replacement a floating button is provided.

Again, this is the default behaviour on AE, regardless of what is configured in the profile.

However, if this is not something you need (many want their status bar back), there is a way. Launcher supports more settings than meets the eye. You can use the custom XML to apply them. For instance, in this case we need this parameter applied

<characteristic type="com.airwatch.android.androidwork.launcher" uuid="568bc89d-1df8-4ce9-a041-e5a24acdb7ec">
<parm name="SkipCosuSetup" value="True"/>
</characteristic>

Once this XML is applied in the Custom Settings payload of the Android profile, you will see the changes.

Case closed! As a bonus, the Home button is gone. As a side-effect, on pre-Android 9 devices you will still see the animations of the task switcher/notifications pulldown etc even when it they are disabled. This is because there is a single API calls that controls rendering the UI and the UI animations. So even when you block, say, the Task Switcher, the animation remains. The behaviour is different for different for Android 6/7/8, but in Android 9 Google had addressed the issue.

Where to find more custom XML for Launcher?

So, we solved one problem using a piece of XML that came out of nowhere. How to solve others and know what other XML pieces are available?

Fortunately, since recently all the custom XML settings are documented in the official Workspace ONE UEM documentation, including the Launcher version they were introduced in (this changed for 1910 release, now all settings are on the same page, if you need those versions – look at the 1909 docs).

With this, you will be able to configure an tweak Launcher to your heart’s content. If you have devices from different vendors, having different Android versions, firmware revisions, mods/quicks and other behavioral differences, it may make sense to use the “normal” Launcher profile as the general setting, and separate the Custom XML into additional “tweak” profiles delivered via Smart Groups to different device types.

But my Launcher is stuck at version #, even though I’m at the latest SaaS console version?

This also comes up from time to time, especially in trials and PoCs with new customers. The answer is simple – check your settings! Go to Settings -> Devices -> Android -> Service Applications and see if “Always Use the Latest Version of Launcher” is enabled (or select the version you want).

For instance, the default value for my sandbox is to use Launcher 3.0 ! Once I override the setting, it’s magically on 4.5. Once you change the setting the Launcher should update automatically on assigned devices.

Summary

This is it. We have seen how

  • Solve the most frequent (and annoying) issue when migrating Launcher setups to AE
  • Find further settings for Launcher, which are not exposed in the GUI, and apply them via custom XML
  • Control Launcher versions per OG using Settings and Inheritance.

Was there a specific XML setting that turned out to be very useful in your setup? Let me know in the comments!

2 thoughts on “VMware Launcher on Android Enterprise – nuances

Add yours

  1. Hi. We would like to use ‘skipCosuSetup’ in Custom Settings. With this setting ON, is there a way to disable access to certain Android settings (for example we don’t want our users to access ‘Apps’ setting)? Thanks

    Liked by 1 person

  2. Unless you are using devices like Zebra/Samsung/Honeywell that allow such customizations, you would have to block access to the native Settings app and use the user-facing settings options available in the Launcher itself.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

<span>%d</span> bloggers like this: