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 po wywołaniu przez administratora urządzenia będą oznaczane jako wycofane. Zalecamy już teraz przygotować się na tę zmianę. Aby dowiedzieć się więcej i poznać opcje migracji, przeczytaj artykuł Wycofanie konta administratora urządzenia.

Android zapewnia obsługę aplikacji dla firm, udostępniając interfejs Android Device Administration API. Interfejs Device Administration API udostępnia funkcje administrowania urządzeniami na poziomie systemu. Pozwalają one tworzyć świadome zabezpieczenia aplikacji, które są przydatne w środowiskach firmowych, w których informatycy potrzebują silnej kontroli nad urządzeniami pracowników. Na przykład wbudowana aplikacja pocztowa 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 haseł alfanumerycznych i numerycznych kodów PIN – na wszystkich urządzeniach. Administratorzy mogą też zdalnie wymazać zgubione lub skradzione telefony (przywrócić ustawienia fabryczne). Użytkownicy Exchange mogą synchronizować dane poczty e-mail i kalendarza.

Ten dokument jest przeznaczony dla programistów, którzy chcą opracowywać rozwiązania dla firm na urządzenia z Androidem. Omówiono w nim różne funkcje interfejsu Device Administration API, które zapewniają bezpieczniejsze korzystanie z urządzeń z Androidem dla pracowników.

Uwaga Informacje o tworzeniu kontrolera zasad Work Policy dla wdrożeń Android for Work znajdziesz w artykule o tworzeniu kontrolera zasad dotyczących urządzeń.

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

W Androidzie 14 (poziom interfejsu API 34) wprowadzamy tryb użytkownika systemowego bez interfejsu graficznego (dotyczy urządzeń, na których UserManager.isHeadlessSystemUserMode zwraca wartość true). W trybie użytkownika systemowego bez interfejsu graficznego użytkownik systemu jest użytkownikiem działającym w tle i w ramach interakcji z użytkownikiem końcowym korzysta z dodatkowych użytkowników na pierwszym planie. W Androidzie 14 wprowadziliśmy też 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 z wyjątkiem użytkownika systemu, dla którego skonfigurowano właściciela urządzenia.

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

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

Omówienie interfejsu API do administrowania urządzeniami

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

• Klienty poczty e-mail.
• Aplikacje zabezpieczające, które zdalnie czyszczenie pamięci.
• Usługi i aplikacje do zarządzania urządzeniami.

Jak to działa?

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

• Administrator systemu pisze aplikację do administrowania urządzeniem, która wymusza zasady zabezpieczeń zdalnych/lokalnych urządzeń. Zasady te mogą być zakodowane na stałe w aplikacji lub aplikacja może dynamicznie pobierać zasady z serwera zewnętrznego.
• Aplikacja jest instalowana na urządzeniach użytkowników. Android nie ma obecnie rozwiązania do automatycznej obsługi administracyjnej. Oto kilka sposobów rozpowszechniania aplikacji wśród użytkowników przez administratora sysadmin:
  • Google Play.
  • Umożliwianie instalacji z innego sklepu.
  • Rozpowszechnianie aplikacji za pomocą innych środków, takich jak e-mail lub strony internetowe.
• System prosi użytkownika o włączenie aplikacji administratora urządzenia. Sposób i czas to zależy od sposobu implementacji aplikacji.
• Gdy użytkownicy włączą aplikację do zarządzania urządzeniem, będą podlegać obowiązującym w niej zasadom. Przestrzeganie tych zasad zwykle przynosi korzyści takie jak dostęp do systemów i danych wrażliwych.

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

Jeśli użytkownik nie przestrzega zasad (na przykład ustawi hasło, które narusza wytyczne), aplikacja decyduje, jak to zrobić. Zwykle jednak uniemożliwia to użytkownikowi synchronizację danych.

Jeśli urządzenie spróbuje połączyć się z serwerem, który wymaga zasad nieobsługiwanych przez interfejs Device Administration API, takie połączenie będzie niedozwolone. Interfejs Device Administration API nie zezwala obecnie na częściową obsługę administracyjną. Inaczej mówiąc, jeśli urządzenie (np. starsze urządzenie) nie obsługuje wszystkich wymienionych zasad, nie ma możliwości zezwolenia na połączenie.

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

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

Zasady

W firmach często zdarza się, że urządzenia pracowników muszą być zgodne z rygorystycznymi zasadami dotyczącymi korzystania z nich. Interfejs Device Administration API obsługuje zasady wymienione w tabeli 1. Pamiętaj, że interfejs Device Administration API obecnie obsługuje tylko hasła do blokady ekranu:

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

