Device Administration
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.
Android 2.2 는 Android Device Andministration API 를 통해, 보안성 등이 필요시되는 기업 어플리케이션을 위한 지원을 한다. Device Administration API 는 system 레벨에서의 기기 관리 기능을 제공한다. 이 API 들은 당신이 IT 기업에서 고용자의 기기에 설정하고자 하는 다양한 보안 설정을 지원하는 어플리케이션의 개발에 유용하게 사용될 수 있다.
예를 들어, Android 에 포함 되어 있는 Email app 은 Exchange 기능 지원을 개선하기 위해 이 API 를 사용했다. Email app 에서 Exchange 관리자는 기기들에 password 정책을 강제 할 수 있다 - 알파벳+숫자 조합 password 나 숫자로만 이루어진 password 등을 포함해서.
관리자는 또한, 잃어버리거나 도둑 맞은 기기에 원격 데이터 삭제 기능(기기를 출고 직후 상태로 되돌린다)을 사용 할 수 있다. Exchange 사용자는 email 과 calendar 데이터를 sync 할 수 있다.
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.
이 기기는 Android 기기에 enterprise solution 을 개발하고자 하는 개발자들을 위한다. 직원의 Android 기기에 강력한 보안 기능을 개발하기 위한 기능을 제공하는 Device Administration API 에 대해 이야기 한다.
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.
Device Administration API 를 사용할 만한 application 의 종류는 다음과 같다 :
- Email client application
- 원격 데이터 삭제를 하는 보안 application
- 기기 관리 서비스와 application
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.
사용자들이 그들의 기기에 설치할 기기 관리 application 을 개발하기 위해 당신은 Device Administration API 를 사용할 것이다.
Device admin application 은 보안 정책을 강제한다. 이것은 다음과 같이 동작한다 :
- system administrator 는 원격/또는 지역적으로 동작할 device security 정책을 강제할 device admin application 을 개발한다.
- 해당 application 이 사용자의 기기에 설치된다. Android 는 현재로썬 자동화된 설치 방법은 없다. system admin 은 다음과 같은 방법으로 application 을 유저에게 배포 할 수 있다 :
- Android market
- non-market 설치를 허용하기.
- email 이나 website 로 배포하기.
- system 은 사용자가 device admin application 을 활성화 하도록 해야 한다. 이것이 어떻게, 언제 이루어지는지는 application 이 어떻게 구현 되었는가에 달렸다.
- 한번 사용자들이 device admin application 을 활성화 하면, 사용자들은 device admin application 의 정책을 따르게 된다. 이 정책들을 따르는 것은 민감한 시스템과 데이터로의 접속과 같은 이익을 제공할 수 있을 것이다.
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.
사용자들이 device admin app 을 활성화 하지 않으면, 그것은 device 에 남아 있겠지만, 비활성화 된 상태로 있을 것이다. 사용자들은 그 정책을 따르지 않게 되고, application 의 기능을 사용하지 못할 것이다 - 예를 들면, data 를 sync 하지 못할 것이다.
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.
사용자가 정책을 따르지 않는다면(예를 들어, 사용자가 가이드라인을 어기는 password 를 설정한다던지), 이를 어떻게 제어할지는 application 의 몫이다. 다만, 일반적으로는 사용자가 data sync 를 못하게 할 것이다.
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.
기기가 Device administration API 에서 지원하지 않는 정책을 요구하는 서버에 연결을 시도하면, 연결은 실패할 것이다. Device Administration API 는 현재로썬 partial provisioning 을 지원하지 않는다. 달리 말하자면, 기기가(예를 들어, 구형 버전의 기기) 모든 정책을 지원하지 않는다면, 해당 기기를 연결할 방법이 없다.
If a device contains multiple enabled admin applications, the strictest policy is enforced. There is no way to target a particular admin application.
기기가 여러개의 admin application 을 활성화 했다면, 가장 강한 정책이 설정된다.
개별의 admin application 을 부분적으로 사용하는 방법은 없다.
To uninstall an existing device admin application, users need to first unregister the application as an administrator.
admin application 을 삭제하고자 한다면, 사용자는 일단 application 을 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:
기업 설정에서, 직원의 기기가 기기의 사용을 제어하는 정책을 설정해야 하는 것은 흔한 경우이다. Device Administration API 는 아래의 표에 적힌 정책들을 지원한다.
현재로써는 Device Administration API 는 screen lock 을 위한 password 만을 제공한다 :
Table 1. Policies supported by the Device Administration API.
| Policy | Description |
| Password enabled |
Requires that devices ask for PIN or passwords.
기기가 PIN(숫자로만 이루어진 비밀번호) 나 password 를 요구하도록 한다. |
| 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.
password 의 최소 길이를 설정 한다. 예를 들어, 당신은 최소 6자 이상의 PIN 이나 password 를 요구 할 수 있다. |
| Alphanumeric password required |
Requires that passwords have a combination of letters and numbers. They may include symbolic characters.
password 가 숫자와 글자의 조합으로 이루어지도록 한다. 특수 문자도 포함될 수 있다. |
| 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.
device 가 데이터를 지워 버리기 전에 몇회까지 틀린 password 의 입력을 허용할 것인지 설정한다. Device Administration API 는 또한 administrator 가 원격으로 기기를 출하 직후 상태로 reset 할 수 있는 기능을 제공한다. 이는 기기를 잃어버렸거나 도둑 맞은 경우 보안을 제공할 수 있다. |
| 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.
사용자가 마지막으로 화면을 터치하거나 button 을 누른 후 얼마나 많은 시간이 지난 후 screen 을 lock 할지를 설정 할 수 있다. 해당 시간이 지나면, 사용자는 그들의 기기를 다시 사용하기 위해 PIN 이나 password 를 입력해야 한다. 값은 1분에서 60분까지 설정 가능하다. |
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).
위의 표에서 설명한 정책들 외에도, Device Administration API 는 다음과 같은 정책을 제공한다 :
- 사용자가 새로운 password 를 설정하도록 요구.
- device 를 즉각 Lock 시킨다.
- device 의 데이터를 삭제(이는, 기기를 출하 직후의 상태로 되돌린다).
Sample Application
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.
이 문서에서 사용하는 예시는 SDK sample 에 포함된 Device Administration API sample 에 기초한다. SDK sample 의 다운로드와 설치를 위해서는 Getting the samples 문서를 참고 바란다. 여기 예제의 전체 코드가 있다.
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:
예제 application 은 device admin 기능의 demo 를 제공한다. 그것은 사용자들이 admin application 을 활성화 할 수 있는 UI 를 제공한다. 한번 사용자가 이 application 을 활성화 하면, 그들은 다음의 기능을 사용하기 위해 버튼을 사용 할 수 있다 :
- Set password quality.
- Specify the minimum length for the user's password.
- Set the password. If the password does not conform to the specified policies, the system returns an error.
- Set how many failed password attempts can occur before the device is wiped (that is, restored to factory settings).
- Set the maximum amount of inactive time that can elapse before the device locks.
- Make the device lock immediately.
- Wipe the device's data (that is, restore factory settings).
- password 제한 설정.
- 사용자 password 의 최소 길이 설정.
- password 설정. 만약 해당 password 가 제시된 정책을 따르지 않을 경우, system 은 에러를 냄.
- 얼마나 많은 password 실패가 반복될 때 기기의 데이터를 삭제할지(즉, 출하 직후 환경으로 복구됨).
- 기기를 lock 하기 전 얼마나 많은 시간을 유지할 것인가 설정.
- 즉시 기기를 lock.
- 기기의 데이터 삭제(출하 직후 환경으로 복구)
Figure 1. Screenshot of the Sample Application
Developing a Device Administration 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.
System administrator 는 remote/local 기기 보안 정책 강제를 할 수 있는 application 의 개발을 위해 Device Administration API 를 사용 할 수 있다. 이 section 은 device administration application 을 개발하기 위한 단계를 요약, 정리해 본다.
Creating the manifest
manifest 만들기
To use the Device Administration API, the application's manifest must include the following:
- A subclass of
DeviceAdminReceiver that includes the following:
- A declaration of security policies used in metadata.
Device Administration API 를 사용하기 위해서, application 의 manifest 는 다음을 포함해야 한다 :
- 다음을 포함하는, DeviceAdminReceiver 의 subclass.
- BIND_DEVICE_ADMIN 권한.
- manifest 에 intent filter 로 선언, ACTION_DEVICE_ADMIN_ENABLE intent 를 받을 수 있어야함.
- 사용하는 보안 정책을 metadata 로 선언.
Here is an excerpt from the Device Administration sample manifest:
Device Administration sample 의 manifest 로부터 다음을 참고하라 :
<activity android:name=".app.DeviceAdminSample$Controller"
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"
android:label="@string/sample_device_admin"
android:description="@string/sample_device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN">
<meta-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>
</receiver>
Note that:
다음을 참고하라 :
- The activity in the sample application is an
Activity subclass called Controller. The syntax ".app.DeviceAdminSample$Controller" indicates that Controller is an inner class that is nested inside the DeviceAdminSample class. Note that an Activity does not need to be an inner class; it just is in this example.
- The following attributes refer to string resources that for the sample application reside in
ApiDemos/res/values/strings.xml. For more information about resources, see Application Resources.
android:label="@string/activity_sample_device_admin" refers to the user-readable label for the activity.android:label="@string/sample_device_admin" refers to the user-readable label for the permission.android:description="@string/sample_device_admin_description" refers to the user-readable description of the permission. A descripton is typically longer and more informative than a label.
android:permission="android.permission.BIND_DEVICE_ADMIN" is a permission that a DeviceAdminReceiver subclass must have, 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 admin app.android.app.action.DEVICE_ADMIN_ENABLED is the the primary action that a DeviceAdminReceiver subclass must handle to be allowed to manage a device. This is set to the receiver when the user enables the device admin app. Your code typically handles this in onEnabled(). To be supported, the receiver must also require the BIND_DEVICE_ADMIN permission so that other applications cannot abuse it.- When a user enables the device admin application, that gives the receiver permission to perform actions in response to the broadcast of particular system events. When suitable event arises, the application can impose a policy. For example, if the user attempts to set a new password that doesn't meet the policy requirements, the application can prompt the user to pick a different password that does meet the requirements.
android:resource="@xml/device_admin_sample" declares the security policies used in metadata. The metadata provides additional information specific to the device administrator, as parsed by the DeviceAdminInfo class. Here are the contents of device_admin_sample.xml:
- 예제 application 에서 사용된 activity 는 Controller 라는 이름의, Activity 의 subclass 이다. ".app.DeviceAdminSample$Controller" 라는 문법은 Controller 가 DeviceAdminSample class 의 nested class 임을 알린다. Activity 가 굳이 inner class 일 필요는 없음을 참고하라; 단지 이 예제에서의 상황일 뿐이다.
- 다음의 속성들은 ApiDemos/res/values/string.xml 에 포함된, 예제 application 의 문자열 resource 를 가리킨다.
- android:label="@string/activity_sample_device_admin" 은 사용자가 읽을 수 있는, activity 의 lable 을 가리킨다.
- android:label="@string/sample_device_admin" 은 사용자가 읽을 수 있는, permission 의 lable 을 가리킨다.
- android:description="@string/sample_device_admin_description" 은 사용자가 읽을 수 있는, permission 의 설명을 가리킨다. 설명은 일반적으로 label 보다 길고, 알아 보기 쉽다.
- android:permission="android.permission.BIND_DEVICE_ADMIN" 은 system 만이 이 receiver 와 상호 동작 한다는(어떤 application 도 이 permission 을 얻을 수 없다), DeviceAdminReceiver subclass 가 반드시 가져야 하는 권한이다. 이것은 다른 application 이 당신의 device admin app 을 방해하지 못하게 한다.
- android.app.action.DEVICE_ADMIN_ENABLED 는 DeviceAdminReceiver subclass 가 기기를 관리 하기 위해 반드시 받아야 하는 action 이다. 이것은 사용자가 device admin app 을 활성화 시킬 때 receiver 에게 전달된다. 당신은 코드 상으로 이를 onEnabled() 에서 처리 하면 된다. receiver 는 또한, 다른 application 이 이를 악용하지 못하도록 BIND_DEVICE_ADMIN 권한을 요청 해야 한다.
- 사용자가 device admin application 을 활성화 할 때, receiver 는 개별적인 system event broadcast 에 대해 반응을 할 수 있는 권한을 얻는다. 그러한 event 가 발생할 때, application 은 정책을 부과 할 수 있다. 예를 들어, 사용자가 현재 보안 정책을 지키지 않는 새로운 password 를 설정한다면 application 은 사용자가 현재 보안 정책을 지키는 다른 password 를 설정하도록 할 수 있다.
- android:resource="@xml/device_admin_sample" 은 metadata 로 사용되는 보안 정책을 기술한다. metadata 는 DeviceAdminInfo class 에 의해 분석되는, device administrator 에 의해 사용되는 추가적인 정보를 제공한다.
<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
<uses-policies>
<limit-password />
<watch-login />
<reset-password />
<force-lock />
<wipe-data />
</uses-policies>
</device-admin>
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.
당신의 device administration application 을 설계함에 있어서, 모든 정책을 metadata 에 포함할 필요는 없다. 당신의 app 에서 사용할 정책만을 기술하면 된다.
For more discussion of the manifest file, see the Android Developers Guide.
manifest file 에 대한 보다 많은 정보를 위해선, Adnroid Developers Guide 를 참고하라.
Implementing the code
The Device Administration API includes the following classes:
DeviceAdminReceiver- Base class for implementing a device administration component. This class provides a convenience for interpreting the raw intent actions that are sent by the system. Your Device Administration application must include a
DeviceAdminReceiver subclass. DevicePolicyManager- A class for managing policies enforced on a device. Most clients of this class must have published a
DeviceAdminReceiver that the user has currently enabled. The DevicePolicyManager manages policies for one or more DeviceAdminReceiver instances DeviceAdminInfo- This class is used to specify metadata for a device administrator component.
These classes provide the foundation for a fully functional device administration application. The rest of this section describes how you use the DeviceAdminReceiver and DevicePolicyManager APIs to write a device admin application.
Device Administration API 는 다음의 class 들을 포함한다 :
DeviceAdminReceiver
- device administration component 를 구현하기 위한 Base class. 이 class 는 system 으로부터 받는 raw intent action 에 쉽게 반응 할 수 있도록 해준다. 당신의 Device Administration application 은 DeviceAdminReceiver 의 subclass 를 포함해야 한다.
DevicePolicyManager
- 기기에서 강제되는 정책들을 관리하기 위한 class. 이 클래스의 대부분의 client 들은 사용자가 현재 활성화 한 DeviceAdminReceiver 를 배포해야 한다. DevicePolicyManager 는 하나 또는 그 이상의 DeviceAdminReceiver instance 들을 위한 정책을 관리한다.
DeviceAdminInfo
- device administrator component 의 metadata 를 기술하는데 사용된다.
이 class 들은 전체 device administration application 을 위한 토대를 제공한다.
이 section 의 다음 부분들은 DeviceAdminReceiver 와 DevicePolicyManager 를 device admin application 을 개발하기 위해 어떻게 사용하는지 기술한다.
Subclassing DeviceAdminReceiver
To create a device admin application, you must subclass DeviceAdminReceiver. The DeviceAdminReceiver class consists of a series of callbacks that are triggered when particular events occur.
device admin application 을 개발하기 위해, 당신은 DeviceAdminReceiver 의 subclass 를 만들어야 한다. DeviceAdminReceiver class 는 몇몇 event 가 일어날 때마다 호출되는 callback 함수들을 가지고 있다.
In its DeviceAdminReceiver subclass, the sample application simply displays a Toast notification in response to particular events. For example:
DeviceAdminReceiver 의 subclass 에서, 예제 application 은 간단히 각각의 event 에 응답해서 Toast notification 만 표시한다. 예를 들면 :
public class DeviceAdminSample extends DeviceAdminReceiver {
...
@Override
public void onEnabled(Context context, Intent intent) {
showToast(context, "Sample Device Admin: enabled");
}
@Override
public CharSequence onDisableRequested(Context context, Intent intent) {
return "This is an optional message to warn the user about disabling.";
}
@Override
public void onDisabled(Context context, Intent intent) {
showToast(context, "Sample Device Admin: disabled");
}
@Override
public void onPasswordChanged(Context context, Intent intent) {
showToast(context, "Sample Device Admin: pw changed");
}
void showToast(Context context, CharSequence msg) {
Toast.makeText(context, msg, Toast.LENGTH_SHORT).show();
}
...
}Enabling the application
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.
device admin application 이 처리해야 하는 가장 중요한 event 중 하나는 사용자의 application 활성화 event 이다. 사용자는 보안 정책의 강제를 위해 application 을 명시적으로 활성화 해야 한다. 사용자가 application 을 활성화 하지 않기로 결정해도 해당 application 은 여전히 device 에 존재하지만, 정책을 강제 당하진 않으며, 사용자는 해당 application 으로부터 어떤 이득을 얻지 못할 것이다.
The process of enabling the application begins when the user performs an action that triggers the ACTION_ADD_DEVICE_ADMIN intent. In the sample application, this happens when the user clicks the Enable Admin button.
application 의 활성화는 사용자가 ACTION_ADD_DEVICE_ADMIN intent 를 발생시키면서 시작된다. 예제 application 에서, 이는 사용자가 Enable Admin 버튼을 클릭할 때 동작한다.
When the user clicks the Enable Admin button, the display changes to prompt the user to enable the device admin application, as shown in figure 2.
사용자가 Enable Admin 버튼을 클릭하면, figure 2 와 같은, 사용자의 device admin application 활성화를 위한 화면으로 이동한다.
Figure 2. Sample Application: Activating the Application
Below is the code that gets executed when the user clicks the Enable Admin button shown in figure 1.
아래는 사용자가 Enable Admin 버튼을 클릭했을 때 실행되는 code 다.
private OnClickListener mEnableListener = new OnClickListener() {
public void onClick(View v) {
// 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,
"Additional text explaining why this needs to be added.");
startActivityForResult(intent, RESULT_ENABLE);
}
};
...
// This code checks whether the device admin app was successfully enabled.
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
switch (requestCode) {
case RESULT_ENABLE:
if (resultCode == Activity.RESULT_OK) {
Log.i("DeviceAdminSample", "Administration enabled!");
} else {
Log.i("DeviceAdminSample", "Administration enable FAILED!");
}
return;
}
super.onActivityResult(requestCode, resultCode, data);
}
The line intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) states that mDeviceAdminSample (which is a DeviceAdminReceiver component) 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(DeviceAdminReceiver component) 이 target policy 임을 가리킨다. 이 내용은 사용자가 사용자가 device administrator 를 system 에 추가하는(또는 이를 거부하는) figure 2 의 화면과 마주하도록 한다.
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 DevicePolicyManager method isAdminActive(). Notice that the DevicePolicyManager methodisAdminActive() takes a DeviceAdminReceiver component as its argument:
application 이 활성화된 device admin application 의 동작을 실행하고자 한다면, application 이 활성화 되어 있음을 확인해야 한다. 이를 위해 DevicePolicyManager 의 isAdminActive() 메소드를 사용 할 수 있다. DevicePolicyManager 의 isAdminActive() 메소드는 DeviceAdminReceiver component 를 그 인자로 사용함을 알아둬라 :
DevicePolicyManager mDPM;
...
boolean active = mDPM.isAdminActive(mDeviceAdminSample);
if (active) {
// Admin app is active, so do some admin stuff
...
} else {
// do something else
}Managing policies
DevicePolicyManager is a public class for managing policies enforced on a device. DevicePolicyManager manages policies for one or more DeviceAdminReceiver instances.
DevicePolicyManager 는 기기에 강제된 정책을 관리하는 public class 이다.
DevicePolicyManager 는 하나 또는 이상의 DeviceAdminReceiver instance 를 위한 정책을 관리한다.
You get a handle to the DevicePolicyManager as follows:
당신은 다음과 같이 DevicePolicyManager 를 얻을 수 있다 :
DevicePolicyManager mDPM =
(DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
이 section 은 관리 업무를 위해 어떻게 DevicePolicyManager 를 사용하는지 기술한다 :
- password 정책 설정
- 기기 lock 설정
- data 삭제 실행
Set password policies
DevicePolicyManager includes 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.
DevicePolicyManager 는 기기의 password 정책을 설정하고 강제할 수 있는 API 를 포함한다. Device Administration API 에서, password 는 screen lock 에만 적용된다. 이 section 에서는 일반적인 password 에 관계된 동작에 대해 기술한다.
Set a password for the device
This code displays a user interface prompting the user to set a password:
아래의 코드는 사용자에게 password 를 설정하도록 하는 화면을 나타나게 한다 :
Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
startActivity(intent);
Set the password quality
PASSWORD_QUALITY_ALPHABETIC- The user must enter a password containing at least alphabetic (or other symbol) characters.
PASSWORD_QUALITY_ALPHANUMERIC- The user must enter a password containing at least both numeric and alphabetic (or other symbol) characters.
PASSWORD_QUALITY_NUMERIC- The user must enter a password containing at least numeric characters.
PASSWORD_QUALITY_SOMETHING- The policy requires some kind of password, but doesn't care what it is.
PASSWORD_QUALITY_UNSPECIFIED- The policy has no requirements for the password.
DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
...
mDPM.setPasswordQuality(mDeviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
Set the minimum password length
You can specify that a password must be at least the specified minimum length. For example:
다음과 같이 password 의 최소 길이를 설정 할 수 있다 :
DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
int pwLength;
...
mDPM.setPasswordMinimumLength(mDeviceAdminSample, pwLength);
Set maximum failed password attempts
You can set the maximum number of allowed failed password attempts before the device is wiped (that is, reset to factory settings). For example:
다음의 코드로 몇회의 password 입력 실패 시 기기의 data 삭제를 실행 할지 설정 할 수 있다 :
DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
int maxFailedPw;
...
mDPM.setMaximumFailedPasswordsForWipe(mDeviceAdminSample, maxFailedPw);
Set device lock
You can set the maximum period of user inactivity that can occur before the device locks. For example:
다음의 코드로 얼마 동안 사용자 입력이 없을 때 기기를 lock 할 지 설정 할 수 있다 :
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:
또한 다음과 같이 당장 기기를 lock 하도록 할 수도 있다 :
DevicePolicyManager mDPM;
mDPM.lockNow();
Perform data wipe
You can use the DevicePolicyManager method 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 usesetMaximumFailedPasswordsForWipe() to state that a device should be wiped after a specific number of failed password attempts.
DevicePolicyManager 의 wipeData() 메소드를 이용해 factory setting 으로 기기를 복원 시킬 수 있다. 이것은 기기를 잃었거나 도난 당했을 때 유용할 것이다. 종종 데이터 삭제는 여러 조건이 복합되었을 때 결정된다. 예를 들어, setMaximumFailedPasswordsForWipe() 를 이용해 여러번 password 입력이 실패했을 때에 데이터 삭제를 진행한다.
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.
wipeData() 메소드는 추가적인 옵션을 bit mask 로 해서 그 인자로 받는다.
현재로썬, 이 값은 반드시 0이어야 한다.
AlwaysOnTop.zip
