Omówienie administrowania urządzeniem

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

Android zapewnia obsługę aplikacji firmowych, oferując Android Device Administration API. Interfejs Device Administration API udostępnia urządzenia funkcje administracyjne 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ą wymuszanie stosowania zasad dotyczących haseł, w tym haseł alfanumerycznych i liczbowych Kody PIN na wszystkich 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 dla firm rozwiązań przeznaczonych dla urządzeń z systemem Android. Omawiamy w nim różne funkcje udostępniane przez interfejs Device Administration API w celu zapewnienia silniejszych zabezpieczeń na urządzeniach z Androidem dla pracowników.

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 to również tryb powiązany z właścicielem urządzenia bez interfejsu graficznego, który dodaje właściciela profilu do wszystkich powiązanych użytkowników innego niż użytkownik systemowy, dla którego skonfigurowano 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ą odnosić się do wskazówki opublikowano na stronie source.android.com.

Omówienie interfejsu API do administrowania urządzeniami

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

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

Jak to działa?

Interfejs Device Administration API służy do zapisywania aplikacji administratora urządzenia, które użytkownicy na swoich urządzeniach. Aplikacja do administrowania urządzeniem wymusza stosowanie . 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 rozwiązania do automatycznego udostępniania. Niektóre możliwe zastosowania Sysadmin należy dystrybuować aplikację w następujący sposób:
    • 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 wykonania tej czynności zależy od tego, jak aplikacja została zaimplementowana.
  • Gdy użytkownicy włączą aplikację do administrowania urządzeniem, podlegają jej zasadami. Ich przestrzeganie zwykle przynosi korzyści, np. dostęp do poufnych systemów i danych.

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 przestrzega zasad (na przykład ustaw które narusza wytyczne), to aplikacja decyduje, jak sobie z tym radzić. 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 zezwala obecnie na i udostępnianie danych. Inaczej mówiąc, jeśli urządzenie (np. starsze) nie obsługuje wszystkich podanych zasad, nie można zezwolić mu na połączenie.

Jeśli na urządzeniu jest kilka włączonych aplikacji administratora, najbardziej rygorystyczna zasada to jest egzekwowane. Nie można kierować reklam do konkretnego administratora .

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

Zasady

W środowisku korporacyjnym pracownicy często muszą używać urządzeń muszą być zgodne ze ścisłym zestawem zasad regulujących korzystanie 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 na ekranie blokada:

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. Na przykład: może wymagać kodu PIN lub hasła o długości co najmniej 6 znaków.
Wymagane hasło ze znakami alfanumerycznymi Hasła muszą zawierać kombinację liter i cyfr. Mogą one zawierać znaki symboliczne.
Wymagane złożone hasło Hasła muszą zawierać co najmniej 1 literę, 1 cyfrę i 1 znak specjalny. Wprowadzono w Androidzie 3.0.
Minimalna liczba liter w hasłach Minimalna liczba liter wymaganych w haśle wszystkich lub tylko jednego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba małych liter wymaganych w haśle Minimalna liczba małych liter liter wymaganych w haśle do wszystkich lub tylko jednego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba znaków innych niż litery wymaganych w haśle Minimalna liczba inne niż litery wymagane w haśle do wszystkich lub tylko jednego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba cyfr wymaganych w haśle Minimalna liczba cyfr wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzono w Androidzie 3.0.
Minimalna liczba symboli wymagana w haśle Minimalna liczba znaków wymagana w haśle dla wszystkich administratorów lub konkretnego administratora. Wprowadzona w Androidzie 3.0.
Minimalna liczba wielkich liter wymaganych w haśle Minimalna liczba wielkich liter wymagana w haśle wymaganym przez wszystkich lub tylko poszczególnych administratorów. Wprowadzona w Androidzie 3.0.
Upłynął limit czasu ważności 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 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. Wprowadzono w Androidzie 3.0.
Maksymalna liczba nieudanych prób podania hasła Określa, ile razy użytkownik może wpisać nieprawidłowe hasło przed ciągiem czyści dane urządzenia. Interfejs Device Administration API umożliwia też administratorom zdalnie zresetować urządzenie do ustawień fabrycznych. Zabezpiecza to dane w przypadku, gdy urządzenie zaginęło lub zostało skradzione.
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ło, aby móc korzystać z urządzeń uzyskać 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ę). Wprowadzona w Androidzie 3.0.
Wyłącz kamerę Określa, że kamera ma być wyłączona. Pamiętaj, że nie musisz wyłączyć funkcji na stałe. Kamerę można włączać i wyłączać dynamicznie w zależności od kontekstu, czasu itd. 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 użyte na tej stronie dotyczą interfejsu Device Administration API który jest dołączony do przykładowych pakietów SDK (dostępnych Android SDK Manager) i znajdują 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 z interfejsem, który pozwala włączyć aplikację administratora urządzenia. Jednorazowo którzy włączyli aplikację, mogą używać przycisków w interfejsie wykonaj następujące czynności:

  • Ustaw jakość haseł.
  • 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 liczbę nieudanych prób wpisania hasła, zanim pamięć urządzenia zostanie wyczyszczona (czyli przywrócone są ustawienia fabryczne).
  • Określ, po jakim czasie hasło wygaśnie.
  • Ustaw długość historii haseł (length odnosi się do liczby starych haseł przechowywanych w historii). Uniemożliwia to użytkownikom ponowne korzystanie z aplikacji jedno z ostatnich n haseł, których użytkownik używał wcześniej.
  • 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 ma zostać zablokowane.
  • Urządzenie powinno być zablokowane natychmiast.
  • Wymaż dane z urządzenia (czyli przywróć ustawienia fabryczne).
  • Wyłącz kamerę.

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