Inne funkcje

Oprócz obsługi zasad wymienionych w powyższej tabeli interfejs Device Administration API umożliwia wykonywanie tych czynności:

• Zachęć użytkownika do ustawienia nowego hasła.
• Natychmiast zablokuj urządzenie.
• Wyczyść dane urządzenia (czyli przywróć na urządzeniu ustawienia fabryczne).

Przykładowa aplikacja

Na tej stronie wykorzystano przykładowy interfejs Device Administration API, który jest uwzględniony w przykładach pakietów SDK (dostępnych w usłudze Android SDK Manager) i znajdujący 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 administracyjnych urządzenia. Udostępnia użytkownikom interfejs, który pozwala włączyć aplikację do administrowania urządzeniem. Po włączeniu aplikacji mogą oni za pomocą przycisków w interfejsie:

• Ustaw jakość haseł.
• Określ wymagania dotyczące hasła użytkownika, takie jak minimalna długość czy minimalna liczba znaków, które musi zawierać hasło.
• Ustaw hasło. Jeśli hasło nie jest zgodne z określonymi zasadami, system zwraca błąd.
• Określ, ile nieudanych prób podania hasła może wystąpić, zanim dane na urządzeniu zostaną wyczyszczone (czyli zostaną przywrócone ustawienia fabryczne).
• Określ, za jaki czas będzie wygasać hasło.
• Ustaw długość historii haseł (length odnosi się do liczby starych haseł przechowywanych w historii). Dzięki temu użytkownicy nie będą mogli ponownie użyć jednego z ostatnich n haseł, których wcześniej używali.
• Określ, czy obszar pamięci ma być zaszyfrowany, jeśli urządzenie obsługuje tę funkcję.
• Ustaw maksymalny czas braku aktywności, po którym urządzenie zostanie zablokowane.
• Natychmiast zablokuj urządzenie.
• Wyczyść dane urządzenia (czyli przywróć ustawienia fabryczne).
• Wyłącz aparat.

Rysunek 1. Zrzut ekranu przykładowej aplikacji

Tworzenie aplikacji do administrowania urządzeniem

Administratorzy systemu mogą używać interfejsu Device Administration API do napisania aplikacji wymuszającej zdalne/lokalne egzekwowanie zasad bezpieczeństwa urządzenia. W tej sekcji podsumowano kroki potrzebne do utworzenia aplikacji do administrowania urządzeniem.

Tworzę plik manifestu

Aby można było korzystać z interfejsu Device Administration API, plik manifestu aplikacji musi zawierać te elementy:

• Podklasa klasy DeviceAdminReceiver obejmująca:
  • Uprawnienie BIND_DEVICE_ADMIN.
  • Możliwość reagowania na zamiar ACTION_DEVICE_ADMIN_ENABLED, wyrażona w pliku manifestu jako filtr intencji.
• Deklaracja zasad bezpieczeństwa używanych w metadanych.

Oto fragment przykładowego pliku manifestu administrowania urządzeniem:

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

Uwaga:

• Poniższe atrybuty odnoszą się do zasobów w postaci ciągów znaków, które znajdują się w przykładowej aplikacji w regionie ApiDemos/res/values/strings.xml. Więcej informacji o zasobach znajdziesz w artykule o zasobach aplikacji.
  • android:label="@string/activity_sample_device_admin" odnosi się do czytelnej dla użytkownika etykiety działania.
  • android:label="@string/sample_device_admin" odnosi się do czytelnej dla użytkownika etykiety uprawnienia.
  • android:description="@string/sample_device_admin_description" odnosi się do czytelnego dla użytkownika opisu uprawnienia. Opis jest zwykle dłuższy i zawiera więcej informacji niż etykieta.
