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 po wywołaniu przez administratora urządzenia. Zalecamy, aby już teraz zacząć się do niej przygotowywać. Więcej informacji oraz opcje migracji znajdziesz w artykule Wycofanie funkcji administracji urządzeniami.

Android obsługuje aplikacje firmowe dzięki interfejsowi Android Device Administration API. Interfejs Device Administration API zapewnia funkcje zarządzania urządzeniami na poziomie systemu. Te interfejsy API umożliwiają tworzenie aplikacji z funkcjami bezpieczeństwa, które są przydatne w środowiskach korporacyjnych, w których specjaliści IT potrzebują rozbudowanej kontroli nad urządzeniami pracowników. Na przykład wbudowana aplikacja poczty e-mail na Androida korzysta z tych interfejsów API, aby poprawić obsługę Exchange. Za pomocą aplikacji Poczta administratorzy Exchange mogą egzekwować zasady dotyczące haseł (w tym alfanumerycznych haseł i liczbowych kodów PIN) na różnych urządzeniach. Administratorzy mogą też zdalnie usuwać dane (tj. przywrócić ustawienia fabryczne) zgubionych lub skradzionych telefonów. Użytkownicy Exchange mogą zsynchronizować dane poczty e-mail i kalendarza.

Ten dokument jest przeznaczony dla programistów, którzy chcą tworzyć rozwiązania dla firm na urządzenia z Androidem. W tym artykule omawiamy różne funkcje interfejsu Device Administration API, które zapewniają większą ochronę urządzeń pracowników z Androidem.

Uwaga: informacje o tworzeniu kontrolera Work Policy dla wdrożeń Android for Work znajdziesz w artykule o tworzeniu kontrolera zasad dotyczących urządzeń.

Tryb właściciela urządzenia bez interfejsu graficznego

Android 14 (poziom interfejsu API 34) wprowadza tryb użytkownika systemowego bez interfejsu graficznego (urządzenia, na których UserManager.isHeadlessSystemUserMode zwraca true). W trybie użytkownika systemowego bez interfejsu graficznego użytkownik systemu jest użytkownikiem w tle i podczas interakcji z nim polega na dodatkowych użytkownikach na pierwszym planie. Android 14 wprowadza też tryb powiązania z urządzeniem bez interfejsu graficznego, który dodaje właściciela profilu do wszystkich powiązanych użytkowników, z wyjątkiem użytkownika systemu, na którym ustawiono właściciela urządzenia.

W przypadku urządzeń skonfigurowanych z użyciem bezgłowy użytkownik systemu (gdzie użytkownik systemu działa w tle) tylko zasady urządzenia o zasięgu globalnym (zasady obowiązujące wszystkich użytkowników) są stosowane do użytkowników na pierwszym planie. Więcej informacji znajdziesz w sekcji addUserRestriction.

Producenci urządzeń z Androidem mogą skorzystać z wskazówek opublikowanych na stronie source.android.com.

Omówienie interfejsu API do administrowania urządzeniami

Oto przykłady typów aplikacji, które mogą używać interfejsu Device Administration API:

Wysyłanie e-maili do klientów.
aplikacje zabezpieczające, które umożliwiają zdalne czyszczenie;
Usługi i aplikacje do zarządzania urządzeniami.

Jak to działa?

Interfejs Device Administration API służy do tworzenia aplikacji administracyjnych, które użytkownicy instalują na swoich urządzeniach. Aplikacja administratora urządzenia wymusza stosowanie odpowiednich zasad. Jak to działa:

Administrator systemu tworzy aplikację do zarządzania urządzeniem, która wymusza stosowanie zasad bezpieczeństwa urządzeń zdalnych lub lokalnych. Te zasady mogą być zakodowane w aplikacji lub pobierane dynamicznie z zewnętrznego serwera.
Aplikacja została zainstalowana na urządzeniach użytkowników. Android nie ma obecnie automatycznego rozwiązania do obsługi wdrożenia. Oto kilka sposobów dystrybucji aplikacji przez administratora systemu:
- Google Play.
- Włączanie instalacji z innego sklepu.
- rozpowszechnianie aplikacji za pomocą innych środków, takich jak e-maile czy strony internetowe;
System prosi użytkownika o włączenie aplikacji do administrowania urządzeniem. Sposób i czas wykonania tej czynności zależy od tego, jak aplikacja została zaimplementowana.
Gdy użytkownicy włączą aplikację do administrowania urządzeniem, będą one podlegać jej zasadom. Ich przestrzeganie zwykle przynosi korzyści, np. dostęp do poufnych systemów i danych.

Jeśli użytkownicy nie włączą aplikacji administratora urządzenia, pozostanie ona na urządzeniu, ale w stanie nieaktywnym. Użytkownicy nie będą podlegać 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 (np. ustawia hasło, które narusza wytyczne), aplikacja sama decyduje, jak sobie z tym poradzić. Jednak zwykle powoduje to, że użytkownik nie może zsynchronizować danych.

Jeśli urządzenie spróbuje połączyć się z serwerem, który wymaga zasad nieobsługiwanych przez interfejs Device Administration API, połączenie nie zostanie dozwolone. Interfejs Device Administration API nie umożliwia obecnie częściowego udostępniania. Innymi słowy, jeśli urządzenie (np. starsze) nie obsługuje wszystkich podanych zasad, nie ma możliwości zezwolenia mu na połączenie.

Jeśli na urządzeniu jest włączonych kilka aplikacji administratora, obowiązuje najbardziej restrykcyjna zasada. Nie można kierować reklam na konkretne aplikacje administratora.

Aby odinstalować istniejącą aplikację administratora urządzenia, użytkownicy muszą najpierw wyrejestrować ją jako administratora.

Zasady

W środowisku korporacyjnym często zdarza się, że urządzenia pracowników muszą przestrzegać rygorystycznych zasad dotyczących korzystania z urządzeń. Interfejs Device Administration API obsługuje zasady wymienione w tabeli 1. Pamiętaj, że interfejs Device Administration API obsługuje obecnie tylko hasła do blokady ekranu:

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. Możesz na przykład wymagać, aby kod PIN lub hasła miały co najmniej 6 znaków.
Wymagane hasło ze znakami alfanumerycznymi	Hasła muszą zawierać kombinację liter i cyfr. Mogą zawierać znaki symboliczne.
Wymagane złożone hasło	Hasła muszą zawierać co najmniej 1 literę, 1 cyfrę i 1 znak specjalny. Wprowadzona w Androidzie 3.0.
Minimalna liczba liter wymaganych w haśle	Minimalna liczba liter wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba małych liter wymagana w hasłach	Minimalna liczba małych liter wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba znaków innych niż litery wymaganych w haśle	Minimalna liczba znaków niebędących literami wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba cyfr wymagana w haśle	Minimalna liczba cyfr wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba symboli wymagana w haśle	Minimalna liczba znaków wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba wielkich liter w haśle	Minimalna liczba wielkich liter wymagana w haśle 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. Wprowadzona w Androidzie 3.0.
Ograniczenie dotyczące historii haseł	Ta zasada uniemożliwia użytkownikom ponowne użycie ostatnich n unikalnych haseł. Ta zasada jest zwykle używana w połączeniu z zasadą `setPasswordExpirationTimeout()`, która wymusza na użytkownikach zaktualizowanie haseł po upływie określonego czasu. Wprowadzona w Androidzie 3.0.
Maksymalna liczba nieudanych prób podania hasła	Określa, ile razy użytkownik może podać nieprawidłowe hasło, zanim urządzenie usunie dane. Interfejs Device Administration API umożliwia też administratorom zdalne przywracanie urządzenia do ustawień fabrycznych. Zabezpiecza to dane w przypadku zgubienia lub kradzieży.
Maksymalny czas braku aktywności – blokada	Określa czas od ostatniego dotknięcia ekranu lub naciśnięcia przycisku do zablokowania ekranu. W takim przypadku użytkownicy będą musieli ponownie wpisać kod PIN lub hasła, aby móc korzystać z urządzeń i uzyskiwać dostęp do danych. Wartość może wynosić od 1 do 60 minut.
Wymaganie szyfrowania przechowywanych danych	Określa, że obszar pamięci powinien być zaszyfrowany, jeśli urządzenie obsługuje szyfrowanie. Wprowadzono w Androidzie 3.0.
Wyłącz kamerę	Określa, że kamera powinna być wyłączona. Pamiętaj, że nie musisz wyłączyć funkcji na stałe. Aparat może być włączany/wyłączany dynamicznie na podstawie kontekstu, czasu itp. Wprowadzona w Androidzie 4.0.

