Wycofanie administratora urządzenia. Od Androida 9 (poziom interfejsu API 28), niektóre zasady administracyjne zostaną oznaczone jako wycofane, wywołany przez administratora urządzenia. Zalecamy, aby już teraz przygotować się do tej zmiany. Aby się uczyć i poznać opcje migracji, przeczytaj Wycofanie administratora urządzenia.
Android zapewnia obsługę aplikacji firmowych, oferując Android Device Administration API. Interfejs Device Administration API udostępnia urządzenia funkcje administracyjne na poziomie systemu. Te interfejsy API pozwalają tworzyć zwiększających bezpieczeństwo podczas pracy w aplikacjach, przydatnych w firmach, wymagają zaawansowanej kontroli nad urządzeniami pracowników. Na przykład parametr wbudowana aplikacja pocztowa na Androida wykorzystała te interfejsy API, Obsługa Exchange. Za pomocą aplikacji Poczta administratorzy Exchange mogą wymuszanie stosowania zasad dotyczących haseł, w tym haseł alfanumerycznych i liczbowych; Kody PIN na wszystkich urządzeniach. Administratorzy mogą też zdalnie czyścić pamięć urządzenia (czyli przywrócić ustawienia fabryczne) zgubionych lub skradzionych telefonów. Użytkownicy Exchange mogą synchronizować jego dane poczty e-mail i kalendarza.
Ten dokument jest przeznaczony dla programistów, którzy chcą tworzyć rozwiązania dla firm rozwiązań przeznaczonych dla urządzeń z systemem Android. Omawiamy w nim różne funkcje udostępniane przez interfejs Device Administration API w celu zapewnienia silniejszych zabezpieczeń na urządzeniach z Androidem dla pracowników.
Uwaga: informacje na temat tworzenia zasad pracy Kontroler do wdrożeń Android for Work: zobacz Utwórz kontroler zasad dotyczących urządzeń.
Tryb właściciela urządzenia bez interfejsu graficznego
Android 14 (poziom interfejsu API 34) wprowadza tryb użytkownika bez interfejsu graficznego (urządzenia
który
UserManager.isHeadlessSystemUserMode
zwraca true
). W trybie użytkownika systemowego bez interfejsu graficznego użytkownik systemu
użytkownika działającego w tle i polega na dodatkowych użytkownikach na pierwszym planie w przypadku użytkownika końcowego
interakcji. Android 14 to również
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
innego niż użytkownik systemowy, dla którego skonfigurowano właściciela urządzenia.
na urządzeniach skonfigurowanych z użytkownikiem bez interfejsu graficznego (gdy użytkownik systemowy
działanie w tle), tylko globalne zasady dotyczące urządzeń.
(zasady obowiązujące wszystkich użytkowników) są stosowane do użytkownika na pierwszym planie.
lub użytkowników. Zobacz
addUserRestriction
.
Producenci urządzeń z Androidem mogą odnosić się do wskazówki opublikowano 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ądzenia, które użytkownicy na swoich urządzeniach. Aplikacja do administrowania urządzeniem wymusza stosowanie . Jak to działa:
- Administrator systemu tworzy aplikację do administrowania urządzeniem, która wymusza zasady zabezpieczeń urządzeń zdalnych/lokalnych. Te zasady można umieścić na stałe w kodzie aplikacja lub może dynamicznie pobierać zasady z innej witryny serwera.
- Aplikacja jest zainstalowana na urządzeniach użytkowników urządzenia. Android
nie ma obecnie rozwiązania do automatycznej obsługi administracyjnej. Niektóre możliwe zastosowania Sysadmin
należy dystrybuować aplikację w następujący sposób:
- 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. Jak To, kiedy to się stanie, zależy od sposobu implementacji aplikacji.
- Gdy użytkownicy włączą aplikację do administrowania urządzeniem, podlegają jej zasadami. Przestrzeganie tych zasad zwykle przynosi korzyści takie jak: 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 przestrzega zasad (na przykład ustaw które narusza wytyczne), to aplikacja decyduje, jak sobie z tym radzić. Zazwyczaj powoduje to jednak, że użytkownik przestaje być synchronizować dane.
Jeśli urządzenie próbuje połączyć się z serwerem, który wymaga zasad, które nie są jest obsługiwany przez interfejs Device Administration API, połączenie nie będzie są dozwolone. Interfejs Device Administration API nie zezwala obecnie na i udostępnianie danych. Inaczej mówiąc, jeśli urządzenie (np. starsze) nie obsługują wszystkich wymienionych zasad, nie można zezwolić na urządzenie, które chcesz połączyć.
Jeśli na urządzeniu jest kilka włączonych aplikacji administratora, najbardziej rygorystyczna zasada to jest egzekwowane. Nie można kierować reklam do konkretnego administratora .
Aby odinstalować dotychczasową aplikację do administrowania urządzeniem, użytkownicy muszą: najpierw wyrejestruj aplikację jako administrator.
Zasady
W środowisku korporacyjnym pracownicy często muszą używać urządzeń muszą być zgodne ze ścisłym zestawem zasad regulujących korzystanie z urządzenia. Interfejs Device Administration API obsługuje zasady wymienione w tabeli 1. Pamiętaj, że interfejs Device Administration API obsługuje obecnie tylko hasła na ekranie blokada:
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 hasła. Na przykład: może wymagać kodu PIN lub hasła o długości co najmniej 6 znaków. |
Wymagane hasło z kodem alfanumerycznym | Wymaga, aby hasła miały kombinacji 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 wszystkich lub tylko jednego administratora. Wprowadzono w Androidzie 3.0. |
Minimalna liczba małych liter wymaganych w haśle | Minimalna liczba małych liter liter wymaganych w haśle wszystkich lub tylko jednego administratora. Wprowadzono w Androidzie 3.0. |
Minimalna liczba znaków innych niż litery wymaganych w haśle | Minimalna liczba inne niż litery wymagane w haśle do wszystkich lub tylko jednego administratora. 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ł.
Te zasady są zwykle używane w połączeniu z
setPasswordExpirationTimeout() , co wymusza
użytkownicy zaktualizują swoje hasła 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 przed ciągiem czyści dane urządzenia. Interfejs Device Administration API umożliwia też administratorom zdalnie zresetować urządzenie do ustawień fabrycznych. Zabezpiecza to dane w przypadku, gdy urządzenie zaginęło lub zostało skradzione. |
Maksymalny czas braku aktywności – blokada | określa czas od ostatniego dotknięcia ekranu przez użytkownika; przycisk został naciśnięty, zanim urządzenie zablokuje ekran. W takim przypadku użytkownicy muszą ponownie wpisać kod PIN lub hasło, aby móc korzystać z urządzeń uzyskać 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 ten element nie zawiera ich trwałe wyłączenie. Kamerę można włączać i wyłączać dynamicznie w zależności od kontekstu, czasu itd. Wprowadzone w Androidzie 4.0. |
Inne funkcje
Oprócz zasad wymienionych w powyższej tabeli Urządzenie Interfejs 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 dotyczą interfejsu Device Administration API
który jest dołączony do przykładowych pakietów SDK (dostępnych
Android SDK Manager) i znajdują 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 z interfejsem, który pozwala włączyć aplikację administratora urządzenia. Jednorazowo którzy włączyli aplikację, mogą używać przycisków w interfejsie wykonaj następujące czynności:
- Ustaw jakość haseł.
- Określ wymagania dotyczące hasła użytkownika, takie jak minimalna długość, minimalna liczba znaków są to znaki numeryczne itd.
- Ustaw hasło. Jeśli hasło nie jest zgodne z podanym zasad, system zwróci błąd.
- Określ liczbę nieudanych prób wpisania hasła, zanim pamięć urządzenia zostanie wyczyszczona (czyli przywrócone są ustawienia fabryczne).
- Określ, po jakim czasie hasło wygaśnie.
- Ustaw długość historii haseł (length odnosi się do liczby starych haseł przechowywanych w historii). Uniemożliwia to użytkownikom ponowne korzystanie z aplikacji jedno z ostatnich n haseł, których użytkownik używał wcześniej.
- Określ, że obszar przechowywania danych powinien być zaszyfrowany, jeśli urządzenie obsługuje tę funkcję.
- Ustaw maksymalny czas braku aktywności, który może upłynąć, zanim urządzenie zamków.
- 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 wymuszanie zdalnego/lokalnego egzekwowania zasad bezpieczeństwa urządzeń Ta sekcja podsumowuje kroki niezbędne do utworzenia administrowania urządzeniem .
Tworzę plik manifestu
Aby można było korzystać z interfejsu Device Administration API, Plik manifestu musi zawierać te elementy:
- Podklasa klasy
DeviceAdminReceiver
, która obejmuje te elementy:- Uprawnienie
BIND_DEVICE_ADMIN
. - Możliwość reagowania na
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 ciągu znaków, w których znajdują się aplikacje przykładowe
ApiDemos/res/values/strings.xml
Więcej informacji o zasobach znajdziesz tutaj: Materiały zgłoszeniowe.android:label="@string/activity_sample_device_admin"
odnosi się do czytelna dla użytkownika etykieta aktywności.android:label="@string/sample_device_admin"
odnosi się do czytelna dla użytkownika etykieta uprawnienia.android:description="@string/sample_device_admin_description"
odnosi się do czytelny dla użytkownika opis uprawnienia. Opis jest zwykle dłuższy i dłuższy informacyjne niż etykietę.
android:permission="android.permission.BIND_DEVICE_ADMIN"
to uprawnienie, które musi podklasaDeviceAdminReceiver
. , by mieć pewność, że tylko system będzie mógł wchodzić w interakcję z odbiornikiem (żadna aplikacja nie może otrzymać tego uprawnienia). Ten zapobiega wykorzystywaniu Twojej aplikacji do administrowania urządzeniem przez inne aplikacje.android.app.action.DEVICE_ADMIN_ENABLED
jest głównym elementem działanie, które podklasaDeviceAdminReceiver
musi obsługiwać, aby została mogą zarządzać urządzeniem. Gdy użytkownik włączy tę opcję, będzie ustawiona na odbiorcę. z aplikacji do administrowania urządzeniem. Twój kod zwykle zajmuje się tym w języku:onEnabled()
Aby ta usługa była obsługiwana, odbiorca musi też wymaga uprawnieniaBIND_DEVICE_ADMIN
, aby inne aplikacje nie mogą nadużywać.- Gdy użytkownik włączy aplikację do administrowania urządzeniem, otrzyma dostęp pozwolenie na wykonywanie działań w odpowiedzi na transmisję danych z danego systemu zdarzeń. Gdy zajdzie odpowiednie zdarzenie, aplikacja może nałożyć odpowiednie zasady. Dla: na przykład gdy użytkownik próbuje ustawić nowe hasło, które nie jest zgodne z zasadami. aplikacji, aplikacja może poprosić użytkownika o wybranie innego hasła który spełnia wymagania.
- Nie zmieniaj nazwy odbiorcy po opublikowaniu aplikacji. Jeśli imię i nazwisko w
zmian w pliku manifestu, administrator urządzenia jest wyłączony, gdy użytkownicy zaktualizują aplikację. Więcej informacji:
<receiver>
android:resource="@xml/device_admin_sample"
deklaruje zasady bezpieczeństwa używane w metadanych. Metadane zawierają dodatkowe informacje specyficzne dla 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>
Projektując aplikację do administrowania urządzeniem, nie musisz uwzględnić wszystkie zasady – tylko te, które dotyczą 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 implementacji komponentu administrowania urządzeniem. Te zajęcia:
Wygoda przy interpretowaniu surowych działań intencji, które są wysyłane przez
systemu. Aplikacja do administrowania urządzeniem musi zawierać
Podklasa
DeviceAdminReceiver
. DevicePolicyManager
- Klasy do zarządzania zasadami wymuszanymi na urządzeniu. Większość klientów
ta klasa musi mieć opublikowany element
DeviceAdminReceiver
, który użytkownik Program jest obecnie włączony.DevicePolicyManager
zarządza zasadami dotyczącymi co najmniej 1 instancjęDeviceAdminReceiver
DeviceAdminInfo
- Ta klasa służy do określania metadanych dla komponentu administratora urządzenia.
Te klasy stanowią podstawę w pełni funkcjonalnej aplikacji do administrowania urządzeniem.
Z dalszej części tej sekcji dowiesz się, jak korzystać z DeviceAdminReceiver
i
Interfejsy API DevicePolicyManager
do pisania aplikacji do administrowania urządzeniem.
Podklasyfikowanie odbiorcy DeviceAdmin Receiver
Aby utworzyć aplikację do administrowania urządzeniem, musisz podklasę
DeviceAdminReceiver
Zajęcia: DeviceAdminReceiver
składa się z serii wywołań zwrotnych, które są wywoływane, gdy określone zdarzenia
wystąpienia.
W podklasie DeviceAdminReceiver
przykładowa aplikacja
wyświetla po prostu powiadomienie Toast
w odpowiedzi na określone
zdarzeń. 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 ważnych zdarzeń, którym musi obsługiwać aplikacja do zarządzania urządzeniem, jest: włączenie aplikacji. Użytkownik musi jawnie włączyć aplikację dla zasady, które mają być egzekwowane. Jeśli użytkownik nie włączy aplikacji będzie on nadal dostępny na urządzeniu, ale jego zasady nie będą egzekwowane, a użytkownik nie czerpać korzyści z tej aplikacji.
Proces włączania aplikacji rozpoczyna się, gdy użytkownik wykona
działanie, które wywołuje ACTION_ADD_DEVICE_ADMIN
intencji. W
przykładowej aplikacji, dzieje się tak, gdy użytkownik kliknie przycisk Włącz
Administracja.
Gdy użytkownik kliknie pole wyboru Włącz ustawienia administratora, zmiany zachęcające użytkownika do aktywowania 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
onPreferenceChange()
oddzwanianie. 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ę, na ekranie
zmiany zachęcające użytkownika do aktywowania aplikacji do administrowania urządzeniem, jak pokazano na ilustracji
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
(czyli
komponent DeviceAdminReceiver
) to zasada docelowa.
Ten wiersz wywołuje interfejs widoczny na ilustracji 2, który prowadzi użytkowników przez
dodanie administratora urządzenia do systemu (lub zezwolenie mu na odrzucenie).
Gdy aplikacja musi wykonać operację, która zależy od
aplikacji do administrowania urządzeniem, potwierdza to, że została
aktywne. Wykorzystuje do tego metodę DevicePolicyManager
isAdminActive()
Zwróć uwagę, że w tabeli DevicePolicyManager
metoda isAdminActive()
pobiera DeviceAdminReceiver
jako argumentu:
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
wyegzekwowane na urządzeniu. DevicePolicyManager
zarządza zasadami jednego
lub więcej 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);
Z tej sekcji dowiesz się, jak wykorzystać DevicePolicyManager
do realizacji
zadania administracyjne:
Ustawianie zasad dotyczących haseł
DevicePolicyManager
zawiera interfejsy API do konfigurowania i egzekwowania zasad
zasad dotyczących haseł na urządzeniach. 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ć zawierające co najmniej znaki alfabetyczne (lub inne symbole).
PASSWORD_QUALITY_ALPHANUMERIC
- Użytkownik musi wpisać Hasło musi zawierać co najmniej zarówno cyfry, jak i litery alfabetu innych symboli).
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 ze specjalnym symbolem.
PASSWORD_QUALITY_SOMETHING
- zasady wymagają ale nie jest ważne, jakie ono jest.
PASSWORD_QUALITY_UNSPECIFIED
- Zasady nie narzucają 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 pozwalają dostosować treść hasła. Dla:
można ustawić zasadę, zgodnie z którą hasła muszą zawierać
n wielkich liter. Oto metody dostrajania hasła
zawartość:
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 określić, że hasło musi zawierać co najmniej określone minimum. długości. 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 wpisania hasła przed pamięć urządzenia zostanie wyczyszczona (tzn. zostaną przywrócone 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);
Ustawianie czasu wygaśnięcia hasła
W Androidzie 3.0 możesz używać
setPasswordExpirationTimeout()
metody określania czasu wygaśnięcia hasła, wyrażonej w postaci delta 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
W Androidzie 3.0 możesz używać
setPasswordHistoryLength()
metody ograniczania dostępu użytkowników
możliwość ponownego używania starych haseł. Ta metoda zajmuje length
który określa liczbę starych
hasła są zachowywane. Gdy ta zasada jest aktywna, użytkownicy nie mogą wpisywać nowej
które jest zgodne z ostatnimi n hasłami. Zapobiega to
przed ciągłym używaniem tego samego hasła. Ta zasada jest zwykle używana
w koniunkcji z
setPasswordExpirationTimeout()
,
co wymusza na użytkownikach
zaktualizować swoje hasła po upływie określonego czasu.
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, który może wystąpić przed blokady 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
Możesz użyć metody DevicePolicyManager
wipeData()
, aby przywrócić ustawienia fabryczne urządzenia. To jest przydatne
w przypadku zgubienia lub kradzieży urządzenia. Decyzję o wyczyszczeniu pamięci urządzenia często podejmujemy
w wyniku spełnienia określonych warunków. Na przykład możesz użyć
setMaximumFailedPasswordsForWipe()
, aby wskazać, że urządzenie powinno być
wyczyszczone po określonej liczbie nieudanych prób wpisania 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);
Metoda wipeData()
przyjmuje jako
maską bitową 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
Metoda 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
W Androidzie 3.0 możesz używać
setStorageEncryption()
aby skonfigurować zasadę wymagającą szyfrowania obszaru przechowywania (o ile jest ona 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
Android AppRestrictionEnforcer i DeviceOwner W przykładach szczegółowo opisano wykorzystanie interfejsów API opisanych na tej stronie.