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 przygotować się do tej zmiany. Więcej informacji i opcje migracji znajdziesz w artykule Wycofanie administratora urządzenia.

Android zapewnia obsługę aplikacji firmowych dzięki interfejsowi Android Device Administration API. Interfejs Device Administration API udostępnia funkcje administrowania urządzeniami na poziomie systemu. Te interfejsy API pozwalają tworzyć aplikacje zwiększające bezpieczeństwo, które są przydatne w środowiskach firmowych, w których informatycy wymagają zaawansowanej kontroli nad urządzeniami pracowników. Na przykład wbudowana aplikacja e-mail na Androida używa tych interfejsów API do poprawy obsługi Exchange. Za pomocą aplikacji Poczta administratorzy Exchange mogą wymuszać stosowanie zasad dotyczących haseł, w tym haseł alfanumerycznych 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ą 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. Omawiamy w nim różne funkcje dostępne przez interfejs Device Administration API, które pozwalają wzmocnić zabezpieczenia urządzeń z Androidem dla pracowników.

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ązany z właścicielem urządzenia bez interfejsu graficznego, w którym właściciel profilu jest dodawany do wszystkich powiązanych użytkowników innych niż użytkownik systemowy, na którym skonfigurowano właściciela urządzenia.

Na urządzeniach skonfigurowanych z użytkownikiem systemu bez interfejsu graficznego (gdy użytkownik systemu działa w tle) do użytkownika na pierwszym planie stosowane są tylko zasady dotyczące urządzeń globalnych (zasady obowiązujące wszystkich użytkowników). Więcej informacji znajdziesz w sekcji addUserRestriction.

Producenci urządzeń z Androidem mogą skorzystać ze wskazówek opublikowanych 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ądzeń, które użytkownicy instalują na swoich urządzeniach. Aplikacja do administrowania urządzeniem egzekwuje wymagane zasady. Jak to działa:

Administrator systemu tworzy aplikację do administrowania urządzeniem, która wymusza zasady zabezpieczeń urządzeń zdalnych/lokalnych. Można je zakodować na stałe w aplikacji lub dynamicznie pobierać zasady z serwera zewnętrznego.
Aplikacja jest zainstalowana na urządzeniach użytkowników. Android nie ma obecnie rozwiązania do automatycznej obsługi administracyjnej. Administrator może rozpowszechniać aplikację wśród użytkowników na kilka sposobów:
- 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. Sposób i czas tego działania zależą od sposobu implementacji aplikacji.
Gdy użytkownicy włączą aplikację do administrowania urządzeniem, będą one podlegać jej zasadom. Przestrzeganie tych zasad skutkuje zwykle korzyściami takimi jak dostęp do systemów i danych wrażliwych.

Jeśli użytkownicy nie włączą aplikacji do administrowania urządzeniem, pozostanie ona na urządzeniu, ale będzie nieaktywna. Użytkownicy nie będą podlegać tym zasadom i nie będą miały żadnych korzyści wynikających z aplikacji – na przykład mogą nie być w stanie synchronizować danych.

Jeśli użytkownik nie będzie przestrzegać zasad (np. ustawi hasło naruszające te wytyczne), to aplikacja decyduje, jak to zrobić. Zazwyczaj uniemożliwia to jednak użytkownikowi synchronizację danych.

Jeśli urządzenie spróbuje połączyć się z serwerem, który wymaga zasad nieobsługiwanych przez interfejs Device Administration API, połączenie nie będzie dozwolone. Interfejs Device Administration API nie obsługuje obecnie częściowej obsługi administracyjnej. Inaczej mówiąc, jeśli urządzenie (na przykład starsze urządzenie) nie obsługuje wszystkich podanych zasad, nie można zezwolić na połączenie.

Jeśli na urządzeniu znajduje się wiele włączonych aplikacji administratora, wymuszana jest najbardziej rygorystyczna zasada. Nie można kierować reklam na konkretną aplikację administratora.

Aby odinstalować dotychczasową aplikację do administrowania urządzeniem, użytkownicy muszą najpierw wyrejestrować ją jako administrator.

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.

