Force Android applications like Google Chrome to update in a zero-day/bug-fix/new-feature scenario with Workspace ONE
There is a real and immediate need for every organization to be able to quickly react to zero-day vulnerabilities or new application releases with features requiring immediate and precise cut-overs. The threat landscape is wider than ever, while the frequency of new application builds in a world of CI/CD pipelines decreases from days to hours; and everything supporting the business has exacting requirements that need to be met.
Workspace ONE and the EUC product line-up is really well equipped to handle any digital workspace use case on any major platform. When you offer all that with API's to manage identity, access management and secure edge services; you have API's for everything to provide secure remote access to resources. What has been interesting to watch over the years is the utility, broad-appeal, varied-price points and proven capabilities of the Android OS. As the OS has matured from the era of Jelly Bean, KitKat and Lollipop; the number of use cases supported by Google devices surprises even the most seasoned veterans in tech. Let the numbers speak for themselves...
It has been almost one year since Google I/O 2019, where Stephanie Cuthbertson shared 2.5 billion Android devices were in use world wide. To put this in perspective, there are more devices running Android than iOS, macOS, and Windows 10 combined. Need a positive thought to dwell on? Think of the electricity savings realized by moving use cases to a platform like Android. Where the SoC chipset consumes 5 watts of power, while the OS packs in energy-saving features such as Doze and App Standby.
https://news.microsoft.com/bythenumbers/en/windowsdevices
https://www.theverge.com/2019/5/7/18528297/google-io-2019-android-devices-play-store-total-number-statistic-keynote
https://www.theverge.com/2019/1/29/18202736/apple-devices-ios-earnings-q1-2019
Power savings are great, but for adoption to continue to expand and use cases to succeed; we need to show real, demonstrable examples of how to manage Android Enterprise applications at scale. It really isn’t a question of if you will have a need to immediately update a fleet of devices, but rather how prepared are you to do this?
There is a large Android Enterprise use case that presented the opportunity to solve this. Start with some context; we’re looking at forcibly updating public Android applications enrolled in Android Enterprise. We want to install them at a specific time that satisfies our business requirements.
Workspace ONE UEM offers an assortment of REST API endpoints that allow us to accomplish a variety of tasks including an API Endpoint with the ability to update purchased Apple (e.g. Apple Business Manager, formerly Volume Purchase Program (VPP)) applications. But don’t mix this API Endpoint with the API endpoint to install/update public applications like those from Google Play.
We see above that we have to POST an HTTP Message with a body that must contain one of the four key/value pairs. In this example I will use the deviceID. The API Endpoint URL requires a parameter to be specified for the application ID. To get the devices assigned to an application ID, we provide the app ID in the parameter of the API Endpoint URL. This is the numeric value of the public application from Workspace ONE UEM. To locate your public application ID's; navigate to; Apps & Books -> Native -> Public
Hover your mouse over the application and then look for the URL to appear with the application ID in the lower left corner or click on the application and look in the Address Bar for the ID.
Application ID, check. Let's get some deviceID's assigned to the application now. We can make another API call to /mam/apps/public/{applicaitonid}/devices to get the deviceID's and store them in an object in Powershell. We can grab the devices assigned to Google Chrome with the snippet of code included below;
In the HTTP Response Body for this API, you will have deviceID's returned in JSON like you see below;
Device ID, check. You store both the device ID's assigned to each respective application ID in an object in Powershell or Python, and then post a series of API calls with the device ID's stored in JSON in the HTTP request body to the API endpoint at /mam/apps/public/{applicationid}/install.
Workspace ONE UEM calls the Google Play EMM API for each of your respective deviceID's, and forces an over-the-air (local Wi-Fi, 3G/4G/5G, wired ethernet) install/update of the application to the currently published version in the Google Play Store. Important to note: this does not work in air-gapped/offline scenarios, or scenarios where the Google Play Store is not enabled or available (e.g. AOSP without Google Play Store, or devices from manufacturers lacking licensing from Google Mobile Services, e.g Huawei, or custom-built hardware). If your device does not have Google Play Store enabled at the time the API call is made; Workspace ONE UEM will not know the Google Device ID of your device, and the device will not be able to receive the request to forcibly update the application.
The curl command would look like this for a single device; but with the appropriate basic credentials, or OAuth 2.0 token (supported in newer Workspace ONE UEM versions). Your aw-tenant-code would also contain the appropriate API key that is scoped to access the resources.
Once you send the HTTP Request to the API Endpoint above, a series of events will occur. Each event is covered in sequential order below;
Looking at a Powershell script to get you started. This will force a public application to install or update on a fleet of devices assigned to application ID 223, this is Google Chrome in my scenario. You could run this Powershell script in Task Scheduler at a specific time.
Mahalo,
Ryan Pringnitz
Workspace ONE and the EUC product line-up is really well equipped to handle any digital workspace use case on any major platform. When you offer all that with API's to manage identity, access management and secure edge services; you have API's for everything to provide secure remote access to resources. What has been interesting to watch over the years is the utility, broad-appeal, varied-price points and proven capabilities of the Android OS. As the OS has matured from the era of Jelly Bean, KitKat and Lollipop; the number of use cases supported by Google devices surprises even the most seasoned veterans in tech. Let the numbers speak for themselves...
It has been almost one year since Google I/O 2019, where Stephanie Cuthbertson shared 2.5 billion Android devices were in use world wide. To put this in perspective, there are more devices running Android than iOS, macOS, and Windows 10 combined. Need a positive thought to dwell on? Think of the electricity savings realized by moving use cases to a platform like Android. Where the SoC chipset consumes 5 watts of power, while the OS packs in energy-saving features such as Doze and App Standby.
https://news.microsoft.com/bythenumbers/en/windowsdevices
https://www.theverge.com/2019/5/7/18528297/google-io-2019-android-devices-play-store-total-number-statistic-keynote
https://www.theverge.com/2019/1/29/18202736/apple-devices-ios-earnings-q1-2019
Power savings are great, but for adoption to continue to expand and use cases to succeed; we need to show real, demonstrable examples of how to manage Android Enterprise applications at scale. It really isn’t a question of if you will have a need to immediately update a fleet of devices, but rather how prepared are you to do this?
There is a large Android Enterprise use case that presented the opportunity to solve this. Start with some context; we’re looking at forcibly updating public Android applications enrolled in Android Enterprise. We want to install them at a specific time that satisfies our business requirements.
Public Applications in Android Enterprise are easily managed by Workspace ONE UEM. Behind the scenes you will see that that the Workspace ONE UEM API's interact with the Google's Play EMM API. We will cover the Play EMM API more in an upcoming post, but in this post we'll cover how we can interact with Play EMM using Workspace ONE UEM API's.
Let's get to it...what are the API endpoints?
Let's get to it...what are the API endpoints?
| HTTP Verb | Workspace ONE UEM API Endpoint | HTTP Request Message Body |
|---|---|---|
| POST | /mam/apps/public/{applicationid}/install | { "DeviceId": 1, "Udid": "6bf0f04c73681fbecfc3eb4f13cbf05b", "SerialNumber": "LGH871c18f631a", "MacAddress": "0x848506B900BA" } |
| GET | /mam/apps/public/{applicationid}/devices | (no request payload, specify application ID in HTTP URL parameter) |
We see above that we have to POST an HTTP Message with a body that must contain one of the four key/value pairs. In this example I will use the deviceID. The API Endpoint URL requires a parameter to be specified for the application ID. To get the devices assigned to an application ID, we provide the app ID in the parameter of the API Endpoint URL. This is the numeric value of the public application from Workspace ONE UEM. To locate your public application ID's; navigate to; Apps & Books -> Native -> Public
Hover your mouse over the application and then look for the URL to appear with the application ID in the lower left corner or click on the application and look in the Address Bar for the ID.
 |
