Wycofanie aplikacji do zarządzania urządzeniem Począwszy od Androida 9 (poziom interfejsu API 28) niektóre zasady administratora po wywołaniu przez administratora urządzenia będą oznaczane jako wycofane. Zalecamy już teraz przygotować się na tę zmianę. Aby dowiedzieć się więcej i poznać opcje migracji, przeczytaj artykuł Wycofanie konta administratora urządzenia.
Android zapewnia obsługę aplikacji dla firm, udostępniając interfejs Android Device Administration API. Interfejs Device Administration API udostępnia funkcje administrowania urządzeniami na poziomie systemu. Pozwalają one tworzyć świadome zabezpieczenia aplikacji, które są przydatne w środowiskach firmowych, w których informatycy potrzebują silnej kontroli nad urządzeniami pracowników. Na przykład wbudowana aplikacja pocztowa 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 haseł alfanumerycznych i numerycznych kodów PIN – na wszystkich urządzeniach. Administratorzy mogą też zdalnie wymazać zgubione lub skradzione telefony (przywrócić ustawienia fabryczne). Użytkownicy Exchange mogą synchronizować dane poczty e-mail i kalendarza.
Ten dokument jest przeznaczony dla programistów, którzy chcą opracowywać rozwiązania dla firm na urządzenia z Androidem. Omówiono w nim różne funkcje interfejsu Device Administration API, które zapewniają bezpieczniejsze korzystanie z urządzeń z Androidem dla pracowników.
Uwaga Informacje o tworzeniu kontrolera zasad 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
W Androidzie 14 (poziom interfejsu API 34) wprowadzamy tryb użytkownika systemowego bez interfejsu graficznego (dotyczy urządzeń, na których UserManager.isHeadlessSystemUserMode
zwraca wartość true
). W trybie użytkownika systemowego bez interfejsu graficznego użytkownik systemu jest użytkownikiem działającym w tle i w ramach interakcji z użytkownikiem końcowym korzysta z dodatkowych użytkowników na pierwszym planie. W Androidzie 14 wprowadziliśmy też tryb powiązany z właścicielem urządzenia bez interfejsu graficznego, który dodaje właściciela profilu do wszystkich powiązanych użytkowników z wyjątkiem użytkownika systemu, dla którego skonfigurowano właściciela urządzenia.
W przypadku urządzeń skonfigurowanych z użytkownikiem systemu bez interfejsu graficznego (gdzie użytkownik systemu działa w tle) do użytkowników na pierwszym planie są stosowane tylko zasady dotyczące urządzeń w zakresie globalnym (zasady obowiązujące wszystkich użytkowników). Więcej informacji znajdziesz w sekcji addUserRestriction
.
Producenci urządzeń z Androidem mogą skorzystać z wskazówek opublikowanych na source.android.com.
Omówienie interfejsu API do administrowania urządzeniami
Oto przykłady aplikacji, które mogą korzystać z interfejsu Device Administration API:
- Klienty poczty e-mail.
- Aplikacje zabezpieczające, które zdalnie czyszczenie pamięci.
- Usługi i aplikacje do zarządzania urządzeniami.
Jak to działa?
Interfejs Device Administration API służy do pisania aplikacji do administrowania urządzeniem, które użytkownicy instalują na swoich urządzeniach. Aplikacja do administrowania urządzeniem wymusza stosowanie odpowiednich zasad. Jak to działa:
- Administrator systemu pisze aplikację do administrowania urządzeniem, która wymusza zasady zabezpieczeń zdalnych/lokalnych urządzeń. Zasady te mogą być zakodowane na stałe w aplikacji lub aplikacja może dynamicznie pobierać zasady z serwera zewnętrznego.
- Aplikacja jest instalowana na urządzeniach użytkowników. Android nie ma obecnie rozwiązania do automatycznej obsługi administracyjnej. Oto kilka sposobów rozpowszechniania aplikacji wśród użytkowników przez administratora sysadmin:
- Google Play.
- Umożliwianie instalacji z innego sklepu.
- Rozpowszechnianie aplikacji za pomocą innych środków, takich jak e-mail lub strony internetowe.
- System prosi użytkownika o włączenie aplikacji administratora urządzenia. Sposób i czas to zależy od sposobu implementacji aplikacji.
- Gdy użytkownicy włączą aplikację do zarządzania urządzeniem, będą podlegać obowiązującym w niej zasadom. Przestrzeganie tych zasad zwykle przynosi korzyści takie 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ą mieli żadnych korzyści wynikających z używania aplikacji (na przykład nie będą mogli synchronizować danych).
Jeśli użytkownik nie przestrzega zasad (na przykład ustawi hasło, które narusza wytyczne), aplikacja decyduje, jak to zrobić. Zwykle jednak uniemożliwia to 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, takie połączenie będzie niedozwolone. Interfejs Device Administration API nie zezwala obecnie na częściową obsługę administracyjną. Inaczej mówiąc, jeśli urządzenie (np. starsze urządzenie) nie obsługuje wszystkich wymienionych zasad, nie ma możliwości zezwolenia na połączenie.
Jeśli urządzenie zawiera wiele włączonych aplikacji administracyjnych, wymuszana jest najbardziej rygorystyczna zasada. Nie można kierować reklam na konkretną aplikację administratora.
Aby odinstalować dotychczasową aplikację do zarządzania urządzeniem, użytkownicy muszą ją najpierw wyrejestrować jako administrator.
Zasady
W firmach często zdarza się, że urządzenia pracowników muszą być zgodne z rygorystycznymi zasadami dotyczącymi korzystania z nich. Interfejs Device Administration API obsługuje zasady wymienione w tabeli 1. Pamiętaj, że interfejs Device Administration API obecnie obsługuje tylko hasła do blokady ekranu:
Zasady | Opis |
---|---|
Hasło włączone | Wymaga, aby urządzenia były wyświetlane z prośbą o podanie kodu PIN lub hasła. |
Minimalna długość hasła | Ustaw wymaganą liczbę znaków hasła. Możesz na przykład wymagać, aby kody PIN lub hasła miały co najmniej 6 znaków. |
Wymagane jest hasło alfanumeryczne | Wymaga, by hasła były kombinacją liter i cyfr. Mogą one zawierać znaki symboliczne. |
Wymagane jest złożone hasło | Wymaga, aby hasła muszą zawierać co najmniej literę, cyfrę i symbol specjalny. Wprowadzono w Androidzie 3.0. |
Minimalna liczba liter wymaganych w haśle | Minimalna liczba liter w haśle dla wszystkich lub tylko dla określonego administratora. Wprowadzono w Androidzie 3.0. |
Minimalna wymagana liczba małych liter w haśle | Minimalna liczba małych liter wymagana w haśle dla wszystkich lub tylko dla określonego administratora. Wprowadzono w Androidzie 3.0. |
Minimalna liczba znaków niebędących literami jest wymagana w haśle | Minimalna liczba znaków innych niż litery wymagane w haśle wszystkich lub tylko dla konkretnego administratora. Wprowadzono w Androidzie 3.0. |
Minimalna liczba cyfr wymaganych w haśle | Minimalna liczba cyfr wymaganych w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzono w Androidzie 3.0. |
Minimalna liczba symboli wymaganych w haśle | Minimalna liczba symboli wymaganych w haśle dla wszystkich administratorów lub jednego z nich. Wprowadzono w Androidzie 3.0. |
Minimalna liczba wielkich liter wymaganych w haśle | Minimalna liczba wielkich liter wymagana w haśle dla wszystkich lub tylko jednego administratora. Wprowadzono w Androidzie 3.0. |
Upłynął limit czasu ważności hasła | Czas wygaśnięcia hasła wyrażona w milisekundach od chwili, gdy administrator urządzenia ustawi czas wygaśnięcia. Wprowadzono w Androidzie 3.0. |
Ograniczenie historii haseł | Ta zasada uniemożliwia użytkownikom ponowne korzystanie z ostatnich n unikalnych haseł.
Ta zasada jest zwykle używana w połączeniu z zasadą setPasswordExpirationTimeout() , która wymusza na użytkownikach aktualizację haseł po upływie określonego czasu.
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 umożliwia też administratorom zdalne resetowanie urządzeń do ustawień fabrycznych. Pozwala to zabezpieczyć dane w razie zagubienia lub kradzieży urządzenia. |
Maksymalny czas braku aktywności | Określa czas od ostatniego dotknięcia ekranu lub naciśnięcia przycisku przez użytkownika, zanim urządzenie zablokuje ekran. W takiej sytuacji użytkownicy muszą jeszcze raz podać kod PIN lub hasło, zanim będą mogli korzystać ze swoich urządzeń i danych. Wartość może wynosić od 1 do 60 minut. |
Wymagaj szyfrowania pamięci | Określa, że obszar pamięci ma być zaszyfrowany, jeśli urządzenie obsługuje tę funkcję. Wprowadzono w Androidzie 3.0. |
Wyłączanie aparatu | Określa, że kamera powinna 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 itd. Wprowadzona w Androidzie 4.0. |
Inne funkcje
Oprócz obsługi zasad wymienionych w powyższej tabeli interfejs Device Administration API umożliwia wykonywanie tych czynności:
- Zachęć użytkownika do ustawienia nowego hasła.
- Natychmiast zablokuj urządzenie.
- Wyczyść dane urządzenia (czyli przywróć na urządzeniu ustawienia fabryczne).
Przykładowa aplikacja
Na tej stronie wykorzystano przykładowy interfejs Device Administration API, który jest uwzględniony w przykładach pakietów SDK (dostępnych w usłudze Android SDK Manager) i znajdujący 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 administracyjnych urządzenia. Udostępnia użytkownikom interfejs, który pozwala włączyć aplikację do administrowania urządzeniem. Po włączeniu aplikacji mogą oni za pomocą przycisków w interfejsie:
- Ustaw jakość haseł.
- Określ wymagania dotyczące hasła użytkownika, takie jak minimalna długość czy minimalna liczba znaków, które musi zawierać hasło.
- Ustaw hasło. Jeśli hasło nie jest zgodne z określonymi zasadami, system zwraca błąd.
- Określ, ile nieudanych prób podania hasła może wystąpić, zanim dane na urządzeniu zostaną wyczyszczone (czyli zostaną przywrócone ustawienia fabryczne).
- Określ, za jaki czas będzie wygasać hasło.
- 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ł, których wcześniej używali.
- Określ, czy obszar pamięci ma być zaszyfrowany, jeśli urządzenie obsługuje tę funkcję.
- Ustaw maksymalny czas braku aktywności, po którym urządzenie zostanie zablokowane.
- Natychmiast zablokuj urządzenie.
- Wyczyść dane urządzenia (czyli przywróć ustawienia fabryczne).
- Wyłącz aparat.
Tworzenie aplikacji do administrowania urządzeniem
Administratorzy systemu mogą używać interfejsu Device Administration API do napisania aplikacji wymuszającej zdalne/lokalne egzekwowanie zasad bezpieczeństwa urządzenia. W tej sekcji podsumowano kroki potrzebne do utworzenia aplikacji do administrowania urządzeniem.
Tworzę plik manifestu
Aby można było korzystać z interfejsu Device Administration API, plik manifestu aplikacji musi zawierać te elementy:
- Podklasa klasy
DeviceAdminReceiver
obejmująca:- Uprawnienie
BIND_DEVICE_ADMIN
. - Możliwość reagowania na zamiar
ACTION_DEVICE_ADMIN_ENABLED
, wyrażona w pliku manifestu jako filtr intencji.
- Uprawnienie
- Deklaracja zasad bezpieczeństwa używanych 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 w postaci ciągów znaków, które znajdują się w przykładowej aplikacji w regionie
ApiDemos/res/values/strings.xml
. Więcej informacji o zasobach znajdziesz w artykule o zasobach aplikacji.android:label="@string/activity_sample_device_admin"
odnosi się do czytelnej dla użytkownika etykiety działania.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 podklasaDeviceAdminReceiver
musi mieć, aby tylko system mógł wchodzić w interakcje z odbiornikiem (nie można przyznać tego uprawnienia żadnej aplikacji). Zapobiega to nadużywaniu aplikacji administratora urządzenia przez inne aplikacje.android.app.action.DEVICE_ADMIN_ENABLED
to główna czynność, którą musi wykonać podklasaDeviceAdminReceiver
, aby mogła zarządzać urządzeniem. Ta wartość jest ustawiona na odbiornik, gdy użytkownik włączy aplikację do administrowania urządzeniem. Twój kod zwykle obsługuje to w zadaniuonEnabled()
. Aby odbiorcy mogli z niego korzystać, muszą też mieć uprawnienieBIND_DEVICE_ADMIN
, aby inne aplikacje nie mogły go nadużywać.- Gdy użytkownik włączy aplikację do administrowania urządzeniem, która umożliwi odbiorcy wykonywanie działań w odpowiedzi na przesyłane zdarzenia systemowe. W razie wystąpienia odpowiedniego zdarzenia aplikacja może zastosować odpowiednie zasady. Jeśli na przykład użytkownik spróbuje ustawić nowe hasło, które nie jest zgodne z zasadami, aplikacja może poprosić go o wybranie innego hasła, które spełnia te wymagania.
- Unikaj zmieniania nazwy odbiorcy po opublikowaniu aplikacji. Jeśli nazwa w pliku manifestu się zmieni, administrator urządzenia zostanie wyłączony, gdy użytkownicy zaktualizują aplikację. Więcej informacji znajdziesz tutaj:
<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ść poladevice_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 te dotyczące Twojej aplikacji.
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 wdrażania komponentu administrowania urządzeniem. Ta klasa ułatwia interpretację nieprzetworzonych działań intencji wysyłanych przez system. Aplikacja do administrowania urządzeniem musi zawierać podklasę
DeviceAdminReceiver
. DevicePolicyManager
- Klasa do zarządzania zasadami egzekwowanymi na urządzeniu. Większość klientów tej klasy musi opublikować
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 opisano sposób używania interfejsów API DeviceAdminReceiver
i DevicePolicyManager
do pisania aplikacji do administrowania urządzeniem.
Podklasa: obiekt DeviceAdminOdbieranie
Aby utworzyć aplikację do administrowania urządzeniem, musisz należeć do podklasy DeviceAdminReceiver
. Klasa DeviceAdminReceiver
składa się z serii wywołań zwrotnych, które są wyzwalane w momencie wystąpienia określonych zdarzeń.
W podklasie DeviceAdminReceiver
przykładowa aplikacja po prostu wyświetla 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 głównych zdarzeń, które musi obsłużyć aplikacja do zarządzania urządzeniem, jest włączenie aplikacji przez użytkownika. Aby zasady były egzekwowane, użytkownik musi samodzielnie włączyć aplikację. Jeśli użytkownik nie zdecyduje się na włączenie aplikacji, będzie ona nadal dostępna na urządzeniu, ale jej zasady nie będą egzekwowane, a korzystanie z niej nie będzie możliwe.
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 administratora.
Gdy użytkownik kliknie pole wyboru Włącz administratora, na ekranie pojawi się prośba o aktywowanie aplikacji administratora urządzenia, jak widać na ilustracji 2.
Poniżej znajduje się kod, który jest uruchamiany, gdy użytkownik kliknie pole wyboru Włącz administratora. W efekcie aktywujesz wywołanie zwrotne onPreferenceChange()
. To wywołanie zwrotne jest wywoływane, gdy wartość parametru Preference
została zmieniona przez użytkownika i zostanie ustawiona lub utrwalona. Jeśli użytkownik włączy aplikację, ekran zmieni się i wyświetli prośbę o aktywowanie aplikacji administratora urządzenia, jak pokazano na ilustracji.
2. W przeciwnym razie aplikacja do zarządzania 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)
informuje, że zasadą docelową jest mDeviceAdminSample
(czyli komponent DeviceAdminReceiver
).
Ten wiersz powoduje wywołanie interfejsu użytkownika pokazanego na rys. 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 jest zależna od włączenia aplikacji do administrowania urządzeniem, potwierdza, że jest ona aktywna. Używa do tego metody DevicePolicyManager
isAdminActive()
. Zwróć uwagę, że metoda DevicePolicyManager
isAdminActive()
przyjmuje komponent DeviceAdminReceiver
jako argument:
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 klasa publiczna do zarządzania zasadami obowiązującymi na urządzeniu. DevicePolicyManager
zarządza zasadami co najmniej 1 instancji DeviceAdminReceiver
.
Uzyskasz taki nick dla elementu DevicePolicyManager
:
Kotlin
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
Java
DevicePolicyManager dpm = (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
W tej sekcji opisano, jak za pomocą DevicePolicyManager
wykonywać zadania administracyjne:
Konfigurowanie zasad dotyczących haseł
DevicePolicyManager
zawiera interfejsy API do konfigurowania 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łem.
ustawić hasło do 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 stałych wartości DevicePolicyManager
:
PASSWORD_QUALITY_ALPHABETIC
- Użytkownik musi wpisać hasło zawierające przynajmniej litery (lub inne symbole).
PASSWORD_QUALITY_ALPHANUMERIC
- Użytkownik musi wpisać hasło zawierające co najmniej zarówno cyfry, jak i litery (lub inne symbole).
PASSWORD_QUALITY_NUMERIC
- Użytkownik musi wpisać hasło zawierające co najmniej cyfry.
PASSWORD_QUALITY_COMPLEX
- Użytkownik musi podać hasło zawierające co najmniej literę, cyfrę i specjalny symbol.
PASSWORD_QUALITY_SOMETHING
- Zasady wymagają podania jakiegoś hasła, ale nie jest obojętne.
PASSWORD_QUALITY_UNSPECIFIED
- Zasada nie ma wymagań dotyczących hasła.
Aby na przykład ustawić wymóg podawania hasła alfanumerycznego w zasadach dotyczących haseł:
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);
Ustaw wymagania dotyczące treści haseł
Począwszy od Androida 3.0 klasa DevicePolicyManager
zawiera metody umożliwiające doprecyzowanie 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 treści hasła:
setPasswordMinimumLetters()
setPasswordMinimumLowerCase()
setPasswordMinimumUpperCase()
setPasswordMinimumNonLetter()
setPasswordMinimumNumeric()
setPasswordMinimumSymbols()
Na przykład ten fragment kodu informuje, że hasło musi się składać z co najmniej 2 wielkich liter:
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ć 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ą dozwoloną liczbę nieudanych prób podania hasła przed wyczyszczeniem pamięci urządzenia (czyli przywróceniem ustawień fabrycznych). 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 ważności hasła
Począwszy od Androida 3.0 można używać metody setPasswordExpirationTimeout()
, aby określić, kiedy hasło wygaśnie, wyrażone w milisekundach od ustawienia tego limitu przez administratora urządzenia. 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ła na podstawie historii
Począwszy od Androida 3.0, można używać metody setPasswordHistoryLength()
, aby ograniczać możliwość używania starych haseł przez użytkowników. Ta metoda wykorzystuje parametr length, który określa, ile starych haseł jest przechowywanych. Gdy ta zasada jest aktywna, użytkownicy nie mogą wpisywać nowego hasła pasującego do ostatnich n haseł. Dzięki temu użytkownicy nie będą musieli ciągle używać tego samego hasła. Ta zasada jest zwykle używana w połączeniu z zasadą setPasswordExpirationTimeout()
, która wymusza na użytkownikach aktualizację haseł po upływie określonego czasu.
Na przykład ten fragment kodu uniemożliwia użytkownikom ponowne użycie jednego z ostatnich 5 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 czas nieaktywności użytkownika, który może wystąpić, zanim urządzenie zostanie zablokowane. 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ć urządzenie, by natychmiast się zablokowało:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Wyczyść dane
Aby przywrócić na urządzeniu ustawienia fabryczne, możesz użyć metody DevicePolicyManager
wipeData()
. Jest to przydatne, gdy urządzenie
zostanie zgubione lub skradzione. Często decyzja o wyczyszczeniu pamięci
urządzenia jest wynikiem spełnienia określonych warunków. Możesz na przykład użyć setMaximumFailedPasswordsForWipe()
, aby określić, że urządzenie powinno zostać wyczyszczone po określonej liczbie nieudanych prób wpisania hasła.
Dane zostaną usunięte w ten sposób:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Java
DevicePolicyManager dpm; dpm.wipeData(0);
Metoda wipeData()
przyjmuje jako parametr jako maskę dodatkowych opcji. Obecnie wartość musi wynosić 0.
Wyłączanie aparatu
Począwszy od Androida 4.0, możesz wyłączyć aparat. 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, godziny itd.
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 3.0, można używać metody setStorageEncryption()
do ustawiania zasad wymagających szyfrowania obszaru pamięci masowej (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, jak włączyć szyfrowanie pamięci masowej, znajdziesz w przykładowym interfejsie Device Administration API.
Dodatkowe przykłady kodu
Przykłady Android AppRestrictionEnforcer i DeviceOwner pokazują wykorzystanie interfejsów API omówionych na tej stronie.