Inne funkcje

Oprócz obsługi zasad wymienionych w powyższej tabeli interfejs Device Administration API umożliwia:

Poproś użytkownika o ustawienie nowego hasła.
Natychmiast zablokuj urządzenie.
Wyczyść dane urządzenia (czyli przywróć urządzenie do ustawień fabrycznych).

Przykładowa aplikacja

Przykłady na tej stronie są oparte na przykładowym interfejsie Device Administration API, który jest dostępny w przykładach pakietu SDK (dostępnych w Menedżerze pakietu Android SDK) i znajduje się w Twoim systemie jako <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java.

Przykładowa aplikacja zawiera demonstrację funkcji administracyjnych urządzenia. Użytkownicy widzą interfejs, który pozwala im włączyć aplikację do zarządzania urządzeniem. Po włączeniu aplikacji mogą używać przycisków w interfejsie do wykonywania tych czynności:

Ustaw jakość hasła.
Określ wymagania dotyczące hasła użytkownika, takie jak minimalna długość, minimalna liczba znaków liczbowych, które musi zawierać, itp.
Ustaw hasło. Jeśli hasło nie jest zgodne ze specyfikacją, system zwraca błąd.
Określ, ile razy użytkownik może nieprawidłowo wpisać hasło, zanim urządzenie zostanie wyczyszczone (czyli przywrócone do ustawień fabrycznych).
Określ, kiedy wygaśnie hasło.
Ustaw długość historii haseł (length odnosi się do liczby starych haseł przechowywanych w historii). Zapobiega to ponownemu użyciu przez użytkowników jednego z ostatnich n haseł.
Określ, że obszar pamięci powinien być zaszyfrowany (jeśli urządzenie obsługuje tę funkcję).
Ustaw maksymalny czas bezczynności, po którym urządzenie się zablokuje.
Natychmiast zablokuj urządzenie.
Wyczyszczenie danych na urządzeniu (czyli przywrócenie ustawień fabrycznych).
Wyłącz aparat.

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

Tworzenie aplikacji do administrowania urządzeniami

Administratorzy systemu mogą użyć interfejsu Device Administration API, aby napisać aplikację, która egzekwuje zasady zabezpieczeń na urządzeniach zdalnie lub lokalnie. W tej sekcji podsumowujemy kroki potrzebne do utworzenia aplikacji do administrowania urządzeniem.

Tworzenie pliku manifestu

Aby korzystać z interfejsu Device Administration API, manifest aplikacji musi zawierać:

Podklasa klasy DeviceAdminReceiver, która obejmuje te elementy:
- Uprawnienie BIND_DEVICE_ADMIN.
- Możliwość odpowiadania na intencję ACTION_DEVICE_ADMIN_ENABLED wyrażoną w pliku manifestu jako filtr intencji.
deklaracja zasad bezpieczeństwa używanych w metadanych.

Oto fragment przykładowego pliku manifestu administracji urządzenia:

<activity android:name=".app.DeviceAdminSample"
            android:label="@string/activity_sample_device_admin">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.SAMPLE_CODE" />
    </intent-filter>