| Tunnel is application ID 192 |
 |
| Google Chrome ID 223 |
Application ID, check. Let's get some deviceID's assigned to the application now. We can make another API call to /mam/apps/public/{applicaitonid}/devices to get the deviceID's and store them in an object in Powershell. We can grab the devices assigned to Google Chrome with the snippet of code included below;
In the HTTP Response Body for this API, you will have deviceID's returned in JSON like you see below;
Device ID, check. You store both the device ID's assigned to each respective application ID in an object in Powershell or Python, and then post a series of API calls with the device ID's stored in JSON in the HTTP request body to the API endpoint at /mam/apps/public/{applicationid}/install.
Workspace ONE UEM calls the Google Play EMM API for each of your respective deviceID's, and forces an over-the-air (local Wi-Fi, 3G/4G/5G, wired ethernet) install/update of the application to the currently published version in the Google Play Store. Important to note: this does not work in air-gapped/offline scenarios, or scenarios where the Google Play Store is not enabled or available (e.g. AOSP without Google Play Store, or devices from manufacturers lacking licensing from Google Mobile Services, e.g Huawei, or custom-built hardware). If your device does not have Google Play Store enabled at the time the API call is made; Workspace ONE UEM will not know the Google Device ID of your device, and the device will not be able to receive the request to forcibly update the application.
The curl command would look like this for a single device; but with the appropriate basic credentials, or OAuth 2.0 token (supported in newer Workspace ONE UEM versions). Your aw-tenant-code would also contain the appropriate API key that is scoped to access the resources.
Once you send the HTTP Request to the API Endpoint above, a series of events will occur. Each event is covered in sequential order below;
- Workspace ONE UEM retrieves a short-lived OAuth 2.0 token explicitly scoped to for the Google Play EMM API for your enterprise ID.
- Workspace ONE UEM retrieves the GoogleDeviceID and GoogleUserID for each Workspace ONE UEM device ID specified in the HTTP Request body in the /mam/apps/public/{applicationid}/install API call
- Google Play EMM API sends an EMM notification to the Android device in a pub/sub manner
More details at; https://developers.google.com/android/work/play/emm-api/about-notifications - If the device is powered on, provided outbound/inbound network connectivity, and Google Play is enabled on the device; an over-the-air update occurs
More details about network firewall requirements at; https://static.googleusercontent.com/media/www.android.com/en//static/2016/pdfs/enterprise/Android-Enterprise-Migration-Bluebook_2019.pdf - Application installation process is requested on device, with Workspace ONE environment logs displaying Install Application Requested
- The install command to install the APK is provided
- The device returns a response to the Workspace ONE environment stating the installation is pending
- Package verification verifies application is signed properly by developer
- SafetyNet Verify optionally verifies apk is not potentially harmful application
https://android-developers.googleblog.com/2017/09/safetynet-verify-apps-api-google-play.html - APK installation occurs, upon completion, logs in Workspace ONE update to display the installation is confirmed.
- Application sample from device returns a response to the Workspace ONE environment stating the installation is complete
Post install request, it takes less than one minute to complete the task.
Things to consider;
- Google briefly caches the EMM notification request for a device, but not for a length of time that can be relied upon to deliver compliance if the device is offline.
- Devices currently using the application being updated will close the application before proceeding with the installation
- If your use case requires an activity to be launched and running in the foreground to display a user interface (e.g. inflight entertainment software, point-of-sale software, electronic billboard display, etc); consider broadcasting an explicit intent of android.intent.action.MAIN to the desired Android activity after completing the update. Or using Workspace ONE Launcher in single app mode, with Launcher pinned to the foreground.
- The device reports the results back in near real time to the console troubleshooting logs
- Syncing the device from the console or from the Workspace ONE UEM API will force the device to upload results back to the console
Ryan Pringnitz
Comments
Post a Comment