Panoramica dell'amministrazione del dispositivo

Ritiro dell'amministratore del dispositivo. A partire da Android 9 (livello API 28), alcuni criteri amministrativi verranno contrassegnati come deprecati quando richiamato da un amministratore del dispositivo. Ti consigliamo di iniziare subito a prepararti a questo cambiamento. Per ulteriori informazioni ed esaminare le opzioni di migrazione, Ritiro dell'amministrazione del dispositivo.

Android include il supporto per le app aziendali offrendo il API Android Device Administration. L'API di amministrazione dei dispositivi fornisce funzionalità di amministrazione a livello di sistema. Queste API consentono di creare per la sicurezza e per la sicurezza che sono utili in contesti aziendali, in cui i professionisti richiedono un ampio controllo sui dispositivi dei dipendenti. Ad esempio, l'app email Android integrata ha sfruttato queste API per migliorare Supporto di Exchange. Tramite l'app Email, gli amministratori di Exchange possono applicare criteri relativi alle password, incluse password alfanumeriche o numeriche PIN su tutti i dispositivi. Gli amministratori possono anche cancellare da remoto i dati (ovvero attivi (ripristinare le impostazioni di fabbrica) dei telefoni smarriti o rubati. Gli utenti di Exchange possono sincronizzare le email e i dati del calendario.

Questo documento è rivolto agli sviluppatori che vogliono sviluppare soluzioni per i dispositivi Android. Illustra le varie funzionalità forniti dall'API di amministrazione dei dispositivi per garantire una maggiore sicurezza dispositivi per i dipendenti basati su Android.

Nota: per informazioni sulla creazione di una norma relativa al lavoro per le implementazioni Android for Work, vedi Crea un controller dei criteri dei dispositivi.

Modalità proprietario dispositivo headless

Android 14 (livello API 34) introduce la modalità Utente di sistema headless (i dispositivi in quale UserManager.isHeadlessSystemUserMode restituisce true). Nella modalità Utente di sistema senza testa, l'utente del sistema utente in background e si affida ad altri utenti in primo piano per l'utente finale un'interazione. Android 14 introduce anche modalità affiliato del proprietario del dispositivo headless, che aggiunge un proprietario del profilo a tutti utenti affiliati diverso dall'utente del sistema su cui è impostato il proprietario del dispositivo.