Tworzenie aplikacji do administrowania urządzeniami

Administratorzy systemu mogą użyć interfejsu Device Administration API, aby napisać aplikację, która egzekwuje zasady zabezpieczeń na urządzeniach zdalnie lub lokalnie. Ta sekcja podsumowuje kroki niezbędne do utworzenia administrowania urządzeniem .

Tworzę plik manifestu

Aby korzystać z interfejsu Device Administration API, w pliku manifestu aplikacji musisz uwzględnić te elementy:

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:

  • 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 tutaj: Materiały zgłoszeniowe.
    • android:label="@string/activity_sample_device_admin" odnosi się do 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 dłuższy informacyjne niż etykietę.
  • android:permission="android.permission.BIND_DEVICE_ADMIN" to uprawnienie, które musi podklasa DeviceAdminReceiver. , by mieć pewność, że tylko system będzie mógł wchodzić w interakcję z odbiornikiem (żadna aplikacja nie może otrzymać tego uprawnienia). Ten zapobiega wykorzystywaniu Twojej aplikacji do administrowania urządzeniem przez inne aplikacje.
  • android.app.action.DEVICE_ADMIN_ENABLED jest głównym elementem działanie, które podklasa DeviceAdminReceiver musi obsługiwać, aby została mogą zarządzać urządzeniem. Jest on ustawiany na odbiornik, gdy użytkownik włączy aplikację do zarządzania urządzeniem. Twój kod zwykle obsługuje to w onEnabled(). Aby 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 transmisję określonych zdarzeń systemowych. Gdy wystąpi odpowiednie zdarzenie, aplikacja może zastosować zasady. Dla: na przykład gdy użytkownik próbuje ustawić nowe hasło, które nie jest zgodne z zasadami. aplikacji, aplikacja może poprosić użytkownika o wybranie innego hasła który spełnia 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 specyficzne dla administratora urządzenia, 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>

Projektując aplikację do administrowania urządzeniem, nie musisz uwzględnić wszystkie zasady – tylko te, które dotyczą Twojej aplikacji.

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

Implementowanie kodu

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

DeviceAdminReceiver
Klasa podstawowa do implementowania komponentu zarządzania urządzeniami. Te zajęcia: Wygoda przy interpretowaniu surowych działań intencji, które są wysyłane przez systemu. Aplikacja Zarządzanie urządzeniami musi zawierać podklasę DeviceAdminReceiver.
DevicePolicyManager
Klasa do zarządzania zasadami wymuszanymi na urządzeniu. Większość klientów ta klasa musi mieć opublikowany element DeviceAdminReceiver, który użytkownik Program jest obecnie włączony. DevicePolicyManager zarządza zasadami w co najmniej 1 instancji DeviceAdminReceiver
DeviceAdminInfo
Ta klasa służy do określania metadanych dla komponentu administratora urządzenia.

Te klasy stanowią podstawę w pełni funkcjonalnej aplikacji do administrowania urządzeniem. Z dalszej części tej sekcji dowiesz się, jak korzystać z DeviceAdminReceiver i Interfejsy API 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 szeregu wywołań zwrotnych, które są wywoływane po wystąpieniu określonych zdarzeń.

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