Polityka prywatności	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 z kodem alfanumerycznym	Wymaga, aby hasła zawierały kombinację 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 hasła wszystkich lub konkretnego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba małych liter wymaganych w haśle	Minimalna liczba małych liter wymaganych w hasłach w przypadku wszystkich lub konkretnego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba znaków innych niż litery wymaganych w haśle	Minimalna liczba znaków niebędących literami wymaganych w haśle wymaganym przez wszystkich lub tylko poszczególnych administratorów. 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ł. Ta zasada jest zwykle używana w połączeniu z zasadą `setPasswordExpirationTimeout()`, która wymusza na użytkownikach zmianę haseł po określonym czasie. Wprowadzono w Androidzie 3.0.
Maksymalna liczba nieudanych prób wpisania hasła	Określa, ile razy użytkownik może wpisać nieprawidłowe hasło, zanim urządzenie wyczyści dane. Interfejs Device Administration API pozwala też administratorom zdalnie resetować urządzenia do ustawień fabrycznych. Zabezpiecza to dane w przypadku zgubienia lub kradzieży.
Maksymalny czas braku aktywności – blokada	Określa czas, jaki minął od ostatniego dotknięcia ekranu lub kliknięcia przycisku przez użytkownika, zanim urządzenie zablokuje ekran. 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.
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 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. Wprowadzone 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.
Wyczyszczenie danych na urządzeniu (czyli przywrócenie na nim ustawień fabrycznych).

Przykładowa aplikacja

Przykłady użyte na tej stronie bazują na przykładowym interfejsie Device Administration API, który znajduje się w przykładowych pakietach SDK (dostępnych w usłudze Android SDK Manager) 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 wersję demonstracyjną funkcji administratora urządzenia. Udostępnia użytkownikom interfejs, za pomocą którego mogą włączyć aplikację administratora urządzenia. Po jej włączeniu użytkownicy mogą używać przycisków w interfejsie, aby wykonywać te czynności:

Ustaw jakość haseł.
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 będzie zgodne z określonymi zasadami, system zwróci błąd.
Określ liczbę dozwolonych nieudanych prób podania hasła, zanim dane na urządzeniu zostaną wyczyszczone (czyli przywrócone do ustawień fabrycznych).
Określ, po jakim czasie hasło wygaśnie.
Ustaw długość historii haseł (length odnosi się do liczby starych haseł przechowywanych w historii). Dzięki temu użytkownicy nie będą mogli ponownie użyć jednego z ostatnich n haseł.
Określ, że obszar przechowywania danych powinien być zaszyfrowany, jeśli urządzenie obsługuje tę funkcję.
Ustaw maksymalny czas braku aktywności, po jakim urządzenie zostanie zablokowane.
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 wymuszających zdalne/lokalne wymuszanie zasad zabezpieczeń urządzeń. W tej sekcji podsumowujemy kroki potrzebne do utworzenia aplikacji do administrowania urządzeniem.

Tworzę plik manifestu

Aby można było używać interfejsu Device Administration API, plik manifestu aplikacji musi zawierać:

Podklasa klasy DeviceAdminReceiver, która obejmuje te elementy:
- Uprawnienie BIND_DEVICE_ADMIN.
- Możliwość reagowania na intencję ACTION_DEVICE_ADMIN_ENABLED wyrażoną w pliku manifestu jako filtr intencji.
Deklaracja zasad bezpieczeństwa stosowanych 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, które znajdują się w przykładowej aplikacji w 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" odnosi się do czytelnej dla użytkownika etykiety aktywności.
- android:label="@string/sample_device_admin" odnosi się do czytelnej dla użytkownika etykiety uprawnienia.
- android:description="@string/sample_device_admin_description" odnosi się do czytelnego dla użytkownika opisu uprawnienia. Opis jest zwykle dłuższy i zawiera więcej informacji niż etykieta.
android:permission="android.permission.BIND_DEVICE_ADMIN" to uprawnienie, które 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ługiwać, aby mogła zarządzać urządzeniem. To ustawienie jest ustawiane na odbiorcę, gdy użytkownik włącza aplikację administratora urządzenia. Zwykle odbywa się to za pomocą kodu w regionie 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 administrowania urządzeniem, odbiorca może wykonywać działania w odpowiedzi na transmisję określonych zdarzeń systemowych. Gdy zajdzie odpowiednie zdarzenie, aplikacja może nałożyć odpowiednie 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, które spełnia te wymagania.
Unikaj zmiany nazwy odbiorcy po opublikowaniu aplikacji. Jeśli nazwa w manifeście się zmieni, administrator urządzenia zostanie wyłączony, gdy użytkownicy zaktualizują aplikację. Więcej informacji znajdziesz w sekcji <receiver>.
android:resource="@xml/device_admin_sample" deklaruje zasady bezpieczeństwa używane w metadanych. Metadane zawierają dodatkowe informacje dotyczące 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>

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.

