如果你是企業的系統管理員，
你可以從APIs及系統capabilities得到好處來管理Android裝置以及控管存取。
Device Administration
序言：
透過Android Device Administration API，Android 2.2引入了對於企業app的支援。
API在系統層級提供了Device Administration功能。
這些APIs允許你來製作在企業設定裡有用的有安全意識的(security-aware)app，
這些設定是IT專業需求對於大量企業裝置的控管。
舉例來說，Android內建的E-mail app已經槓桿了(leveraged)新的APIs來提升Exchange的支援。
透過E-mail app，Exchange系統管理員可以強制密碼政策，
當中包括字母數字組合(alphanumeric)的密碼或者數字的PINs(橫跨裝置)。
系統管理員也可以遠端wipe(也就是回復出廠預設值)弄丟或者失竊的手持裝置。
Exchange使用者可以同步處理他們的email以及行事曆資料。
這份文件是為了要給那些在Android裝置上發展企業解決方案的開發者的。
它討論了由Device Administration API所提供的多樣化功能，
來提供對雇員的Android裝置更強的安全性。
Device Administration API Overview：
下面是那些可能會用到Device Administration API的app種類。
1. Email clients。
2. 做remote wipe的安全app。
3. 裝置管理服務和app。
How does it work?
使用Device Administration API來寫入使用者安裝到他們的裝置的admin apps。
裝置的admin app強制執行所想要的政策(policies)。下面是它如何運作的模式:
1. 系統管理員寫一個device admin app用以強制遠端/本地裝置的安全性政策。
這些政策可以是在app裡被hard-coded的，或者app可以動態從第三方的server去取到。
2. app是被裝在使用者的裝置上的。Android現在並沒有一個自動化的安裝方案。
一個sysadmin可能散布app到使用者上的其中幾個方法如下:
a. Google Play。
b. 從另一個商店來打開安裝。
c. 其他方法來散布app，比如email或網站。
3. 系統提示使用者來啟動device admin app。如何及何時發生，
取決於app是如何被實作的。
4. 一旦使用者啟動了device admin app，他們就受其政策控管了。
執行這些政策在典型上授予了優勢，像是存取sensitive系統和資料。
如果使用者沒有啟動device admin app，它還是在裝置上但在不主動的模式。
使用者並不會遵循政策且任何app，相對來說也不會得到app的好處。
舉例來說，他們可能會沒辦法同步資料。
如果一個使用者沒能遵行policies(比如設定了一個違反指引的密碼)，
這會有app來決定要怎麼去處理它。
儘管如此，典型的狀況的結果大概會令使用者無法同步資料。
如果裝置試著去連接一個需求不在Device Administration API裡支援的server，
連線就不會被允許。
Device Administration API現在並不允許部分的provisioning。
換句話說，如果一個裝置(比如一個legacy device)並不支援所有被敘述的policies，
那麼沒有方法可以令裝置做連結。
如果一個裝置包含了多個啟動的admin apps最嚴格的policy會被執行。
沒有任何方法去以特定的admin app來做為目標。
要解除安裝已存在在裝置上的device admin app的話，
使用者需要先以系統管理員權限來反註冊該app。
Policies：
在企業的設定，狀況通常是，
員工的裝置必須依附到一組嚴格管制裝置使用的policies。
Device Administration API支援了下表所列的policies。
注意Device Administration API現在只支援password給螢幕鎖。
| 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. |
| Disable camera | 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. |
Other features:
除了支援上表列出的policies以外，
Device Administration API讓你做下面的事情：
1. 令使用者來設定新密碼。
2. 馬上鎖定裝置。
3. 清掉裝置的資料。(也就是回復裝置的原廠預設值)
Sample Application：
這份文件裡使用的範例是基於在SDK samples裡的Device Administration API sample，
要看下載安裝SDK samples的話，可以參照Getting the Samples。
範例程式提供了device admin功能的demo。
它給使用者一個借來藉以打開device admin app。
一旦他們打開了app，他們可以使用使用者介面的按鈕來做下面的事情:
1. 設定密碼品質。
2. 指定使用者密碼的需求，比如說最小長度，必須含有最小數字的碼數。
3. 設定密碼。如果密碼並沒有符合特定的policies，
系統會回傳error。
4. 設定在裝置被wipe掉之前，容許多少次密碼嘗試失敗。
5. 設定密碼從現在起多久會過期。
6. 設定密碼歷史長度。(長度是指存在歷史紀錄的舊密碼數目)
這防止了使用者使用前n次用過的密碼。
7. 指定哪個儲存區域必須被加密。(如果裝置支援的話)
8. 設定最大的非主動的時間可以容許(其後裝置上鎖)
9. 讓裝置自動上鎖。
10. 刷掉裝置的資料。
11. 關掉相機的功能。
Developing a Device Administration Application：
系統管理員可以使用Device Administration API來寫app，
用其來強制遠端/本地的裝置的安全政策執行。
這個段落總結了製作這樣子的app的步驟。
Creating the manifest:
要使用Device Administration API，
app的manifest必須包含下面的東西:
1. DeviceAdminReceiver的subclass，且包含下列:
a.
BIND_DEVICE_ADMIN的permission。b. 對於
ACTION_DEVICE_ADMIN_ENABLED intent做回應的能力。(在manifest裡以intent filter來表達)
2. 在metadata裡使用，對於security policies的聲明。
下面是manifest使用範例的片段:
<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>
注意到:
1. 下面的attributes，
參考到給sample app在ApiDemos/res/values/strings.xml裡的string資源。
在Application Resources可以看更多有關資源的部分。
a. android:label="@string/activity_sample_device_admin"參考到
user-readable的給activity的label。
b. android:label="@string/sample_device_admin"參考到
user-readable的給permission的label。
c. android:description="@string/sample_device_admin_description"參考到
user-readable描述(description)的permission。
一個描述通常比較長且比起label有更多資訊。
2. android:permission="android.permission.BIND_DEVICE_ADMIN"
是DeviceAdminReceiver的subclass必須要有的permissions，
用來確保只有系統可以和receiver互動。(沒有app可以被允許此授權)
這防止了其他app濫用你的device admin app。
3. android.app.action.DEVICE_ADMIN_ENABLED
是DeviceAdminReceiver的subclass必須要處理，
用來允許管理裝置的主要的action。
這是當使用者開始device admin app時設定到receiver的。
你的code基本上要在
onEnabled()裡做處理。要被支援的話，receiver一定要要求
BIND_DEVICE_ADMIN permission，使得其他apps不能濫用它。
4. 當一個使用者啟用device admin app時，這給了receiver許可權來執行actions，
去向特定的系統廣播做回應。當適合的event發生時，
app可以施予一個policy。
舉例來說，如果使用者嘗試建立一個不符合policy的新密碼，
app可以令使用者去選一個不同的密碼以符合要求。
5. android:resource="@xml/device_admin_sample"
聲明了被在metadata裡使用的security policies。
metadata提供了對裝置管理員有特別意義的附加資訊，
它被從DeviceAdminInfo class裡解析出來。
下面是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>
在設計你的device administration app的時候，
你不需要去包含所有的policies，
只需要做跟你的app有關的就可以了。
對於manifest file的更多討論，請見Android Developers Guide。
Implementing the code：
Device Administration API 包含了下面的classes:
DeviceAdminReceiver
基礎的class，用來實作一個device administration組件(component)。
這個class提供了對於被系統所傳送的raw intent actions的翻譯上的方便。
你的Device Administration app必須要include一個
DeviceAdminReceiver的subclass。DevicePolicyManager
一個用來管理在裝置上要被執行的policies的class。
大多數這個class的clients，
必需要已經發佈(published)一個使用者現在正啟用的DeviceAdminReceiver。
DevicePolicyManager管理一個或多個DeviceAdminReceiver的實例的policies。DeviceAdminInfo
這個class是用來指明一個device administrator組件的metadata。
這些classes提供了基礎給完整功能的device administration app。
剩下的段落會描述怎麼使用DeviceAdminReceiver和
DevicePolicyManager兩個APIs來寫一個device admin app。
Subclassing DeviceAdminReceiver：
要製作一個device admin app，你必須要開DeviceAdminReceiver的subclass。
DeviceAdminReceiver class是由一系列的callbacks所組成的，
它們在特定events發生時會被觸發。
在它的DeviceAdminReceiver subclass中，sample app簡單地顯示一個Toast提醒，
作為對於特定events的回應。
舉例來說:
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)); } ... }
Enabling the application：
一個device admin app必須要處理的主要的events中，
其中之一是讓使用者啟用app。
使用者必須要明確地啟動app來讓policies被執行。
如果使用者選擇不去啟動app，
它仍舊會在裝置上被展示，但它的policies就不會被執行，
且使用者將不會獲得任何這個app所帶來的好處。
啟用app的程序會在使用者執行會觸發ACTION_ADD_DEVICE_ADMIN intent的action時開始。
在這個sample app哩，這會在使用者按下Enable Admin的checkbox時發生。
當使用者點下Enable Admin的checkbox時，
顯示螢幕會切換令使用者來選擇啟動device admin app，如下圖所示。
下面是那些當使用者點下Enable Admin的checkbox時，
所會執行的code。這個callback會在Preference的value被使用者改變，
且準備要被設定且/或堅持時，被喚起(invoked)。
如果使用者正在啟用app，
就會如上圖那樣切換顯示令使用者來啟用。
其他狀況的話，device admin app是被關掉的。
@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; }
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample)這行，
敘述
mDeviceAdminSample(是一個DeviceAdminReceiver組件)是目標的policy。這行喚起了使用者的介面(如上面的圖所示)，
用來指引使用者來新增device administrator到系統(或者允許它們去拒絕它)。
當app需要去執行一個operation，附隨在正在啟用狀態的device admin app，
它確認了app是啟動的(active)。為了要做到這點，
它使用了
DevicePolicyManager的method isAdminActive()。注意的
DevicePolicyManager的method isAdminActive()取用一個DeviceAdminReceiver組件作為它的參數:
DevicePolicyManager mDPM; ... private boolean isActiveAdmin() { return mDPM.isAdminActive(mDeviceAdminSample); }
Managing policies：
DevicePolicyManager是一個public class，管理著被執行在裝置上的policies。
DevicePolicyManager管理policies給一個或多個
DeviceAdminReceiver 實例。透過下面的程式碼取得對於DevicePolicyManager的掌控:
DevicePolicyManager mDPM = (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
這個段落描述了如何使用DevicePolicyManager來進行管理員工作:
1. 設定密碼的policies
2. 設定裝置鎖
3. 執行資料wipe
Set password policies：
DevicePolicyManager包含了APIs給設定和執行裝置密碼的policy。
在Device Administration API，密碼只會在螢幕鎖上面被使用。
這個段落描述了常見的密碼相關的工作。
Set a password for the device:
這個code顯示了一個使用者介面，令使用者設定一個密碼:
Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); startActivity(intent);
Set the password quality:
密碼品質可以是下面的的DevicePolicyManager的常數之一：
使用者必須輸入至少含有英文字母(或其他符號)的字元的密碼。
使用者必須輸入至少含有數字+英文(或其他符號)的字元的密碼。
使用者必須輸入至少含有數字的字元的密碼。
PASSWORD_QUALITY_COMPLEX
使用者必須輸入至少含有一個字母，一個數字，以及一個特殊符號的密碼。
這個policy需要某種類的密碼，但是不關心它到底是什麼。
PASSWORD_QUALITY_UNSPECIFIED
這個policy對於密碼沒有任何要求。
舉例來說，如果你要把密碼的policy設為需要字母+數字的密碼:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; ... mDPM.setPasswordQuality(mDeviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
Set password content requirements:
從Android 3.0開始，
DevicePolicyManager class包括了那些methods，讓你可以微調密碼的內容，你可以設定一個policy，
讓其敘述密碼必須要含有至少n個大寫字母。
這裡是讓微調一個密碼的內容所使用的methods:
setPasswordMinimumLetters()setPasswordMinimumLowerCase()setPasswordMinimumUpperCase()setPasswordMinimumNonLetter()setPasswordMinimumNumeric()setPasswordMinimumSymbols()
舉例來說，下面的片段描述了密碼至少要有兩個大寫字母:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; int pwMinUppercase = 2; ... mDPM.setPasswordMinimumUpperCase(mDeviceAdminSample, pwMinUppercase);
Set the minimum password length:
你可以指定讓密碼最少要有指定的最小長度，
舉例來說:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; int pwLength; ... mDPM.setPasswordMinimumLength(mDeviceAdminSample, pwLength);
Set maximum failed password attempts:
你可以設定在wipe掉裝置前，最大所允許失敗的密碼嘗試次數。
舉例來說:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; int maxFailedPw; ... mDPM.setMaximumFailedPasswordsForWipe(mDeviceAdminSample, maxFailedPw);
Set password expiration timeout:
從Android 3.0起，
你可以使用setPasswordExpirationTimeout()的method，
來設定何時密碼會過期，
它是以一個毫秒的差值來表示的。
(從裝置管理設定了過期時間後)
舉例來說:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; long pwExpiration; ... mDPM.setPasswordExpirationTimeout(mDeviceAdminSample, pwExpiration);
Restrict password based on history:
從Android 3.0開始，
你可以使用setPasswordHistoryLength()的method來限制使用者重新使用舊密碼。
這個method需要一個長度的參數，來指定有多少舊密碼被存起來。
當這個policy是啟用時，使用者不能輸入一個會跟前n個密碼相符的新密碼。
這防止了使用者重複使用同樣的密碼。
這個policy典型來說常和
setPasswordExpirationTimeout()配合使用，用來強迫使用者在經過指定的時間後要更新他們的密碼。
舉例來說，這個片段禁止使用者重新使用前5個用過的密碼:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; int pwHistoryLength = 5; ... mDPM.setPasswordHistoryLength(mDeviceAdminSample, pwHistoryLength);
Set device lock:
你可以設定最大的使用者可以不主動的期間，
在那之後裝置就會鎖上。
舉例來說:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; ... long timeMs = 1000L*Long.parseLong(mTimeout.getText().toString()); mDPM.setMaximumTimeToLock(mDeviceAdminSample, timeMs);
你也可以程式化地告訴裝置現在立刻上鎖裝置:
DevicePolicyManager mDPM; mDPM.lockNow();
Perform data wipe:
你可以使用DevicePolicyManager的wipeData() method，
來重設裝置到原廠預設值。
這在裝置不見或被偷時很有用。
通常清裝置的決定是因為碰到特定的狀況。
舉例來說，你可以使用
setMaximumFailedPasswordsForWipe()來敘述一個裝置應該在指定次數的錯誤密碼嘗試後，被清掉資料。
你可以如下進行清除資料:
DevicePolicyManager mDPM; mDPM.wipeData(0);
wipeData()的method拿它的參數作為一個bit mask來應用在額外的狀況。
當前的值必須為0。
Disable camera:
從Android 4.0開始，你可以停用相機功能。
注意這並不需要是永久的停用。
相機可以基於context，時間，及其他東西，
來動態地開/關。
使用setCameraDisabled()的method來控管相機是否是關的。
舉例來說，這個片段將相機設定為開或關，
是基於一個checkbox的設定值:
private CheckBoxPreference mDisableCameraCheckbox; DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; ... mDPM.setCameraDisabled(mDeviceAdminSample, mDisableCameraCheckbox.isChecked());
Storage encryption:
從Android 3.0開始，你可以使用
setStorageEncryption()的method，在來設定一個需求對儲存空間的加密的policy(當有支援的時候)。
舉例來說:
DevicePolicyManager mDPM; ComponentName mDeviceAdminSample; ... mDPM.setStorageEncryption(mDeviceAdminSample, true);
可以參見Device Administration API sample來看完整示範如何開啟空間加密的範例。
