Using Product Provisioning in Workspace ONE to deliver intents to Android devices and perform tasks like activating Zimperium zIPS
Friday the 13th, 2020 has come and gone, and what a week it was. Everyday we should be thankful, but this week I am especially thankful; thankful for health, thankful for my colleagues, team-mates, teachers, friends and mentors I get to work with and learn from everyday - even remotely. It is a honor to be able to collaborate on projects that push the envelope, and work with people who selflessly share their time and knowledge. Weeks like this remind me to appreciate the small things, encourages me to be more generous, and look for more ways to help others.
I am thankful for everyone who does their part to make the world we all have come to appreciate, a better place. We might not have everything we want, but we can keep working toward our goals. Join me in being thankful, and looking for more ways to help where you can.
The labor force is shifting in unprecedented ways this week, with class-A office space traded for makeshift offices - or makeshift medical facilities. We all have a role to play in making sure the services and products required to make the economy function are available - and working.
The digital workspace is varied; with use cases solving problems that didn’t exist 3 months or 3 years ago. For you to get to Hawaii safely, you might run in to a few devices along the way. Ticket scanners, kiosks, in-flight entertainment, digital signage. And the information displayed, or the applications in use won’t always be the same. They may change daily, hourly, and you don’t even realize it. Automating actions that could require user input on remote Android devices makes things a bit easier. Maybe you need to update the application - and start the application. We covered this at a high-level with Zimperium zIPS previously, but lets look at how to do this with other examples that allow us to look at a code sample. But before that, cue the mood boosting visuals...
On with the show; let's take a look at how to unlock some under-appreciated capabilities in Workspace ONE. It just might help you deliver services that people really depend on more than ever today.
In a prior blog post we covered how to secure mobile devices by delivering a mobile threat detection and response product by Zimperium called zIPS. What we did not cover in detail was how zIPS could be delivered and activated on devices in various power states. Android OS's native power saving capabilities (app standby and doze mode) allow us to get the battery life we demand, but these features do not have to come at the expense of security or your patience during a maintenance window.
If your maintenance window provides a window to communicate with devices that are idle, with the display off, or even unplugged from a power source; you need a tactical approach to accomplish this, and the ability communicate with them reliably during this window. Even if the device is being used, you will find the Android OS is actively putting individual applications in battery conserving states like app standby, or even the device itself with doze mode.
For more on how Android OS defers network communication and conserves battery life; I have included links below covering Doze Mode, App Standby, and Wakelocks below.
https://developer.android.com/training/monitoring-device-state/doze-standby
https://developer.android.com/training/scheduling/wakelock
https://youtu.be/Rwshwq_vI1s - Joanna Smith, Google, App Standby vs Doze: Understanding System Sleep (Big Android BBQ 2015)
https://youtu.be/p6ZiDZBgPY8 - Joanna Smith, Google, App Standby vs Doze: Understanding System Sleep (Android Dev Summit 2015)
Workspace ONE UEM overcomes these challenges by leveraging Google's recently introduced Firebase Cloud Messaging (FCM). When you send a product with Workspace ONE and communicate with 50,000 or 500,000 devices; you have the power of a high-priority FCM message going to your devices. High-priority FCM messages are sent to any Android device it is intended for, even if it means turning on the wireless radio (e.g. cellular wireless (3G/4G/5G) or Wi-Fi (802.11)).
Workspace ONE UEM's adoption of FCM allows us to have confidence in our ability to communicate with our devices. This is worth writing about, sharing, and demonstrating. This gives us the ability to provide a zero-touch solution when delivering mobile security products such as Zimperium zIPS to devices in various power states. But this ability with product provisioning to send intents has other use cases it can assist with. Let’s walk through the flow in the Zimperium zIPS use case, and then demonstrate this with a custom application that we can show the source code in - so you can apply this to more use cases of your own.
When we deliver an application that has not had its services started in the background or foreground; we need a little help from Workspace ONE to activate Zimperium's zIPS. Product Provisioning in Workspace ONE is able to deliver high-priority FCM messages. A high-priority FCM gives us the capability to wake up the device from any power state (except devices powered off) and complete the prescribed tasks. With zIPS; the zIPS application has an intent explicitly sent by Product Provisioning. When we send this explicit intent after installation; we tell the device to start the Zimperium zIPS activity. This allows zIPS to start its own pub/sub messaging service on the device.
zIPS receives the intent, and starts the necessary services locally on the device. Workspace ONE provides the managed configuration for the application which tells the zIPS application where to direct the activation request. The device sends outbound network traffic destined for the Zimperium zConsole. As soon as activation occurs, the device is offered protection from mobile threats with the zIPS mobile threat detection and response engine. zIPS works in conjunction with Workspace ONE UEM as Device Owner (in Android Enterprise Work Managed use cases) to carry out threat remediation responses configured in Zimperium & Workspace ONE.
Your use case could differ slightly, but solved in a similar manner. If your use case requires an intent; you can use Workspace ONE UEM's Product Provisioning capabilities. For more details on Product Provisioning in Workspace ONE, see the PDF below.
https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/1903/WS1_ProdProv_for_Android.pdf
Let's look at an example of how intents work with product provisioning.
In the screenshot above, you see a screenshot of Android Studio, and one of the core-components in an Android application, AndroidManifest.xml. In the AndroidManifest.xml file you can find all the services, activities, content providers, receivers and intent-filters. Intent-filters tell your application what broadcasts to listen to from the Android OS. If there are multiple applications listening for the same intent; and the intent is broadcast implicitly, the user can be presented with the choice of which application to perform the action with. We prefer the best user experience without interruptions, and should try to use explicit intents where possible.
Q: So we broadcast an intent to what?
A: To either an activity or service.
Q: To do what?
A: Start something, a service or activity
Q: What is an activity?
A: The activity presents the view that your users interact with.
Take a look below at the demo application below. Android Studio is showing what we view in applications activity. If we want to bring this activity to the foreground, we would send an intent with Workspace ONE Product Provisioning.
If we wanted to open Chrome, we would send an intent of android.intent.action.MAIN to the activity of apps.chrome.Main. This activity is inside of the Android component, or bundle ID of com.android.chrome. So in the example above, if we wanted to remotely launch the 'Commercial Real Estate Services' application; we would use the following line in our product.
Let's give it a try with our demo application and see how it works in a different use case. We'll create a 'File/Actions' component called 'Molokai - Foreground Activity', add the intent you see below in the product manifest. Then create a product in Product Provisioning, and deliver it.
I am thankful for everyone who does their part to make the world we all have come to appreciate, a better place. We might not have everything we want, but we can keep working toward our goals. Join me in being thankful, and looking for more ways to help where you can.
The labor force is shifting in unprecedented ways this week, with class-A office space traded for makeshift offices - or makeshift medical facilities. We all have a role to play in making sure the services and products required to make the economy function are available - and working.
The digital workspace is varied; with use cases solving problems that didn’t exist 3 months or 3 years ago. For you to get to Hawaii safely, you might run in to a few devices along the way. Ticket scanners, kiosks, in-flight entertainment, digital signage. And the information displayed, or the applications in use won’t always be the same. They may change daily, hourly, and you don’t even realize it. Automating actions that could require user input on remote Android devices makes things a bit easier. Maybe you need to update the application - and start the application. We covered this at a high-level with Zimperium zIPS previously, but lets look at how to do this with other examples that allow us to look at a code sample. But before that, cue the mood boosting visuals...
 |