• android:permission="android.permission.BIND_DEVICE_ADMIN" to uprawnienie, które podklasa DeviceAdminReceiver musi mieć, aby tylko system mógł wchodzić w interakcje z odbiornikiem (nie można przyznać tego uprawnienia żadnej aplikacji). Zapobiega to nadużywaniu aplikacji administratora urządzenia przez inne aplikacje.
• android.app.action.DEVICE_ADMIN_ENABLED to główna czynność, którą musi wykonać podklasa DeviceAdminReceiver, aby mogła zarządzać urządzeniem. Ta wartość jest ustawiona na odbiornik, gdy użytkownik włączy aplikację do administrowania urządzeniem. Twój kod zwykle obsługuje to w zadaniu onEnabled(). Aby odbiorcy mogli z niego korzystać, muszą też mieć uprawnienie BIND_DEVICE_ADMIN, aby inne aplikacje nie mogły go nadużywać.
• Gdy użytkownik włączy aplikację do administrowania urządzeniem, która umożliwi odbiorcy wykonywanie działań w odpowiedzi na przesyłane zdarzenia systemowe. W razie wystąpienia odpowiedniego zdarzenia aplikacja może zastosować odpowiednie zasady. Jeśli na przykład użytkownik spróbuje ustawić nowe hasło, które nie jest zgodne z zasadami, 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 się zmieni, administrator urządzenia zostanie wyłączony, gdy użytkownicy zaktualizują aplikację. Więcej informacji znajdziesz tutaj: <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ść pola 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 dotyczące Twojej aplikacji.

Implementacja kodu

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

DeviceAdminReceiver

Klasa podstawowa do wdrażania komponentu administrowania urządzeniem. Ta klasa ułatwia interpretację 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 opublikować DeviceAdminReceiver, który użytkownik obecnie włączył. DevicePolicyManager zarządza zasadami co najmniej 1 instancji DeviceAdminReceiver

DeviceAdminInfo

Ta klasa służy do określania metadanych komponentu administratora urządzenia.

Te klasy stanowią podstawę w pełni funkcjonalnej aplikacji do administrowania urządzeniem. W pozostałej części tej sekcji opisano sposób używania interfejsów API DeviceAdminReceiver i DevicePolicyManager do pisania aplikacji do administrowania urządzeniem.

Podklasa: obiekt DeviceAdminOdbieranie

Aby utworzyć aplikację do administrowania urządzeniem, musisz należeć do podklasy DeviceAdminReceiver. Klasa DeviceAdminReceiver składa się z serii wywołań zwrotnych, które są wyzwalane w momencie wystąpienia określonych zdarzeń.

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

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łączam aplikację

Jednym z głównych zdarzeń, które musi obsłużyć aplikacja do zarządzania urządzeniem, jest włączenie aplikacji przez użytkownika. Aby zasady były egzekwowane, użytkownik musi samodzielnie włączyć aplikację. Jeśli użytkownik nie zdecyduje się na włączenie aplikacji, będzie ona nadal dostępna na urządzeniu, ale jej zasady nie będą egzekwowane, a korzystanie z niej nie będzie możliwe.

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

Gdy użytkownik kliknie pole wyboru Włącz administratora, na ekranie pojawi się prośba o aktywowanie aplikacji administratora urządzenia, jak widać na ilustracji 2.

Rysunek 2. Przykładowa aplikacja: aktywowanie aplikacji

Poniżej znajduje się kod, który jest uruchamiany, gdy użytkownik kliknie pole wyboru Włącz administratora. W efekcie aktywujesz wywołanie zwrotne onPreferenceChange(). To wywołanie zwrotne jest wywoływane, gdy wartość parametru Preference została zmieniona przez użytkownika i zostanie ustawiona lub utrwalona. Jeśli użytkownik włączy aplikację, ekran zmieni się i wyświetli prośbę o aktywowanie aplikacji administratora urządzenia, jak pokazano na ilustracji. 2. W przeciwnym razie aplikacja do zarządzania urządzeniem jest wyłączona.

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;
}

Wiersz intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) informuje, że zasadą docelową jest mDeviceAdminSample (czyli komponent DeviceAdminReceiver). Ten wiersz powoduje wywołanie interfejsu użytkownika pokazanego na rys. 2, który prowadzi użytkowników przez proces dodawania administratora urządzenia do systemu (lub umożliwia jego odrzucenie).

Gdy aplikacja musi wykonać operację, która jest zależna od włączenia aplikacji do administrowania urządzeniem, potwierdza, że jest ona aktywna. Używa do tego metody DevicePolicyManager isAdminActive(). Zwróć uwagę, że metoda DevicePolicyManagerisAdminActive() przyjmuje komponent DeviceAdminReceiver jako argument:

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 klasa publiczna do zarządzania zasadami obowiązującymi na urządzeniu. DevicePolicyManager zarządza zasadami co najmniej 1 instancji DeviceAdminReceiver.

Uzyskasz taki nick dla elementu DevicePolicyManager:

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

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

