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

Omówienie administrowania urządzeniem

Wycofanie aplikacji do zarządzania urządzeniem Od Androida 9 (poziom API 28) niektóre zasady administracyjne będą oznaczane jako wycofane, gdy będą wywoływane przez administratora urządzenia. Zalecamy rozpoczęcie przygotowań do tej zmiany już teraz. Więcej informacji i opcje migracji znajdziesz w artykule Wycofanie administratora urządzenia.

Android obsługuje aplikacje firmowe dzięki interfejsowi Android Device Administration API. Interfejs Device Administration API udostępnia funkcje administracji urządzeniami na poziomie systemu. Te interfejsy API umożliwiają tworzenie aplikacji z uwzględnieniem zabezpieczeń, które są przydatne w środowiskach firmowych, gdzie specjaliści IT wymagają rozbudowanej kontroli nad urządzeniami pracowników. Na przykład wbudowana aplikacja poczty e-mail na Androida wykorzystuje te interfejsy API, aby ulepszyć obsługę Exchange. Administratorzy Exchange mogą wymuszać stosowanie zasad dotyczących haseł, w tym haseł alfanumerycznych lub numerycznych kodów PIN, na wszystkich urządzeniach za pomocą aplikacji Poczta. Administratorzy mogą też zdalnie wyczyścić (czyli przywrócić ustawienia fabryczne) zgubione lub skradzione telefony. Użytkownicy Exchange mogą synchronizować dane poczty e-mail i kalendarza.

Ten dokument jest przeznaczony dla programistów, którzy chcą tworzyć rozwiązania dla firm na urządzenia z Androidem. Opisuje różne funkcje interfejsu Device Administration API, które zapewniają większe bezpieczeństwo urządzeń pracowników z Androidem.

Uwaga: informacje o tworzeniu kontrolera zasad służbowych na Androida na potrzeby wdrożeń Androida w pracy znajdziesz w artykule Tworzenie 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, w których UserManager.isHeadlessSystemUserMode zwraca true). W tym trybie użytkownik systemowy działa w tle i polega na dodatkowych użytkownikach pierwszego planu w zakresie interakcji z użytkownikiem końcowym. Android 14 wprowadza też tryb powiązany właściciela urządzenia bez interfejsu graficznego, który dodaje właściciela profilu do wszystkich powiązanych użytkowników z wyjątkiem użytkownika systemu, w którym ustawiony jest właściciel urządzenia.

Na urządzeniach skonfigurowanych z użytkownikiem systemu bez interfejsu (gdzie użytkownik systemu działa w tle) do użytkownika lub użytkowników na pierwszym planie stosowane są tylko zasady dotyczące urządzenia o zakresie globalnym (zasady mające zastosowanie do wszystkich użytkowników). Więcej informacji znajdziesz w sekcji addUserRestriction.

Producenci urządzeń z Androidem mogą zapoznać się z wytycznymi opublikowanymi na stronie source.android.com.

Omówienie interfejsu Device Administration API

Oto przykłady typów aplikacji, które mogą korzystać z interfejsu Device Administration API:

klientów poczty e-mail,
aplikacje zabezpieczające, które umożliwiają zdalne czyszczenie pamięci;
usługi i aplikacje do zarządzania urządzeniami;

Jak to działa?

Za pomocą interfejsu Device Administration API możesz pisać aplikacje administratora urządzenia, które użytkownicy instalują na swoich urządzeniach. Aplikacja administratora urządzenia wymusza stosowanie odpowiednich zasad. Jak to działa:

Administrator systemu pisze aplikację administratora urządzenia, która wymusza stosowanie zdalnych/lokalnych zasad bezpieczeństwa urządzenia. Zasady te mogą być zakodowane na stałe w aplikacji lub aplikacja może dynamicznie pobierać je z serwera zewnętrznego.
Aplikacja jest instalowana na urządzeniach użytkowników. Android nie ma obecnie automatycznego rozwiązania do wdrażania. Administrator systemu może rozpowszechniać aplikację wśród użytkowników na kilka sposobów:
- Google Play.
- Włączanie instalacji z innego sklepu.
- dystrybuowanie aplikacji w inny sposób, np. za pomocą e-maila lub stron internetowych;
System wyświetla użytkownikowi prośbę o włączenie aplikacji do administrowania urządzeniem. Sposób i moment wyświetlenia tej prośby zależą od implementacji aplikacji.
Gdy użytkownicy włączą aplikację administratora urządzenia, będą podlegać jej zasadom. Przestrzeganie tych zasad zwykle przynosi korzyści, takie jak dostęp do systemów i danych o charakterze poufnym.