Nei dispositivi configurati con un utente di sistema headless (in cui l'utente del sistema vengono eseguiti in background), solo i criteri relativi ai dispositivi con ambito globale (criteri applicabili a tutti gli utenti) vengono applicati all'utente in primo piano o utenti. Consulta addUserRestriction per maggiori dettagli.

I produttori di dispositivi Android possono fare riferimento alle indicazioni pubblicato su source.android.com.

Panoramica dell'API Device Administration

Di seguito sono riportati alcuni esempi di tipi di app che potrebbero utilizzare l'API Device Administration:

  • Client di posta.
  • App per la sicurezza che eseguono la cancellazione da remoto.
  • App e servizi di gestione dei dispositivi.

Come funziona?

Puoi utilizzare l'API di amministrazione del dispositivo per scrivere le app di amministrazione del dispositivo che gli utenti installare sui propri dispositivi. L'app di amministrazione del dispositivo applica in modo forzato criteri. Ecco come funziona:

  • Un amministratore di sistema scrive un'app di amministrazione del dispositivo che applica criteri di sicurezza dei dispositivi remoti/locali. Questi criteri possono essere hard-coded in l'app oppure l'app potrebbe recuperare dinamicamente i criteri da una terza parte o server web.
  • L'app è installata sul dispositivo dispositivi mobili. Android al momento non dispongono di una soluzione di provisioning automatizzato. Alcuni modi in cui un amministratore di sistema per distribuire l'app agli utenti:
    • Google Play.
    • Attivazione dell'installazione da un altro store.
    • Distribuzione dell'app tramite altri mezzi, ad esempio email o siti web.
  • Il sistema chiede all'utente di attivare l'app di amministrazione del dispositivo. Come e quando questo avviene dipende da come è implementata l'app.
  • Una volta attivata l'app di amministrazione del dispositivo, gli utenti sono soggetti alle le relative norme. Il rispetto di queste norme in genere conferisce vantaggi, l'accesso a dati e sistemi sensibili.

Se gli utenti non abilitano l'app di amministrazione del dispositivo, questa rimane sul dispositivo, ma in stato inattivo. Gli utenti non saranno soggetti alle relative norme e, al contrario, non usufruiranno dei vantaggi dell'app (ad esempio, potrebbero non essere in grado di sincronizzare i dati).

Se un utente non rispetta i criteri (ad esempio, se imposta una password che viola le linee guida), spetta all'app decidere gestire la situazione. Tuttavia, in genere ciò impedisce all'utente in grado di sincronizzare i dati.

Se un dispositivo tenta di connettersi a un server che richiede criteri non supportata nell'API di amministrazione del dispositivo, la connessione non essere consentite. L'API Device Administration al momento non consente per eseguire il provisioning. In altre parole, se un dispositivo (ad esempio, un dispositivo legacy) non supportano tutti i criteri dichiarati, non c'è modo di consentire dispositivo per la connessione.

Se un dispositivo contiene più app di amministrazione abilitate, il criterio più severo è in modo forzato. Non è possibile scegliere come target un amministratore specifico dell'app.

Per disinstallare un'app di amministrazione del dispositivo esistente, gli utenti devono: annulla prima la registrazione dell'app come amministratore.

Norme

In ambito aziendale, i dispositivi dei dipendenti spesso devono rispettare una serie di norme rigorose che regolano l'utilizzo del dispositivo. La L'API di amministrazione dei dispositivi supporta i criteri elencati nella Tabella 1. Tieni presente che l'API Device Administration attualmente supporta solo le password per lo schermo blocco:

Tabella 1. Criteri supportati dall'API Device Administration.

Norme Descrizione
Password attivata Richiede che i dispositivi chiedano PIN o password.
Lunghezza minima della password Imposta il numero di caratteri richiesto per la password. Ad esempio, può richiedere un PIN o una password di almeno sei caratteri.
Password alfanumerica obbligatoria Richiede che le password includano un combinazione di lettere e numeri. Possono includere caratteri simbolici.
È richiesta una password complessa Richiede che le password contengano almeno una lettera, una cifra numerica e un simbolo speciale. Introdotto in Android 3.0.
Numero minimo di lettere richieste nella password Il numero minimo di lettere richieste nella password per tutti gli amministratori o per uno specifico. Introdotto in Android 3.0.
Numero minimo di lettere minuscole richieste nella password Il numero minimo di lettere minuscole lettere richieste nella password per tutti gli amministratori o per uno specifico. Introdotto in Android 3.0.
Nella password sono richiesti almeno caratteri non costituiti da lettere Il numero minimo di caratteri non costituiti da lettere richiesti nella password per tutti gli amministratori o per uno specifico. Introdotto in Android 3.0.
Numero minimo di cifre richieste nella password Il numero minimo di cifre numeriche richiesto nella password per tutti gli amministratori o per uno specifico. Introdotto in Android 3.0.
Numero minimo di simboli richiesti nella password Il numero minimo di simboli richiesti nella password per tutti gli amministratori o per uno specifico. Introdotto in Android 3.0.
Numero minimo di lettere maiuscole richieste nella password Il numero minimo di lettere maiuscole richiesto nella password per tutti gli amministratori o per uno specifico. Introdotto in Android 3.0.
Timeout scadenza password Data di scadenza della password, espressa come delta in millisecondi dal momento in cui un amministratore del dispositivo imposta il timeout per la scadenza. Introdotto in Android 3.0.
Restrizione cronologia password Questo criterio impedisce agli utenti di riutilizzare le ultime n password univoche. Questo criterio viene in genere utilizzato insieme a setPasswordExpirationTimeout(), che forza agli utenti di aggiornare le proprie password dopo che è trascorso un determinato periodo di tempo. Introdotto in Android 3.0.
Numero massimo di tentativi per la password non riusciti Specifica quante volte un utente può inserire una password errata prima del dispositivo cancella i propri dati. L'API di amministrazione dei dispositivi consente inoltre agli amministratori ripristinare da remoto le impostazioni di fabbrica del dispositivo. In questo modo i dati sono protetti se il dispositivo è stato smarrito o rubato.
Blocco del tempo di inattività massimo Consente di impostare l'intervallo di tempo trascorso dall'ultima volta che l'utente ha toccato lo schermo oppure premuto un pulsante prima che il dispositivo blocchi lo schermo. In questi casi, gli utenti dovrà inserire nuovamente il PIN o la password prima di poter utilizzare i dispositivi accedere ai dati. Il valore può essere compreso tra 1 e 60 minuti.
Richiedi crittografia dello spazio di archiviazione Specifica che l'area di archiviazione deve essere criptata, se il dispositivo la supporta. Introdotto in Android 3.0.
Disattiva videocamera Specifica che la fotocamera deve essere disattivata. Tieni presente che non sono state una disattivazione permanente. La videocamera può essere attivata/disattivata in modo dinamico in base al contesto, all'ora e così via. Introdotto in Android 4.0.

Altre funzionalità

Oltre a supportare le norme elencate nella tabella precedente, il Dispositivo L'API di amministrazione ti consente di:

  • Chiedi all'utente di impostare una nuova password.
  • Blocca immediatamente il dispositivo.
  • Cancellare i dati del dispositivo (ripristinare le impostazioni di fabbrica del dispositivo).

App di esempio

Gli esempi utilizzati in questa pagina si basano sull'API Device Administration esempio, che è incluso negli esempi dell'SDK (disponibili tramite Android SDK Manager) e che si trova nel sistema come <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java.

L'app di esempio offre una demo delle funzionalità di amministrazione del dispositivo. Presenta gli utenti con un'interfaccia utente che consente di abilitare l'app di amministrazione del dispositivo. Una volta dopo aver attivato l'app, possono usare i pulsanti nell'interfaccia utente effettuare le seguenti operazioni:

  • Imposta la qualità della password.
  • Specifica i requisiti per la password dell'utente, ad esempio la lunghezza minima, il numero minimo di caratteri numerici che deve contenere e così via.
  • Imposta la password. Se la password non è conforme a criteri, il sistema restituisce un errore.
  • Imposta il numero di tentativi di inserimento della password non riusciti prima della cancellazione dei dati del dispositivo (ovvero il ripristino delle impostazioni di fabbrica).
  • Imposta per quanto tempo la password scadrà.
  • Imposta la lunghezza della cronologia delle password (lunghezza si riferisce al numero di password precedenti memorizzate nella cronologia). In questo modo gli utenti non possono riutilizzare una delle ultime n password usate in precedenza.
  • Specifica che l'area di archiviazione deve essere criptata, se il dispositivo la supporta.
  • Imposta il tempo massimo di inattività che può trascorrere prima che il dispositivo serrature.
  • Attiva immediatamente il blocco del dispositivo.
  • Cancellare i dati del dispositivo (ripristinare le impostazioni di fabbrica).
  • Disattiva la fotocamera.

Figura 1. Screenshot dell'app di esempio

Sviluppo di un'app di amministrazione dei dispositivi

Gli amministratori di sistema possono utilizzare l'API di amministrazione dispositivo per scrivere un'app che applica i criteri di sicurezza dei dispositivi remoti/locali. Questa sezione riassume i passaggi necessari per la creazione di un'amministrazione dispositivi dell'app.

Creazione del manifest

Per utilizzare l'API Device Administration, l'app il file manifest deve includere quanto segue:

Ecco un estratto del file manifest di esempio per l'amministrazione dei dispositivi:

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

Tieni presente che:

  • I seguenti attributi si riferiscono alle risorse stringa che risiedono nell'app di esempio ApiDemos/res/values/strings.xml. Per ulteriori informazioni sulle risorse, consulta Risorse per le applicazioni.
    • android:label="@string/activity_sample_device_admin" si riferisce al un'etichetta leggibile per l'attività.
    • android:label="@string/sample_device_admin" si riferisce al un'etichetta leggibile per l'autorizzazione.
    • android:description="@string/sample_device_admin_description" si riferisce a la descrizione leggibile dell'autorizzazione. Una descrizione è in genere più lunga e più lunga informativo rispetto un'etichetta.
  • android:permission="android.permission.BIND_DEVICE_ADMIN" è un'autorizzazione che una sottoclasse DeviceAdminReceiver deve per garantire che solo il sistema possa interagire con il destinatario (non è possibile concedere questa autorizzazione a nessuna app). Questo impedisce ad altre app di utilizzare in modo illecito l'app di amministrazione del dispositivo.
  • android.app.action.DEVICE_ADMIN_ENABLED è il livello principale che una sottoclasse DeviceAdminReceiver deve gestire per autorizzati a gestire un dispositivo. Viene impostato sul destinatario quando l'utente abilita l'app di amministrazione del dispositivo. Il tuo codice solitamente gestisce questa operazione onEnabled(). Per essere supportato, il destinatario deve anche richiedono l'autorizzazione BIND_DEVICE_ADMIN affinché altre app non possono abusarne.
  • Quando un utente attiva l'app di amministrazione del dispositivo, il destinatario l'autorizzazione a eseguire azioni in risposta alla trasmissione di un particolare sistema eventi. Quando si verifica un evento adatto, l'app può imporre delle norme. Per Ad esempio, se un utente tenta di impostare una nuova password che non soddisfa il criterio, requisiti, l'app può chiedere all'utente di scegliere una password diversa che soddisfano i requisiti.
  • Evita di modificare il nome del destinatario dopo aver pubblicato l'app. Se il nome nel campo modifiche al file manifest, l'amministrazione del dispositivo viene disattivata quando gli utenti aggiornano l'app. Per saperne di più, vedi <receiver>
  • android:resource="@xml/device_admin_sample" dichiara i criteri di sicurezza usati nei metadati. I metadati forniscono informazioni specifiche per l'amministratore del dispositivo, come analizzate dalla classe DeviceAdminInfo. Ecco i contenuti 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>

Durante la progettazione dell'app di amministrazione dei dispositivi, non è necessario includere tutte le norme, solo quelle pertinenti per la tua app.

Per ulteriori discussioni sul file manifest, consulta la Guida per gli sviluppatori Android.

Implementazione del codice

L'API di amministrazione dei dispositivi include le seguenti classi:

DeviceAdminReceiver
Classe di base per l'implementazione di un componente di amministrazione del dispositivo. Questo corso fornisce è utile per interpretare le azioni di intent non elaborate inviate dal di un sistema operativo completo. L'app Amministrazione dispositivo deve includere un DeviceAdminReceiver sottoclasse.
DevicePolicyManager
Un corso per la gestione dei criteri applicati a un dispositivo. La maggior parte dei clienti di questo corso deve aver pubblicato un DeviceAdminReceiver che l'utente è attualmente abilitato. L'DevicePolicyManager gestisce i criteri per una o più istanze DeviceAdminReceiver
DeviceAdminInfo
Questa classe viene utilizzata per specificare i metadati per un componente per l'amministratore del dispositivo.

Questi corsi forniscono le basi per un'app di amministrazione dei dispositivi completamente funzionale. Il resto di questa sezione descrive come utilizzi DeviceAdminReceiver e DevicePolicyManager API per scrivere un'app di amministrazione del dispositivo.

Creazione di sottoclassi DeviceAdminReceiver

Per creare un'app di amministrazione del dispositivo, devi sottoclasse DeviceAdminReceiver. Il corso DeviceAdminReceiver consiste in una serie di callback che vengono attivati quando determinati eventi che si verificano.

Nella sottoclasse DeviceAdminReceiver, l'app di esempio mostra semplicemente una notifica Toast in risposta a un eventi. Ad esempio:

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

Attivazione dell'app

Uno degli eventi principali che un'app di amministrazione del dispositivo deve gestire è l'utente attivare l'app. L'utente deve abilitare esplicitamente l'app per: i criteri da applicare. Se l'utente sceglie di non attivare l'app sarà comunque presente sul dispositivo, ma i relativi criteri non verranno applicati e usufruire dei vantaggi dell'app.

Il processo di abilitazione dell'app inizia quando l'utente esegue un azione che attiva ACTION_ADD_DEVICE_ADMIN l'intento. Nella app di esempio, questo accade quando l'utente fa clic sul pulsante Attiva Console di amministrazione.

Quando l'utente fa clic sulla casella di controllo Attiva amministratore, la visualizzazione cambia per richiedere all'utente di attivare l'app di amministrazione del dispositivo, come mostrato nella figura 2.

Figura 2. App di esempio: attivazione dell'app

Di seguito è riportato il codice che viene eseguito quando l'utente fa clic sulla casella di controllo Abilita amministratore. Ciò ha l'effetto di attivare onPreferenceChange() di Google. Questo callback viene attivato quando il valore di questo Preference è stato modificato dall'utente e sta per essere impostato e/o mantenuto. Se l'utente attiva l'app, lo schermo cambia per richiedere all'utente di attivare l'app di amministrazione del dispositivo, come mostrato nella figura 2. In caso contrario, l'app di amministrazione del dispositivo è disattivata.

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

La linea intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) indica che mDeviceAdminSample (ovvero DeviceAdminReceiver) è il criterio di destinazione. Questa riga richiama l'interfaccia utente mostrata nella Figura 2, che guida gli utenti attraverso aggiungere l'amministratore del dispositivo al sistema (o consentire agli utenti di rifiutarlo).

