Developing Android for Work apps

- [Instructor] Android for Work is Google's offering for enterprise security. It provides the distinction between personal and enterprise apps and data and leverages some of the Samsung Knox architecture to deliver additional security. There are three key features to improve security for an enterprise device: managed profiles, managed configurations, and enforcement of single-purpose devices. Managed profiles were introduced in Android 5.0 Lollipop.

That's API 21. Which allows profile settings to be managed by an enterprise administrator. This allows control of both the apps which can run and the device features which can be used. Managed profiles also, by default, do not permit intents to cross profile boundaries, and any attempt to do so will cause the activity to fail. Apps strict check whether an intent can be handled using the Resolve Activity method, and where required define explicit permissions to enable intents to cross profiles.

The managed profile is provisioned by the device administrator. Let's look at a snippet of code from a managed service provider. The code firstly checks that it's starting up fresh and if so gets the policy manager configuration. If the managed profile is already set up, then the main screen is displayed. Otherwise the app enters setup mode. Here we see the profile, having been set up, being provisioned via an intent. Another security feature for the enterprise is managed configurations, previously known as application restrictions.

This feature allows the administrator to use his or her central mobile device management console to manage the settings for a device app. For example, whitelisting or blacklisting URLs for a web browser, controlling the use of cellular data for syncing, and managing email settings. An app's managed configurations are defined in its managed configurations file, and this is declared in the manifest. A managed configuration provider app runs on the same device and is used by the device administrator to change configurations.

Here's an example of checking whether cellular data downloading is allowed. The app restrictions file is declared in the manifest, and the file itself will appear in the resources XML folder. We can see that the default value is set to true. An application can check the configuration setting by retrieving the app restrictions key download on cellular. Apps should check the restrictions manager object and adjust their processing to the managed configuration when they start and also on resuming after pausing.

In addition, long-running apps may also need to listen for a notification of configuration change while they're active. This snippet shows how to dynamically register a broadcast receiver for a configuration change and to reread the application restrictions. The third feature for enterprises, introduced in Android 6.0 Marshmallow, is to enable provisioning of single-purpose devices. These are devices which boot up to a single app and cannot escape from it. This is achieved by two features: app pinning, which brings up an app and temporarily locks it onto the screen, and locked task mode, which removes the ability of the user to escape from the app.

Together, an app will stay permanently on the screen and the device will be dedicated to single use. Additional capabilities available through Android at Work include the capability for administrators to specify what apps can be loaded into the work container, silently add and remove apps, and to restrict copy and paste and screen capture to protect against data loss. We've just looked at the basics of developing Android enterprise apps. There's much more detail available on developing Android for Work in the Android developer site as shown.