Jeśli użytkownicy nie włączą aplikacji administratora urządzenia, pozostanie ona na urządzeniu, ale będzie nieaktywna. Użytkownicy nie będą podlegać zasadom tej aplikacji i nie będą mogli korzystać z jej zalet, np. synchronizować danych.

Jeśli użytkownik nie przestrzega zasad (np. ustawi hasło, które narusza wytyczne), aplikacja decyduje, jak sobie z tym poradzić. Zazwyczaj jednak uniemożliwia to użytkownikowi synchronizację danych.

Jeśli urządzenie spróbuje połączyć się z serwerem, który wymaga zasad nieobsługiwanych w interfejsie Device Administration API, połączenie nie będzie możliwe. Interfejs Device Administration API nie zezwala obecnie na częściową konfigurację. Innymi słowy, jeśli urządzenie (np. starsze urządzenie) nie obsługuje wszystkich wymienionych 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 rygorystyczna zasada. Nie ma możliwości kierowania reklam na konkretną aplikację administratora.

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

Zasady

W firmach urządzenia pracowników często muszą być zgodne z ściśle określonymi zasadami, które regulują sposób korzystania z nich. 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
Włączono hasło	Wymaga, aby urządzenia prosiły o kod PIN lub hasło.
Minimalna długość hasła	Ustaw wymaganą liczbę znaków w haśle. Możesz na przykład wymagać, aby kody PIN i hasła miały co najmniej 6 znaków.
Wymagane hasło ze znakami alfanumerycznymi	Wymaga, aby hasła zawierały kombinację liter i cyfr. Mogą zawierać znaki symboliczne.
Wymagane jest złożone hasło	Wymaga, aby hasła zawierały co najmniej literę, cyfrę i symbol specjalny. Wprowadzono w Androidzie 3.0.
Minimalna liczba liter w haśle	Minimalna liczba liter wymagana w haśle wszystkich administratorów lub konkretnego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba małych liter wymagana w haśle	Minimalna liczba małych liter wymaganych w haśle wszystkich administratorów lub konkretnego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba znaków innych niż litery wymagana w haśle	Minimalna liczba znaków niebędących literami wymagana w haśle wszystkich administratorów lub wybranego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba cyfr wymagana w haśle	Minimalna liczba cyfr wymagana w haśle wszystkich administratorów lub konkretnego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba symboli wymagana w haśle	Minimalna liczba symboli wymagana w haśle wszystkich administratorów lub wybranego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba wielkich liter wymagana w haśle	Minimalna liczba wielkich liter wymagana w haśle wszystkich administratorów lub wybranego administratora. Wprowadzono w Androidzie 3.0.
Limit czasu wygaśnięcia hasła	Czas wygaśnięcia hasła wyrażony w milisekundach od momentu, w którym administrator urządzenia ustawi limit czasu wygaśnięcia. Wprowadzono w Androidzie 3.0.
Ograniczenie historii haseł	Ta zasada uniemożliwia użytkownikom ponowne użycie ostatnich n unikalnych haseł. Ta zasada jest zwykle używana w połączeniu z zasadą `setPasswordExpirationTimeout()`, która wymusza na użytkownikach zmianę haseł po upływie określonego czasu. Wprowadzono w Androidzie 3.0.
Maksymalna liczba nieudanych prób podania hasła	Określa, ile razy użytkownik może wpisać nieprawidłowe hasło, zanim urządzenie wymaże dane. Interfejs Device Administration API umożliwia też administratorom zdalne przywracanie urządzenia do ustawień fabrycznych. Dzięki temu dane są bezpieczne w przypadku zgubienia lub kradzieży urządzenia.
Maksymalny czas braku aktywności, po którym włącza się blokada	Określa czas, jaki upłynął od ostatniego dotknięcia ekranu lub naciśnięcia przycisku przez użytkownika, po którym urządzenie blokuje ekran. W takiej sytuacji użytkownicy muszą ponownie wpisać kod PIN lub hasła, aby móc korzystać z urządzeń i uzyskiwać dostęp do danych. Wartość może wynosić od 1 do 60 minut.
Wymagaj szyfrowania pamięci	Określa, że obszar pamięci powinien być zaszyfrowany, jeśli urządzenie to obsługuje. Wprowadzono w Androidzie 3.0.
Wyłącz kamerę	Określa, że kamera powinna być wyłączona. Pamiętaj, że nie musi to być trwałe wyłączenie. Kamerę można włączać i wyłączać dynamicznie w zależności od kontekstu, czasu itp. Wprowadzono w Androidzie 4.0.

