Omówienie administrowania urządzeniem

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

Android obsługuje aplikacje firmowe dzięki interfejsowi Android Device Administration API. Interfejs Device Administration API udostępnia funkcje administracyjne na poziomie systemu. Te interfejsy API umożliwiają tworzenie aplikacji uwzględniających bezpieczeństwo, 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 do ulepszenia obsługi Exchange. Za pomocą aplikacji do poczty e-mail administratorzy Exchange mogą egzekwować zasady dotyczące haseł, w tym haseł alfanumerycznych lub numerycznych kodów PIN, na różnych urządzeniach. 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 deweloperów, którzy chcą tworzyć rozwiązania dla firm na urządzenia z Androidem. Omówiono w nim 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 dotyczących pracy na potrzeby wdrożeń Androida for Work znajdziesz w artykule Tworzenie kontrolera zasad dotyczących urządzeń.

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

Android 14 (API na poziomie 34) wprowadza tryb użytkownika systemowego bez interfejsu graficznego (urządzenia, na których UserManager.isHeadlessSystemUserMode zwraca true). W tym trybie użytkownik systemowy jest użytkownikiem działającym w tle i polega na dodatkowych użytkownikach działających na pierwszym planie, którzy wchodzą w interakcje 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 innych niż użytkownik systemowy, na którym ustawiono właściciela urządzenia.

Na urządzeniach skonfigurowanych z bezgłowym użytkownikiem systemu (gdy użytkownik systemu działa w tle) tylko zasady dotyczące urządzeń o zasięgu globalnym (zasady, które mają zastosowanie do wszystkich użytkowników) są stosowane do użytkownika lub użytkowników na pierwszym planie. Więcej informacji znajdziesz na stronie addUserRestriction.

Producenci urządzeń z Androidem mogą zapoznać się ze wskazówkami 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:

  • Klienty poczty e-mail.
  • 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 administratora urządzenia, które użytkownicy instalują na swoich urządzeniach. Aplikacja administratora urządzenia wymusza odpowiednie zasady. Jak to działa:

  • Administrator systemu pisze aplikację administratora urządzenia, która wymusza stosowanie zasad bezpieczeństwa na urządzeniu zdalnym lub lokalnym. Zasady te mogą być zakodowane na stałe w aplikacji lub aplikacja może je pobierać dynamicznie z serwera innej firmy.
  • Aplikacja zostanie zainstalowana na urządzeniach użytkowników. Android nie ma obecnie rozwiązania do automatycznej obsługi administracyjnej. Oto kilka sposobów, w jakie administrator systemu może rozpowszechniać aplikację wśród użytkowników:
    • Google Play.
    • Włączanie instalacji z innego sklepu.
    • rozpowszechnianie aplikacji w inny sposób, np. przez e-maile lub strony internetowe;
  • System prosi użytkownika o włączenie aplikacji administratora urządzenia. To, jak i kiedy to nastąpi, zależy od sposobu wdrożenia aplikacji.
  • Gdy użytkownicy włączą aplikację administratora urządzenia, będą podlegać jej zasadom. Zgodność z tymi zasadami zwykle przynosi korzyści, takie jak dostęp do systemów i danych wrażliwych.

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 aplikacji i nie będą mogli korzystać z jej funkcji, np. synchronizować danych.

Jeśli użytkownik nie przestrzega zasad (np. ustawia hasło, które narusza wytyczne), aplikacja decyduje, jak postąpić w takiej sytuacji. Zwykle jednak uniemożliwia to użytkownikowi synchronizowanie 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 zostanie nawiązane. Interfejs Device Administration API nie zezwala obecnie na częściową obsługę administracyjną. Innymi słowy, jeśli urządzenie (np. starsze urządzenie) nie obsługuje wszystkich określonych zasad, nie ma możliwości zezwolenia mu na połączenie.

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

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

Zasady