</activity>
<receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver"
        android:label="@string/sample_device_admin"
        android:description="@string/sample_device_admin_description"
        android:permission="android.permission.BIND_DEVICE_ADMIN">
    <meta-data android:name="android.app.device_admin"
            android:resource="@xml/device_admin_sample" />
    <intent-filter>
        <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
    </intent-filter>
</receiver>

Uwaga:

Te atrybuty odnoszą się do zasobów ciągu znaków, które w przypadku przykładowej aplikacji znajdują się w katalogu ApiDemos/res/values/strings.xml. Więcej informacji o zasobach znajdziesz w artykule na temat zasobów aplikacji.
- android:label="@string/activity_sample_device_admin" to czytelna dla użytkownika etykieta aktywności.
- android:label="@string/sample_device_admin" to czytelna dla użytkownika etykieta uprawnienia.
- android:description="@string/sample_device_admin_description" odnosi się do czytelnego dla użytkownika opisu uprawnienia. Opis jest zwykle dłuższy i bardziej szczegółowy niż etykieta.
android:permission="android.permission.BIND_DEVICE_ADMIN" to uprawnienie, które musi mieć podklasa DeviceAdminReceiver, aby mieć pewność, że tylko system może wchodzić w interakcję z odbiornikiem (żadnej aplikacji nie można przyznać tego uprawnienia). Zapobiega to wykorzystywaniu Twojej aplikacji do administrowania urządzeniem przez inne aplikacje.
android.app.action.DEVICE_ADMIN_ENABLED to główne działanie, które podklasa DeviceAdminReceiver musi obsłużyć, aby można było zarządzać urządzeniem. Jest on ustawiany na odbiornik, gdy użytkownik włączy aplikację do zarządzania urządzeniem. Twój kod zwykle obsługuje to w onEnabled(). Aby aplikacja była obsługiwana, odbiorca musi też wymagać uprawnienia BIND_DEVICE_ADMIN, aby inne aplikacje nie mogły go nadużywać.
Gdy użytkownik włączy aplikację do zarządzania urządzeniem, da to odbiorcom uprawnienia do wykonywania działań w odpowiedzi na rozpowszechnianie określonych zdarzeń systemowych. Gdy wystąpi odpowiednie zdarzenie, aplikacja może zastosować zasady. Jeśli na przykład użytkownik spróbuje ustawić nowe hasło, które nie spełnia wymagań, aplikacja może poprosić go o wybranie innego hasła, które spełnia te wymagania.
Nie zmieniaj nazwy odbiorcy po opublikowaniu aplikacji. Jeśli nazwa w pliku manifestu ulegnie zmianie, funkcja administratora urządzenia zostanie wyłączona, gdy użytkownicy zaktualizują aplikację. Więcej informacji znajdziesz w artykule <receiver>.
android:resource="@xml/device_admin_sample" deklaruje zasady bezpieczeństwa używane w metadanych. Metadane zawierają dodatkowe informacje dotyczące administratora urządzenia, które są analizowane przez klasę DeviceAdminInfo. Oto zawartość device_admin_sample.xml:

<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
  <uses-policies>
    <limit-password />
    <watch-login />
    <reset-password />
    <force-lock />
    <wipe-data />
    <expire-password />
    <encrypted-storage />
    <disable-camera />
  </uses-policies>
</device-admin>

Podczas projektowania aplikacji do administrowania urządzeniem nie musisz uwzględniać wszystkich zasad – tylko tych, które są związane z Twoją aplikacją.

Więcej informacji o pliku manifestu znajdziesz w przewodniku dla deweloperów aplikacji na Androida.

Implementowanie kodu

Interfejs Device Administration API obejmuje te klasy:

DeviceAdminReceiver: Klasa podstawowa do implementacji komponentu administrowania urządzeniem. Ta klasa ułatwia interpretowanie działań związanych z zamierzeniem w postaci nieprzetworzonych danych, które są wysyłane przez system. Aplikacja Zarządzanie urządzeniem musi zawierać podklasę DeviceAdminReceiver.
DevicePolicyManager: Klasy do zarządzania zasadami wymuszanymi na urządzeniu. Większość klientów tej klasy musi opublikować DeviceAdminReceiver, który jest obecnie włączony przez użytkownika. DevicePolicyManager zarządza zasadami co najmniej 1 instancji DeviceAdminReceiver
DeviceAdminInfo: Ta klasa służy do określania metadanych komponentu administratora urządzenia.

