Wycofanie administratora urządzenia. Od Androida 9 (poziom interfejsu API 28) niektóre zasady administracyjne zostaną oznaczone jako wycofane po wywołaniu przez administratora urządzenia. Zalecamy, aby już teraz przygotować się do tej zmiany. Więcej informacji i opcje migracji znajdziesz w artykule Wycofanie administratora urządzenia.
Android zapewnia obsługę aplikacji firmowych dzięki interfejsowi Android Device Administration API. Interfejs Device Administration API udostępnia funkcje administrowania urządzeniami na poziomie systemu. Te interfejsy API pozwalają tworzyć aplikacje zwiększające bezpieczeństwo, które są przydatne w środowiskach firmowych, w których informatycy wymagają zaawansowanej kontroli nad urządzeniami pracowników. Na przykład wbudowana aplikacja e-mail na Androida używa tych interfejsów API do poprawy obsługi Exchange. Za pomocą aplikacji Poczta administratorzy Exchange mogą wymuszać stosowanie zasad dotyczących haseł, w tym haseł alfanumerycznych i liczbowych kodów PIN, na różnych urządzeniach. Administratorzy mogą też zdalnie usuwać dane (tj. przywrócić ustawienia fabryczne) zgubionych lub skradzionych telefonów. Użytkownicy Exchange mogą synchronizować dane poczty e-mail i kalendarza.
Ten dokument jest przeznaczony dla programistów, którzy chcą tworzyć rozwiązania dla firm na urządzenia z Androidem. Omawiamy w nim różne funkcje dostępne przez interfejs Device Administration API, które pozwalają wzmocnić zabezpieczenia urządzeń z Androidem dla pracowników.
Uwaga: informacje o tworzeniu kontrolera Work Policy dla wdrożeń Android for Work znajdziesz w artykule o tworzeniu 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, na których UserManager.isHeadlessSystemUserMode
zwraca true
). W trybie użytkownika systemowego bez interfejsu graficznego użytkownik systemu jest użytkownikiem w tle i podczas interakcji z nim polega na dodatkowych użytkownikach na pierwszym planie. Android 14 wprowadza też tryb powiązany z właścicielem urządzenia bez interfejsu graficznego, w którym właściciel profilu jest dodawany do wszystkich powiązanych użytkowników innych niż użytkownik systemowy, na którym skonfigurowano właściciela urządzenia.
Na urządzeniach skonfigurowanych z użytkownikiem systemu bez interfejsu graficznego (gdy użytkownik systemu działa w tle) do użytkownika na pierwszym planie stosowane są tylko zasady dotyczące urządzeń globalnych (zasady obowiązujące wszystkich użytkowników). Więcej informacji znajdziesz w sekcji addUserRestriction
.
Producenci urządzeń z Androidem mogą skorzystać ze wskazówek opublikowanych na stronie source.android.com.
Omówienie interfejsu API do administrowania urządzeniami
Oto przykłady aplikacji, w których można używać interfejsu Device Administration API:
- Klienty poczty e-mail.
- Aplikacje zabezpieczające, które umożliwiają zdalne czyszczenie pamięci.
- Aplikacje i usługi zarządzania urządzeniami.
Jak to działa?
Interfejs Device Administration API służy do zapisywania aplikacji administratora urządzeń, które użytkownicy instalują na swoich urządzeniach. Aplikacja do administrowania urządzeniem egzekwuje wymagane zasady. Jak to działa:
- Administrator systemu tworzy aplikację do administrowania urządzeniem, która wymusza zasady zabezpieczeń urządzeń zdalnych/lokalnych. Można je zakodować na stałe w aplikacji lub dynamicznie pobierać zasady z serwera zewnętrznego.
- Aplikacja jest zainstalowana na urządzeniach użytkowników. Android nie ma obecnie rozwiązania do automatycznej obsługi administracyjnej. Administrator może rozpowszechniać aplikację wśród użytkowników na kilka sposobów:
- Google Play.
- Umożliwianie instalacji z innego sklepu.
- rozpowszechnianie aplikacji w inny sposób, np. przez e-maila lub strony internetowe;
- System prosi użytkownika o włączenie aplikacji do administrowania urządzeniem. Sposób i czas tego działania zależą od sposobu implementacji aplikacji.
- Gdy użytkownicy włączą aplikację do administrowania urządzeniem, będą one podlegać jej zasadom. Przestrzeganie tych zasad skutkuje zwykle korzyściami takimi jak dostęp do systemów i danych wrażliwych.
Jeśli użytkownicy nie włączą aplikacji do administrowania urządzeniem, pozostanie ona na urządzeniu, ale będzie nieaktywna. Użytkownicy nie będą podlegać tym zasadom i nie będą miały żadnych korzyści wynikających z aplikacji – na przykład mogą nie być w stanie synchronizować danych.
Jeśli użytkownik nie będzie przestrzegać zasad (np. ustawi hasło naruszające te wytyczne), to aplikacja decyduje, jak to zrobić. Zazwyczaj uniemożliwia to jednak użytkownikowi synchronizację 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 będzie dozwolone. Interfejs Device Administration API nie obsługuje obecnie częściowej obsługi administracyjnej. Inaczej mówiąc, jeśli urządzenie (na przykład starsze urządzenie) nie obsługuje wszystkich podanych zasad, nie można zezwolić na połączenie.
Jeśli na urządzeniu znajduje się wiele włączonych aplikacji administratora, wymuszana jest najbardziej rygorystyczna zasada. Nie można kierować reklam na konkretną aplikację administratora.
Aby odinstalować dotychczasową aplikację do administrowania urządzeniem, użytkownicy muszą najpierw wyrejestrować ją jako administrator.
Zasady
W środowisku korporacyjnym często zdarza się, że urządzenia pracowników muszą przestrzegać rygorystycznych zasad dotyczących korzystania z urządzeń. Interfejs Device Administration API obsługuje zasady wymienione w tabeli 1. Pamiętaj, że interfejs Device Administration API obsługuje obecnie tylko hasła do blokady ekranu:
Polityka prywatności | 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 hasła. Możesz na przykład wymagać, aby kod PIN lub hasła miały co najmniej 6 znaków. |
Wymagane hasło z kodem alfanumerycznym | Wymaga, aby hasła zawierały kombinację liter i cyfr. Mogą one zawierać znaki symboliczne. |
Wymagane jest złożone hasło | Hasła muszą zawierać co najmniej literę, cyfrę i specjalny symbol. Wprowadzono w Androidzie 3.0. |
Minimalna liczba liter wymaganych w haśle | Minimalna liczba liter wymaganych w haśle hasła wszystkich lub konkretnego administratora. Wprowadzono w Androidzie 3.0. |
Minimalna liczba małych liter wymaganych w haśle | Minimalna liczba małych liter wymaganych w hasłach w przypadku wszystkich lub konkretnego administratora. Wprowadzono w Androidzie 3.0. |
Minimalna liczba znaków innych niż litery wymaganych w haśle | Minimalna liczba znaków niebędących literami wymaganych w haśle wymaganym przez wszystkich lub tylko poszczególnych administratorów. Wprowadzono w Androidzie 3.0. |
Minimalna liczba cyfr wymaganych w haśle | Minimalna liczba cyfr wymaganych w haśle wymaganym przez wszystkich administratorów lub konkretne osoby. Wprowadzono w Androidzie 3.0. |
Minimalna liczba symboli wymaganych w haśle | Minimalna liczba symboli wymaganych w haśle do wszystkich lub tylko jednego administratora. Wprowadzono w Androidzie 3.0. |
Minimalna liczba wielkich liter wymaganych w haśle | Minimalna liczba wielkich liter wymagana w haśle wymaganym przez wszystkich lub tylko poszczególnych administratorów. Wprowadzono w Androidzie 3.0. |
Upłynął limit czasu ważności hasła | Czas wygaśnięcia hasła wyrażony jako różnica w milisekundach od momentu, gdy administrator urządzenia ustawił ten czas. Wprowadzono w Androidzie 3.0. |
Ograniczenie 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 zmianę haseł po określonym czasie.
Wprowadzono w Androidzie 3.0. |
Maksymalna liczba nieudanych prób wpisania hasła | Określa, ile razy użytkownik może wpisać nieprawidłowe hasło, zanim urządzenie wyczyści dane. Interfejs Device Administration API pozwala też administratorom zdalnie resetować urządzenia do ustawień fabrycznych. Zabezpiecza to dane w przypadku zgubienia lub kradzieży. |
Maksymalny czas braku aktywności – blokada | Określa czas, jaki minął od ostatniego dotknięcia ekranu lub kliknięcia przycisku przez użytkownika, zanim urządzenie zablokuje ekran. W takim przypadku użytkownicy będą musieli ponownie wpisać kod PIN lub hasła, aby móc korzystać z urządzeń i uzyskiwać dostęp do danych. Wartość może wynosić od 1 do 60 minut. |
Wymagaj szyfrowania miejsca na dane | Określa, że obszar przechowywania powinien być zaszyfrowany (jeśli urządzenie obsługuje tę funkcję). Wprowadzono w Androidzie 3.0. |
Wyłącz kamerę | Określa, że kamera ma być wyłączona. Pamiętaj, że nie musi to być trwałe wyłączenie. Kamerę można włączać i wyłączać dynamicznie w zależności od kontekstu, czasu itp. Wprowadzone w Androidzie 4.0. |
Inne funkcje
Oprócz obsługi zasad wymienionych w powyższej tabeli interfejs Device Administration API umożliwia:
- Poproś użytkownika o ustawienie nowego hasła.
- Natychmiast zablokuj urządzenie.
- Wyczyszczenie danych na urządzeniu (czyli przywrócenie na nim ustawień fabrycznych).
Przykładowa aplikacja
Przykłady użyte na tej stronie bazują na przykładowym interfejsie Device Administration API, który znajduje się w przykładowych pakietach SDK (dostępnych w usłudze Android SDK Manager) 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 wersję demonstracyjną funkcji administratora urządzenia. Udostępnia użytkownikom interfejs, za pomocą którego mogą włączyć aplikację administratora urządzenia. Po jej włączeniu użytkownicy mogą używać przycisków w interfejsie, aby wykonywać te czynności:
- Ustaw jakość haseł.
- Określ wymagania dotyczące hasła użytkownika, takie jak minimalna długość, minimalna liczba znaków liczbowych, które musi zawierać, itp.
- Ustaw hasło. Jeśli hasło nie będzie zgodne z określonymi zasadami, system zwróci błąd.
- Określ liczbę dozwolonych nieudanych prób podania hasła, zanim dane na urządzeniu zostaną wyczyszczone (czyli przywrócone do ustawień fabrycznych).
- Określ, po jakim czasie hasło wygaśnie.
- Ustaw długość historii haseł (length odnosi się do liczby starych haseł przechowywanych w historii). Dzięki temu użytkownicy nie będą mogli ponownie użyć jednego z ostatnich n haseł.
- Określ, że obszar przechowywania danych powinien być zaszyfrowany, jeśli urządzenie obsługuje tę funkcję.
- Ustaw maksymalny czas braku aktywności, po jakim urządzenie zostanie zablokowane.
- Natychmiast zablokuj urządzenie.
- Wyczyszczenie danych na urządzeniu (czyli przywrócenie ustawień fabrycznych).
- Wyłącz aparat.
Opracowywanie aplikacji do administrowania urządzeniem
Administratorzy systemu mogą używać interfejsu Device Administration API do pisania aplikacji wymuszających zdalne/lokalne wymuszanie zasad zabezpieczeń urządzeń. W tej sekcji podsumowujemy kroki potrzebne do utworzenia aplikacji do administrowania urządzeniem.
Tworzę plik manifestu
Aby można było używać interfejsu Device Administration API, plik manifestu aplikacji musi zawierać:
- Podklasa klasy
DeviceAdminReceiver
, która obejmuje te elementy:- Uprawnienie
BIND_DEVICE_ADMIN
. - Możliwość reagowania na intencję
ACTION_DEVICE_ADMIN_ENABLED
wyrażoną w pliku manifestu jako filtr intencji.
- Uprawnienie
- Deklaracja zasad bezpieczeństwa stosowanych w metadanych.
Oto fragment przykładowego pliku manifestu administrowania urządzeniem:
<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:
- Poniższe atrybuty odnoszą się do zasobów ciągu znaków, które znajdują się w przykładowej aplikacji w
ApiDemos/res/values/strings.xml
. Więcej informacji o zasobach znajdziesz w artykule na temat zasobów aplikacji.android:label="@string/activity_sample_device_admin"
odnosi się do czytelnej dla użytkownika etykiety aktywności.android:label="@string/sample_device_admin"
odnosi się do czytelnej dla użytkownika etykiety uprawnienia.android:description="@string/sample_device_admin_description"
odnosi się do czytelnego dla użytkownika opisu uprawnienia. Opis jest zwykle dłuższy i zawiera więcej informacji niż etykieta.
android:permission="android.permission.BIND_DEVICE_ADMIN"
to uprawnienie, które musi mieć podklasaDeviceAdminReceiver
, aby mieć pewność, że tylko system może wchodzić w interakcję z odbiornikiem (żadnej aplikacji nie można przyznać tego uprawnienia). Zapobiega to wykorzystywaniu Twojej aplikacji do administrowania urządzeniem przez inne aplikacje.android.app.action.DEVICE_ADMIN_ENABLED
to główne działanie, które podklasaDeviceAdminReceiver
musi obsługiwać, aby mogła zarządzać urządzeniem. To ustawienie jest ustawiane na odbiorcę, gdy użytkownik włącza aplikację administratora urządzenia. Zwykle odbywa się to za pomocą kodu w regionieonEnabled()
. Aby aplikacja była obsługiwana, odbiorca musi też wymagać uprawnieniaBIND_DEVICE_ADMIN
, aby inne aplikacje nie mogły go nadużywać.- Gdy użytkownik włączy aplikację do administrowania urządzeniem, odbiorca może wykonywać działania w odpowiedzi na transmisję określonych zdarzeń systemowych. Gdy zajdzie odpowiednie zdarzenie, aplikacja może nałożyć odpowiednie 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, które spełnia te wymagania.
- Unikaj zmiany nazwy odbiorcy po opublikowaniu aplikacji. Jeśli nazwa w manifeście się zmieni, administrator urządzenia zostanie wyłączony, gdy użytkownicy zaktualizują aplikację. Więcej informacji znajdziesz w sekcji
<receiver>
. android:resource="@xml/device_admin_sample"
deklaruje zasady bezpieczeństwa używane w metadanych. Metadane zawierają dodatkowe informacje dotyczące administratora urządzenia, analizowane przez klasęDeviceAdminInfo
. Oto zawartość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>
Podczas projektowania aplikacji do administrowania urządzeniem nie musisz uwzględniać wszystkich zasad – tylko tych, które są związane z Twoją aplikacją.
Więcej informacji o pliku manifestu znajdziesz w przewodniku dla deweloperów aplikacji na Androida.Implementacja kodu
Interfejs Device Administration API zawiera następujące klasy:
DeviceAdminReceiver
- Klasa podstawowa do implementacji komponentu administrowania urządzeniem. Ta klasa zapewnia wygodę podczas interpretowania nieprzetworzonych działań intencji, które są wysyłane przez system. Aplikacja do administrowania urządzeniem musi zawierać podklasę
DeviceAdminReceiver
. DevicePolicyManager
- Klasy do zarządzania zasadami wymuszanymi na urządzeniu. Większość klientów tej klasy musi opublikować zasób
DeviceAdminReceiver
, który użytkownik obecnie włączył.DevicePolicyManager
zarządza zasadami 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 administrowania urządzeniem.
W pozostałej części tej sekcji opisujemy, jak używać interfejsów API DeviceAdminReceiver
i DevicePolicyManager
do pisania aplikacji do administrowania urządzeniem.
Podklasyfikowanie odbiorcy DeviceAdmin Receiver
Aby utworzyć aplikację do administrowania urządzeniem, musisz podklasę DeviceAdminReceiver
. Klasa DeviceAdminReceiver
składa się z serii wywołań zwrotnych, które są aktywowane po wystąpieniu określonych zdarzeń.
Przykładowa aplikacja w podklasie DeviceAdminReceiver
wyświetla po prostu powiadomienie Toast
w odpowiedzi na określone zdarzenia. Na przykład:
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łączam aplikację
Jednym z najważniejszych zdarzeń, które musi obsługiwać aplikacja do zarządzania urządzeniem, jest włączenie aplikacji przez użytkownika. Aby zasady były wymuszane, użytkownik musi bezpośrednio włączyć aplikację. Jeśli użytkownik nie włączy aplikacji, nadal będzie ona widoczna na urządzeniu, ale związane z nią zasady nie będą egzekwowane i nie będą miały żadnych zalet aplikacji.
Proces włączania aplikacji rozpoczyna się, gdy użytkownik wykona działanie, które aktywuje intencję ACTION_ADD_DEVICE_ADMIN
. W przykładowej aplikacji dzieje się tak, gdy użytkownik kliknie pole wyboru Włącz ustawienia administracyjne.
Gdy użytkownik kliknie pole wyboru Włącz funkcję administratora, ekran zmieni się i pojawi się prośba o aktywowanie aplikacji do administrowania urządzeniem, jak pokazano na ilustracji 2.
Poniżej znajduje się kod, który jest uruchamiany, gdy użytkownik kliknie pole wyboru Włącz ustawienia administratora. Powoduje to aktywowanie wywołania zwrotnego onPreferenceChange()
. To wywołanie zwrotne jest wywoływane, gdy wartość parametru Preference
została zmieniona przez użytkownika i ma zostać ustawiona lub zachowana. Jeśli użytkownik włączy aplikację, ekran zmieni się i pojawi się prośba o aktywowanie aplikacji do administrowania urządzeniem, jak widać na rysunku 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; }
Wiersz intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample)
wskazuje, że zasadą docelową jest mDeviceAdminSample
(który jest komponentem DeviceAdminReceiver
).
Ten wiersz wywołuje interfejs widoczny na ilustracji 2, który prowadzi użytkowników przez proces dodawania administratora urządzenia do systemu (lub umożliwia jego odrzucenie).
Gdy aplikacja musi wykonać operację, która wymaga włączenia aplikacji do administrowania urządzeniem, potwierdza, że jest ona aktywna. Wykorzystuje do tego metodę DevicePolicyManager
isAdminActive()
. Zwróć uwagę, że argumentem metody DevicePolicyManager
isAdminActive()
jest 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 wymuszanymi na urządzeniu. DevicePolicyManager
zarządza zasadami
co najmniej 1 instancji DeviceAdminReceiver
.
Nick dla DevicePolicyManager
będzie wyglądać tak:
Kotlin
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
Java
DevicePolicyManager dpm = (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
W tej sekcji dowiesz się, jak używać usługi DevicePolicyManager
do wykonywania zadań administracyjnych:
Ustawianie zasad dotyczących haseł
DevicePolicyManager
obejmuje interfejsy API do ustawiania i egzekwowania zasad dotyczących haseł do urządzeń. W interfejsie Device Administration API hasło dotyczy tylko blokady ekranu. W tej sekcji opisano typowe zadania związane z hasłem.
Ustaw hasło dla 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 haseł
Jakość hasła może być jedną z tych wartości stałych DevicePolicyManager
:
PASSWORD_QUALITY_ALPHABETIC
- Użytkownik musi wpisać hasło zawierające co najmniej znaki alfabetu (lub inne symbole).
PASSWORD_QUALITY_ALPHANUMERIC
- Użytkownik musi wpisać hasło zawierające co najmniej obie cyfry i znaki alfabetyczne (lub inne symbole).
PASSWORD_QUALITY_NUMERIC
- Użytkownik musi wpisać hasło zawierające co najmniej cyfry.
PASSWORD_QUALITY_COMPLEX
- Użytkownik musi wpisać hasło zawierające co najmniej literę, cyfrę i specjalny symbol.
PASSWORD_QUALITY_SOMETHING
- Zasada wymaga podania jakiegoś rodzaju hasła, ale nie ma znaczenia.
PASSWORD_QUALITY_UNSPECIFIED
- Zasada nie ma wymagań dotyczących hasła.
Aby na przykład ustawić w zasadach dotyczących haseł wymóg stosowania 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);
Określanie wymagań dotyczących treści haseł
Począwszy od Androida 3.0 klasa DevicePolicyManager
zawiera metody, które umożliwiają dostosowanie zawartości hasła. Możesz na przykład ustawić zasadę, zgodnie z którą hasła muszą zawierać co najmniej n wielkich liter. Oto metody dostrajania zawartości hasła:
setPasswordMinimumLetters()
setPasswordMinimumLowerCase()
setPasswordMinimumUpperCase()
setPasswordMinimumNonLetter()
setPasswordMinimumNumeric()
setPasswordMinimumSymbols()
Na przykład ten fragment wskazuje, ż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 ustawić hasło, które ma przynajmniej określoną minimalną długość. Na przykład:
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);
Ustaw maksymalną liczbę nieudanych prób wpisania hasła
Możesz ustawić maksymalną liczbę dozwolonych nieudanych prób wpisania hasła, zanim pamięć urządzenia zostanie wyczyszczona (czyli przywracane są ustawienia fabryczne). Na przykład:
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);
Ustaw czas wygaśnięcia hasła
Począwszy od Androida w wersji 3.0 możesz używać metody setPasswordExpirationTimeout()
do określania czasu wygaśnięcia hasła, wyrażonego w milisekundach od momentu, gdy administrator urządzenia ustawił ten czas. Na przykład:
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);
Ogranicz hasło na podstawie historii
Począwszy od Androida 3.0 możesz używać metody setPasswordHistoryLength()
do ograniczenia możliwości ponownego używania starych haseł przez użytkowników. Ta metoda korzysta z parametru length, który określa, ile starych haseł jest przechowywanych. Gdy ta zasada jest aktywna, użytkownicy nie mogą podać nowego hasła pasującego do ostatnich n haseł. Dzięki temu użytkownicy nie mogą używać tego samego hasła wielokrotnie. Ta zasada jest zwykle używana w połączeniu z zasadą setPasswordExpirationTimeout()
, która wymusza na użytkownikach zmianę haseł po określonym czasie.
Na przykład ten fragment zabrania użytkownikom ponownego użycia któregokolwiek z 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);
Ustaw blokadę urządzenia
Możesz ustawić maksymalny okres braku aktywności użytkownika przed zablokowaniem urządzenia. Na przykład:
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ż automatycznie skonfigurować automatyczne blokowanie urządzenia:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Wyczyść dane
Aby przywrócić ustawienia fabryczne urządzenia, możesz użyć metody DevicePolicyManager
wipeData()
. Przydaje się to w razie zgubienia lub kradzieży urządzenia. Decyzja o wyczyszczeniu pamięci urządzenia
jest często efektem spełnienia określonych warunków. Za pomocą setMaximumFailedPasswordsForWipe()
możesz na przykład określić, że urządzenie powinno zostać wyczyszczone po określonej liczbie nieudanych prób podania hasła.
Dane można wyczyścić w ten sposób:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Java
DevicePolicyManager dpm; dpm.wipeData(0);
Jako parametr metody wipeData()
stosowana jest maska bitowa dodatkowych opcji. Obecnie wartość musi wynosić 0.
Wyłącz kamerę
Wraz z Androidem 4.0 możesz wyłączyć aparat. Pamiętaj, że wyłączenie tej funkcji nie musi być trwałe. Kamerę można włączać i wyłączać dynamicznie w zależności od kontekstu, czasu i innych czynników.
Aby określić, czy kamera ma być wyłączona, użyj metody setCameraDisabled()
. Na przykład ten fragment kodu włącza lub wyłącza kamerę 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 masowej
Począwszy od Androida w wersji 3.0 możesz używać metody setStorageEncryption()
do konfigurowania zasad wymagających szyfrowania miejsca na dane (o ile jest obsługiwana).
Na przykład:
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 miejsca na dane zawiera przykładowy interfejs Device Administration API.
Dodatkowe przykłady kodu
Przykłady zasad Android AppRestrictionEnforcer i DeviceOwner pozwalają dodatkowo zaprezentować wykorzystanie interfejsów API opisanych na tej stronie.