Implementacja kodu

Interfejs Device Administration API zawiera następujące klasy:

DeviceAdminReceiver: Klasa podstawowa do implementacji komponentu administrowania urządzeniem. Ta klasa zapewnia wygodę podczas interpretowania nieprzetworzonych działań intencji, które są wysyłane przez system. Aplikacja do administrowania urządzeniem musi zawierać podklasę DeviceAdminReceiver.
DevicePolicyManager: Klasy do zarządzania zasadami wymuszanymi na urządzeniu. Większość klientów tej klasy musi opublikować zasób DeviceAdminReceiver, który użytkownik obecnie włączył. 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 administrowania urządzeniem. W pozostałej części tej sekcji opisujemy, jak używać interfejsów API DeviceAdminReceiver i DevicePolicyManager do pisania aplikacji do administrowania urządzeniem.

Podklasyfikowanie odbiorcy DeviceAdmin Receiver

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

Przykładowa aplikacja w podklasie DeviceAdminReceiver wyświetla po prostu powiadomienie Toast w odpowiedzi na określone zdarzenia. Na przykład:

Kotlin

class DeviceAdminSample : DeviceAdminReceiver() {

    private fun showToast(context: Context, msg: String) {
        context.getString(R.string.admin_receiver_status, msg).let { status ->
            Toast.makeText(context, status, Toast.LENGTH_SHORT).show()
        }
    }

    override fun onEnabled(context: Context, intent: Intent) =
            showToast(context, context.getString(R.string.admin_receiver_status_enabled))

    override fun onDisableRequested(context: Context, intent: Intent): CharSequence =
            context.getString(R.string.admin_receiver_status_disable_warning)

    override fun onDisabled(context: Context, intent: Intent) =
            showToast(context, context.getString(R.string.admin_receiver_status_disabled))

    override fun onPasswordChanged(context: Context, intent: Intent, userHandle: UserHandle) =
            showToast(context, context.getString(R.string.admin_receiver_status_pw_changed))
...
}

Java

public class DeviceAdminSample extends DeviceAdminReceiver {

    void showToast(Context context, String msg) {
        String status = context.getString(R.string.admin_receiver_status, msg);
        Toast.makeText(context, status, Toast.LENGTH_SHORT).show();
    }

    @Override
    public void onEnabled(Context context, Intent intent) {
        showToast(context, context.getString(R.string.admin_receiver_status_enabled));
    }

    @Override
    public CharSequence onDisableRequested(Context context, Intent intent) {
        return context.getString(R.string.admin_receiver_status_disable_warning);
    }

    @Override
    public void onDisabled(Context context, Intent intent) {
        showToast(context, context.getString(R.string.admin_receiver_status_disabled));
    }

    @Override
    public void onPasswordChanged(Context context, Intent intent, UserHandle userHandle) {
        showToast(context, context.getString(R.string.admin_receiver_status_pw_changed));
    }
...
}

Włączam aplikację

Jednym z najważniejszych zdarzeń, które musi obsługiwać aplikacja do zarządzania urządzeniem, jest włączenie aplikacji przez użytkownika. Aby zasady były wymuszane, użytkownik musi bezpośrednio włączyć aplikację. Jeśli użytkownik nie włączy aplikacji, nadal będzie ona widoczna na urządzeniu, ale związane z nią 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 aktywuje intencję ACTION_ADD_DEVICE_ADMIN. W przykładowej aplikacji dzieje się tak, gdy użytkownik kliknie pole wyboru Włącz ustawienia administracyjne.

Gdy użytkownik kliknie pole wyboru Włącz funkcję administratora, ekran zmieni się i pojawi się prośba o aktywowanie 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 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łączy aplikację, ekran zmieni się i pojawi się prośba o aktywowanie aplikacji do administrowania urządzeniem, jak widać na rysunku 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;
}

