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.
Device Administration API Overview
Here are examples of the types of applications that might use the Device Administration API:
- Email clients.
- Security applications that do remote wipe.
- Device management services and applications.
How does it work?
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:
- A system administrator writes a device admin application that enforces remote/local device security policies. These policies could be hard-coded into the app, or the application could dynamically fetch policies from a third-party server.
- The application is installed on users' devices. Android does not currently have an automated provisioning solution. Some of the ways a sysadmin might distribute the application to users are as follows:
- Android Market.
- Enabling non-market installation.
- Distributing the application through other means, such as email or websites.
- The system prompts the user to enable the device admin application. How and when this happens depends on how the application is implemented.
- Once users enable the device admin application, they are subject to its policies. Complying with those policies typically confers benefits, such as access to sensitive systems and data.
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.
Policies
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.
| Policy | Description |
| Password enabled | Requires that devices ask for PIN or passwords. |
| Minimum password length | Set the required number of characters for the password. For example, you can require PIN or passwords to have at least six characters. |
| Alphanumeric password required | Requires that passwords have a combination of letters and numbers. They may include symbolic characters. |
| Complex password required | Requires that passwords must contain at least a letter, a numerical digit, and a special symbol. Introduced in Android 3.0. |
| Minimum letters required in password | The minimum number of letters required in the password for all admins or a particular one. Introduced in Android 3.0. |
| Minimum lowercase letters required in password | The minimum number of lowercase letters required in the password for all admins or a particular one. Introduced in Android 3.0. |
| Minimum non-letter characters required in password | The minimum number of non-letter characters required in the password for all admins or a particular one. Introduced in Android 3.0. |
| Minimum numerical digits required in password | The minimum number of numerical digits required in the password for all admins or a particular one. Introduced in Android 3.0. |
| Minimum symbols required in password | The minimum number of symbols required in the password for all admins or a particular one. Introduced in Android 3.0. |
| Minimum uppercase letters required in password | The minimum number of uppercase letters required in the password for all admins or a particular one. Introduced in Android 3.0. |
| Password expiration timeout | When the password will expire, expressed as a delta in milliseconds from when a device admin sets the expiration timeout. Introduced in Android 3.0. |
| Password history restriction | This policy prevents users from reusing the last n unique passwords. This policy is typically used in conjunction with setPasswordExpirationTimeout(), which forces users to update their passwords after a specified amount of time has elapsed. Introduced in Android 3.0. |
| Maximum failed password attempts | Specifies how many times a user can enter the wrong password before the device wipes its data. The Device Administration API also allows administrators to remotely reset the device to factory defaults. This secures data in case the device is lost or stolen. |
| Maximum inactivity time lock | Sets the length of time since the user last touched the screen or pressed a button before the device locks the screen. When this happens, users need to enter their PIN or passwords again before they can use their devices and access data. The value can be between 1 and 60 minutes. |
| Require storage encryption | Specifies that the storage area should be encrypted, if the device supports it. Introduced in Android 3.0. |
Other features
In addition to supporting the policies listed in the above table, the Device Administration API lets you do the following:
- Prompt user to set a new password.
- Lock device immediately.
- Wipe the device's data (that is, restore the device to its factory defaults).
0 件のコメント:
コメントを投稿