Te klasy stanowią podstawę w pełni funkcjonalnej aplikacji do zarządzania urządzeniem. W pozostałych częściach tej sekcji opisano, jak używać interfejsów API DeviceAdminReceiver i DevicePolicyManager do pisania aplikacji do zarządzania urządzeniem.

Tworzenie podklasy klasy DeviceAdminReceiver

Aby utworzyć aplikację do administrowania urządzeniem, musisz mieć podklasę DeviceAdminReceiver. Klasa DeviceAdminReceiver składa się z szeregu wywołań zwrotnych, które są wywoływane po wystąpieniu określonych zdarzeń.

W podklasie DeviceAdminReceiver przykładowa aplikacja wyświetla powiadomienie Toast w odpowiedzi na określone zdarzenia. 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łączanie aplikacji

Jednym z głównych zdarzeń, które musi obsłużyć aplikacja administratora urządzenia, jest włączenie aplikacji przez użytkownika. Aby zasady mogły obowiązywać, użytkownik musi wyraźnie włączyć aplikację. Jeśli użytkownik nie włączy aplikacji, nadal będzie ona widoczna na urządzeniu, ale jej zasady nie będą egzekwowane i nie będą miały żadnych zalet aplikacji.

Proces włączania aplikacji rozpoczyna się, gdy użytkownik wykona działanie, które powoduje wywołanie inencji ACTION_ADD_DEVICE_ADMIN. W przypadku aplikacji przykładowej dzieje się to, gdy użytkownik kliknie pole wyboru Włącz Administracja.

Gdy użytkownik kliknie pole wyboru Włącz administratora, wyświetli się ekran z prośbą o aktywowanie aplikacji administratora urządzenia (patrz rysunek 2).

Rysunek 2. Przykładowa aplikacja: aktywowanie aplikacji

Poniżej znajduje się kod, który jest wykonywany, gdy użytkownik kliknie pole wyboru Włącz administratora. Powoduje to aktywowanie wywołania zwrotnego onPreferenceChange(). To wywołanie zwrotne jest wywoływane, gdy wartość parametru Preference została zmieniona przez użytkownika i ma zostać ustawiona lub zachowana. Jeśli użytkownik włącza aplikację, wyświetlacz zmienia się, aby wyświetlić prośbę o aktywowanie aplikacji do administrowania urządzeniem (patrz rysunek 2). W przeciwnym razie aplikacja do administrowania urządzeniem jest wyłączona.

Kotlin

override fun onPreferenceChange(preference: Preference, newValue: Any): Boolean {
    if (super.onPreferenceChange(preference, newValue)) return true
    val value = newValue as Boolean
    if (preference == enableCheckbox) {
        if (value != adminActive) {
            if (value) {
                // Launch the activity to have the user enable our admin.
                val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply {
                    putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample)
                    putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
                            activity.getString(R.string.add_admin_extra_app_text))
                }
                startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN)
                // return false - don't update checkbox until we're really active
                return false
            } else {
                dpm.removeActiveAdmin(deviceAdminSample)
                enableDeviceCapabilitiesArea(false)
                adminActive = false
            }
        }
    } else if (preference == disableCameraCheckbox) {
        dpm.setCameraDisabled(deviceAdminSample, value)
    }
    return true
}

Java

@Override
public boolean onPreferenceChange(Preference preference, Object newValue) {
    if (super.onPreferenceChange(preference, newValue)) {
        return true;
    }
    boolean value = (Boolean) newValue;
    if (preference == enableCheckbox) {
        if (value != adminActive) {
            if (value) {
                // Launch the activity to have the user enable our admin.
                Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
                intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample);
                intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
                        activity.getString(R.string.add_admin_extra_app_text));
                startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN);
                // return false - don't update checkbox until we're really active
                return false;
            } else {
                dpm.removeActiveAdmin(deviceAdminSample);
                enableDeviceCapabilitiesArea(false);
                adminActive = false;
            }
        }
    } else if (preference == disableCameraCheckbox) {
        dpm.setCameraDisabled(deviceAdminSample, value);
    }
    return true;
}