Inne funkcje

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

Poproś użytkownika o ustawienie nowego hasła.
Natychmiastowe blokowanie urządzenia.
wymazać dane urządzenia (czyli przywrócić urządzenie do ustawień fabrycznych);

Przykładowa aplikacja

Przykłady użyte na tej stronie są oparte na przykładzie interfejsu Device Administration API, który jest częścią przykładów SDK (dostępnych w Menedżerze pakietu Android SDK) i znajduje się w systemie w lokalizacji <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java.

Przykładowa aplikacja zawiera demonstrację funkcji administratora urządzenia. Wyświetla ona interfejs użytkownika, który umożliwia włączenie aplikacji administratora urządzenia. Po włączeniu aplikacji użytkownicy 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, np. minimalną długość, minimalną liczbę znaków numerycznych, które musi zawierać, itp.
Ustaw hasło. Jeśli hasło nie jest zgodne z określonymi zasadami, system zwraca błąd.
Określ, ile nieudanych prób wpisania hasła może wystąpić, zanim urządzenie zostanie wyczyszczone (czyli przywrócone do ustawień fabrycznych).
Określ, po jakim czasie od teraz hasło wygaśnie.
Ustaw długość historii haseł (długość odnosi się do liczby starych haseł przechowywanych w historii). Uniemożliwia to użytkownikom ponowne użycie jednego z ostatnich n haseł.
Określ, że obszar pamięci ma być zaszyfrowany, jeśli urządzenie to obsługuje.
Ustaw maksymalny czas bezczynności, po którym urządzenie zostanie zablokowane.
Natychmiastowe zablokowanie urządzenia.
wymazać dane z urządzenia (czyli przywrócić ustawienia fabryczne);
wyłączyć kamerę;

Rysunek 1. Zrzut ekranu przykładowej aplikacji

Tworzenie aplikacji do administrowania urządzeniem

Administratorzy systemów mogą używać interfejsu Device Administration API do pisania aplikacji, która wymusza stosowanie zasad zabezpieczeń urządzenia zdalnie lub lokalnie. W tej sekcji znajdziesz podsumowanie czynności związanych z tworzeniem aplikacji do zarządzania urządzeniami.

Tworzenie pliku manifestu

Aby korzystać z interfejsu Device Administration API, plik manifestu aplikacji musi zawierać te elementy:

Podklasa 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 zabezpieczeń używanych w metadanych.

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

<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ągów znaków, które w aplikacji przykładowej znajdują się w pliku ApiDemos/res/values/strings.xml. Więcej informacji o zasobach znajdziesz w artykule Zasoby aplikacji.
- android:label="@string/activity_sample_device_admin" to czytelna dla użytkownika etykieta aktywności.
- android:label="@string/sample_device_admin" to etykieta uprawnienia czytelna dla użytkownika.
- android:description="@string/sample_device_admin_description" to opis uprawnień zrozumiały dla użytkownika. Opis jest zwykle dłuższy i zawiera więcej informacji niż etykieta.
android:permission="android.permission.BIND_DEVICE_ADMIN" to uprawnienie, które musi mieć podklasa DeviceAdminReceiver, aby zapewnić, że tylko system może wchodzić w interakcje z odbiornikiem (żadna aplikacja nie może otrzymać tego uprawnienia). Zapobiega to nadużywaniu aplikacji do administrowania urządzeniem przez inne aplikacje.
android.app.action.DEVICE_ADMIN_ENABLED to podstawowa czynność, którą musi obsługiwać podklasa DeviceAdminReceiver, aby móc zarządzać urządzeniem. Jest on ustawiany na odbiorcę, gdy użytkownik włączy aplikację administratora urządzenia. Twój kod zwykle obsługuje to w onEnabled(). Aby odbiorca był obsługiwany, musi też wymagać uprawnienia BIND_DEVICE_ADMIN, aby inne aplikacje nie mogły go nadużywać.
Gdy użytkownik włączy aplikację administratora urządzenia, odbiorca uzyska uprawnienia do wykonywania działań w odpowiedzi na transmisję 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ń zasad, aplikacja może poprosić go o wybranie innego hasła, które spełnia te wymagania.
Po opublikowaniu aplikacji unikaj zmiany nazwy odbiorcy. Jeśli nazwa w pliku manifestu ulegnie zmianie, po zaktualizowaniu aplikacji przez użytkowników administrator urządzenia zostanie wyłączony. Więcej informacji znajdziesz w artykule <receiver>.
android:resource="@xml/device_admin_sample" deklaruje zasady zabezpieczeń używane w metadanych. Metadane zawierają dodatkowe informacje dotyczące administratora urządzenia, które są analizowane przez klasę DeviceAdminInfo. Oto zawartość elementu 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 zarządzania urządzeniami nie musisz uwzględniać wszystkich zasad, tylko te, które są istotne dla Twojej aplikacji.

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