| Hawaii still has plenty of aloha to share |
 |
| This little goober is still willing to flash a smile |
 | |
|
 |
| And today my solar array surpassed 4 Megawatt hours of production, with my SolarEdge inverter reporting over 6,200 lbs of CO2 emissions saved from the atmosphere. Fun fact: the second Friday in March is solar appreciation day. |
In a prior blog post we covered how to secure mobile devices by delivering a mobile threat detection and response product by Zimperium called zIPS. What we did not cover in detail was how zIPS could be delivered and activated on devices in various power states. Android OS's native power saving capabilities (app standby and doze mode) allow us to get the battery life we demand, but these features do not have to come at the expense of security or your patience during a maintenance window.
If your maintenance window provides a window to communicate with devices that are idle, with the display off, or even unplugged from a power source; you need a tactical approach to accomplish this, and the ability communicate with them reliably during this window. Even if the device is being used, you will find the Android OS is actively putting individual applications in battery conserving states like app standby, or even the device itself with doze mode.
For more on how Android OS defers network communication and conserves battery life; I have included links below covering Doze Mode, App Standby, and Wakelocks below.
https://developer.android.com/training/monitoring-device-state/doze-standby
https://developer.android.com/training/scheduling/wakelock
https://youtu.be/Rwshwq_vI1s - Joanna Smith, Google, App Standby vs Doze: Understanding System Sleep (Big Android BBQ 2015)
https://youtu.be/p6ZiDZBgPY8 - Joanna Smith, Google, App Standby vs Doze: Understanding System Sleep (Android Dev Summit 2015)
Workspace ONE UEM overcomes these challenges by leveraging Google's recently introduced Firebase Cloud Messaging (FCM). When you send a product with Workspace ONE and communicate with 50,000 or 500,000 devices; you have the power of a high-priority FCM message going to your devices. High-priority FCM messages are sent to any Android device it is intended for, even if it means turning on the wireless radio (e.g. cellular wireless (3G/4G/5G) or Wi-Fi (802.11)).
Workspace ONE UEM's adoption of FCM allows us to have confidence in our ability to communicate with our devices. This is worth writing about, sharing, and demonstrating. This gives us the ability to provide a zero-touch solution when delivering mobile security products such as Zimperium zIPS to devices in various power states. But this ability with product provisioning to send intents has other use cases it can assist with. Let’s walk through the flow in the Zimperium zIPS use case, and then demonstrate this with a custom application that we can show the source code in - so you can apply this to more use cases of your own.
When we deliver an application that has not had its services started in the background or foreground; we need a little help from Workspace ONE to activate Zimperium's zIPS. Product Provisioning in Workspace ONE is able to deliver high-priority FCM messages. A high-priority FCM gives us the capability to wake up the device from any power state (except devices powered off) and complete the prescribed tasks. With zIPS; the zIPS application has an intent explicitly sent by Product Provisioning. When we send this explicit intent after installation; we tell the device to start the Zimperium zIPS activity. This allows zIPS to start its own pub/sub messaging service on the device.
zIPS receives the intent, and starts the necessary services locally on the device. Workspace ONE provides the managed configuration for the application which tells the zIPS application where to direct the activation request. The device sends outbound network traffic destined for the Zimperium zConsole. As soon as activation occurs, the device is offered protection from mobile threats with the zIPS mobile threat detection and response engine. zIPS works in conjunction with Workspace ONE UEM as Device Owner (in Android Enterprise Work Managed use cases) to carry out threat remediation responses configured in Zimperium & Workspace ONE.
Your use case could differ slightly, but solved in a similar manner. If your use case requires an intent; you can use Workspace ONE UEM's Product Provisioning capabilities. For more details on Product Provisioning in Workspace ONE, see the PDF below.
https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/1903/WS1_ProdProv_for_Android.pdf
Let's look at an example of how intents work with product provisioning.
In the screenshot above, you see a screenshot of Android Studio, and one of the core-components in an Android application, AndroidManifest.xml. In the AndroidManifest.xml file you can find all the services, activities, content providers, receivers and intent-filters. Intent-filters tell your application what broadcasts to listen to from the Android OS. If there are multiple applications listening for the same intent; and the intent is broadcast implicitly, the user can be presented with the choice of which application to perform the action with. We prefer the best user experience without interruptions, and should try to use explicit intents where possible.
Q: So we broadcast an intent to what?
A: To either an activity or service.
Q: To do what?
A: Start something, a service or activity
Q: What is an activity?
A: The activity presents the view that your users interact with.
Take a look below at the demo application below. Android Studio is showing what we view in applications activity. If we want to bring this activity to the foreground, we would send an intent with Workspace ONE Product Provisioning.
If we wanted to open Chrome, we would send an intent of android.intent.action.MAIN to the activity of apps.chrome.Main. This activity is inside of the Android component, or bundle ID of com.android.chrome. So in the example above, if we wanted to remotely launch the 'Commercial Real Estate Services' application; we would use the following line in our product.
Let's give it a try with our demo application and see how it works in a different use case. We'll create a 'File/Actions' component called 'Molokai - Foreground Activity', add the intent you see below in the product manifest. Then create a product in Product Provisioning, and deliver it.
- In the console, navigate to Devices -> Provisioning -> Components -> Files/Actions
- Click 'Add Files/Actions' and in the new window that opens, click 'Android'
- Name the Files/Actions appropriately
- Click 'Manifest', followed by 'Add Action'
- In the 'Command Line and Arguments to run' form field, enter the intent you see in the Gist snippet below
- Specify a timeout value of -1 and click 'Save'
- In 'Provisioning', click 'Product List View' followed by 'Add Product' and select 'Android'
- Name the product appropriately, assign it to the appropriate smart group
- Click 'Manifest' followed by 'Add'
- In the 'Actions to Perform' drop-down, select 'Install Files/Actions'
- Select your File/Action event you just created and click 'Save'
- Click 'Activate' followed by 'Activate' in the next window that appears
In upcoming blog posts, we'll look at how to bring Workspace ONE Launcher in to the equation.
Mahalo,
Ryan Pringnitz
Song of the day: Odesza - Don't Stop
Comments
Post a Comment