Linia intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) wskazuje, że mDeviceAdminSample (która jest komponentem DeviceAdminReceiver) jest zasadą docelową. Ta linia wywołuje interfejs użytkownika pokazany na rysunku 2. Prowadzi on użytkowników przez proces dodawania administratora urządzenia do systemu (lub umożliwia odrzucenie tej opcji).

Gdy aplikacja musi wykonać operację, która zależy od włączenia aplikacji administratora urządzenia, potwierdza, że aplikacja jest aktywna. W tym celu używa metody DevicePolicyManager.isAdminActive() Zwróć uwagę, że argumentem metody DevicePolicyManager isAdminActive() jest komponent DeviceAdminReceiver:

Kotlin

private lateinit var dpm: DevicePolicyManager
...
private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)

Java

DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
    return dpm.isAdminActive(deviceAdminSample);
}

Zarządzanie zasadami

DevicePolicyManager to publiczna klasa do zarządzania zasadami stosowanymi na urządzeniu. DevicePolicyManager zarządza zasadami w co najmniej 1 instancji DeviceAdminReceiver.

Aby uzyskać identyfikator DevicePolicyManager, wykonaj te czynności:

Kotlin

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

Java

DevicePolicyManager dpm =
    (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);

Z tej sekcji dowiesz się, jak używać DevicePolicyManager do wykonywania zadań administracyjnych:

Ustawianie zasad dotyczących haseł
Konfigurowanie blokowania urządzenia
Wymazywanie danych

Ustawianie zasad dotyczących haseł

DevicePolicyManager zawiera interfejsy API do ustawiania i egzekwowania zasad dotyczących haseł na urządzeniach. W interfejsie Device Administration API hasło dotyczy tylko blokady ekranu. W tej sekcji opisano typowe czynności związane z hasłami.

Ustawianie hasła urządzenia

Ten kod wyświetla interfejs z prośbą o ustawienie hasła:

Kotlin

Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
    startActivity(intent)
}

Java

Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
startActivity(intent);

Ustawianie jakości hasła

Jakość hasła może być jedną z tych wartości stałych DevicePolicyManager:

PASSWORD_QUALITY_ALPHABETIC: Użytkownik musi wpisać hasło zawierające co najmniej litery (lub inne symbole).
PASSWORD_QUALITY_ALPHANUMERIC: Użytkownik musi podać hasło zawierające co najmniej zarówno znaki cyfry, jak i litery (lub inne symbole).
PASSWORD_QUALITY_NUMERIC: Użytkownik musi podać hasło zawierające co najmniej cyfry.
PASSWORD_QUALITY_COMPLEX: Użytkownik musi wprowadzić hasło zawierające co najmniej jedną literę, cyfrę i znak specjalny.
PASSWORD_QUALITY_SOMETHING: Polityka wymaga użycia jakiegoś rodzaju hasła, ale nie ma znaczenia, jakiego.
PASSWORD_QUALITY_UNSPECIFIED: Zasady nie określają wymagań dotyczących hasła.

Oto przykład ustawienia zasady dotyczącej hasła, która wymaga hasła alfanumerycznego:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);

Ustawianie wymagań dotyczących treści hasła

Począwszy od Androida 3.0 klasa DevicePolicyManager zawiera metody, które umożliwiają dostosowanie zawartości hasła. Możesz na przykład ustawić zasadę, że hasła muszą zawierać co najmniej n wielkich liter. Oto metody doprecyzowania zawartości hasła:

Na przykład ten fragment kodu określa, że hasło musi zawierać co najmniej 2 wielkie litery:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwMinUppercase = 2
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwMinUppercase = 2;
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase);