W środowisku firmowym często zdarza się, że urządzenia pracowników muszą być zgodne z rygorystycznymi zasadami dotyczącymi korzystania z urządzenia. Interfejs Device Administration API obsługuje zasady wymienione w tabeli 1. Pamiętaj, że interfejs Device Administration API obsługuje obecnie tylko hasła 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 podanie kodu PIN lub hasła.
Minimalna długość hasła Ustaw wymaganą liczbę znaków w haśle. Możesz na przykład wymagać, aby kody PIN lub hasła miały co najmniej 6 znaków.
Wymagane hasło alfanumeryczne 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 1 literę, 1 cyfrę i 1 symbol specjalny. Wprowadzona w Androidzie 3.0.
Minimalna liczba liter wymaganych w haśle Minimalna liczba liter wymaganych w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba małych liter wymaganych w haśle Minimalna liczba małych liter wymaganych w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba znaków niebędących literami wymagana w haśle Minimalna liczba znaków niebędących literami wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba cyfr wymaganych w haśle Minimalna liczba cyfr wymaganych w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba symboli wymaganych w haśle Minimalna liczba symboli wymaganych w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba wielkich liter wymaganych w haśle Minimalna liczba wielkich liter wymaganych w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Limit czasu wygaśnięcia hasła Kiedy hasło wygaśnie, wyrażone jako delta w milisekundach od momentu, gdy administrator urządzenia ustawi limit czasu wygaśnięcia. Wprowadzona 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 aktualizowanie 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 wpisać nieprawidłowe hasło, zanim urządzenie wyczyści dane. Interfejs Device Administration API umożliwia też administratorom zdalne przywracanie ustawień fabrycznych urządzenia. Dzięki temu dane są bezpieczne w przypadku zgubienia lub kradzieży urządzenia.
Maksymalny czas bezczynności przed zablokowaniem Określa czas, jaki musi upłynąć od ostatniego dotknięcia ekranu lub naciśnięcia przycisku przez użytkownika, zanim urządzenie zablokuje ekran. W takim przypadku użytkownicy muszą ponownie wpisać kod PIN lub hasło, aby móc korzystać z urządzeń 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. Wprowadzona w Androidzie 3.0.
Wyłącz kamerę Określa, że aparat powinien być wyłączony. Pamiętaj, że nie musi to być trwałe wyłączenie. Kamerę można włączać i wyłączać dynamicznie na podstawie kontekstu, czasu itp. Wprowadzona 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.
  • Natychmiast zablokuj urządzenie.
  • wyczyścić dane na urządzeniu (czyli przywrócić je do ustawień fabrycznych);

Przykładowa aplikacja

Przykłady użyte na tej stronie są oparte na przykładowym interfejsie Device Administration API, który jest dołączony do przykładów pakietu SDK (dostępnych w Menedżerze pakietów SDK Androida) i znajduje się w 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. Użytkownikom wyświetla się interfejs, który umożliwia im włączenie aplikacji administratora urządzenia. Po włączeniu aplikacji mogą oni używać przycisków w interfejsie, aby:

  • Ustaw jakość hasła.
  • Określ wymagania dotyczące hasła użytkownika, takie jak minimalna długość, minimalna liczba znaków numerycznych 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).
  • Ustaw, za ile dni hasło wygaśnie.
  • Ustaw długość historii haseł (długość odnosi się do liczby starych haseł przechowywanych w historii). Zapobiega to ponownemu użyciu przez użytkowników jednego z n haseł, których używali wcześniej.
  • Określ, że obszar pamięci powinien być zaszyfrowany, jeśli urządzenie to obsługuje.
  • Ustaw maksymalny czas bezczynności, po którym urządzenie zostanie zablokowane.
  • Natychmiast zablokuj urządzenie.
  • wyczyścić dane na urządzeniu (czyli przywrócić ustawienia fabryczne);
  • Wyłącz kamerę.

Rysunek 1. Zrzut ekranu przykładowej aplikacji

Tworzenie aplikacji do administrowania urządzeniem

