Panoramica dell'amministrazione del dispositivo

Ritiro di Amministrazione 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 apprendere 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 Device Administration fornisce funzionalità di gestione del dispositivo a livello di sistema. Queste API ti consentono di creare app attente alla sicurezza utili in ambienti aziendali, in cui i professionisti IT richiedono un controllo completo sui dispositivi dei dipendenti. Ad esempio, l'app Email integrata di Android ha sfruttato queste API per migliorare il supporto di Exchange. Tramite l'app Email, gli amministratori di Exchange possono applicare i criteri per le password, incluse le password alfanumeriche o i PIN numerici, su tutti i dispositivi. Gli amministratori possono anche cancellare da remoto (ovvero ripristinare le impostazioni predefinite di fabbrica) gli smartphone smarriti o rubati. Gli utenti di Exchange possono sincronizzare i propri dati di email e calendario.

Questo documento è rivolto agli sviluppatori che vogliono sviluppare soluzioni aziendali per 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 un Work Policy Controller per i deployment di Android for Work, consulta Creare 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 di 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 di sistema viene eseguito in background), all'utente o agli utenti in primo piano vengono applicati solo i criteri del dispositivo di ambito globale (applicabili a tutti gli utenti). Consulta: addUserRestriction per maggiori dettagli.

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

Panoramica dell'API di amministrazione dei dispositivi

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

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

Come funziona?

L'API Device Administration viene utilizzata per scrivere app di amministrazione dei dispositivi che gli utenti installano 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. Al momento Android non ha una soluzione di provisioning automatico. Alcuni modi in cui un amministratore di sistema per distribuire l'app agli utenti:
    • Google Play.
    • Attivare l'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 ai suoi criteri. 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 norme e non usufruiranno, al contrario, 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), è compito dell'app decidere come gestire la situazione. Tuttavia, in genere l'utente non potrà sincronizzare i dati.

Se un dispositivo tenta di connettersi a un server che richiede criteri non supportati nell'API Device Administration, la connessione non sarà consentita. Al momento l'API Device Administration non consente il provisioning parziale. In altre parole, se un dispositivo (ad esempio uno legacy) non supporta tutti i criteri dichiarati, non è possibile consentirne la connessione.

Se un dispositivo contiene più app di amministrazione abilitate, il criterio più rigido è in modo forzato. Non è possibile scegliere come target una determinata app di amministrazione.

Per disinstallare un'app di amministrazione del dispositivo esistente, gli utenti devono prima annullarne la registrazione 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 di amministrazione del dispositivo supporta attualmente solo le password per lo schermo blocco:

Tabella 1. Norme supportate 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 abbiano una combinazione di lettere e numeri. Possono includere caratteri simbolici.
È richiesta una password complessa Le password devono contenere almeno una lettera, una cifra numerica e un simbolo speciale. Introdotta 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. Introdotta in Android 3.0.
Numero minimo di lettere minuscole richieste nella password Il numero minimo di lettere minuscole obbligatorie nella password per tutti gli amministratori o per uno specifico. Introdotta in Android 3.0.
Numero minimo di caratteri non alfabetici richiesti nella password Il numero minimo di caratteri diversi dalle lettere richiesto 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 richieste nella password per tutti gli amministratori o per uno specifico. Introdotta in Android 3.0.
Numero minimo di simboli obbligatori nella password Il numero minimo di simboli richiesti nella password per tutti gli amministratori o per uno in particolare. Introdotto in Android 3.0.
Numero minimo di lettere maiuscole richieste nella password Il numero minimo di lettere maiuscole richieste nella password per tutti gli amministratori o per uno in particolare. 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. Introdotta 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 in combinazione con setPasswordExpirationTimeout(), che obbliga gli utenti ad aggiornare le proprie password dopo un determinato periodo di tempo. Introdotto in Android 3.0.
Numero massimo di tentativi di inserimento della 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 vengono protetti nel caso in cui il dispositivo venga 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.
Disattivazione della fotocamera Specifica che la videocamera deve essere disattivata. Tieni presente che non sono state una disattivazione permanente. La videocamera può essere attivata/disattivata dinamicamente 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 alle norme specificate, 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 il tempo che deve trascorrere prima della scadenza della password.
  • Imposta la lunghezza della cronologia delle password (length si riferisce al numero di password precedenti memorizzate nella cronologia). In questo modo gli utenti non possono riutilizzare una delle ultime n password che hanno utilizzato 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).
  • Disattivare la fotocamera.

Figura 1. Screenshot dell'app di esempio