Quando l'app deve eseguire un'operazione che dipende dal l'app di amministrazione del dispositivo viene attivata, conferma che l'app sia attivo. Per farlo utilizza il metodo DevicePolicyManager isAdminActive(). Nota che l'DevicePolicyManager metodo isAdminActive() richiede un DeviceAdminReceiver come argomento:

Kotlin

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

Java

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

Gestione delle norme

DevicePolicyManager è una classe pubblica per la gestione dei criteri in modo forzato su un dispositivo. DevicePolicyManager gestisce i criteri per uno o più istanze di DeviceAdminReceiver.

Per ottenere un handle per DevicePolicyManager:

Kotlin

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

Java

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

Questa sezione descrive come utilizzare DevicePolicyManager per eseguire attività amministrative:

Imposta criteri per le password

DevicePolicyManager include le API per l'impostazione e l'applicazione delle criteri relativi alle password del dispositivo. Nell'API Device Administration, la password si applica solo a blocco schermo. Questa sezione descrive le attività comuni relative alle password.

Imposta una password per il dispositivo

Questo codice visualizza un'interfaccia utente in cui viene chiesto all'utente di impostare una password:

Kotlin

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

Java

Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
startActivity(intent);
Impostare la qualità delle password

La qualità della password può essere una delle seguenti costanti DevicePolicyManager:

