If you are an administrator, you can leverage the API and system capabilities to manage Android devices and control access.
In the ICS Unified key store Access
Powered by Android 4.0 (ICS) comes with some improvements that make it easier for people to bring their personal Android device to work. In this article, we'll look at the key storage feature.
Android?? The OID 2.2 introduces support for enterprise applications by providing an Android device Management API. The Device Management API provides device management capabilities at the system level. These APIs allow you to create useful security-aware applications in enterprise settings where IT professionals need rich control over the employees ' devices. For example, e-mail for built-in Android apps has leveraged the new API to enhance Exchange support. Through the e-mail application, Exchange Administrators can enforce password policies-including alphanumeric passwords or digital pins-across devices. The administrator can also remotely erase (that is, restore factory defaults) to a lost or stolen phone. Exchange users can synchronize their e-mail and calendar data.
This document is intended for the development of enterprise solutions who want to develop Android powered devices. It discusses the various features that the Device Management API provides for greater security by carrying Android employee devices.
Note about the construction work guidelines for controller deployment Android for working information, see Building a work policy controller.
Device Management API Overview
The following are examples of types of possible use of Device management API applications:
? e-mail client.
? Those remote wipe security applications.
? Device management Services and applications.
How does it work?
You can use the device Management API to write users to install Device management applications on their devices. The Device management application enforces the required policies. Here's how it works:
The system administrator writes about device management applications that implement remote/local device security policies. These policies may be hard-coded to applications or applications that can be dynamically fetched from third-party server policies.
? The application is installed on the user's device. The Android version does not currently have an automated provisioning solution. Is how some system administrators will distribute the application to users in the following ways:? Google Play.
From another store? Enabling installation.
? Distributing through other means, such as email or website applications.
? The user is prompted to enable the Device management application. How and when this happens depends on how the application is implemented.
? Once a user opens the Device management application, they are subject to their policies. These policies are usually in line with the granting of benefits, such as access to sensitive systems and data.
If the user does not enable the Device management application, it is still on the device, but is not active. Users will not be affected by their policies, they will in turn not get the benefits of any application, for example, they may not be able to synchronize data.
If the user does not comply with the policy (for example, if the user settings violate the code password), it is up to the application to decide how to handle the problem. Typically, however, this will result in users not being able to synchronize data.
If a device tries to connect to a policy server that is not supported in the desired Device Management API, the connection is not allowed. The Device Management API currently does not allow partial configuration. In other words, if a device (for example, a traditional device) does not support all stated policies, there is no way for the device to connect.
If the device contains multiple enable management applications, the most stringent policy enforcement. There is no way to target a specific management application.
To uninstall an existing device management application, the user needs to log off the application as an administrator first.
Policy
In an enterprise environment, it is often the case that employee devices must follow a strict set of policies governing the use of the device. Device Management API Support table 1. Note that the device Management API currently supports only the policies listed on the screen lock password:
Table 1. Policy is supported by the Device Management API.
Policy
Describe
Enable password
Require the device to require a PIN or password.
Minimum password length
Set the required number as the character of the password. For example, you may need a pin or a password of at least six characters.
Alphanumeric Password required
A password is required to have a combination of letters and numbers. They can include symbolic characters.
Requires a complex password
Requires that the password must contain at least one letter, a digit, and a special symbol. Introduction to Android 3.0.
The minimum letter required for the password
The minimum number of passwords for all administrators or a specific required letter. Introduction to Android 3.0.
Minimum lowercase letters required in the password
The minimum number of passwords for all administrators or for a particular one requires lowercase letters. Introduction to Android 3.0.
Minimum non-alphabetic characters required in the password
The minimum number of non-alphabetic characters in the password for all administrators or a specific requirement. Introduction to Android 3.0.
Minimum number of digits required in the password
The minimum number of passwords for all administrators or for a specific number of numeric values required. Introduction to Android 3.0.
Minimum symbol required for password
Minimum number of passwords, all administrators or a specific required symbol. Introduction to Android 3.0.
Minimum uppercase letters required in the password
The minimum number of passwords, all administrators, or a specific one of the required uppercase letters. Introduction to Android 3.0.
Password Expiration timeout
When the password expires, it is expressed as an increment in milliseconds when a device administrator sets an expiration timeout. Introduction to Android 3.0.
Password history limit
This policy prevents the user from reusing the last n unique password. This policy is typically used in conjunction with Setpasswordexpirationtimeout (), which forces the user to update their password after the specified amount of time has passed. Introduction to Android 3.0.
Maximum password attempt failed
Specifies how many times the user can enter an incorrect password before the device wipes its data. The Device Management API also allows administrators to remotely reset devices to factory defaults. This fixed case in which the device was lost or stolen data.
Maximum inactivity Time lock
Set, because the user's length of time last touch the screen or device lock screen before pressing the button. When this happens, users need to enter their PIN or password again before they can use their device and access data. The value can be between 1-60 minutes.
Requires storage encryption
Specifies that the storage area should be encrypted if the device supports it. Introduction to Android 3.0.
Disabling the camera
Specifies that the camera should be disabled. It is important to note that this does not have to be a permanent disable. The camera can be dynamically based on context, time enabled/disabled, and so on. Introduction to Android 4.0.
Other features
In addition to supporting the policies listed in the table above, the Device Management API allows you to do the following:
? Prompt the user to set a new password.
The locking device takes effect immediately.
? Wipe device data (that is, restore the device to factory default settings).
Sample Application
The sample used in this document is based on the Device Management API sample, which is included in the SDK sample (available through Android SDK Manager) on your system for <sdk_root>/Apidemos/application/src Directory/master/java/com/Example/ Android/API/app/Deviceadminsample.java.
The sample application provides a demonstration of the device management features. It presents a user interface that allows users to manage applications in the device. Once the application is enabled, they can use these buttons to perform the following actions in the user interface:
? set the password quality.
What does it mean?? A user's password requirement, such as minimum length, must contain the minimum number of numeric characters, and so on.
? set the password. If the password does not conform to the specified policy, an error will be returned.
How many failed password attempts (that is, restore to factory settings) will occur before erasing the device.
How to set the password will expire soon from now.
? Set the password history length (length refers to the number of old passwords stored in the history). This prevents users from reusing one of the last n passwords they used before.
What does it mean?? The storage area should be encrypted if the device supports it.
? Sets the maximum amount of inactivity that can elapse before a device is locked.
? immediate device lock.
Wipe your device's data (that is, restore the factory settings).
? Disable the camera.
Figure 1. Screen of the sample application
Development of an application in device management
System administrators can use the device Management API to write applications that enforce enforcement of remote/local device security policies. This section summarizes the steps involved in creating a device management application.
Create a checklist
To use the Device Management API, the application's manifest must include the following:? Deviceadminreceiver subclasses, including the following:? Thebind_device_admin License.
Enable intent to respond to action device_admin? The ability to be represented in the list as an intent filter.
? The declaration of the security policy used in metadata.
Here is an excerpt from the Device Management sample list:
<activity android:name= ". App. Deviceadminsample "android:label=" @string/activity_sample_device_admin "> <intent-filter> < ; Action android:name= "Android.intent.action.MAIN"/> <category android:name= "android.intent.category.SAMPLE_ CODE "/> </intent-filter></activity><receiver 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" > <met A-data android:name= "Android.app.device_admin" android:resource= "@xml/device_admin_sample"/> <intent- filter> <action android:name= "Android.app.action.DEVICE_ADMIN_ENABLED"/> </intent-filter></re Ceiver>
Note that:? The following properties refer to string resources that the sample application resides in Apidemos/res/value/Strings.xml. For more information about resources, see application resources. android: Tag = "@ string/Active sample Device_admin" refers to the user-readable label of the activity.
Android: Tag = "@ string/sample_device_admin" refers to a label that is allowed to be readable by the user.
Android: Description = "@ string/Sample Device_admin description" refers to the user-readable description of the permission. A descriptive feature is usually longer and richer than the label.
? android: Permission = "Android.permission.BIND_DEVICE_ADMIN" is a deviceadminreceiver subclass that must have permission to ensure that only the system can interact with the receiver (no application can be granted this permission). This prevents other applications from abusing your device management app. Android.app.action.DEVICE_ADMIN_ENABLED is a deviceadminreceiver subclass that must handle the primary operations that are allowed to manage devices. This is set when the user makes the device management application sink. Your code usually handles this onenabled (). To support, the receiver must also require Bind_device_admin permissions so that other applications cannot abuse it.
? When the user has enabled the Device management application, the recipient's permission is given in response to the broadcast execution of a particular system event. When an appropriate event occurs, the application can levy the policy. For example, if a user tries to set a new password that does not meet the policy requirements, the application can prompt the user to choose a different password that does meet the requirements.
? android: Resource = The security policy used by metadata in the "@ xml/device_admin_sample" declaration. Metadata provides additional information such as parsing by the Deviceadmininfo class that is specific to the device administrator. The following are the contents of Device_admin_sample.xml:
<device-admin xmlns:android= "Http://schemas.android.com/apk/res/android" > <uses-policies> <limit-password/> <watch-login/> <reset-password/> <force-lock/> < Wipe-data/> <expire-password/> <encrypted-storage/> <disable-camera/> </uses-policies></device-admin>
In designing your device management application, you don't need to include all the policies, just people about your application. For more discussion of manifest files, see the Android Developer Guide.
Implementing code
The Device Management API includes the following classes: The Deviceadminreceiver base class implements the device management component. This class provides the convenience of interpreting the original intent action sent by the system. Your device management application must include the Deviceadminreceiver subclass. Devicepolicymanager a policy class that is used to manage coercion on a device. Most clients of this class must advertise that the user is currently enabled for Deviceadminreceiver. Instancesdeviceadmininfo This class is used to Devicepolicymanager one or more deviceadminreceiver policies for the metadata management specified by the device administrator component.
These classes provide the basis for a fully functional device management application. The remainder of this section describes how to use Device management applications written using the Deviceadminreceiver and Devicepolicymanager APIs.
Sub-class Deviceadminreceiver
To create a device management application, you must inherit deviceadminreceiver. The Deviceadminreceiver class contains a series of callbacks that are triggered when a particular event occurs.
In its subclass Deviceadminreceiver, the sample application only displays toast notifications in response to a specific event. For example:
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)); } ...}
Make the application
One of the main events that the Device management application is dealing with is the user-enabled application. The user must explicitly make the application such as the policy to be executed. If the user chooses not to make the app it will still exist on the device, but its policies will not be executed, and the user will not get the benefits of any application.
The process of the application starts when the user executes an action that triggers the action_add_device_admin intent. In the sample application, this behavior occurs when the user clicks the Enable Administrator check box.
When the user clicks the Enable Administrator check box, the display becomes prompt for the user to activate the device management application, 2.
Figure 2. Sample application: Activating an Application
The following is the code that is executed when the user clicks the Enable Administrator check box. This has the effect of triggering the Onpreferencechange () callback. When the value of this preference has been changed by the user, it is called to be set and/or continued callback. If the user enables the application, the display will become prompt for the user to activate the device management application, 2 otherwise, the Device management application is disabled
@Override public boolean Onpreferencechange (Preference Preference, Object newvalue) {if (Super.onprefer Encechange (preference, newvalue)) {return true; } Boolean value = (Boolean) newvalue; if (preference = = Menablecheckbox) {if (value! = madminactive) {if (value) { Launch the activity to has 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; }}} and else if (preference = = Mdisablecameracheckbox) {mdpm.setcameradisabled (mDe Viceadminsample, value); ... } return true; }
Line Intent.putextra (Devicepolicymanager.extra device_admin, Mdeviceadminsample) points out that mdeviceadminsample (which is a deviceadminreceiver ingredient) is the target strategy. This row is called in Figure 2 by adding a device administrator to the system to instruct the user (or allow them to reject it) as shown in the user interface.
When the application needs to perform a team operation that is to be enabled for the Device management application, confirm that the application is active. To do this, it uses the Devicepolicymanager method Isadminactive (). Note that the Devicepolicymanager method Isadminactive () takes the Deviceadminreceiver component as its parameter:
Devicepolicymanager mdpm;...private Boolean isactiveadmin () { return mdpm.isadminactive (mdeviceadminsample);}
Management policy
Devicepolicymanager is a public class that enforces a policy on the management device. Devicepolicymanager manages one or more deviceadminreceiver instance policies.
You get the handle Devicepolicymanager as follows:
Devicepolicymanager MDPM = (Devicepolicymanager) Getsystemservice (Context.device_policy_service);
This section describes how to use Devicepolicymanager to perform administrative tasks:
? Set Password Policy
? Set device Lock
? perform data erasure
Set Password Policy
Devicepolicymanager includes APIs for setting up and executing device password policies. In the Device Management API, the password is only available for screen lock. Describes common password-related tasks.
Set a password for a device
This code shows the user interface prompting the user to set a password:
Intent Intent = new Intent (Devicepolicymanager.action_set_new_password); startactivity (Intent);
Set Password quality
The password quality can be one of the following Devicepolicymanager constants:
Password_quality alphabetic The user must enter at least a letter (or other symbol) Characters.password Quality_ Alphanumericthe the user must enter at least a number and a letter (or other symbol) characters.password_quality_numericthe the user's password must enter a password character that contains at least a numeric password. Password_quality_complexthe user must enter at least one letter, one digit and one special symbol. The password for the Password_quality_somethingthe policy requires some kind of password, but does not care about it. The password_quality_unspecified policy has no requirements for passwords.
For example, this is how you will set the password policy to require an alphanumeric password:
Devicepolicymanager MDPM; ComponentName mdeviceadminsample;...mdpm.setpasswordquality (Mdeviceadminsample, DevicePolicyManager.PASSWORD_ Quality_alphanumeric);
Set Minimum password length
You can specify a minimum length that a password must specify at least. For example:
Devicepolicymanager MDPM; ComponentName mdeviceadminsample;int pwlength;...mdpm.setpasswordminimumlength (mDeviceAdminSample, pwLength);
Failed to set maximum password attempt
You can set the maximum number of password attempts that are allowed to fail before erasing the device (that is, resetting to factory settings). For example:
Devicepolicymanager MDPM; ComponentName Mdeviceadminsample;int MAXFAILEDPW; ... mdpm.setmaximumfailedpasswordsforwipe (mdeviceadminsample, MAXFAILEDPW);
Set Password expiration timeout
Starting with Android3.0, you can use the Set Password expiration timeout () method to set when the password expires, expressed as an increment in milliseconds when a device administrator sets an expiration timeout. For example:
Devicepolicymanager MDPM; ComponentName Mdeviceadminsample;long pwexpiration;...mdpm.setpasswordexpirationtimeout (MDeviceAdminSample, Pwexpiration);
Limit password based on history
Starting with Android3.0, you can use the Setpasswordhistorylength () method to limit the user's ability to reuse the old password. This method requires the length parameter, which specifies how many old passwords are stored. When this policy is active, the user cannot enter the last N password to match the new password. This will prevent users from using the same password over and over again. This policy is typically used in conjunction with a set of password expiration Timeouts (), which forces users to update their passwords after a specified time has elapsed.
For example, this section prohibits users from reusing any of their last 5 passwords:
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 ();
Perform data erasure
You can use the Devicepolicymanager method Wipedata () to reset the device to factory settings. This is useful if the device is lost or stolen. The decision to wipe the equipment often is a result of satisfying certain conditions. For example, you can use Setmaximumfailedpasswordsforwipe () to declare that the device should wipe after a specific number of failed password attempts.
You wipe the data as follows:
Devicepolicymanager mdpm;mdpm.wipedata (0);
The Wipedata () method is a bitmask of additional options for the parameter. The value must be 0 at this time.
Disabling the camera
Starting with Android4.0, you can disable the camera. It is important to note that this does not have to be a permanent disable. The camera can be dynamically based on context, time enabled/disabled, and so on.
You can control whether the camera is closed by using the Setcamera disabled () method. For example, this fragment sets the camera to be enabled or disabled according to the check box settings:
Private Checkboxpreference Mdisablecameracheckbox;devicepolicymanager MDPM; ComponentName mdeviceadminsample;...mdpm.setcameradisabled (Mdeviceadminsample, mDisableCameraCheckbox.isChecked ( ));
Storage encryption
Starting with Android3.0, you can use the Setstorageencryption () method to set the required storage area if the encryption policy is supported.
For example:
Devicepolicymanager MDPM; ComponentName mdeviceadminsample;...mdpm.setstorageencryption (Mdeviceadminsample, true);
See a complete example of how the Device Management API sample enables encrypted storage.
Android API Guides---administration