Implementowanie kodu

Interfejs Device Administration API zawiera te klasy:

DeviceAdminReceiver: Klasa bazowa do implementowania komponentu administracji urządzeniem. Ta klasa ułatwia interpretowanie surowych działań związanych z intencjami wysyłanych przez system. Aplikacja do zarządzania urządzeniem musi zawierać podklasę DeviceAdminReceiver.
DevicePolicyManager: Klasa do zarządzania zasadami wymuszanymi na urządzeniu. Większość klientów tej klasy musi mieć opublikowaną DeviceAdminReceiver, która jest obecnie włączona przez użytkownika. DevicePolicyManagerzarządza zasadami w przypadku 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ądzeniami. W pozostałej części tej sekcji opisujemy, jak za pomocą interfejsów API DeviceAdminReceiver i DevicePolicyManager napisać aplikację do zarządzania urządzeniami.

Tworzenie podklasy DeviceAdminReceiver

Aby utworzyć aplikację administratora urządzenia, musisz utworzyć podklasęDeviceAdminReceiver. Klasa DeviceAdminReceiver składa się z serii wywołań zwrotnych, które są wywoływane, gdy wystąpią określone zdarzenia.

W swojej 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ługiwać aplikacja administratora urządzenia, jest włączenie jej przez użytkownika. Aby można było egzekwować zasady, użytkownik musi wyraźnie włączyć aplikację. Jeśli użytkownik nie włączy aplikacji, będzie ona nadal obecna na urządzeniu, ale jej zasady nie będą egzekwowane, a użytkownik nie będzie mógł korzystać z jej funkcji.

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

Gdy użytkownik kliknie pole wyboru Włącz administratora, wyświetli się prośba o aktywowanie aplikacji administratora urządzenia, jak pokazano na rysunku 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. Spowoduje to wywołanie zwrotne onPreferenceChange(). To wywołanie zwrotne jest wywoływane, gdy użytkownik zmieni wartość tego elementu Preference i ma ona zostać ustawiona lub zapisana. Jeśli użytkownik włącza aplikację, wyświetlacz zmienia się, aby poprosić go o aktywację aplikacji do administrowania urządzeniem, jak pokazano na rysunku 2. W przeciwnym razie aplikacja do administrowania urządzeniem zostanie wyłączona.

Kotlin

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

Java

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

Wiersz intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) informuje, że mDeviceAdminSample (czyli komponent DeviceAdminReceiver) jest zasadą docelową. Ten wiersz wywołuje interfejs użytkownika pokazany na rysunku 2, który prowadzi użytkowników przez proces dodawania administratora urządzenia do systemu (lub umożliwia odrzucenie tego procesu).

Gdy aplikacja musi wykonać operację, która zależy od włączenia aplikacji administratora urządzenia, sprawdza, czy jest ona aktywna. W tym celu stosuje DevicePolicyManagermetodęisAdminActive(). Zwróć uwagę, że metoda DevicePolicyManager isAdminActive() przyjmuje jako argument DeviceAdminReceiver komponent:

Kotlin

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

Java

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

Zarządzanie zasadami

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

Uchwyt do DevicePolicyManager uzyskasz w ten sposób:

Kotlin

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

Java

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

W tej sekcji opisujemy, jak używać DevicePolicyManager do wykonywania zadań administracyjnych:

Ustawianie zasad dotyczących haseł
Ustawianie blokady urządzenia
Usuwanie danych

