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 subito a prepararti 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 Android integrata 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à fornite dall'API di amministrazione dei dispositivi per garantire una maggiore sicurezza ai 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 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 del sistema viene eseguito in background), all'utente o agli utenti in primo piano vengono applicati solo i criteri relativi ai dispositivi con ambito globale (criteri applicabili a tutti gli utenti). Per maggiori dettagli, consulta addUserRestriction.

Nota: in Android 14 (livello API 34), un'applicazione DPC può essere impostata come proprietario del dispositivo su un dispositivo configurato come dispositivo in modalità utente di sistema headless solo se supporta la modalità affiliato. Per maggiori dettagli, consulta HEADLESS_DEVICE_OWNER_MODE_AFFILIATED.

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?

Puoi utilizzare l'API Device Administration per scrivere le app di amministrazione del dispositivo che gli utenti installano sui loro dispositivi. L'app di amministrazione del dispositivo applica i criteri desiderati. 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 dal modo in cui l'app è implementata.
• 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 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 un dispositivo precedente) non supporta tutti i criteri dichiarati, non è possibile consentire la connessione del dispositivo.

Se un dispositivo contiene più app di amministrazione abilitate, viene applicato il criterio più rigido. Non è possibile scegliere come target un'app di amministrazione specifica.

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. 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, 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. Introdotto 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 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. 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 specifico. Introdotta in Android 3.0.
Timeout della scadenza della 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.
Limitazione della cronologia delle password	Questo criterio impedisce agli utenti di riutilizzare le ultime n password univoche. Questo criterio viene in genere utilizzato insieme a setPasswordExpirationTimeout(), che obbliga gli utenti ad aggiornare le proprie password una volta trascorso 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 ripristinare da remoto le impostazioni di fabbrica del dispositivo. 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 la password prima di poter utilizzare i propri dispositivi e 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 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 precedente, l'API Device Administration consente di eseguire le seguenti operazioni:

• 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'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 ai criteri specificati, 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 (lunghezza 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 usato 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.
• Attiva immediatamente il blocco del dispositivo.
• Resetta i dati del dispositivo (ovvero ripristina 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 Device Administration per scrivere un'app che applichi i criteri di sicurezza dei dispositivi remoti/locali. Questa sezione riassume i passaggi necessari per creare un'app di amministrazione del dispositivo.

Creazione del manifest

Per utilizzare l'API Device Administration, il file 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 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 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" fa riferimento all'etichetta leggibile dall'utente per l'autorizzazione.
  • 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 (questa autorizzazione non può essere concessa 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 richiedere l'autorizzazione BIND_DEVICE_ADMIN in modo che altre app non possano abusarne.
• Quando un utente attiva l'app di amministrazione del dispositivo, concede al destinatario l'autorizzazione a 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 file manifest cambia, l'amministratore del dispositivo viene disattivato quando gli utenti aggiornano l'app. Per scoprire 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 è utile per interpretare le azioni degli intent non elaborate inviate dal sistema. L'app di amministrazione del dispositivo deve includere una sottoclasse DeviceAdminReceiver.

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 la sottoclasse DeviceAdminReceiver. 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:

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 abilitare l'app, questa sarà comunque presente sul dispositivo, ma i relativi criteri non verranno applicati forzatamente e l'utente non usufruirà 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 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 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 DevicePolicyManagerisAdminActive() utilizza 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:

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

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:

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

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

Imposta timeout scadenza 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 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 il metodosetPasswordHistoryLength() per limitare la possibilità degli utenti di riutilizzare le vecchie password. Questo metodo utilizza un parametro length, che specifica quante vecchie password 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 usare il metodo DevicePolicyManager wipeData() per ripristinare le impostazioni di fabbrica del dispositivo. Ciò è utile in caso di furto o smarrimento del dispositivo. 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() utilizza 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 metodo setCameraDisabled(). Ad esempio, questo snippet imposta la fotocamera in modo che venga 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 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:

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.