Wiersz intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) wskazuje, że zasadą docelową jest mDeviceAdminSample (który jest komponentem DeviceAdminReceiver). Ten wiersz wywołuje interfejs widoczny na ilustracji 2, który prowadzi użytkowników przez proces dodawania administratora urządzenia do systemu (lub umożliwia jego odrzucenie).

Gdy aplikacja musi wykonać operację, która wymaga włączenia aplikacji do administrowania urządzeniem, potwierdza, że jest ona aktywna. Wykorzystuje do tego metodę 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 wymuszanymi na urządzeniu. DevicePolicyManager zarządza zasadami co najmniej 1 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);

W tej sekcji dowiesz się, jak używać usługi DevicePolicyManager do wykonywania zadań administracyjnych:

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

Ustawianie zasad dotyczących haseł

DevicePolicyManager obejmuje interfejsy API do ustawiania i egzekwowania zasad dotyczących haseł do urządzeń. 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ć hasło zawierające co najmniej znaki alfabetu (lub inne symbole).
PASSWORD_QUALITY_ALPHANUMERIC: Użytkownik musi wpisać hasło zawierające co najmniej obie cyfry i znaki alfabetyczne (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 specjalny symbol.
PASSWORD_QUALITY_SOMETHING: Zasada wymaga podania jakiegoś rodzaju hasła, ale nie ma znaczenia.
PASSWORD_QUALITY_UNSPECIFIED: Zasada nie ma 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 umożliwiają dostosowanie zawartości hasła. Możesz na przykład ustawić zasadę, zgodnie z którą hasła muszą zawierać co najmniej n wielkich liter. Oto metody dostrajania zawartości hasła:

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 ustawić hasło, które ma przynajmniej określoną minimalną długość. Na przykład:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwLength: Int = ...
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwLength;
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);

Ustaw maksymalną liczbę nieudanych prób wpisania hasła

Możesz ustawić maksymalną liczbę dozwolonych nieudanych prób wpisania hasła, zanim pamięć urządzenia zostanie wyczyszczona (czyli przywracane są 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);

Ustaw czas wygaśnięcia hasła

Począwszy od Androida w wersji 3.0 możesz używać metody setPasswordExpirationTimeout() do określania czasu wygaśnięcia hasła, wyrażonego 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

Począwszy od Androida 3.0 możesz używać metody setPasswordHistoryLength() do ograniczenia możliwości ponownego używania starych haseł przez użytkowników. Ta metoda korzysta z parametru length, który określa, ile starych haseł jest przechowywanych. Gdy ta zasada jest aktywna, użytkownicy nie mogą podać nowego hasła pasującego do ostatnich n haseł. Dzięki temu użytkownicy nie mogą 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ę 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);

Ustaw blokadę urządzenia

Możesz ustawić maksymalny okres braku aktywności użytkownika przed zablokowaniem 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

Aby przywrócić ustawienia fabryczne urządzenia, możesz użyć metody DevicePolicyManager wipeData(). Przydaje się to w razie zgubienia lub kradzieży urządzenia. Decyzja o wyczyszczeniu pamięci urządzenia jest często efektem spełnienia określonych warunków. Za pomocą setMaximumFailedPasswordsForWipe() możesz na przykład określić, że urządzenie powinno zostać wyczyszczone po określonej liczbie nieudanych prób podania 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ę

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 metody setCameraDisabled(). Na przykład ten fragment kodu włącza lub wyłącza kamerę na podstawie ustawienia pola wyboru:

Kotlin

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

Java

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

Szyfrowanie pamięci masowej

Począwszy od Androida w wersji 3.0 możesz używać metody setStorageEncryption() do konfigurowania zasad wymagających szyfrowania miejsca na dane (o ile jest obsługiwana).

Na przykład:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setStorageEncryption(deviceAdminSample, true)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setStorageEncryption(deviceAdminSample, true);

Pełny przykład włączania szyfrowania miejsca na dane zawiera przykładowy interfejs Device Administration API.

Dodatkowe przykłady kodu

Przykłady zasad Android AppRestrictionEnforcer i DeviceOwner pozwalają dodatkowo zaprezentować wykorzystanie interfejsów API opisanych na tej stronie.