Ta strona została przetłumaczona przez Cloud Translation API.

Omówienie administrowania urządzeniem

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:

Tabela 1. Zasady obsługiwane przez interfejs Device Administration API.

Zasady	Opis
Hasło włączone	Wymaga, aby urządzenia prosiły o kod PIN lub hasło.
Minimalna długość hasła	Ustaw wymaganą liczbę znaków 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.

Rysunek 1. Zrzut ekranu przedstawiający przykładową aplikację

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.
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 podklasa DeviceAdminReceiver. , 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 podklasa DeviceAdminReceiver 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 uprawnienia BIND_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.

Rysunek 2. Przykładowa aplikacja: aktywowanie aplikacji

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:

Konfigurowanie zasad dotyczących haseł
Ustawianie blokady urządzenia
Czyszczenie danych

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ść:

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.