Table of Contents
Introducing The Next Phase Of Android App ManagementIn mid-December MaaS360 completed the 10.76 code elevation which brought a variety of changes to application management for Android devices. This includes additions and enhancements to the Android Enterprise workflows, some of which were the final checkbox on the deployment checklist that many companies have been waiting on to start rollout of BYOD (AKA Profile Owner, AKA PO) enrollments. The options for Android app distribution are as follows:
- Google Play - Public and Private apps distributed to the account via a 3rd party (more on this below). Supported for all enrollments, though instant installs (no end user interaction) are only available on Android Enterprise enrollments.
- Enterprise App - Applications hosted on the MaaS360 platform. Distributions will work for all Device Admin (legacy) enrollments as well as full managed (DO or COSU) Android Enterprise devices.
- Private App - Applications hosted privately in the Google Play catalog available just to devices enrolled in Android Enterprise and MaaS360. Supported on both fully managed (DO and COSU) and BYOD (PO).
- Webapp for Android Enterprise - Web apps for distribution and installation on the home screen for all Android Enterprise enrollments.
Each option comes with some new features, many of which are a drastic departure from the way app additions were handled in the past, so we will cover each item one-by-one down below, but there are some other features of which admins need to be aware.
- Play Protect - this is a service that is enabled by default on all AE managed devices and can not be disabled. It's free, mostly non-intrusive, and aids in keeping managed devices safe. The shortest description I can really give of what Play Protect does is that Google scans their app inventory for malware and illicit behavior, while facilitating automatic removal of apps from devices that have them installed. This means if Google finds some bad code in an app and removes it from the Play store, it will automatically be removed from devices with Play Protect active. More information on the program can be found here.
- App Whitelist - By default MaaS360 leaves most apps disabled on the devices enrolled in AE. They can be whitelisted via the AE policy app compliance either by check box (for Google native apps) or by app ID (for 3rd party native apps). Due to the way Android is built, some 3rd party apps can not be removed from the device, but they can be disabled from use in the same App Compliance policy.
- Opening up the full Play Store - Android Enterprise managed devices receive the Play account for the work profile from MaaS360 as part of enrollment. This means that users only see the applications approved by administrators in the Play app when launched. There are scenarios where organizations wish to allow users to install their own apps in the work profile with no restrictions. In these cases, admins will first have allow account modification in the AE security policy, then users will have to manually add their personal Play account, and manually switch to it in the Play Store app on the device. It can be a hassle to explain to end users, but for security purposes this is restricted by default (most scenarios where this is required are on fully managed devices, as BYOD PO management includes work/personal spaces). Please note: Allowing users to enter their own personal credentials can seriously compromise the work profile and may lead to unintended consequences (such as the user being able to remove control of MaaS360) and is not recommended for every environment. COPE (now in the final stretch of beta) may be a better alternative for DO devices where admins wish to maintain total device control, but give users a more personal experience.
Google Play Apps
Managing public apps on Android devices has been a mixed bag of functionality depending on the management style being leveraged. The legacy Device admin style of management doesn't have direct Play store integration - users received what was essentially a redirect link in the MaaS360 catalog, but it is up to them to configure Google Play credentials and install the app. Admins can remove the apps remotely, however, since Device Admin rights gives them permission to do so.
Android Enterprise really ramped things up considerably with direct Play Store integration, silent installs for all AE enrolled devices, and new options for configuration (App Config). This means that administrators can now silently install, update, and configure apps (where supported) on managed devices with no user interaction. This is especially useful in the kiosk scenarios that we find many of our clients using. No user interaction would be required post-enrollment to configure the devices with all the apps they need to function properly.
Prior to the 10.76 code elevation there were two options for app additions - one for DA and another for AE. We've now unified the app distribution in to a single interface that presents application search options as one would see them in the Play Store.
If Android Enterprise is setup on the portal (and it really should be by every client managing Androids at this point) there will be a prompt to "Approve" the app as part of adding it to the app catalog. Public app management for AE is based on these approvals so there is no need to build complex blacklists, the admins have complete control of the apps installed in the work profile.
In scenarios where the apps are already in the catalog, but AE has only been recently setup, they will appear with a red "!" over the icon. Clicking on the "!" will open a box with the permissions for admins to accept, so that they do not have to go through the full app addition process again. Only after this is done will the apps be available for installation on AE enrolled devices.
Enterprise Apps for Android
Enterprise app distribution for Android has traditionally been relatively cut-and-dry, but AE introduced some new mechanics that throw some people off a bit. DA management remains the same, enterprise apps are uploaded to the MaaS360 portal, various fields are filled out, and depending on device OEM instant install may or may not be available. AE only supports this traditional method for fully managed (DO) devices - there is no mechanism by which we can use this app upload for PO devices, as the work profile can only receive the app installs from the Google Play services.
Nothing has changed with this workflow as of 10.76, but as we move further and further away from Device Admin being a viable management option, I suspect it will get used less and less as DA transitions over to AE. Google has also hinted that we could see the end of instant install support for any apps that do not come from the Play channel in some fashion, which is a nice segue in to.......
Private Channel Apps
In its first iteration, private channel apps were a source of great frustration for many admins handling MAM for AE. They were required for enterprise app installation on PO devices, but the process of making the apps available was a lot to take in for clients, many of whom have no experience in the Play console outside the end-user experience.
It required that the app be uploaded to the Play store using standard developer workflows, which meant filling out a lot of information that many companies found irrelevant to the process they were implementing, marking the app as private (to exclude it from a public Play listing), and finally whitelisting the organizational ID of the account bound to MaaS360 in the AE setup.
With 10.76, MaaS360 has updated our iFrame implementation to remove almost all of the burden of the processes to make things as easy as possible for supporting private channel apps. Now, in just a few steps (no development account required), they can be uploaded directly via the MaaS360 portal. There are still some caveats:
- Package ID must still be unique to the Play store - meaning the app ID (looks something like com.appname.identifiers) must be unique and can not be the same as any existing Play apps. This means apps coming from third parties need to be compiled with a unique name for each client to whom they distribute.
- App must be properly signed - it has to include the same keystore that would be used to validate it for public Play access.
- App can only be distributed to devices enrolled in the MaaS360 portal. There is no option with this upload feature to share with external organizations.
- Only works with DO/PO - DA enrolled devices will require the old enterprise app workflows. This means potentially having to manage the same app via 2 different workflows.
To upload, simply select the Private Channel option for Apps, and follow the on-screen steps.
Please note: Workflows are in an iFrame window and sometimes this requires a bit of scrolling to see items that are outside of the window.
Potential errors on upload:
- Upload a new APK with a different package name - the app ID must be unique and can not match any other existing Play applications.
- APK is not zip aligned - the package is not properly signed for upload to the Play channel.
Once apps are uploaded they will be displayed on the Private Channel page with each subsequent login. Select the "+" to add more, or select an individual app for distribution (
the app will not appear on the app catalog page until this step is completed and the app has been "added").
More details can be added to the listing using the Play console via MaaS360 (
Note: admins will need to login to the Play console with the email address used in the AE bind in MaaS360 setup. Oftentimes when using Chrome for this workflow the store will auto-login using the credentials associated with the browser. If this happens, the private channel apps will not be visible).
Once the application distribution is complete it will appear in the app catalog alongside all other apps.
What about Private Apps whitelisted to the account via direct Play upload?
In scenarios where the organization ID has been whitelisted for a private app (usually by a third party) admins will use the public app workflows and just search the app ID.
Web AppsWeb apps have, until this point, been a mixed bag for AE managed devices. In PO especially they were troublesome because they had to be launched from the app catalog on the device, there was no shortcut. The iFrame enhancements in 10.76 have fixed this problem, and Web Apps (or web clips as we sometimes call them) can now be added with a workflow similar to the private apps. From the Android app catalog settings, simply choose "Webapp for Android Enterprise" (
Note: the generic Web App item can still be used for DA management).
Simply follow the on-screen prompts (very similar to private app workflows) to create the webapp, then select it from the listing to distribute and properly add to the app catalog.
Note: The option to upload an icon is optional. If one is not uploaded it will use a generic Android icon.
The web app will be listed as a "Private App For Android" and will not appear if you sort the catalog page by "Web Apps" it must be located as a "Private App For Android Enterprise"
ConclusionThe road to the point at which we currently reside in regards to Android app management has been a long one. We're still seeing low adoption percentages for Android Enterprise, even among clients who are deploying devices running the more current OS version. App management has had a lot to do with keeping clients from diving in to the deep end, but I'm hopeful that these enhancements will change that, and give organizations the push they need to move forward. My personal recommendation has always been to deploy AE to any devices on 8.0 or higher, no matter the perceived or actual limitations. That has not been the case though, and I see a lot of companies shooting themselves in the foot (idiomatically, of course) in regards to future-proofing their Android systems and management.
Android Enterprise can seem like a mountain compared to Device Admin management, but I can assure everyone that it is just a hill, and one that can easily be climbed by anyone - technical or not. The first plan of action, at the very least, should be to enable the feature in the portal, even if deployment isn't in the foreseeable future.
Setup>Services>Mobile Device Management. Most clients will be using the "Managed Google Play" option as all it requires is a gmail account (do not user a personal account - a common shortcut that can have drastic repercussions down the road). For more information around getting setup and started, visit our
Knowledge Center for implementation content, or our
Ongoing Product Education page for webinars and quickstart guides.