PASSWORD_QUALITY_ALPHABETIC
L'utente deve inserire un password contenente almeno caratteri alfabetici (o altri simboli).
PASSWORD_QUALITY_ALPHANUMERIC
L'utente deve inserire un password contenente almeno sia numerici e alfabetici (oppure (altro simbolo).
PASSWORD_QUALITY_NUMERIC
L'utente deve inserire una password contenente almeno caratteri numerici.
PASSWORD_QUALITY_COMPLEX
L'utente deve essere stata inserita una password contenente almeno una lettera, una cifra numerica un simbolo speciale.
PASSWORD_QUALITY_SOMETHING
Il richiede una sorta di della password, ma non gli importa cosa sia.
PASSWORD_QUALITY_UNSPECIFIED
Il criterio non ha requisiti per la password.

Ad esempio, ecco come puoi impostare i criteri relativi alle password in modo che richiedano una password alfanumerica:

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);
Imposta requisiti per i contenuti delle password

A partire da Android 3.0, la classe DevicePolicyManager include metodi che consentono di ottimizzare il contenuto della password. Per Ad esempio, puoi impostare un criterio per stabilire che le password debbano contenere almeno n lettere maiuscole. Di seguito sono riportati i metodi per il perfezionamento contenuti:

Ad esempio, questo snippet indica che la password deve contenere almeno due lettere maiuscole:

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);
Impostare la lunghezza minima della password