KotlinJava
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))
...
}
 
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 ważnych zdarzeń, którym musi obsługiwać aplikacja do zarządzania urządzeniem, jest: włączenie aplikacji. Użytkownik musi jawnie włączyć aplikację dla zasady, które mają być egzekwowane. Jeśli użytkownik nie włączy aplikacji będzie on nadal dostępny na urządzeniu, ale jego zasady nie będą egzekwowane, a użytkownik nie czerpać korzyści z tej aplikacji.

Proces włączania aplikacji rozpoczyna się, gdy użytkownik wykona działanie, które wywołuje ACTION_ADD_DEVICE_ADMIN intencji. W przykładowej aplikacji, dzieje się tak, gdy użytkownik kliknie przycisk Włącz Administracja.

Gdy użytkownik kliknie pole wyboru Włącz ustawienia administratora, zmiany zachęcające użytkownika do aktywowania 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 wykonywany, gdy użytkownik kliknie pole wyboru Włącz administratora. Powoduje to aktywowanie onPreferenceChange() oddzwanianie. 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.

KotlinJava
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
}
 
@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ą. Ten wiersz wywołuje interfejs przedstawiony na rys. 2, który prowadzi użytkowników przez dodanie administratora urządzenia do systemu (lub zezwolenie mu na odrzucenie).

Gdy aplikacja musi wykonać operację, która zależy od aplikacji do administrowania urządzeniem, potwierdza to, że została aktywne. Wykorzystuje do tego metodę DevicePolicyManager isAdminActive() Zwróć uwagę, że metoda DevicePolicyManager isAdminActive() przyjmuje jako argument komponent DeviceAdminReceiver:

KotlinJava
private lateinit var dpm: DevicePolicyManager
...
private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)
 
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 jednego lub więcej instancji (DeviceAdminReceiver).

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

KotlinJava
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
 
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 zadania związane z hasłem.

Ustaw hasło dla urządzenia

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

KotlinJava
Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
    startActivity(intent)
}
 
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ć zawierające co najmniej znaki alfabetyczne (lub inne symbole).
PASSWORD_QUALITY_ALPHANUMERIC
Użytkownik musi podać hasło zawierające co najmniej zarówno znaki cyfry, jak i litery (lub inne symbole).
PASSWORD_QUALITY_NUMERIC
Użytkownik musi wpisać hasło zawierających 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
zasady wymagają ale nie jest obojętne, jakie jest jego hasło.
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:

KotlinJava
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)
 
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 dostrajania hasła zawartość:

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

KotlinJava
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwMinUppercase = 2
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase)
 
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 zawierać co najmniej określone minimum. długości. Na przykład:

KotlinJava
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwLength: Int = ...
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)
 
DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwLength;
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);
Ustawienie maksymalnej liczby nieudanych prób podania hasła

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

KotlinJava
val dPM:DevicePolicyManager
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val maxFailedPw: Int = ...
...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)
 
DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int maxFailedPw;
 ...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
Ustawianie czasu wygaśnięcia hasła

W Androidzie 3.0 możesz używać setPasswordExpirationTimeout() metody określania czasu wygaśnięcia hasła, wyrażonej w postaci delta w milisekundach od momentu, gdy administrator urządzenia ustawił ten czas. Na przykład:

KotlinJava
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwExpiration: Long = ...
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)
 
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 przed ciągłym używaniem 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 zabrania użytkownikom ponownego użycia któregokolwiek z 5 ostatnich haseł:

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

Ustaw blokadę urządzenia

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

KotlinJava
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val timeMs: Long = 1000L * timeout.text.toString().toLong()
...
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)
 
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:

KotlinJava
private lateinit var dpm: DevicePolicyManager
dpm.lockNow()
 
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. Decyzję o wyczyszczeniu pamięci urządzenia często podejmuje się w wyniku spełnienia określonych warunków. Możesz na przykład użyć parametru setMaximumFailedPasswordsForWipe(), aby określić, że dane urządzenie powinno zostać wyczyszczone po określonej liczbie nieudanych prób wpisania hasła.

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

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

Metoda wipeData() przyjmuje jako parametr maskę bitową 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.

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:

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

Szyfrowanie pamięci

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

Na przykład:

KotlinJava
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setStorageEncryption(deviceAdminSample, true)
 
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

Android AppRestrictionEnforcer i DeviceOwner Przykłady dokładniej pokazują wykorzystanie interfejsów API omówionych na tej stronie.