Sviluppo di un'app di amministrazione del dispositivo

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" fa riferimento all'etichetta leggibile dall'utente per l'attività.
    • android:label="@string/sample_device_admin" si riferisce all'etichetta leggibile dall'utente 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). In questo modo, altre app non potranno abusare della tua app di amministrazione del dispositivo.
  • android.app.action.DEVICE_ADMIN_ENABLED è l'azione principale che una sottoclasse DeviceAdminReceiver deve gestire per poter gestire un dispositivo. Questo valore viene impostato sul destinatario quando l'utente attiva l'app di amministrazione del dispositivo. In genere, il codice gestisce questo valore in 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 ottiene l'autorizzazione per eseguire azioni in risposta alla trasmissione di determinati eventi di sistema. Quando si verifica un evento adatto, l'app può imporre delle norme. Ad esempio, se l'utente tenta di impostare una nuova password che non soddisfa i requisiti previsti dalle norme, l'app può chiedergli di scegliere una password diversa che soddisfi i requisiti.
  • Evita di modificare il nome del destinatario dopo aver pubblicato l'app. Se il nome nel manifest cambia, l'amministrazione del dispositivo viene disattivata quando gli utenti aggiornano l'app. Per saperne di più, consulta <receiver>.
  • android:resource="@xml/device_admin_sample" dichiara i criteri di sicurezza utilizzati nei metadati. I metadati forniscono informazioni aggiuntive specifiche per l'amministratore del dispositivo, come analizzato 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 client di questa classe deve aver pubblicato un DeviceAdminReceiver attualmente abilitato dall'utente. DevicePolicyManager gestisce i criteri per una o più istanze DeviceAdminReceiver
DeviceAdminInfo
Questa classe viene utilizzata per specificare i metadati per un componente di amministratore del dispositivo.

Queste classi forniscono le basi per un'app di amministrazione del dispositivo completamente funzionale. Il resto di questa sezione descrive come utilizzare le API DeviceAdminReceiver e DevicePolicyManager per scrivere un'app di amministrazione del dispositivo.

Creazione di sottoclassi di DeviceAdminReceiver

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

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

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

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, questa rimarrà sul dispositivo, ma i relativi criteri non verranno applicati e l'utente non potrà usufruire dei vantaggi dell'app.

Il processo di attivazione dell'app inizia quando l'utente esegue un'azione che attiva l'intent ACTION_ADD_DEVICE_ADMIN. 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 il callback onPreferenceChange(). Questo callback viene invocato quando il valore di Preference è stato modificato dall'utente ed è in procinto di essere impostato e/o mantenuto. Se l'utente sta attivando l'app, la visualizzazione cambia per chiedere 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.

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

La riga intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) indica che mDeviceAdminSample (che è un componente 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. A tal fine, utilizza il metodo DevicePolicyManager isAdminActive(). Tieni presente che il metodo DevicePolicyManager isAdminActive() prende un componente DeviceAdminReceiver come argomento:

KotlinJava
private lateinit var dpm: DevicePolicyManager
...
private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)
 
DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
    return dpm.isAdminActive(deviceAdminSample);
}

Gestione delle norme

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

Per ottenere un handle per DevicePolicyManager:

KotlinJava
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
 
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.

Impostare una password per il dispositivo

Questo codice mostra un'interfaccia utente che chiede all'utente di impostare una password:

KotlinJava
Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
    startActivity(intent)
}
 
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 una 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 aver inserito una password contenente almeno una lettera, una cifra e un simbolo speciale.
PASSWORD_QUALITY_SOMETHING
Il richiede una sorta di della password, ma non gli importa cosa sia.
PASSWORD_QUALITY_UNSPECIFIED
Le norme non prevedono requisiti per la password.

Ad esempio, ecco come impostare il criterio della password in modo che richieda una password alfanumerica:

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);
Impostare i requisiti dei contenuti delle password

A partire da Android 3.0, la classe DevicePolicyManager include metodi che ti consentono di perfezionare i contenuti della password. Ad esempio, puoi impostare un criterio che imponga 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:

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

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

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

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);
Impostare il timeout della scadenza della password

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

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

A partire da Android 3.0, puoi utilizzare il metodosetPasswordHistoryLength() per limitare la possibilità degli utenti di riutilizzare le vecchie password. Questo metodo accetta un parametro length, che specifica quante password vecchie vengono archiviate. Quando questo criterio è attivo, gli utenti non possono inserirne uno nuovo che corrisponda alle ultime n password. In questo modo, gli utenti non possono utilizzare la stessa password più volte. Questo criterio viene in genere utilizzato insieme a setPasswordExpirationTimeout(), che impone agli utenti di aggiornare le proprie password dopo un determinato periodo di tempo.

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

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

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:

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

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

KotlinJava
private lateinit var dpm: DevicePolicyManager
dpm.lockNow()
 
DevicePolicyManager dpm;
dpm.lockNow();

Esegui la cancellazione dei dati

Puoi usare il metodo DevicePolicyManager wipeData() per ripristinare le impostazioni di fabbrica del dispositivo. Questa opzione è utile se il dispositivo viene smarrito o rubato. 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:

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

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

Disattivazione della fotocamera

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 imposta la fotocamera in modo che venga attivata o disattivata in base a un'impostazione della casella di controllo:

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

Crittografia dello spazio di archiviazione

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

Ad esempio:

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

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