Puoi specificare che una password debba essere almeno del valore minimo specificato lunghezza. Ad esempio:

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);
Imposta il numero massimo di tentativi di inserimento della password non riusciti

Puoi impostare il numero massimo consentito di tentativi di inserimento della password non riusciti prima del i dati del dispositivo (ovvero il ripristino delle impostazioni di fabbrica). Ad esempio:

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);
Imposta timeout scadenza password

A partire da Android 3.0, puoi utilizzare setPasswordExpirationTimeout() per impostare la scadenza di una password, espressa come delta in millisecondi dalla data in cui l'amministratore del dispositivo imposta il timeout per la scadenza. Ad esempio:

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);
Limita password in base alla cronologia

A partire da Android 3.0, puoi utilizzare setPasswordHistoryLength() per limitare l'accesso di riutilizzare le vecchie password. Questo metodo richiede una lunghezza , che specifica quanti vengono memorizzate. Quando questo criterio è attivo, gli utenti non possono inserirne uno nuovo che corrisponda alle ultime n password. In questo modo di usare la stessa password più volte. Questo criterio viene in genere utilizzato in combinazione con setPasswordExpirationTimeout(), che obbliga gli utenti di aggiornare le password una volta trascorso un determinato periodo di tempo.

Ad esempio, questo snippet impedisce agli utenti di riutilizzare una delle ultime 5 password:

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

