android-Building Apps for Work,Ensuring Compatibility with Managed Profiles

The Android framework provides features to support the security, data separation, and administration needs of a enterprise environment.

 Learn how to make your app function smoothly in corporate environments that restrict device features and data access. Go further to support enterprise use of your app by enabling restrictions that corporate technology administrators can use to remotely configure your app.

>Ensuring Compatibility with Managed Profiles

 If the user can use their own device, the enterprise has to worry that confidential information (like employee emails and contacts) are on a device the enterprise does not control.To address this situation, Android 5.0 (API level 21) allows enterprises to set up managed profiles. If a device has a managed profile, the profile's settings are under the control of the enterprise administrator. 

 If a device has a managed profile, there are implications for apps running on the device, no matter which profile the app is running under:

• By default, most intents do not cross from one profile to the other. If an app running on profile fires an intent, there is no handler for the intent on that profile, and the intent is not allowed to cross to the other profile due to profile restrictions, the request fails and the app may shut down unexpectedly.
• The profile administrator can limit which system apps are available on the managed profile. This restriction can also result in there being no handler for some common intents on the managed profile.
• Since the managed and unmanaged profiles have separate storage areas, a file URI that is valid on one profile is not valid on the other. Any intent fired on one profile might be handled on the other (depending on profile settings), so it is not safe to attach file URIs to intents.

> On a device with a managed profile, there are restrictions on whether intents can cross from one profile to another. The profile administrator can choose which intents are allowed to cross from one profile to another. 

 if your app needs to set timers, it would need to check that there's a valid handler for theACTION_SET_TIMER intent. If the app cannot resolve the intent, it should take an appropriate action (such as showing an error message).

public void startTimer(String message, int seconds) {

    // Build the "set timer" intent
    Intent timerIntent = new Intent(AlarmClock.ACTION_SET_TIMER)
            .putExtra(AlarmClock.EXTRA_MESSAGE, message)
            .putExtra(AlarmClock.EXTRA_LENGTH, seconds)
            .putExtra(AlarmClock.EXTRA_SKIP_UI, true);

    // Check if there's a handler for the intent
    if (timerIntent.resolveActivity(getPackageManager()) == null) {

        // Can't resolve the intent! Fail this operation cleanly
        // (perhaps by showing an error message)

    } else {
        // Intent resolves, it's safe to fire it off
        startActivity(timerIntent);

    }
}

> There are two ways you would ordinarily share a file: with afile URI or a content URI.

A file URI begins with the file: prefix, followed by the absolute path of the file on the device's storage. However, because the managed profile and the personal profile use separate storage areas, a file URI that is valid on one profile is not valid on the other. This situation means that if you attach a file URI to an intent, and the intent is handled on the other profile, the handler is not able to access the file.

Instead, you should share files with content URIs. Content URIs identify the file in a more secure, shareable fashion. The content URI contains the file path, but also the authority that provides the file, and an ID number identifying the file. You can generate a content ID for any file by using a FileProvider. You can then share that content ID with other apps (even on the other profile). The recipient can use the content ID to get access to the actual file.

// Open File object from its file URI
File fileToShare = new File(fileUriToShare);

Uri contentUriToShare = FileProvider.getUriForFile(getContext(),
        "com.example.myapp.fileprovider", fileToShare);

We have provided a sample app, BasicManagedProfile, which you can use to set up a managed profile on an Android device that runs Android 5.0 (API level 21) and higher. This app offers you a simple way to test your app in a managed-profile environment. You can also use this app to configure the managed profile as follows:

• Specify which default apps are available on the managed profile
• Configure which intents are allowed to cross from one profile to the other

 There are a few tricks that you may find helpful in testing on a managed-profile device.

• As noted, when you side-load an app on a managed profile device, it is installed on both profiles. If you wish, you can delete the app from one profile and leave it on the other.
• Most of the activity manager commands available in the Android Debug Bridge (adb) shell support the --user flag, which lets you specify which user to run as. By specifying a user, you can choose whether to run as the unmanaged or managed profile. For more information, see ADB Shell Commands.
• To find the active users on a device, use the adb package manager's list users command. The first number in the output string is the user ID, which you can use with the --user flag. For more information, seeADB Shell Commands.