W tej sekcji opisano, jak za pomocą DevicePolicyManager wykonywać zadania administracyjne:

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

Konfigurowanie 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 czynności związane z hasłem.

ustawić hasło do urządzenia,

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

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 stałych wartości DevicePolicyManager:

PASSWORD_QUALITY_ALPHABETIC

Użytkownik musi wpisać hasło zawierające przynajmniej litery (lub inne symbole).

PASSWORD_QUALITY_ALPHANUMERIC

Użytkownik musi wpisać hasło zawierające co najmniej zarówno cyfry, jak i litery (lub inne symbole).

PASSWORD_QUALITY_NUMERIC

Użytkownik musi wpisać hasło zawierające co najmniej cyfry.

PASSWORD_QUALITY_COMPLEX

Użytkownik musi podać hasło zawierające co najmniej literę, cyfrę i specjalny symbol.

PASSWORD_QUALITY_SOMETHING

Zasady wymagają podania jakiegoś hasła, ale nie jest obojętne.

PASSWORD_QUALITY_UNSPECIFIED

Zasada nie ma wymagań dotyczących hasła.

Aby na przykład ustawić wymóg podawania hasła alfanumerycznego w zasadach dotyczących haseł:

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);

Ustaw wymagania dotyczące treści haseł

Począwszy od Androida 3.0 klasa DevicePolicyManager zawiera metody umożliwiające doprecyzowanie zawartości hasła. Możesz na przykład ustawić zasadę, zgodnie z którą hasła muszą zawierać co najmniej n wielkich liter. Oto metody dostrajania treści hasła:

• setPasswordMinimumLetters()
• setPasswordMinimumLowerCase()
• setPasswordMinimumUpperCase()
• setPasswordMinimumNonLetter()
• setPasswordMinimumNumeric()
• setPasswordMinimumSymbols()

Na przykład ten fragment kodu informuje, że hasło musi się składać z co najmniej 2 wielkich liter:

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 mieć przynajmniej określoną minimalną długość. Na przykład:

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);

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

Możesz ustawić maksymalną dozwoloną liczbę nieudanych prób podania hasła przed wyczyszczeniem pamięci urządzenia (czyli przywróceniem ustawień fabrycznych). Na przykład:

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);

Ustaw czas ważności hasła

Począwszy od Androida 3.0 można używać metody setPasswordExpirationTimeout(), aby określić, kiedy hasło wygaśnie, wyrażone w milisekundach od ustawienia tego limitu przez administratora urządzenia. Na przykład:

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);

Ogranicz hasła na podstawie historii

Począwszy od Androida 3.0, można używać metody setPasswordHistoryLength(), aby ograniczać możliwość używania starych haseł przez użytkowników. Ta metoda wykorzystuje parametr length, który określa, ile starych haseł jest przechowywanych. Gdy ta zasada jest aktywna, użytkownicy nie mogą wpisywać nowego hasła pasującego do ostatnich n haseł. Dzięki temu użytkownicy nie będą musieli ciągle używać tego samego hasła. Ta zasada jest zwykle używana w połączeniu z zasadą setPasswordExpirationTimeout(), która wymusza na użytkownikach aktualizację haseł po upływie określonego czasu.

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

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 czas nieaktywności użytkownika, który może wystąpić, zanim urządzenie zostanie zablokowane. Na przykład:

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ż automatycznie skonfigurować urządzenie, by natychmiast się zablokowało:

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

DevicePolicyManager dpm;
dpm.lockNow();

Wyczyść dane

Aby przywrócić na urządzeniu ustawienia fabryczne, możesz użyć metody DevicePolicyManager wipeData(). Jest to przydatne, gdy urządzenie zostanie zgubione lub skradzione. Często decyzja o wyczyszczeniu pamięci 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 zostaną usunięte w ten sposób:

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

DevicePolicyManager dpm;
dpm.wipeData(0);

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

Wyłączanie aparatu

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

Aby określić, czy kamera ma być wyłączona, użyj metody setCameraDisabled(). Na przykład ten fragment kodu włącza lub wyłącza kamerę na podstawie ustawienia pola wyboru:

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 masowej

Począwszy od Androida 3.0, można używać metody setStorageEncryption() do ustawiania zasad wymagających szyfrowania obszaru pamięci masowej (o ile jest obsługiwana).

Na przykład:

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, jak włączyć szyfrowanie pamięci masowej, znajdziesz w przykładowym interfejsie Device Administration API.

Dodatkowe przykłady kodu

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