Imposta il blocco del dispositivo

Puoi impostare il periodo massimo di inattività dell'utente che può verificarsi prima del i blocchi del dispositivo. Ad esempio:

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

Puoi anche impostare in modo programmatico il dispositivo in modo che venga bloccato immediatamente:

Kotlin

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

Java

DevicePolicyManager dpm;
dpm.lockNow();

Esegui la cancellazione dei dati

Puoi usare il metodo DevicePolicyManager wipeData() per ripristinare le impostazioni di fabbrica del dispositivo. È utile in caso di smarrimento o furto del dispositivo. Spesso la decisione di cancellare i dati dal dispositivo risultato del soddisfacimento di determinate condizioni. Ad esempio, puoi utilizzare setMaximumFailedPasswordsForWipe() per indicare che un dispositivo dovrebbe essere cancellazione dei dati dopo un determinato numero di tentativi di inserimento password non riusciti.

Puoi cancellare i dati nel seguente modo:

Kotlin

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

Java

DevicePolicyManager dpm;
dpm.wipeData(0);

Il metodo wipeData() utilizza come suo una maschera di bit con opzioni aggiuntive. Attualmente il valore deve essere 0.

Disattiva videocamera

A partire da Android 4.0, puoi disattivare la fotocamera. Tieni presente che questa disattivazione non deve necessariamente comportare una disattivazione definitiva. La videocamera può essere attivata/disattivata in modo dinamico in base al contesto, all'ora e così via.

Puoi controllare se la videocamera è disattivata utilizzando il setCameraDisabled(). Ad esempio, questo snippet consente di attivare o disattivare la videocamera in base all'impostazione di una casella di controllo:

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

Crittografia dello spazio di archiviazione

A partire da Android 3.0, puoi utilizzare setStorageEncryption() per impostare un criterio che richieda la crittografia dell'area di archiviazione, se supportato.

Ad esempio:

Kotlin

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

Java

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

Per un esempio completo di come attivare la crittografia dello spazio di archiviazione, vedi l'esempio dell'API di amministrazione dei dispositivi.

Altri esempi di codice

Android AppRestrictionEnforcer e DeviceOwner esempi dimostrano ulteriormente l'uso delle API trattate in questa pagina.