Your shopping cart is empty!
Android 2.2 introduces support for enterprise applications by offering the Android Device Administration API. The Device Administration API provides device administration features at the system level. These APIs allow you to create security-aware applications that are useful in enterprise settings, in which IT professionals require rich control over employee devices. For example, the built-in Android Email application has leveraged the new APIs to improve Exchange support. Through the Email application, Exchange administrators can enforce password policies — including alphanumeric passwords or numeric PINs — across devices. Administrators can also remotely wipe (that is, restore factory defaults on) lost or stolen handsets. Exchange users can sync their email and calendar data.
This document is intended for developers who want to develop enterprise solutions for Android-powered devices. It discusses the various features provided by the Device Administration API to provide stronger security for employee devices that are powered by Android.
Here are examples of the types of applications that might use the Device Administration API:
You use the Device Administration API to write device admin applications that users install on their devices. The device admin application enforces the desired policies. Here's how it works:
If users do not enable the device admin app, it remains on the device, but in an inactive state. Users will not be subject to its policies, and they will conversely not get any of the application's benefits—for example, they may not be able to sync data.
If a user fails to comply with the policies (for example, if a user sets a password that violates the guidelines), it is up to the application to decide how to handle this. However, typically this will result in the user not being able to sync data.
If a device attempts to connect to a server that requires policies not supported in the Device Administration API, the connection will not be allowed. The Device Administration API does not currently allow partial provisioning. In other words, if a device (for example, a legacy device) does not support all of the stated policies, there is no way to allow the device to connect.
If a device contains multiple enabled admin applications, the strictest policy is enforced. There is no way to target a particular admin application.
To uninstall an existing device admin application, users need to first unregister the application as an administrator.
In an enterprise setting, it's often the case that employee devices must adhere to a strict set of policies that govern the use of the device. The Device Administration API supports the policies listed in Table 1. Note that the Device Administration API currently only supports passwords for screen lock:
Table 1. Policies supported by the Device Administration API.
setPasswordExpirationTimeout()
In addition to supporting the policies listed in the above table, the Device Administration API lets you do the following:
The examples used in this document are based on the Device Administration API sample, which is included in the SDK samples. For information on downloading and installing the SDK samples, see Getting the Samples. Here is the complete code for the sample.
The sample application offers a demo of device admin features. It presents users with a user interface that lets them enable the device admin application. Once they've enabled the application, they can use the buttons in the user interface to do the following:
Figure 1. Screenshot of the Sample Application
System administrators can use the Device Administration API to write an application that enforces remote/local device security policy enforcement. This section summarizes the steps involved in creating a device administration application.
To use the Device Administration API, the application's manifest must include the following:
DeviceAdminReceiver
BIND_DEVICE_ADMIN
ACTION_DEVICE_ADMIN_ENABLED
Here is an excerpt from the Device Administration sample manifest:
android:name=".app.DeviceAdminSample" android:label="@string/activity_sample_device_admin"> android:name="android.intent.action.MAIN" /> android:name="android.intent.category.SAMPLE_CODE" /> android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver" android:label="@string/sample_device_admin" android:description="@string/sample_device_admin_description" android:permission="android.permission.BIND_DEVICE_ADMIN"> android:name="android.app.device_admin" android:resource="@xml/device_admin_sample" /> android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
Note that:
ApiDemos/res/values/strings.xml
android:label="@string/activity_sample_device_admin"
android:label="@string/sample_device_admin"
android:description="@string/sample_device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN"
android.app.action.DEVICE_ADMIN_ENABLED
onEnabled()
android:resource="@xml/device_admin_sample"
DeviceAdminInfo
device_admin_sample.xml
xmlns:android="https://schemas.android.com/apk/res/android"> /> /> /> /> /> /> /> />
In designing your device administration application, you don't need to include all of the policies, just the ones that are relevant for your app.
For more discussion of the manifest file, see the Android Developers Guide.
The Device Administration API includes the following classes:
DevicePolicyManager
These classes provide the foundation for a fully functional device administration application. The rest of this section describes how you use the DeviceAdminReceiverand DevicePolicyManagerAPIs to write a device admin application.
To create a device admin application, you must subclass DeviceAdminReceiver. The DeviceAdminReceiverclass consists of a series of callbacks that are triggered when particular events occur.
In its DeviceAdminReceiversubclass, the sample application simply displays a Toastnotification in response to particular events. For example:
Toast
public class DeviceAdminSample extends DeviceAdminReceiver { void showToast(Context context, String msg) { String status = context.getString(R.string.admin_receiver_status, msg); Toast.makeText(context, status, Toast.LENGTH_SHORT).show(); } @Override public void onEnabled(Context context, Intent intent) { showToast(context, context.getString(R.string.admin_receiver_status_enabled)); } @Override public CharSequence onDisableRequested(Context context, Intent intent) { return context.getString(R.string.admin_receiver_status_disable_warning); } @Override public void onDisabled(Context context, Intent intent) { showToast(context, context.getString(R.string.admin_receiver_status_disabled)); } @Override public void onPasswordChanged(Context context, Intent intent) { showToast(context, context.getString(R.string.admin_receiver_status_pw_changed)); } ... }
One of the major events a device admin application has to handle is the user enabling the application. The user must explicitly enable the application for the policies to be enforced. If the user chooses not to enable the application it will still be present on the device, but its policies will not be enforced, and the user will not get any of the application's benefits.
The process of enabling the application begins when the user performs an action that triggers the ACTION_ADD_DEVICE_ADMINintent. In the sample application, this happens when the user clicks the Enable Admin checkbox.
ACTION_ADD_DEVICE_ADMIN
When the user clicks the Enable Admin checkbox, the display changes to prompt the user to activate the device admin application, as shown in figure 2.
Figure 2. Sample Application: Activating the Application
Below is the code that gets executed when the user clicks the Enable Admin checkbox. This has the effect of triggering the onPreferenceChange()callback. This callback is invoked when the value of this Preferencehas been changed by the user and is about to be set and/or persisted. If the user is enabling the application, the display changes to prompt the user to activate the device admin application, as shown in figure 2. Otherwise, the device admin application is disabled.
onPreferenceChange()
Preference
@Override public boolean onPreferenceChange(Preference preference, Object newValue) { if (super.onPreferenceChange(preference, newValue)) { return true; } boolean value = (Boolean) newValue; if (preference == mEnableCheckbox) { if (value != mAdminActive) { if (value) { // Launch the activity to have the user enable our admin. Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN); intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample); intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION, mActivity.getString(R.string.add_admin_extra_app_text)); startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN); // return false - don't update checkbox until we're really active return false; } else { mDPM.removeActiveAdmin(mDeviceAdminSample); enableDeviceCapabilitiesArea(false); mAdminActive = false; } } } else if (preference == mDisableCameraCheckbox) { mDPM.setCameraDisabled(mDeviceAdminSample, value); ... } return true; }
The line intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample)states that mDeviceAdminSample(which is a DeviceAdminReceivercomponent) is the target policy. This line invokes the user interface shown in figure 2, which guides users through adding the device administrator to the system (or allows them to reject it).
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample)
mDeviceAdminSample
When the application needs to perform an operation that is contingent on the device admin application being enabled, it confirms that the application is active. To do this it uses the DevicePolicyManagermethod isAdminActive(). Notice that the DevicePolicyManagermethod isAdminActive()takes a DeviceAdminReceivercomponent as its argument:
isAdminActive()
DevicePolicyManager mDPM; ... private boolean isActiveAdmin() { return mDPM.isAdminActive(mDeviceAdminSample); }
DevicePolicyManageris a public class for managing policies enforced on a device. DevicePolicyManagermanages policies for one or more DeviceAdminReceiverinstances.
You get a handle to the DevicePolicyManageras follows:
DevicePolicyManager mDPM = (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
This section describes how to use DevicePolicyManagerto perform administrative tasks:
DevicePolicyManagerincludes APIs for setting and enforcing the device password policy. In the Device Administration API, the password only applies to screen lock. This section describes common password-related tasks.
This code displays a user interface prompting the user to set a password:
Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); startActivity(intent);
The password quality can be one of the following DevicePolicyManagerconstants:
PASSWORD_QUALITY_ALPHABETIC
PASSWORD_QUALITY_ALPHANUMERIC
PASSWORD_QUALITY_NUMERIC
PASSWORD_QUALITY_COMPLEX
PASSWORD_QUALITY_SOMETHING
PASSWORD_QUALITY_UNSPECIFIED
For example, this is how you would set the password policy to require an alphanumeric password:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; ... mDPM.setPasswordQuality(mDeviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
Beginning with Android 3.0, the DevicePolicyManagerclass includes methods that let you fine-tune the contents of the password. For example, you could set a policy that states that passwords must contain at least n uppercase letters. Here are the methods for fine-tuning a password's contents:
setPasswordMinimumLetters()
setPasswordMinimumLowerCase()
setPasswordMinimumUpperCase()
setPasswordMinimumNonLetter()
setPasswordMinimumNumeric()
setPasswordMinimumSymbols()
For example, this snippet states that the password must have at least 2 uppercase letters:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; int pwMinUppercase = 2; ... mDPM.setPasswordMinimumUpperCase(mDeviceAdminSample, pwMinUppercase);
You can specify that a password must be at least the specified minimum length. For example:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; int pwLength; ... mDPM.setPasswordMinimumLength(mDeviceAdminSample, pwLength);
You can set the maximum number of allowed failed password attempts before the device is wiped (that is, reset to factory settings). For example:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; int maxFailedPw; ... mDPM.setMaximumFailedPasswordsForWipe(mDeviceAdminSample, maxFailedPw);
Beginning with Android 3.0, you can use the setPasswordExpirationTimeout()method to set when a password will expire, expressed as a delta in milliseconds from when a device admin sets the expiration timeout. For example:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; long pwExpiration; ... mDPM.setPasswordExpirationTimeout(mDeviceAdminSample, pwExpiration);
Beginning with Android 3.0, you can use the setPasswordHistoryLength()method to limit users' ability to reuse old passwords. This method takes a length parameter, which specifies how many old passwords are stored. When this policy is active, users cannot enter a new password that matches the last n passwords. This prevents users from using the same password over and over. This policy is typically used in conjunction with setPasswordExpirationTimeout(), which forces users to update their passwords after a specified amount of time has elapsed.
setPasswordHistoryLength()
For example, this snippet prohibits users from reusing any of their last 5 passwords:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; int pwHistoryLength = 5; ... mDPM.setPasswordHistoryLength(mDeviceAdminSample, pwHistoryLength);
You can set the maximum period of user inactivity that can occur before the device locks. For example:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; ... long timeMs = 1000L*Long.parseLong(mTimeout.getText().toString()); mDPM.setMaximumTimeToLock(mDeviceAdminSample, timeMs);
You can also programmatically tell the device to lock immediately:
DevicePolicyManager mDPM; mDPM.lockNow();
You can use the DevicePolicyManagermethod wipeData()to reset the device to factory settings. This is useful if the device is lost or stolen. Often the decision to wipe the device is the result of certain conditions being met. For example, you can use setMaximumFailedPasswordsForWipe()to state that a device should be wiped after a specific number of failed password attempts.
wipeData()
setMaximumFailedPasswordsForWipe()
You wipe data as follows:
DevicePolicyManager mDPM; mDPM.wipeData(0);
The wipeData()method takes as its parameter a bit mask of additional options. Currently the value must be 0.
Beginning with Android 4.0, you can disable the camera. Note that this doesn't have to be a permanent disabling. The camera can be enabled/disabled dynamically based on context, time, and so on.
You control whether the camera is disabled by using the setCameraDisabled()method. For example, this snippet sets the camera to be enabled or disabled based on a checkbox setting:
setCameraDisabled()
private CheckBoxPreference mDisableCameraCheckbox; DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; ... mDPM.setCameraDisabled(mDeviceAdminSample, mDisableCameraCheckbox.isChecked());
Beginning with Android 3.0, you can use the setStorageEncryption()method to set a policy requiring encryption of the storage area, where supported.
setStorageEncryption()
For example:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; ... mDPM.setStorageEncryption(mDeviceAdminSample, true);