Omówienie administrowania urządzeniem

Wycofanie aplikacji do zarządzania urządzeniem. Od Androida 9 (poziom API 28) niektóre zasady administratora będą oznaczone jako wycofane, gdy zostaną wywołane przez administratora urządzenia. Zalecamy, aby już teraz zacząć się do niej przygotowywać. Więcej informacji oraz opcje migracji znajdziesz w artykule Wycofanie funkcji administracyjnych urządzeń.

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

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

Uwaga: informacje o tworzeniu kontrolera zasad służbowych na potrzeby wdrożeń Androida dla firm 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 jest użytkownikiem w tle i korzysta z dodatkowych użytkowników w planie pierwszym do interakcji z użytkownikiem końcowym. Android 14 wprowadza też tryb powiązania z urządzeniem bez interfejsu graficznego, który dodaje właściciela profilu do wszystkich powiązanych użytkowników, z wyjątkiem użytkownika systemu, na którym ustawiono właściciela urządzenia.

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

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

Omówienie interfejsu API administracji urządzeniami

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

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

Jak to działa?

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

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

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

Jeśli użytkownik nie przestrzega zasad (np. ustawia hasło, które narusza wytyczne), aplikacja sama decyduje, jak sobie z tym poradzić. Zazwyczaj jednak spowoduje to, że użytkownik nie będzie mógł zsynchronizować danych.

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

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

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

Zasady

W firmie często zdarza się, że urządzenia pracowników muszą być zgodne ze ścisłymi zasadami regulującymi ich użytkowanie. Interfejs Device Administration API obsługuje zasady wymienione w tabeli 1. Uwaga: interfejs Device Administration API obsługuje obecnie tylko hasła do blokady ekranu:

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

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

Inne funkcje

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

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

Przykładowa aplikacja

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

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

  • Ustaw jakość hasła.
  • Określ wymagania dotyczące hasła użytkownika, takie jak minimalna długość, minimalna liczba cyfr, które musi zawierać itp.
  • Ustaw hasło. Jeśli hasło nie jest zgodne ze specyfikacją, system zwraca błąd.
  • Określ, ile nieudanych prób podania hasła może wystąpić przed wyczyszczeniem urządzenia (czyli przywróceniem ustawień fabrycznych).
  • Określ, kiedy 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 ostatnich n haseł.
  • Określ, że obszar pamięci powinien być zaszyfrowany (jeśli urządzenie obsługuje tę funkcję).
  • Ustaw maksymalny czas bezczynności, po którym urządzenie się zablokuje.
  • Urządzenie powinno być natychmiast blokowane.
  • Wymaż dane z urządzenia (czyli przywróć ustawienia fabryczne).
  • Wyłącz kamerę.

Rysunek 1. Zrzut ekranu przykładowej aplikacji

Tworzenie aplikacji do administrowania urządzeniami

Administratorzy systemu mogą użyć interfejsu Device Administration API, aby napisać aplikację, która egzekwuje zasady zabezpieczeń urządzeń 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, w pliku manifestu aplikacji musisz uwzględnić te elementy:

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

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

Uwaga:

  • Te atrybuty odnoszą się do zasobów ciągu znaków, które w przypadku przykładowej aplikacji znajdują się w katalogu ApiDemos/res/values/strings.xml. Więcej informacji o zasobach znajdziesz w artykule Zasoby 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" to opis uprawnień w formie zrozumiałej dla użytkownika. 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 zapewnić, że tylko system może wchodzić w interakcje z odbiorcą (żadna aplikacja nie może uzyskać tego uprawnienia). Zapobiega to nadużywaniu aplikacji do administrowania urządzeniem przez inne aplikacje.
  • android.app.action.DEVICE_ADMIN_ENABLED to główne działanie, które podklasa DeviceAdminReceiver musi obsłużyć, aby mieć możliwość zarządzania urządzeniem. Jest on ustawiany na odbiornik, gdy użytkownik włączy aplikację do zarządzania urządzeniem. Twój kod zwykle obsługuje to w onEnabled(). Aby to było możliwe, odbiorca musi też wymagać uprawnienia BIND_DEVICE_ADMIN, aby inne aplikacje nie mogły go nadużywać.
  • Gdy użytkownik włączy aplikację do zarządzania urządzeniem, da to odbiorcom uprawnienia do wykonywania działań w odpowiedzi na rozpowszechnianie określonych zdarzeń systemowych. Gdy wystąpi odpowiednie zdarzenie, aplikacja może zastosować zasady. Jeśli na przykład użytkownik spróbuje ustawić nowe hasło, które nie spełnia wymagań, aplikacja może poprosić go o wybranie innego hasła, które spełnia te wymagania.
  • Nie zmieniaj nazwy odbiorcy po opublikowaniu aplikacji. Jeśli nazwa w pliku manifestu ulegnie zmianie, funkcja administratora urządzenia zostanie wyłączona, gdy użytkownicy zaktualizują aplikację. Więcej informacji znajdziesz w artykule <receiver>.
  • android:resource="@xml/device_admin_sample"deklaruje zasady zabezpieczeń używane w metadanych. Metadane zawierają dodatkowe informacje dotyczące administratora urządzenia, które są analizowane przez klasę DeviceAdminInfo. Oto zawartość zakresu 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 tych, 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 obejmuje te klasy:

DeviceAdminReceiver
Klasa podstawowa do implementowania komponentu zarządzania urządzeniami. Ta klasa ułatwia interpretowanie nieprzetworzonych działań intencji wysyłanych przez system. Aplikacja Zarządzanie urządzeniem musi zawierać podklasę DeviceAdminReceiver.
DevicePolicyManager
Klasa do zarządzania zasadami stosowanymi na urządzeniu. Większość klientów tej klasy musi opublikować DeviceAdminReceiver, który jest obecnie włączony przez użytkownika. DevicePolicyManager zarządza zasadami w co najmniej 1 instancji DeviceAdminReceiver
DeviceAdminInfo
Ta klasa służy do określania metadanych komponentu administratora urządzenia.

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

Tworzenie podklasy klasy DeviceAdminReceiver

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

W podklasie DeviceAdminReceiver przykładowa aplikacja wyświetla powiadomienie Toast w odpowiedzi na określone zdarzenia. Może to obejmować np. te funkcje:

Kotlin

class DeviceAdminSample : DeviceAdminReceiver() {

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

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

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

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

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

Java

public class DeviceAdminSample extends DeviceAdminReceiver {

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

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

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

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

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

Włączanie aplikacji

Jednym z głównych zdarzeń, które musi obsłużyć aplikacja administratora urządzenia, jest włączenie aplikacji przez użytkownika. Aby zasady mogły obowiązywać, użytkownik musi wyraźnie włączyć aplikację. Jeśli użytkownik zdecyduje się nie włączać aplikacji, będzie ona nadal obecna na urządzeniu, ale zasady nie będą stosowane, a użytkownik nie będzie mógł korzystać z żadnych jej funkcji.

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

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

Rysunek 2. Przykładowa aplikacja: aktywowanie aplikacji

Poniżej znajduje się kod, który jest wykonywany, gdy użytkownik kliknie pole wyboru Włącz administratora. W efekcie powoduje to wywołanie funkcjionPreferenceChange(). Ten wywołujący jest wywoływany, gdy użytkownik zmienił wartość tego parametru Preference i ma zostać on ustawiony lub zapisany. Jeśli użytkownik włącza aplikację, wyświetlacz zmienia się, aby wyświetlić prośbę o aktywowanie aplikacji do administrowania urządzeniem (patrz rysunek 2). W przeciwnym razie aplikacja do administrowania urządzeniem jest wyłączona.

Kotlin

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

Java

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

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

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

Kotlin

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

Java

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

Zarządzanie zasadami

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

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

Kotlin

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

Java

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

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

Ustawianie zasad dotyczących haseł

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

Ustawianie hasła urządzenia

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

Kotlin

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

Java

Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
startActivity(intent);
Ustawianie jakości hasła

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

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

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

Kotlin

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

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
Ustawianie wymagań dotyczących treści hasła

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

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

Kotlin

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

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwMinUppercase = 2;
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase);
Ustawianie minimalnej długości hasła

Możesz określić, że hasło musi mieć co najmniej określoną minimalną długość. Może to obejmować np. te funkcje:

Kotlin

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

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwLength;
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);
Ustawienie maksymalnej liczby nieudanych prób podania hasła

Możesz ustawić maksymalną liczbę dozwolonych nieudanych prób podania hasła, której przekroczenie powoduje wymazanie pamięci urządzenia (czyli przywrócenie ustawień fabrycznych). Może to obejmować np. te funkcje:

Kotlin

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

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int maxFailedPw;
 ...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
Ustawianie czasu ważności hasła

Od Androida 3.0 możesz używać metody setPasswordExpirationTimeout()do ustawiania czasu ważności hasła wyrażonego w milisekundach od momentu ustawienia przez administratora urządzenia czasu wygaśnięcia. Może to obejmować np. te funkcje:

Kotlin

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwExpiration: Long = ...
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
long pwExpiration;
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);
Ograniczanie hasła na podstawie historii

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

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

Kotlin

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

Java

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

Konfigurowanie blokady urządzenia

Możesz ustawić maksymalny okres bezczynności użytkownika, po którym urządzenie się zablokuje. Może to obejmować np. te funkcje:

Kotlin

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

Java

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

Możesz też zaprogramować urządzenie, aby natychmiast się zablokowało:

Kotlin

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

Java

DevicePolicyManager dpm;
dpm.lockNow();

Wyczyść dane

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

Wymaż dane 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ę

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

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

Kotlin

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

Java

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

Szyfrowanie pamięci

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

Może to obejmować np. te funkcje:

Kotlin

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

Java

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

Pełny przykład włączania szyfrowania pamięci znajdziesz w przykładowym interfejsie Device Administration API.

Dodatkowe przykłady kodu

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