Wycofanie aplikacji do zarządzania urządzeniem. Od Androida 9 (poziom API 28) niektóre zasady administratora będą oznaczone jako wycofane, gdy zostaną wywołane przez administratora urządzenia. Zalecamy, aby już teraz zacząć się do niej przygotowywać. Więcej informacji oraz opcje migracji znajdziesz w artykule Wycofanie funkcji administracyjnych urządzeń.
Android obsługuje aplikacje firmowe dzięki interfejsowi Android Device Administration API. Interfejs Device Administration API udostępnia funkcje zarządzania urządzeniami na poziomie systemu. Te interfejsy API umożliwiają tworzenie aplikacji z funkcjami bezpieczeństwa, które są przydatne w środowiskach korporacyjnych, w których specjaliści IT potrzebują rozbudowanej kontroli nad urządzeniami pracowników. Na przykład wbudowana aplikacja poczty e-mail na Androida korzysta z tych interfejsów API, aby poprawić obsługę Exchange. Za pomocą aplikacji Poczta administratorzy Exchange mogą egzekwować zasady dotyczące haseł (w tym alfanumerycznych haseł i kodów PIN) na różnych urządzeniach. Administratorzy mogą też zdalnie czyścić (czyli przywrócić do ustawień fabrycznych) utracone lub skradzione telefony. Użytkownicy Exchange mogą zsynchronizować dane poczty e-mail i kalendarza.
Ten dokument jest przeznaczony dla programistów, którzy chcą tworzyć rozwiązania korporacyjne na urządzenia z Androidem. W tym artykule omawiamy różne funkcje interfejsu Device Administration API, które zapewniają większą ochronę urządzeń pracowników z Androidem.
Uwaga: informacje o tworzeniu kontrolera zasad służbowych na potrzeby wdrożeń Androida dla firm znajdziesz w artykule Tworzenie kontrolera zasad dotyczących urządzeń.
Tryb właściciela urządzenia bez interfejsu graficznego
Android 14 (poziom interfejsu API 34) wprowadza tryb użytkownika systemowego bez interfejsu graficznego (urządzenia, w których UserManager.isHeadlessSystemUserMode zwraca true). W tym trybie użytkownik systemowy jest użytkownikiem w tle i korzysta z dodatkowych użytkowników w planie pierwszym do interakcji z użytkownikiem końcowym. Android 14 wprowadza też tryb powiązania z urządzeniem bez interfejsu graficznego, który dodaje właściciela profilu do wszystkich powiązanych użytkowników, z wyjątkiem użytkownika systemu, na którym ustawiono właściciela urządzenia.
W przypadku urządzeń skonfigurowanych z użyciem bezgłowy użytkownik systemu (gdzie użytkownik systemu działa w tle) tylko zasady urządzenia o zasięgu globalnym (zasady obowiązujące wszystkich użytkowników) są stosowane do użytkowników na pierwszym planie. Więcej informacji znajdziesz w sekcji addUserRestriction.
Producenci urządzeń z Androidem mogą skorzystać z wskazówek opublikowanych na stronie source.android.com.
Omówienie interfejsu API administracji urządzeniami
Oto przykłady typów aplikacji, które mogą używać interfejsu Device Administration API:
- Wysyłanie e-maili do klientów.
- aplikacje zabezpieczające, które umożliwiają zdalne czyszczenie;
- Usługi i aplikacje do zarządzania urządzeniami.
Jak to działa?
Interfejs Device Administration API służy do tworzenia aplikacji administracyjnych, które użytkownicy instalują na swoich urządzeniach. Aplikacja administratora urządzenia wymusza stosowanie odpowiednich zasad. Jak to działa:
- Administrator systemu tworzy aplikację do zarządzania urządzeniem, która wymusza stosowanie zasad bezpieczeństwa urządzeń zdalnych lub lokalnych. Te zasady mogą być zakodowane w aplikacji lub pobierane dynamicznie z zewnętrznego serwera.
- Aplikacja została zainstalowana na urządzeniach użytkowników. Android nie ma obecnie automatycznego rozwiązania do obsługi wdrożenia. Oto kilka sposobów dystrybucji aplikacji przez administratora systemu:
- Google Play.
- Włączanie instalacji z innego sklepu.
- rozpowszechnianie aplikacji za pomocą innych środków, takich jak e-maile czy strony internetowe;
- System prosi użytkownika o włączenie aplikacji do administrowania urządzeniem. Sposób i czas wykonania tej czynności zależy od tego, jak aplikacja została zaimplementowana.
- Gdy użytkownicy włączą aplikację administratora urządzenia, będą podlegać jej zasadom. Ich przestrzeganie zwykle przynosi korzyści, np. dostęp do poufnych systemów i danych.
Jeśli użytkownicy nie włączą aplikacji administratora urządzenia, pozostanie ona na urządzeniu, ale w stanie nieaktywnym. Użytkownicy nie będą podlegać jej zasadom i nie będą mogli korzystać z żadnych jej funkcji, np. nie będą mogli synchronizować danych.
Jeśli użytkownik nie przestrzega zasad (np. ustawia hasło, które narusza wytyczne), aplikacja sama decyduje, jak sobie z tym poradzić. Zazwyczaj jednak spowoduje to, że użytkownik nie będzie mógł zsynchronizować danych.
Jeśli urządzenie spróbuje połączyć się z serwerem, który wymaga zasad nieobsługiwanych przez interfejs Device Administration API, połączenie nie zostanie dozwolone. Interfejs Device Administration API nie umożliwia obecnie częściowego udostępniania. Inaczej mówiąc, jeśli urządzenie (np. starsze) nie obsługuje wszystkich podanych zasad, nie ma możliwości zezwolenia mu na połączenie.
Jeśli na urządzeniu jest włączonych kilka aplikacji administratora, obowiązuje najbardziej restrykcyjna zasada. Nie można kierować reklam na konkretne aplikacje administratora.
Aby odinstalować istniejącą aplikację administratora urządzenia, użytkownicy muszą najpierw wyrejestrować ją jako administratora.
Zasady
W firmie często zdarza się, że urządzenia pracowników muszą być zgodne ze ścisłymi zasadami regulującymi ich użytkowanie. Interfejs Device Administration API obsługuje zasady wymienione w tabeli 1. Uwaga: interfejs Device Administration API obsługuje obecnie tylko hasła do blokady ekranu:
Tabela 1. Zasady obsługiwane przez interfejs Device Administration API.
| Zasady | Opis |
|---|---|
| Hasło włączone | Wymaga, aby urządzenia prosiły o kod PIN lub hasło. |
| Minimalna długość hasła | Ustaw wymaganą liczbę znaków w hasłach. Możesz na przykład wymagać, aby kody PIN lub hasła miały co najmniej 6 znaków. |
| Wymagane hasło ze znakami alfanumerycznymi | Hasła muszą zawierać kombinację liter i cyfr. Mogą zawierać znaki symboliczne. |
| Wymagane złożone hasło | Hasła muszą zawierać co najmniej 1 literę, 1 cyfrę i 1 znak specjalny. Wprowadzona w Androidzie 3.0. |
| Minimalna liczba liter w hasłach | Minimalna liczba liter wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0. |
| Minimalna liczba małych liter wymagana w hasłach | Minimalna liczba małych liter wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0. |
| Minimalna liczba znaków innych niż litery wymagana w haśle | Minimalna liczba znaków niebędących literami wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0. |
| Minimalna liczba cyfr w hasłach | Minimalna liczba cyfr wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0. |
| Minimalna liczba symboli wymagana w haśle | Minimalna liczba znaków wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0. |
| Minimalna liczba wielkich liter w haśle | Minimalna liczba wielkich liter wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0. |
| Limit czasu wygaśnięcia hasła | Data wygaśnięcia hasła wyrażona jako różnica w milisekundach od momentu ustawienia przez administratora urządzenia czasu wygaśnięcia. Wprowadzona w Androidzie 3.0. |
| Ograniczenie dotyczące historii haseł | Ta zasada uniemożliwia użytkownikom ponowne użycie ostatnich n unikalnych haseł.
Ta zasada jest zwykle używana w połączeniu z zasadą setPasswordExpirationTimeout(), która wymusza na użytkownikach zaktualizowanie haseł po upływie określonego czasu.
Wprowadzona w Androidzie 3.0. |
| Maksymalna liczba nieudanych prób podania hasła | Określa, ile razy użytkownik może podać nieprawidłowe hasło, zanim urządzenie usunie dane. Interfejs Device Administration API umożliwia też administratorom zdalne przywracanie urządzenia do ustawień fabrycznych. Dzięki temu dane pozostają chronione w przypadku zgubienia lub kradzieży urządzenia. |
| Maksymalny czas bezczynności, po którym włącza się blokada | Określa czas od ostatniego dotknięcia ekranu lub naciśnięcia przycisku do zablokowania ekranu. W takim przypadku użytkownicy muszą ponownie wpisać kod PIN lub hasła, aby móc korzystać z urządzeń i dostępu do danych. Wartość może wynosić od 1 do 60 minut. |
| Wymaganie szyfrowania przechowywanych danych | Określa, że obszar pamięci powinien być zaszyfrowany, jeśli urządzenie obsługuje szyfrowanie. Wprowadzona w Androidzie 3.0. |
| Wyłącz kamerę | Określa, że kamera powinna być wyłączona. Pamiętaj, że nie musisz wyłączyć funkcji na stałe. Aparat może być włączany/wyłączany dynamicznie na podstawie kontekstu, czasu itp. Wprowadzona w Androidzie 4.0. |
Inne funkcje
Oprócz obsługi zasad wymienionych w tabeli powyżej interfejs Device Administration API umożliwia też:
- Poproś użytkownika o ustawienie nowego hasła.
- natychmiast zablokować urządzenie,
- Wyczyść dane urządzenia (czyli przywróć urządzenie do ustawień fabrycznych).
Przykładowa aplikacja
Przykłady na tej stronie są oparte na przykładowym interfejsie Device Administration API, który jest dostępny w przykładach pakietu SDK (dostępnych w Menedżerze pakietu Android SDK) i znajduje się w Twoim systemie jako <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java.
Przykładowa aplikacja zawiera demonstrację funkcji administracyjnych urządzenia. Użytkownicy mogą korzystać z interfejsu, aby włączyć aplikację do zarządzania urządzeniem. Po włączeniu aplikacji mogą używać przycisków w interfejsie do wykonywania tych czynności:
- Ustaw jakość hasła.
- Określ wymagania dotyczące hasła użytkownika, takie jak minimalna długość, minimalna liczba cyfr, które musi zawierać itp.
- Ustaw hasło. Jeśli hasło nie jest zgodne ze specyfikacją, system zwraca błąd.
- Określ, ile nieudanych prób podania hasła może wystąpić przed wyczyszczeniem urządzenia (czyli przywróceniem ustawień fabrycznych).
- Określ, kiedy hasło wygaśnie.
- Ustaw długość historii haseł (długość odnosi się do liczby starych haseł przechowywanych w historii). Zapobiega to ponownemu użyciu przez użytkowników jednego z ostatnich n haseł.
- Określ, że obszar pamięci powinien być zaszyfrowany (jeśli urządzenie obsługuje tę funkcję).
- Ustaw maksymalny czas bezczynności, po którym urządzenie się zablokuje.
- Urządzenie powinno być natychmiast blokowane.
- Wymaż dane z urządzenia (czyli przywróć ustawienia fabryczne).
- Wyłącz kamerę.
Rysunek 1. Zrzut ekranu przykładowej aplikacji
Tworzenie aplikacji do administrowania urządzeniami
Administratorzy systemu mogą użyć interfejsu Device Administration API, aby napisać aplikację, która egzekwuje zasady zabezpieczeń urządzeń zdalnie lub lokalnie. W tej sekcji znajdziesz podsumowanie czynności związanych z tworzeniem aplikacji do zarządzania urządzeniami.
Tworzenie pliku manifestu
Aby korzystać z interfejsu Device Administration API, w pliku manifestu aplikacji musisz uwzględnić te elementy:
- Podklasa klasy
DeviceAdminReceiver, która obejmuje:- Uprawnienie
BIND_DEVICE_ADMIN. - Możliwość odpowiadania na intencję
ACTION_DEVICE_ADMIN_ENABLEDwyrażoną w pliku manifestu jako filtr intencji.
- Uprawnienie
- deklaracja zasad bezpieczeństwa używanych w metadanych.
Oto fragment przykładowego pliku manifestu administracji urządzenia:
<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>
Uwaga:
- Te atrybuty odnoszą się do zasobów ciągu znaków, które w przypadku przykładowej aplikacji znajdują się w katalogu
ApiDemos/res/values/strings.xml. Więcej informacji o zasobach znajdziesz w artykule Zasoby aplikacji.android:label="@string/activity_sample_device_admin"to czytelna dla użytkownika etykieta aktywności.android:label="@string/sample_device_admin"to czytelna dla użytkownika etykieta uprawnienia.android:description="@string/sample_device_admin_description"to opis uprawnień w formie zrozumiałej dla użytkownika. Opis jest zwykle dłuższy i bardziej szczegółowy niż etykieta.
android:permission="android.permission.BIND_DEVICE_ADMIN"to uprawnienie, które musi mieć podklasaDeviceAdminReceiver, aby zapewnić, że tylko system może wchodzić w interakcje z odbiorcą (żadna aplikacja nie może uzyskać tego uprawnienia). Zapobiega to nadużywaniu aplikacji do administrowania urządzeniem przez inne aplikacje.android.app.action.DEVICE_ADMIN_ENABLEDto główne działanie, które podklasaDeviceAdminReceivermusi obsłużyć, aby mieć możliwość zarządzania urządzeniem. Jest on ustawiany na odbiornik, gdy użytkownik włączy aplikację do zarządzania urządzeniem. Twój kod zwykle obsługuje to wonEnabled(). Aby to było możliwe, odbiorca musi też wymagać uprawnieniaBIND_DEVICE_ADMIN, aby inne aplikacje nie mogły go nadużywać.- Gdy użytkownik włączy aplikację do zarządzania urządzeniem, da to odbiorcom uprawnienia do wykonywania działań w odpowiedzi na rozpowszechnianie określonych zdarzeń systemowych. Gdy wystąpi odpowiednie zdarzenie, aplikacja może zastosować zasady. Jeśli na przykład użytkownik spróbuje ustawić nowe hasło, które nie spełnia wymagań, aplikacja może poprosić go o wybranie innego hasła, które spełnia te wymagania.
- Nie zmieniaj nazwy odbiorcy po opublikowaniu aplikacji. Jeśli nazwa w pliku manifestu ulegnie zmianie, funkcja administratora urządzenia zostanie wyłączona, gdy użytkownicy zaktualizują aplikację. Więcej informacji znajdziesz w artykule
<receiver>. android:resource="@xml/device_admin_sample"deklaruje zasady zabezpieczeń używane w metadanych. Metadane zawierają dodatkowe informacje dotyczące administratora urządzenia, które są analizowane przez klasęDeviceAdminInfo. Oto zawartość zakresudevice_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>
Podczas projektowania aplikacji do zarządzania urządzeniami nie musisz uwzględniać wszystkich zasad, tylko tych, które są istotne dla Twojej aplikacji.
Więcej informacji o pliku manifestu znajdziesz w przewodniku dla deweloperów aplikacji na Androida.Implementowanie kodu
Interfejs Device Administration API obejmuje te klasy:
DeviceAdminReceiver- Klasa podstawowa do implementowania komponentu zarządzania urządzeniami. Ta klasa ułatwia interpretowanie nieprzetworzonych działań intencji wysyłanych przez system. Aplikacja Zarządzanie urządzeniem musi zawierać podklasę
DeviceAdminReceiver. DevicePolicyManager- Klasa do zarządzania zasadami stosowanymi na urządzeniu. Większość klientów tej klasy musi opublikować
DeviceAdminReceiver, który jest obecnie włączony przez użytkownika.DevicePolicyManagerzarządza zasadami w co najmniej 1 instancjiDeviceAdminReceiver DeviceAdminInfo- Ta klasa służy do określania metadanych komponentu administratora urządzenia.
Te klasy stanowią podstawę w pełni funkcjonalnej aplikacji do zarządzania urządzeniem. W pozostałych częściach tej sekcji opisano, jak używać interfejsów API DeviceAdminReceiver i DevicePolicyManager do pisania aplikacji do zarządzania urządzeniem.
Tworzenie podklasy klasy DeviceAdminReceiver
Aby utworzyć aplikację do zarządzania urządzeniami, musisz utworzyć podklasę interfejsu DeviceAdminReceiver. Klasa DeviceAdminReceiver składa się z szeregu wywołań zwrotnych, które są wywoływane po wystąpieniu określonych zdarzeń.
W podklasie DeviceAdminReceiver przykładowa aplikacja wyświetla powiadomienie Toast w odpowiedzi na określone zdarzenia. Może to obejmować np. te funkcje:
Kotlin
class DeviceAdminSample : DeviceAdminReceiver() {
private fun showToast(context: Context, msg: String) {
context.getString(R.string.admin_receiver_status, msg).let { status ->
Toast.makeText(context, status, Toast.LENGTH_SHORT).show()
}
}
override fun onEnabled(context: Context, intent: Intent) =
showToast(context, context.getString(R.string.admin_receiver_status_enabled))
override fun onDisableRequested(context: Context, intent: Intent): CharSequence =
context.getString(R.string.admin_receiver_status_disable_warning)
override fun onDisabled(context: Context, intent: Intent) =
showToast(context, context.getString(R.string.admin_receiver_status_disabled))
override fun onPasswordChanged(context: Context, intent: Intent, userHandle: UserHandle) =
showToast(context, context.getString(R.string.admin_receiver_status_pw_changed))
...
}
Java
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, UserHandle userHandle) {
showToast(context, context.getString(R.string.admin_receiver_status_pw_changed));
}
...
}
Włączanie aplikacji
Jednym z głównych zdarzeń, które musi obsłużyć aplikacja administratora urządzenia, jest włączenie aplikacji przez użytkownika. Aby zasady mogły obowiązywać, użytkownik musi wyraźnie włączyć aplikację. Jeśli użytkownik zdecyduje się nie włączać aplikacji, będzie ona nadal obecna na urządzeniu, ale zasady nie będą stosowane, a użytkownik nie będzie mógł korzystać z żadnych jej funkcji.
Proces włączania aplikacji rozpoczyna się, gdy użytkownik wykona działanie, które powoduje wywołanie inencji ACTION_ADD_DEVICE_ADMIN. W przypadku aplikacji przykładowej dzieje się to, gdy użytkownik kliknie pole wyboru Włącz Administracja.
Gdy użytkownik kliknie pole wyboru Włącz administratora, wyświetli się ekran z prośbą o aktywowanie aplikacji administratora urządzenia (patrz rysunek 2).
Rysunek 2. Przykładowa aplikacja: aktywowanie aplikacji
Poniżej znajduje się kod, który jest wykonywany, gdy użytkownik kliknie pole wyboru Włącz administratora. W efekcie powoduje to wywołanie funkcjionPreferenceChange(). Ten wywołujący jest wywoływany, gdy użytkownik zmienił wartość tego parametru Preference i ma zostać on ustawiony lub zapisany. Jeśli użytkownik włącza aplikację, wyświetlacz zmienia się, aby wyświetlić prośbę o aktywowanie aplikacji do administrowania urządzeniem (patrz rysunek 2). W przeciwnym razie aplikacja do administrowania urządzeniem jest wyłączona.
Kotlin
override fun onPreferenceChange(preference: Preference, newValue: Any): Boolean {
if (super.onPreferenceChange(preference, newValue)) return true
val value = newValue as Boolean
if (preference == enableCheckbox) {
if (value != adminActive) {
if (value) {
// Launch the activity to have the user enable our admin.
val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply {
putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample)
putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
activity.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 {
dpm.removeActiveAdmin(deviceAdminSample)
enableDeviceCapabilitiesArea(false)
adminActive = false
}
}
} else if (preference == disableCameraCheckbox) {
dpm.setCameraDisabled(deviceAdminSample, value)
}
return true
}
Java
@Override
public boolean onPreferenceChange(Preference preference, Object newValue) {
if (super.onPreferenceChange(preference, newValue)) {
return true;
}
boolean value = (Boolean) newValue;
if (preference == enableCheckbox) {
if (value != adminActive) {
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, deviceAdminSample);
intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
activity.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 {
dpm.removeActiveAdmin(deviceAdminSample);
enableDeviceCapabilitiesArea(false);
adminActive = false;
}
}
} else if (preference == disableCameraCheckbox) {
dpm.setCameraDisabled(deviceAdminSample, value);
}
return true;
}
Linia intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample) wskazuje, że mDeviceAdminSample (która jest komponentem DeviceAdminReceiver) jest zasadą docelową.
Ta linia wywołuje interfejs użytkownika pokazany na rysunku 2. Prowadzi on użytkowników przez proces dodawania administratora urządzenia do systemu (lub umożliwia odrzucenie tej opcji).
Gdy aplikacja musi wykonać operację, która zależy od włączenia aplikacji administratora urządzenia, potwierdza, że aplikacja jest aktywna. W tym celu używa metody DevicePolicyManager.isAdminActive() Zwróć uwagę, że metoda DevicePolicyManager isAdminActive() przyjmuje jako argument komponent DeviceAdminReceiver:
Kotlin
private lateinit var dpm: DevicePolicyManager ... private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)
Java
DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
return dpm.isAdminActive(deviceAdminSample);
}
Zarządzanie zasadami
DevicePolicyManager to publiczna klasa do zarządzania zasadami stosowanymi na urządzeniu. DevicePolicyManager zarządza zasadami w co najmniej 1 instancji DeviceAdminReceiver.
Aby uzyskać identyfikator DevicePolicyManager, wykonaj te czynności:
Kotlin
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
Java
DevicePolicyManager dpm =
(DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
Z tej sekcji dowiesz się, jak używać DevicePolicyManager do wykonywania zadań administracyjnych:
Ustawianie zasad dotyczących haseł
DevicePolicyManager zawiera interfejsy API do ustawiania i egzekwowania zasad dotyczących haseł na urządzeniach. W interfejsie Device Administration API hasło dotyczy tylko blokady ekranu. W tej sekcji opisano typowe czynności związane z hasłami.
Ustawianie hasła urządzenia
Ten kod wyświetla interfejs z prośbą o ustawienie hasła:
Kotlin
Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
startActivity(intent)
}
Java
Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); startActivity(intent);
Ustawianie jakości hasła
Jakość hasła może być jedną z tych wartości DevicePolicyManager:
PASSWORD_QUALITY_ALPHABETIC- Użytkownik musi wpisać hasło zawierające co najmniej litery (lub inne symbole).
PASSWORD_QUALITY_ALPHANUMERIC- Użytkownik musi podać hasło zawierające co najmniej co najmniej jedną cyfrę i co najmniej 1 literę (lub inny symbol).
PASSWORD_QUALITY_NUMERIC- Użytkownik musi podać hasło zawierające co najmniej cyfry.
PASSWORD_QUALITY_COMPLEX- Użytkownik musi wprowadzić hasło zawierające co najmniej 1 literę, 1 cyfrę i 1 znak specjalny.
PASSWORD_QUALITY_SOMETHING- Polityka wymaga użycia jakiegoś rodzaju hasła, ale nie ma znaczenia, jakiego.
PASSWORD_QUALITY_UNSPECIFIED- Zasady nie określają wymagań dotyczących hasła.
Oto przykład ustawienia zasady dotyczącej hasła, która wymaga hasła alfanumerycznego:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
Ustawianie wymagań dotyczących treści hasła
Począwszy od Androida 3.0, klasa DevicePolicyManager zawiera metody, które umożliwiają dokładne dostosowanie zawartości hasła. Możesz na przykład ustawić zasadę, że hasła muszą zawierać co najmniej
n wielkich liter. Oto metody doprecyzowania zawartości hasła:
setPasswordMinimumLetters()setPasswordMinimumLowerCase()setPasswordMinimumUpperCase()setPasswordMinimumNonLetter()setPasswordMinimumNumeric()setPasswordMinimumSymbols()
Na przykład ten fragment kodu określa, że hasło musi zawierać co najmniej 2 wielkie litery:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwMinUppercase = 2 ... dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwMinUppercase = 2; ... dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase);
Ustawianie minimalnej długości hasła
Możesz określić, że hasło musi mieć co najmniej określoną minimalną długość. Może to obejmować np. te funkcje:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwLength: Int = ... ... dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwLength; ... dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);
Ustawienie maksymalnej liczby nieudanych prób podania hasła
Możesz ustawić maksymalną liczbę dozwolonych nieudanych prób podania hasła, której przekroczenie powoduje wymazanie pamięci urządzenia (czyli przywrócenie ustawień fabrycznych). Może to obejmować np. te funkcje:
Kotlin
val dPM:DevicePolicyManager private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val maxFailedPw: Int = ... ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int maxFailedPw; ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
Ustawianie czasu ważności hasła
Od Androida 3.0 możesz używać metody setPasswordExpirationTimeout()do ustawiania czasu ważności hasła wyrażonego w milisekundach od momentu ustawienia przez administratora urządzenia czasu wygaśnięcia. Może to obejmować np. te funkcje:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwExpiration: Long = ... ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; long pwExpiration; ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);
Ograniczanie hasła na podstawie historii
Począwszy od Androida 3.0 możesz użyć metody setPasswordHistoryLength(), aby ograniczyć możliwość ponownego używania starych haseł przez użytkowników. Ta metoda przyjmuje parametr length, który określa, ile starych haseł jest przechowywanych. Gdy ta zasada jest aktywna, użytkownicy nie mogą wpisać nowego hasła, które jest takie samo jak ostatnie n haseł. Zapobiega to wielokrotnemu używaniu tego samego hasła. Ta zasada jest zwykle używana w połączeniu z zasadą setPasswordExpirationTimeout(), która wymusza na użytkownikach aktualizację hasła po upływie określonego czasu.
Na przykład ten fragment kodu uniemożliwia użytkownikom ponowne użycie 5 ostatnich haseł:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwHistoryLength = 5 ... dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwHistoryLength = 5; ... dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength);
Konfigurowanie blokady urządzenia
Możesz ustawić maksymalny okres bezczynności użytkownika, po którym urządzenie się zablokuje. Może to obejmować np. te funkcje:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val timeMs: Long = 1000L * timeout.text.toString().toLong() ... dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... long timeMs = 1000L*Long.parseLong(timeout.getText().toString()); dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);
Możesz też zaprogramować urządzenie, aby natychmiast się zablokowało:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Wyczyść dane
Aby przywrócić urządzenie do ustawień fabrycznych, możesz użyć metody DevicePolicyManager
wipeData(). Jest to przydatne, jeśli urządzenie zostanie zgubione lub skradzione. Często decyzja o wyczyścieniu urządzenia jest wynikiem spełnienia określonych warunków. Możesz na przykład użyć parametru setMaximumFailedPasswordsForWipe(), aby określić, że dane urządzenie powinno zostać wyczyszczone po określonej liczbie nieudanych prób wpisania hasła.
Wymaż dane w ten sposób:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Java
DevicePolicyManager dpm; dpm.wipeData(0);
Metoda wipeData() przyjmuje jako parametr maskę bitową dodatkowych opcji. Obecnie wartość musi wynosić 0.
Wyłącz kamerę
Począwszy od Androida 4.0 możesz wyłączyć kamerę. Pamiętaj, że nie musisz wyłączyć tej funkcji na stałe. Kamera może być włączana i wyłączana dynamicznie w zależności od kontekstu, czasu itp.
Użytkownik decyduje, czy kamera ma być wyłączona, korzystając z metody setCameraDisabled(). Na przykład ten fragment kodu powoduje, że aparat jest włączany lub wyłączany na podstawie ustawienia pola wyboru:
Kotlin
private lateinit var disableCameraCheckbox: CheckBoxPreference private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)
Java
private CheckBoxPreference disableCameraCheckbox; DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked());
Szyfrowanie pamięci
Począwszy od Androida 3.0 możesz użyć metody setStorageEncryption(), aby ustawić zasadę wymagającą szyfrowania obszaru pamięci, w przypadku gdy jest to obsługiwane.
Może to obejmować np. te funkcje:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setStorageEncryption(deviceAdminSample, true)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setStorageEncryption(deviceAdminSample, true);
Pełny przykład włączania szyfrowania pamięci znajdziesz w przykładowym interfejsie Device Administration API.
Dodatkowe przykłady kodu
Przykłady Android AppRestrictionEnforcer i DeviceOwner pokazują, jak używać interfejsów API opisanych na tej stronie.