Ustawianie zasad dotyczących haseł

DevicePolicyManager obejmuje interfejsy API do ustawiania i egzekwowania zasad dotyczących hasła na urządzeniu. W interfejsie Device Administration API hasło dotyczy tylko blokady ekranu. W tej sekcji opisujemy typowe zadania związane z hasłami.

Ustawianie hasła urządzenia

Ten kod wyświetla interfejs, który prosi użytkownika 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);

Ustaw jakość hasła

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

PASSWORD_QUALITY_ALPHABETIC: Użytkownik musi wpisać hasło zawierające co najmniej litery (lub inne symbole).
PASSWORD_QUALITY_ALPHANUMERIC: Użytkownik musi wpisać hasło zawierające co najmniej zarówno cyfry, jak i litery (lub inne symbole).
PASSWORD_QUALITY_NUMERIC: Użytkownik musi wpisać hasło zawierające co najmniej cyfry.
PASSWORD_QUALITY_COMPLEX: Użytkownik musi wpisać hasło zawierające co najmniej literę, cyfrę i znak specjalny.
PASSWORD_QUALITY_SOMETHING: Zasady wymagają hasła, ale nie określają, jakie ma być.
PASSWORD_QUALITY_UNSPECIFIED: Zasady nie określają wymagań dotyczących haseł.

Na przykład tak możesz ustawić zasadę dotyczącą hasła, aby 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ą precyzyjne dostosowanie zawartości hasła. Możesz na przykład ustawić zasadę, która wymaga, aby hasła zawierały 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 podaną 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);

Ustawianie maksymalnej liczby nieudanych prób podania hasła

Możesz ustawić maksymalną liczbę dozwolonych nieudanych prób podania hasła, po której przekroczeniu urządzenie zostanie wyczyszczone (czyli przywrócone do 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 limitu czasu wygaśnięcia hasła

Od Androida 3.0 możesz używać metody setPasswordExpirationTimeout() do ustawiania daty wygaśnięcia hasła. Jest ona wyrażona jako różnica w milisekundach od momentu, w którym administrator urządzenia ustawił limit 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

Od Androida 3.0 możesz używać 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 będą mogli używać tego samego hasła wielokrotnie. Ta zasada jest zwykle używana w połączeniu z zasadą setPasswordExpirationTimeout(), która wymusza na użytkownikach zmianę hasła po upływie określonego czasu.

Na przykład ten fragment kodu uniemożliwia użytkownikom ponowne użycie ostatnich 5 haseł:

Kotlin

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

Java

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

Ustawianie blokady urządzenia

Możesz ustawić maksymalny okres bezczynności użytkownika, po którym urządzenie zostanie zablokowane. Na przykład:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val timeMs: Long = 1000L * timeout.text.toString().toLong()
...
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
long timeMs = 1000L*Long.parseLong(timeout.getText().toString());
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);

Możesz też programowo nakazać urządzeniu natychmiastowe zablokowanie:

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ć DevicePolicyManagertej metodywipeData(). Jest to przydatne, jeśli urządzenie zostanie zgubione lub skradzione. Decyzja o wyczyszczeniu urządzenia jest często podejmowana po spełnieniu określonych warunków. Możesz na przykład użyć elementu setMaximumFailedPasswordsForWipe(), aby określić, że urządzenie ma zostać wyczyszczone po określonej liczbie nieudanych prób wpisania hasła.

Dane możesz wymazać w ten sposób:

Kotlin

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

Java

DevicePolicyManager dpm;
dpm.wipeData(0);

Metoda wipeData() przyjmuje jako parametr maskę bitową dodatkowych opcji. Obecnie wartość musi wynosić 0.

Wyłącz kamerę

Od Androida 4.0 możesz wyłączyć aparat. Pamiętaj, że nie musi to być trwałe wyłączenie. Kamerę można włączać i wyłączać dynamicznie w zależności od kontekstu, czasu itp.

Możesz wyłączyć kamerę za pomocą metody setCameraDisabled(). Na przykład ten fragment kodu włącza lub wyłącza kamerę w zależności od 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

Od Androida 3.0 możesz używać metody setStorageEncryption(), aby ustawić zasadę wymagającą szyfrowania obszaru pamięci, jeśli 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ładzie interfejsu Device Administration API.

Dodatkowe przykłady kodu

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