Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica dell'amministrazione del dispositivo

Ritiro di Amministrazione dispositivo. A partire da Android 9 (livello API 28), alcuni criteri di amministrazione verranno contrassegnati come obsoleti quando invocati da un amministratore dispositivo. Ti consigliamo di iniziare a prepararti ora a questo cambiamento. Per saperne di più e visualizzare le opzioni di migrazione, leggi ritiro dell'amministratore dispositivo.

Android include il supporto per le app aziendali offrendo l'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. Vengono descritte le varie funzionalità offerte dall'API Device Administration per garantire una maggiore sicurezza per i dispositivi dei 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 del dispositivo headless

Android 14 (livello API 34) introduce la modalità utente di sistema headless (dispositivi in cui UserManager.isHeadlessSystemUserMode restituisce true). In questa modalità, l'utente di sistema è un utente in background e si basa su utenti in primo piano aggiuntivi per l'interazione con l'utente finale. Android 14 introduce anche una modalità affiliazione del proprietario del dispositivo headless, che aggiunge un proprietario del profilo a tutti gli utenti affiliati tranne che all'utente di 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). Per maggiori dettagli, consulta addUserRestriction.

I produttori di dispositivi Android possono fare riferimento alle linee guida pubblicate 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 i criteri preferiti. Ecco come funziona:

Un amministratore di sistema scrive un'app di amministrazione del dispositivo che applica i criteri di sicurezza dei dispositivi remoti/locali. Queste norme potrebbero essere hardcoded nell'app o l'app potrebbe recuperarle dinamicamente da un server di terze parti.
L'app è installata sui dispositivi degli utenti. Al momento Android non ha una soluzione di provisioning automatico. Ecco alcuni modi in cui un amministratore di sistema può 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 accade e quando dipende da come viene implementata l'app.
Una volta attivata l'app di amministrazione del dispositivo, gli utenti sono soggetti ai suoi criteri. La conformità a queste norme comporta in genere dei vantaggi, ad esempio l'accesso a sistemi e dati sensibili.

Se gli utenti non attivano l'app di amministrazione del dispositivo, questa rimane sul dispositivo, ma in uno stato inattivo. Gli utenti non saranno soggetti alle sue norme e, di conseguenza, non potranno usufruire dei vantaggi dell'app, ad esempio potrebbero non essere in grado di sincronizzare i dati.