Ustawianie minimalnej długości hasła

Możesz określić, że hasło musi mieć co najmniej określoną minimalną długość. 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);

Ustawienie maksymalnej liczby nieudanych prób podania hasła

Możesz ustawić maksymalną liczbę dozwolonych nieudanych prób podania hasła, której przekroczenie powoduje wymazanie pamięci urządzenia (czyli przywrócenie ustawień fabrycznych). 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 ważności hasła

Od Androida 3.0 możesz używać metody setPasswordExpirationTimeout()do ustawiania czasu ważności hasła wyrażonego w milisekundach od momentu ustawienia przez administratora urządzenia czasu wygaśnięcia. 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);

Ograniczanie hasła na podstawie historii

Począwszy od Androida 3.0 możesz użyć metody setPasswordHistoryLength(), aby ograniczyć możliwość ponownego używania starych haseł przez użytkowników. Ta metoda przyjmuje parametr length, który określa, ile starych haseł jest przechowywanych. Gdy ta zasada jest aktywna, użytkownicy nie mogą wpisać nowego hasła, które jest takie samo jak ostatnie n haseł. Dzięki temu użytkownicy nie mogą wielokrotnie używać tego samego hasła. Ta zasada jest zwykle używana w połączeniu z zasadą setPasswordExpirationTimeout(), która wymusza na użytkownikach zaktualizowanie haseł po określonym czasie.

Na przykład ten fragment zabrania użytkownikom ponownego użycia któregokolwiek z 5 ostatnich haseł:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwHistoryLength = 5
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwHistoryLength = 5;
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength);

Konfigurowanie blokady urządzenia

Możesz ustawić maksymalny okres bezczynności użytkownika, po którym urządzenie się zablokuje. 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ż zaprogramować urządzenie, aby natychmiast się zablokowało:

Kotlin

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

Java

DevicePolicyManager dpm;
dpm.lockNow();

Wyczyść dane

Aby przywrócić urządzenie do ustawień fabrycznych, możesz użyć metody DevicePolicyManager wipeData(). Jest to przydatne, jeśli urządzenie zostanie zgubione lub skradzione. Decyzja o wyczyszczeniu pamięci urządzenia jest często efektem spełnienia określonych warunków. Możesz na przykład użyć parametru setMaximumFailedPasswordsForWipe(), aby określić, że dane urządzenie powinno zostać wyczyszczone po określonej liczbie nieudanych prób wpisania hasła.

Dane można wyczyścić w ten sposób:

Kotlin

private lateinit var dpm: DevicePolicyManager
dpm.wipeData(0)

Java

DevicePolicyManager dpm;
dpm.wipeData(0);

Jako parametr metody wipeData() stosowana jest maska bitowa dodatkowych opcji. Obecnie wartość musi wynosić 0.

Wyłącz kamerę

Począwszy od Androida 4.0 możesz wyłączyć kamerę. Pamiętaj, że nie musisz wyłączyć funkcji na stałe. Kamera może być włączana i wyłączana dynamicznie w zależności od kontekstu, czasu itp.

Użytkownik decyduje, czy kamera ma być wyłączona, korzystając z metody setCameraDisabled(). Na przykład ten fragment kodu powoduje, że aparat jest włączany lub wyłączany na podstawie ustawienia pola wyboru:

Kotlin

private lateinit var disableCameraCheckbox: CheckBoxPreference
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)

Java

private CheckBoxPreference disableCameraCheckbox;
DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked());

Szyfrowanie pamięci

Począwszy od Androida 3.0 możesz użyć metody setStorageEncryption(), aby ustawić zasadę wymagającą szyfrowania obszaru pamięci, w przypadku gdy jest to obsługiwane.

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 pamięci znajdziesz w przykładowym interfejsie Device Administration API.

Dodatkowe przykłady kodu

Przykłady Android AppRestrictionEnforcer i DeviceOwner pokazują, jak używać interfejsów API opisanych na tej stronie.