Administratorzy systemu mogą używać interfejsu Device Administration API do tworzenia aplikacji, które wymuszają stosowanie zasad zabezpieczeń na urządzeniach zdalnych i lokalnych. W tej sekcji znajdziesz podsumowanie czynności związanych z tworzeniem aplikacji do administrowania urządzeniami.

Tworzenie pliku manifestu

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

Oto fragment przykładowego pliku manifestu aplikacji do zarządzania 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 tekstowych, które w przypadku przykładowej aplikacji znajdują się w pliku ApiDemos/res/values/strings.xml. Więcej informacji o zasobach znajdziesz w artykule o zasobach 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 uprawnień. 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 tylko system mógł wchodzić w interakcje z odbiornikiem (żadna aplikacja nie może otrzymać tego uprawnienia). Zapobiega to nadużywaniu aplikacji administratora urządzenia przez inne aplikacje.
  • android.app.action.DEVICE_ADMIN_ENABLED to podstawowe działanie, które musi obsługiwać podklasa DeviceAdminReceiver, aby mogła zarządzać urządzeniem. Jest on ustawiany na odbiorcę, gdy użytkownik włącza aplikację administratora urządzenia. Kod zwykle obsługuje to w onEnabled(). Aby odbiornik 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 otrzyma uprawnienia do wykonywania działań w odpowiedzi na transmisję określonych zdarzeń systemowych. Gdy wystąpi odpowiednie zdarzenie, aplikacja może zastosować zasadę. Jeśli na przykład użytkownik spróbuje ustawić nowe hasło, które nie spełnia wymagań wynikających z zasad, aplikacja może poprosić go o wybranie innego hasła, które spełnia te wymagania.
  • Unikaj zmieniania nazwy odbiorcy po opublikowaniu aplikacji. Jeśli nazwa w pliku manifestu ulegnie zmianie, administrator urządzenia zostanie wyłączony, gdy użytkownicy zaktualizują aplikację. Więcej informacji znajdziesz w <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ść pliku 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 te, które są istotne dla Twojej aplikacji.

Więcej informacji o pliku manifestu znajdziesz w Przewodniku dla programistów aplikacji na Androida.

Implementowanie kodu

Interfejs Device Administration API obejmuje te klasy:

DeviceAdminReceiver
Klasa podstawowa do implementacji komponentu administracji urządzeniem. Ta klasa ułatwia interpretowanie nieprzetworzonych działań intencji wysyłanych przez system. Aplikacja do administrowania urządzeniem musi zawierać podklasę DeviceAdminReceiver.
DevicePolicyManager
Klasa do zarządzania zasadami egzekwowanymi na urządzeniu. Większość klientów tej klasy musi mieć opublikowany element DeviceAdminReceiver, który użytkownik ma obecnie włączony. DevicePolicyManager zarządza zasadami dotyczącymi 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 administratora urządzenia. W pozostałej części tej sekcji opisano, jak używać interfejsów API DeviceAdminReceiver i DevicePolicyManager do tworzenia aplikacji administratora urządzenia.

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ą aktywowane, gdy wystąpią określone zdarzenia.

W podklasie DeviceAdminReceiver przykładowa aplikacja po prostu wyświetla powiadomienie Toast w odpowiedzi na określone zdarzenia. 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 aplikacji przez użytkownika. Aby zasady były egzekwowane, użytkownik musi wyraźnie włączyć aplikację. Jeśli użytkownik nie zdecyduje się na włączenie aplikacji, pozostanie ona 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łuje intencję ACTION_ADD_DEVICE_ADMIN. W przykładowej aplikacji dzieje się tak, gdy użytkownik zaznaczy 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 zaznaczy pole wyboru Włącz uprawnienia administratora. Spowoduje to wywołanie funkcji wywołania zwrotnego onPreferenceChange(). To wywołanie zwrotne jest wywoływane, gdy wartość tego elementu Preference została zmieniona przez użytkownika i ma zostać ustawiona lub utrwalona. Jeśli użytkownik włącza aplikację, wyświetla się prośba o aktywowanie aplikacji administratora urządzenia, jak pokazano na rysunku 2. W przeciwnym razie aplikacja administratora urządzenia 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 mDeviceAdminSample (który jest komponentem DeviceAdminReceiver) jest zasadą docelową. Ten wiersz wywołuje interfejs użytkownika pokazany na rysunku 2, który przeprowadza użytkowników przez proces dodawania administratora urządzenia do systemu (lub umożliwia im odrzucenie tej opcji).