Se un utente non rispetta le norme (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 attivate, viene applicato il criterio più restrittivo. 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 un contesto aziendale, spesso i dispositivi dei dipendenti devono rispettare un insieme rigoroso di criteri che regolano l'utilizzo del dispositivo. L'API Device Administration supporta i criteri elencati nella Tabella 1. Tieni presente che l'API Device Administration al momento supporta solo le password per il blocco schermo:

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, puoi richiedere che i PIN o le password contengano 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 obbligatorie nella password per tutti gli amministratori o per uno in particolare. 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. Introdotta in Android 3.0.
Cifre numeriche minime 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.
Simboli minimi richiesti nella password	Il numero minimo di simboli richiesti nella password per tutti gli amministratori o per uno in particolare. Introdotta 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. Introdotta in Android 3.0.
Timeout della scadenza della password	La data di scadenza della password, espressa come delta in millisecondi dal momento in cui un amministratore del dispositivo imposta il timeout di scadenza. Introdotta in Android 3.0.
Limitazione della cronologia delle 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. Introdotta in Android 3.0.
Numero massimo di tentativi di inserimento della password non riusciti	Specifica il numero di volte in cui un utente può inserire la password sbagliata prima che il dispositivo resetti i dati. L'API Device Administration consente inoltre agli amministratori di eseguire il ripristino dei dati di fabbrica del dispositivo da remoto. In questo modo i dati vengono protetti in caso di smarrimento o furto del dispositivo.
Blocco del tempo di inattività massimo	Imposta il periodo di tempo che deve trascorrere dall'ultima volta che l'utente ha toccato lo schermo o premuto un pulsante prima che il dispositivo blocchi lo schermo. In questo caso, gli utenti devono inserire di nuovo il PIN o le password prima di poter utilizzare i dispositivi e accedere ai dati. Il valore può essere compreso tra 1 e 60 minuti.
Richiedere la crittografia dell'archiviazione	Specifica che l'area di archiviazione deve essere criptata, se il dispositivo lo supporta. Introdotta in Android 3.0.
Disattivazione della fotocamera	Specifica che la videocamera deve essere disattivata. Tieni presente che la disattivazione non deve essere obbligatoriamente definitiva. La videocamera può essere attivata/disattivata dinamicamente in base al contesto, all'ora e così via. Introdotta in Android 4.0.

Altre funzionalità

Oltre a supportare i criteri elencati nella tabella sopra, l'API Device Administration consente di eseguire le seguenti operazioni:

Chiedi all'utente di impostare una nuova password.
Blocca immediatamente il dispositivo.
Cancella i dati del dispositivo (ovvero ripristina le impostazioni di fabbrica predefinite).

App di esempio

Gli esempi utilizzati in questa pagina si basano sull'esempio dell'API Device Administration, inclusa negli esempi SDK (disponibili tramite Android SDK Manager) e situata sul 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 agli utenti un'interfaccia utente che consente loro di attivare l'app di amministrazione del dispositivo. Dopo aver attivato l'app, possono utilizzare i pulsanti dell'interfaccia utente per:

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 password non riusciti che possono verificarsi prima che venga eseguita la 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 lo supporta.
Imposta il tempo massimo di inattività che può trascorrere prima che il dispositivo si blocchi.
Blocca immediatamente il dispositivo.
Resetta i dati del dispositivo (ovvero ripristina 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 Device Administration per scrivere un'app che applichi i criteri di sicurezza dei dispositivi remoti/locali. Questa sezione riassume i passaggi per creare un'app di amministrazione del dispositivo.

Creazione del file manifest

Per utilizzare l'API di amministrazione dei dispositivi, il manifest dell'app deve includere quanto segue:

Una sottoclasse di DeviceAdminReceiver che include quanto segue:
- L'autorizzazione BIND_DEVICE_ADMIN.
- La capacità di rispondere all'intent ACTION_DEVICE_ADMIN_ENABLED, espresso nel manifest come filtro per intent.
Una dichiarazione dei criteri di sicurezza utilizzati nei metadati.

Ecco un estratto del manifest di esempio di 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 fanno riferimento alle risorse stringa che per l'app di esempio si trovano in ApiDemos/res/values/strings.xml. Per ulteriori informazioni sulle risorse, consulta Risorse dell'applicazione.
- 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 di autorizzazione leggibile dall'utente.
- android:description="@string/sample_device_admin_description" fa riferimento alla descrizione leggibile dall'utente dell'autorizzazione. Una descrizione è in genere più lunga e più informativa di un'etichetta.
android:permission="android.permission.BIND_DEVICE_ADMIN" è un'autorizzazione che deve avere una sottoclasse DeviceAdminReceiver per garantire che solo il sistema possa interagire con il destinatario (nessuna app può ricevere questa autorizzazione). 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. Viene impostato sul destinatario quando l'utente attiva l'app di amministrazione del dispositivo. In genere, il codice gestisce questo aspetto in onEnabled(). Per essere supportato, il destinatario deve anche richiedere l'autorizzazione BIND_DEVICE_ADMIN in modo che altre app non possano 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 appropriato, l'app può imporre una norma. 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 di 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>

Quando progetti l'app di amministrazione del dispositivo, non è necessario includere tutti i criteri, ma solo quelli pertinenti per la tua app.

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

Implementazione del codice

L'API Device Administration include le seguenti classi:

DeviceAdminReceiver: Classe di base per l'implementazione di un componente di amministrazione del dispositivo. Questa classe consente di interpretare facilmente le azioni di intent non elaborate inviate dal sistema. L'app di amministrazione del dispositivo deve includere una sottoclasse DeviceAdminReceiver.
DevicePolicyManager: Una classe per la gestione dei criteri applicati su 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 eventi specifici. 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'attivazione dell'app da parte dell'utente. L'utente deve attivare esplicitamente l'app affinché i criteri vengano applicati. 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.

La procedura di attivazione dell'app inizia quando l'utente esegue un'azione che attiva l'intent ACTION_ADD_DEVICE_ADMIN. Nell'app di esempio, questo accade quando l'utente fa clic sulla casella di controllo Attiva amministratore.

Quando l'utente fa clic sulla casella di controllo Attiva amministrazione, la visualizzazione cambia per chiedere 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 Attiva amministrazione. 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 viene 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 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 nell'aggiungere l'amministratore del dispositivo al sistema (o consente loro di rifiutarlo).

Quando l'app deve eseguire un'operazione che dipende dall'attivazione dell'app di amministrazione del dispositivo, conferma che l'app è attiva. A tal fine, utilizza il metodo DevicePolicyManager isAdminActive(). Tieni presente che il metodo DevicePolicyManager isAdminActive() prende un componente 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 applicati su un dispositivo. DevicePolicyManager gestisce i criteri per una o più istanze DeviceAdminReceiver.

Puoi ottenere un handle per DevicePolicyManager come segue:

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:

Impostare i criteri relativi alle password
Impostare il blocco del dispositivo
Eseguire l'eliminazione dei dati

Impostare i criteri per le password

DevicePolicyManager include API per impostare e applicare il criterio per le password dei dispositivi. Nell'API Device Administration, la password si applica solo al 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:

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à della 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 una password contenente almeno sia caratteri numerici che alfabetici (o altri simboli).
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 regolamento richiede un qualche tipo di password, ma non importa quale 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:

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

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. Ecco i metodi per perfezionare i contenuti di una password:

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

Imposta la lunghezza minima della password

Puoi specificare che una password deve avere almeno la lunghezza minima specificata. 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);

Impostare il numero massimo di tentativi di inserimento della password non riusciti

Puoi impostare il numero massimo di tentativi di immissione password non riusciti consentiti prima della cancellazione dei dati del dispositivo (ovvero del ripristino dei dati 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);

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:

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

Limitare la 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 inserire una nuova password 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:

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

Impostare il blocco del dispositivo

Puoi impostare il periodo massimo di inattività dell'utente che può verificarsi prima che il dispositivo si blocchi. 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 chiedere al dispositivo di bloccarsi immediatamente tramite codice:

Kotlin

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

Java

DevicePolicyManager dpm;
dpm.lockNow();

Eseguire l'eliminazione dei dati

Puoi utilizzare 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 resettare il dispositivo è il risultato del verificarsi di determinate condizioni. Ad esempio, puoi utilizzare setMaximumFailedPasswordsForWipe() per indicare che un dispositivo deve essere ripristinato dopo un numero specifico 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() prende come parametro una maschera di bit di opzioni aggiuntive. Al momento il valore deve essere 0.

Disattivazione della fotocamera

A partire da Android 4.0, puoi disattivare la fotocamera. Tieni presente che la disattivazione non deve essere necessariamente permanente. 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 metodosetCameraDisabled(). Ad esempio, questo snippet imposta la fotocamera su attivata o disattivata in base a un'impostazione della 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 dell'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:

Kotlin

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

Java

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

Consulta l'esempio dell'API Device Administration per un esempio completo di come attivare la crittografia dello spazio di archiviazione.

Altri esempi di codice

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