Let's look at setting up an app protection policy within the Microsoft endpoint manager admin center. Go to the apps page and select app protection policies. I'm going to create a protection policy for an app on the Android platform, so I'll select Android from the create policy drop-down button. Give the policy a name and description, and we can see Android is the selected platform.

On the Apps page, we can target apps on all device types, which is what I'll go with, or you can target specific device types. Protection policies target a user's identity rather than their device, so we don't know the specific device the policy will be applied to. Devices can be managed as in enrolled, which can be subcategorized into additional device types, or unmanaged as in BYOD. You can create different protection policies based on device type. For instance, an app protection policy for a managed device could have more relaxed data protection controls than an unmanaged device because you generally have more control over the device and, therefore, the app's environment. 

Next, we choose the apps the policy will target. I'll leave it on selected apps and then select a public app or three. With the usual office suspects selected, let's set up data protection. Data protection lets us specify where the apps' data can be saved or moved.  We can override Android backup services and set valid save locations, as well as specifying how organizational data can be shared between apps. For example, you could allow sharing a document between Outlook and Word, but not transferring it to DropBox. We can restrict data exchange between apps, including copying and pasting. You can even prevent capturing data with screenshots. Organizational data can be encrypted, printing controlled, and web content restricted.

Access requirements allow you to customize authentication for accessing the apps in the form of a PIN, although you can override the PIN with biometrics. I think it would be fair to describe access configuration as comprehensive. I'll set the minimum PIN length to 6, not allow biometrics, set the PIN to be reset after 60 days, retain the last five PINs, and require work or school account credentials. 

Conditional launch lets us set a number of parameters with corresponding actions related to accessing or attempting to access the app. We can specify what happens after a number of incorrect PIN attempts are made. The offline grace period says we can work with the app's data for up to 12 hours or 720 minutes without authenticating with Azure AD. After 90 days without authentication, the app's data will be wiped. There are a variety of device conditions we can create actions for, starting with what happens if the app is run on a jailbroken or rooted device.  

Once the policy has been configured, we can deploy it, assigning it to a user group. You can refine the policy target by specifying which user groups to exclude if needed. Finally, review and create the app protection policy.