Gdy aplikacja musi wykonać operację, która wymaga włączenia aplikacji administratora urządzenia, sprawdza, czy aplikacja jest aktywna. W tym celu używa metody DevicePolicyManagerisAdminActive(). Zauważ, że metoda DevicePolicyManager isAdminActive() przyjmuje komponent DeviceAdminReceiver jako argument:

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 egzekwowanymi na urządzeniu. DevicePolicyManager zarządza zasadami dotyczącymi co najmniej 1 instancji DeviceAdminReceiver.

Uchwyt do DevicePolicyManager możesz uzyskać 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 opisano, jak używać DevicePolicyManager do wykonywania zadań administracyjnych:

Ustawianie zasad dotyczących haseł

DevicePolicyManager zawiera interfejsy API do konfigurowania 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 zadania związane z hasłami.

ustawić hasło do urządzenia,

Ten kod wyświetla interfejs użytkownika, 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);
Ustawianie jakości hasła

Jakość hasła może być jedną z tych 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 zarówno cyfry, jak i litery (lub inne symbole).
PASSWORD_QUALITY_NUMERIC
Użytkownik musi wpisać hasło zawierające co najmniej znaki numeryczne.
PASSWORD_QUALITY_COMPLEX
Użytkownik musi wpisać hasło zawierające co najmniej 1 literę, 1 cyfrę i 1 symbol specjalny.
PASSWORD_QUALITY_SOMETHING
Zasada wymaga jakiegoś hasła, ale nie określa, jakiego.
PASSWORD_QUALITY_UNSPECIFIED
Zasada nie zawiera wymagań dotyczących hasła.

Na przykład w ten sposób możesz ustawić zasadę dotyczącą haseł, 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 haseł

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 dostosowywania 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ść. 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ę nieudanych prób wpisania hasła, po których urządzenie zostanie wyczyszczone (czyli przywrócone do ustawień fabrycznych). Przykład:

Kotlin

val dPM:DevicePolicyManager
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val maxFailedPw: Int = ...
...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int maxFailedPw;
 ...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
Ustawianie czasu wygaśnięcia hasła

Począwszy od Androida 3.0, możesz używać metody setPasswordExpirationTimeout(), aby ustawić datę ważności hasła, wyrażoną jako różnica w milisekundach od momentu, gdy administrator urządzenia ustawia limit czasu ważności. 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

Od Androida 3.0 możesz używać metody setPasswordHistoryLength(), aby ograniczyć użytkownikom możliwość ponownego używania starych haseł. 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 jedno z ostatnich 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 aktualizowanie haseł po upływie określonego czasu.

Na przykład ten fragment kodu uniemożliwia użytkownikom ponowne użycie dowolnego 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);

Ustawianie blokady urządzenia

Możesz ustawić maksymalny czas bezczynności użytkownika, po którym urządzenie zostanie zablokowane. 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();

Czyszczenie danych

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

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

Kotlin

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

Java

DevicePolicyManager dpm;
dpm.wipeData(0);

Metoda wipeData() przyjmuje jako 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. Aparat można włączać i wyłączać dynamicznie na podstawie kontekstu, czasu itp.

Możesz określić, czy aparat jest wyłączony, za pomocą metody setCameraDisabled(). Na przykład ten fragment kodu ustawia włączenie lub wyłączenie kamery 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 przechowywanych danych

Począwszy 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.

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 korzystać z interfejsów API opisanych na tej stronie.