1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
|
page.title=Device Administration
page.tags=devicepolicymanager,policy,security
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>In this document</h2>
<ol>
<li><a href="#overview">Device Administration API Overview</a>
<ol>
<li><a href="#how">How does it work?</a></li>
<li><a href="#policies">Policies</a></li>
</ol>
</li>
<li><a href="#sample">Sample Application</a></li>
<li><a href="#developing">Developing a Device Administration Application</a>
<ol>
<li><a href="#manifest">Creating the manifest</a></li>
<li><a href="#code">Implementing the code</a></li>
</ol>
</li>
</ol>
<h2>Key classes</h2>
<ol>
<li>{@link android.app.admin.DeviceAdminReceiver}</li>
<li>{@link android.app.admin.DevicePolicyManager}</li>
<li>{@link android.app.admin.DeviceAdminInfo}</li>
</ol>
</div>
</div>
<p>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.</p>
<p>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.</p>
<h2 id="overview">Device Administration API Overview</h2>
<p>Here are examples of the types of applications that might use the Device Administration API:</p>
<ul>
<li>Email clients.</li>
<li>Security applications that do remote wipe.</li>
<li>Device management services and applications.</li>
</ul>
<h3 id="how">How does it work?</h3>
<p>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:</p> <ul>
<li>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. </li>
<li>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:
<ul>
<li>Google Play.</li>
<li>Enabling installation from another store.</li>
<li>Distributing the application through other means, such as email or websites.</li>
</ul>
</li>
<li>The system prompts the user to enable the device admin application. How
and when this happens depends on how the application is implemented.</li>
<li>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.</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>If a device contains multiple enabled admin applications, the strictest policy is
enforced. There is no way to target a particular admin
application.</p>
<p>To uninstall an existing device admin application, users need to
first unregister the application as an administrator. </p>
<h3 id="policies">Policies</h3>
<p>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:</p>
<p class="table-caption"><strong>Table 1.</strong> Policies supported by the Device Administration API.</p>
<table border="1">
<tr>
<th>Policy</th>
<th>Description</th>
</tr>
<tr>
<td>Password enabled</td>
<td>Requires that devices ask for PIN or passwords.</td>
</tr>
<tr>
<td>Minimum password length</td>
<td>Set the required number of characters for the password. For example, you
can require PIN or passwords to have at least six characters. </td> </tr>
<tr>
<td>Alphanumeric password required</td>
<td>Requires that passwords have a
combination of letters and numbers. They may include symbolic characters.
</td>
</tr>
<tr>
<td>Complex password required</td>
<td>Requires that passwords must contain at least a letter, a numerical digit, and a special symbol. Introduced in Android 3.0.
</td>
</tr>
<tr>
<td>Minimum letters required in password</td> <td>The minimum number of
letters required in the password for all admins or a particular one. Introduced in Android 3.0.</td>
</tr>
<tr>
<td>Minimum lowercase letters required in password</td>
<td>The minimum number of lowercase
letters required in the password for all admins or a particular one. Introduced in Android 3.0.</td>
</tr>
<tr>
<td>Minimum non-letter characters required in password</td>
<td>The minimum number of
non-letter characters required in the password for all admins or a particular one. Introduced in Android 3.0.</td>
</tr>
<tr>
<td>Minimum numerical digits required in password</td>
<td>The minimum number of numerical digits required in the password for all admins or a particular one. Introduced in Android 3.0.</td>
</tr>
<tr>
<td>Minimum symbols required in password</td>
<td>The minimum number of symbols required in the password for all admins or a particular one. Introduced in Android 3.0.</td>
</tr>
<tr>
<td>Minimum uppercase letters required in password</td>
<td>The minimum number of uppercase letters required in the password for all admins or a particular one. Introduced in Android 3.0.</td>
</tr>
<tr>
<td>Password expiration timeout</td>
<td>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.</td>
</tr>
<tr>
<td>Password history restriction</td>
<td>This policy prevents users from reusing the last <em>n</em> unique passwords.
This policy is typically used in conjunction with
{@link android.app.admin.DevicePolicyManager#setPasswordExpirationTimeout(android.content.ComponentName,long) setPasswordExpirationTimeout()}, which forces
users to update their passwords after a specified amount of time has elapsed.
Introduced in Android 3.0.</td>
</tr>
<tr>
<td>Maximum failed password attempts </td>
<td>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.</td>
</tr>
<tr>
<td>Maximum inactivity time lock</td>
<td>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.</td> </tr>
<tr>
<td>Require storage encryption</td>
<td>Specifies that the storage area should be encrypted, if the device supports it.
Introduced in Android 3.0.</td> </tr>
<tr>
<td>Disable camera</td>
<td>Specifies that the camera should be disabled. 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. Introduced in Android 4.0.</td>
</tr>
</table>
<h4>Other features</h4>
<p>In addition to supporting the policies listed in the above table, the Device
Administration API lets you do the following:</p> <ul>
<li>Prompt user to set a new password.</li>
<li>Lock device immediately.</li>
<li>Wipe the device's data (that is, restore the device to its factory defaults).</li>
</ul>
<h2 id="sample">Sample Application</h2>
<p>The examples used in this document are based on the Device Administration API
sample, which is included in the SDK samples (available through the
Android SDK Manager) and located on your system as
<code><sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java</code>.</p>
<p>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:</p>
<ul>
<li>Set password quality.</li>
<li>Specify requirements for the user's password, such as minimum length, the minimum number of
numeric characters it must contain, and so on.</li>
<li>Set the password. If the password does not conform to the specified
policies, the system returns an error.</li>
<li>Set how many failed password attempts can occur before the device is wiped
(that is, restored to factory settings).</li>
<li>Set how long from now the password will expire.</li>
<li>Set the password history length (<em>length</em> refers to number of old passwords stored in the history).
This prevents users from reusing
one of the last <em>n</em> passwords they previously used.</li>
<li>Specify that the storage area should be encrypted, if the device supports it.</li>
<li>Set the maximum amount of inactive time that can elapse before the device
locks.</li>
<li>Make the device lock immediately.</li>
<li>Wipe the device's data (that is, restore factory settings).</li>
<li>Disable the camera.</li>
</ul>
<img src="{@docRoot}images/admin/device-admin-app.png"/>
<p class="img-caption"><strong>Figure 1.</strong> Screenshot of the Sample Application</p>
<h2 id="developing">Developing a Device Administration Application</h2>
<p>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.</p>
<h3 id="manifest">Creating the manifest</h3>
<p>To use the Device Administration API, the application's
manifest must include the following:</p>
<ul>
<li>A subclass of {@link android.app.admin.DeviceAdminReceiver} that includes the following:
<ul>
<li>The {@link android.Manifest.permission#BIND_DEVICE_ADMIN} permission.</li>
<li>The ability to respond to the {@link android.app.admin.DeviceAdminReceiver#ACTION_DEVICE_ADMIN_ENABLED}
intent, expressed in the manifest as an intent filter.</li>
</ul>
</li>
<li>A declaration of security policies used in metadata.</li>
</ul>
<p>Here is an excerpt from the Device Administration sample manifest:</p>
<pre><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">
<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></pre>
<p>Note that:</p>
<ul>
<li>The following attributes refer to string resources that for the sample application reside in
<code>ApiDemos/res/values/strings.xml</code>. For more information about resources, see
<a
href="{@docRoot}guide/topics/resources/index.html">Application Resources</a>.
<ul>
<li><code>android:label="@string/activity_sample_device_admin"</code> refers to the
user-readable label for the activity.</li>
<li><code>android:label="@string/sample_device_admin"</code> refers to the
user-readable label for the permission.</li>
<li><code>android:description="@string/sample_device_admin_description"</code> refers to
the user-readable description of the permission. A descripton is typically longer and more
informative than
a label.</li>
</ul>
<li><code>android:permission="android.permission.BIND_DEVICE_ADMIN"
</code> is a permission that a {@link android.app.admin.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.</li>
<li><code>android.app.action.DEVICE_ADMIN_ENABLED</code> is the primary
action that a {@link android.app.admin.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
{@link android.app.admin.DeviceAdminReceiver#onEnabled onEnabled()}. To be supported, the receiver must also
require the {@link android.Manifest.permission#BIND_DEVICE_ADMIN} permission so that other applications
cannot abuse it. </li>
<li>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.</li>
<li><code>android:resource="@xml/device_admin_sample"</code>
declares the security policies used in metadata. The metadata provides additional
information specific to the device administrator, as parsed by the {@link
android.app.admin.DeviceAdminInfo} class. Here are the contents of
<code>device_admin_sample.xml</code>:</li>
</ul>
<pre><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>
</pre>
<p> 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.
</p>
For more discussion of the manifest file, see the <a
href="{@docRoot}guide/topics/manifest/manifest-intro.html">Android Developers Guide</a>.
<h3 id="code">Implementing the code</h3>
<p>The Device Administration API includes the following classes:</p>
<dl>
<dt>{@link android.app.admin.DeviceAdminReceiver}</dt>
<dd>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
{@link android.app.admin.DeviceAdminReceiver} subclass.</dd>
<dt>{@link android.app.admin.DevicePolicyManager}</dt>
<dd>A class for managing policies enforced on a device. Most clients of
this class must have published a {@link android.app.admin.DeviceAdminReceiver} that the user
has currently enabled. The {@link android.app.admin.DevicePolicyManager} manages policies for
one or more {@link android.app.admin.DeviceAdminReceiver} instances</dd>
<dt>{@link android.app.admin.DeviceAdminInfo}</dt>
<dd>This class is used to specify metadata
for a device administrator component.</dd>
</dl>
<p>These classes provide the foundation for a fully functional device administration application.
The rest of this section describes how you use the {@link
android.app.admin.DeviceAdminReceiver} and
{@link android.app.admin.DevicePolicyManager} APIs to write a device admin application.</p>
<h4 id="receiver">Subclassing DeviceAdminReceiver</h4>
<p>To create a device admin application, you must subclass
{@link android.app.admin.DeviceAdminReceiver}. The {@link android.app.admin.DeviceAdminReceiver} class
consists of a series of callbacks that are triggered when particular events
occur.</p>
<p>In its {@link android.app.admin.DeviceAdminReceiver} subclass, the sample application
simply displays a {@link android.widget.Toast} notification in response to particular
events. For example:</p>
<pre>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));
}
...
}</pre>
<h4 id="enabling">Enabling the application</h4>
<p>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.</p>
<p>The process of enabling the application begins when the user performs an
action that triggers the {@link android.app.admin.DevicePolicyManager#ACTION_ADD_DEVICE_ADMIN}
intent. In the
sample application, this happens when the user clicks the <strong>Enable
Admin</strong> checkbox. </p>
<p>When the user clicks the <strong>Enable Admin</strong> checkbox, the display
changes to prompt the user to activate the device admin application, as shown in figure
2.</p>
<img src="{@docRoot}images/admin/device-admin-activate-prompt.png"/>
<p class="img-caption"><strong>Figure 2.</strong> Sample Application: Activating the Application</p>
<p>Below is the code that gets executed when the user clicks the <strong>Enable Admin</strong> checkbox. This has the effect of triggering the
{@link android.preference.Preference.OnPreferenceChangeListener#onPreferenceChange(android.preference.Preference, java.lang.Object) onPreferenceChange()}
callback. This callback is invoked when the value of this {@link android.preference.Preference} has 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. </p>
<pre>@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;
}</pre>
<p>The line
<code>intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample)</code> states that <code>mDeviceAdminSample</code> (which is
a {@link android.app.admin.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).</p>
<p>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 {@link android.app.admin.DevicePolicyManager} method
{@link android.app.admin.DevicePolicyManager#isAdminActive(android.content.ComponentName) isAdminActive()}. Notice that the {@link android.app.admin.DevicePolicyManager}
method {@link android.app.admin.DevicePolicyManager#isAdminActive(android.content.ComponentName) isAdminActive()} takes a {@link android.app.admin.DeviceAdminReceiver}
component as its argument:</p>
<pre>
DevicePolicyManager mDPM;
...
private boolean isActiveAdmin() {
return mDPM.isAdminActive(mDeviceAdminSample);
}
</pre>
<h3 id="admin_ops">Managing policies</h3>
<p>{@link android.app.admin.DevicePolicyManager} is a public class for managing policies
enforced on a device. {@link android.app.admin.DevicePolicyManager} manages policies for one
or more {@link android.app.admin.DeviceAdminReceiver} instances. </p>
<p>You get a handle to the {@link android.app.admin.DevicePolicyManager} as follows: </p>
<pre>
DevicePolicyManager mDPM =
(DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
</pre>
<p>This section describes how to use {@link android.app.admin.DevicePolicyManager} to perform
administrative tasks:</p>
<ul>
<li><a href="#pwd">Set password policies</a></li>
<li><a href="#lock">Set device lock</a></li>
<li><a href="#wipe">Perform data wipe</a></li>
</ul>
<h4 id="pwd">Set password policies</h4>
<p>{@link android.app.admin.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.</p>
<h5>Set a password for the device</h5>
<p>This code displays a user interface prompting the user to set a password:</p>
<pre>Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
startActivity(intent);
</pre>
<h5>Set the password quality</h5>
<p>The password quality can be one of the following {@link android.app.admin.DevicePolicyManager} constants: </p>
<dl>
<dt>{@link android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_ALPHABETIC}</dt><dd>The user must enter a
password containing at least alphabetic (or other symbol) characters.</dd>
<dt>{@link android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_ALPHANUMERIC}</dt><dd>The user must enter a
password containing at least <em>both</em> numeric <em>and</em> alphabetic (or
other symbol) characters.</dd>
<dt>{@link android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_NUMERIC}</dt><dd>The user must enter a password
containing at least numeric characters.</dd>
<dt>{@link
android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_COMPLEX}</dt><dd>The user
must have entered a password containing at least a letter, a numerical digit and
a special symbol.</dd>
<dt>{@link
android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_SOMETHING}</dt><dd>The
policy requires some kind
of password, but doesn't care what it is.</dd>
<dt>{@link android.app.admin.DevicePolicyManager#PASSWORD_QUALITY_UNSPECIFIED}</dt><dd>
The policy has no requirements for the password. </dd>
</dl>
<p>For example, this is how you would set the password policy to require an alphanumeric password:</p>
<pre>
DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
...
mDPM.setPasswordQuality(mDeviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
</pre>
<h5>Set password content requirements</h5>
<p>Beginning with Android 3.0, the {@link android.app.admin.DevicePolicyManager} class
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
<em>n</em> uppercase letters. Here are the methods for fine-tuning a password's
contents:</p>
<ul>
<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumLetters(android.content.ComponentName,int) setPasswordMinimumLetters()}</li>
<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumLowerCase(android.content.ComponentName,int) setPasswordMinimumLowerCase()}</li>
<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumUpperCase(android.content.ComponentName,int) setPasswordMinimumUpperCase()}</li>
<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumNonLetter(android.content.ComponentName,int) setPasswordMinimumNonLetter()}</li>
<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumNumeric(android.content.ComponentName,int) setPasswordMinimumNumeric()}</li>
<li>{@link android.app.admin.DevicePolicyManager#setPasswordMinimumSymbols(android.content.ComponentName,int) setPasswordMinimumSymbols()}</li>
</ul>
<p>For example, this snippet states that the password must have at least 2 uppercase letters:</p>
<pre>
DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
int pwMinUppercase = 2;
...
mDPM.setPasswordMinimumUpperCase(mDeviceAdminSample, pwMinUppercase);</pre>
<h5>Set the minimum password length</h5>
<p>You can specify that a password must be at least the specified minimum
length. For example:</p>
<pre>DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
int pwLength;
...
mDPM.setPasswordMinimumLength(mDeviceAdminSample, pwLength);
</pre>
<h5>Set maximum failed password attempts</h5>
<p>You can set the maximum number of allowed failed password attempts before the
device is wiped (that is, reset to factory settings). For example:</p>
<pre>DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
int maxFailedPw;
...
mDPM.setMaximumFailedPasswordsForWipe(mDeviceAdminSample, maxFailedPw);</pre>
<h5 id="expiration">Set password expiration timeout</h5>
<p>Beginning with Android 3.0, you can use the
{@link android.app.admin.DevicePolicyManager#setPasswordExpirationTimeout(android.content.ComponentName,long) 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:</p>
<pre>DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
long pwExpiration;
...
mDPM.setPasswordExpirationTimeout(mDeviceAdminSample, pwExpiration);
</pre>
<h5 id="history">Restrict password based on history</h5>
<p>Beginning with Android 3.0, you can use the
{@link android.app.admin.DevicePolicyManager#setPasswordHistoryLength(android.content.ComponentName,int) setPasswordHistoryLength()}
method to limit users'
ability to reuse old passwords. This method takes a <em>length</em>
parameter, which specifies how many old
passwords are stored. When this policy is active, users cannot enter a new
password that matches the last <em>n</em> passwords. This prevents
users from using the same password over and over. This policy is typically used
in conjunction with
{@link android.app.admin.DevicePolicyManager#setPasswordExpirationTimeout(android.content.ComponentName,long) setPasswordExpirationTimeout()},
which forces users
to update their passwords after a specified amount of time has elapsed. </p>
<p>For example, this snippet prohibits users from reusing any of their last 5 passwords:</p>
<pre>DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
int pwHistoryLength = 5;
...
mDPM.setPasswordHistoryLength(mDeviceAdminSample, pwHistoryLength);
</pre>
<h4 id="lock">Set device lock</h4>
<p>You can set the maximum period of user inactivity that can occur before the
device locks. For example:</p>
<pre>
DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
...
long timeMs = 1000L*Long.parseLong(mTimeout.getText().toString());
mDPM.setMaximumTimeToLock(mDeviceAdminSample, timeMs);
</pre>
<p>You can also programmatically tell the device to lock immediately:</p>
<pre>
DevicePolicyManager mDPM;
mDPM.lockNow();
</pre>
<h4 id="wipe">Perform data wipe</h4>
<p>You can use the {@link android.app.admin.DevicePolicyManager} method
{@link android.app.admin.DevicePolicyManager#wipeData 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
{@link android.app.admin.DevicePolicyManager#setMaximumFailedPasswordsForWipe setMaximumFailedPasswordsForWipe()} to state that a device should be
wiped after a specific number of failed password attempts.</p>
<p>You wipe data as follows:</p>
<pre>
DevicePolicyManager mDPM;
mDPM.wipeData(0);</pre>
<p>The {@link android.app.admin.DevicePolicyManager#wipeData wipeData()} method takes as its
parameter a bit mask of additional options. Currently the value must be 0. </p>
<h4>Disable camera</h4>
<p>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. </p>
<p>You control whether the camera is disabled by using the
{@link android.app.admin.DevicePolicyManager#setCameraDisabled(android.content.ComponentName, boolean) setCameraDisabled()} method. For example, this snippet sets the camera to be enabled or disabled based on a checkbox setting:</p>
<pre>private CheckBoxPreference mDisableCameraCheckbox;
DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
...
mDPM.setCameraDisabled(mDeviceAdminSample, mDisableCameraCheckbox.isChecked());<br />
</pre>
<h4 id="storage">Storage encryption</h4>
<p>Beginning with Android 3.0, you can use the
{@link android.app.admin.DevicePolicyManager#setStorageEncryption(android.content.ComponentName,boolean) setStorageEncryption()}
method to set a policy requiring encryption of the storage area, where supported.</p>
<p>For example:</p>
<pre>
DevicePolicyManager mDPM;
ComponentName mDeviceAdminSample;
...
mDPM.setStorageEncryption(mDeviceAdminSample, true);
</pre>
<p>
See the Device Administration API sample for a complete example of how to enable storage encryption.
</p>
|