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 vengono richiamati da un amministratore del dispositivo. Ti consigliamo di iniziare a prepararti ora per questo cambiamento. Per saperne di più e visualizzare le opzioni di migrazione, leggi Ritiro dell'amministratore dei dispositivi.

Android include il supporto per le app aziendali offrendo l'API Android Device Administration. L'API Device Administration fornisce funzionalità di amministrazione dei dispositivi a livello di sistema. Queste API ti consentono di creare app attente alla sicurezza utili nelle impostazioni 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 criteri per le password, tra cui password alfanumeriche o PIN numerici, su tutti i dispositivi. Gli amministratori possono anche cancellare da remoto (ovvero ripristinare le impostazioni predefinite di fabbrica) i dati dei cellulari smarriti o rubati. Gli utenti di Exchange possono sincronizzare i dati di email e calendario.

Questo documento è destinato agli sviluppatori che vogliono sviluppare soluzioni aziendali per dispositivi Android. Vengono illustrate le varie funzionalità fornite dall'API Device Administration per garantire una maggiore sicurezza per i dispositivi dei dipendenti basati su Android.

Nota: per informazioni sulla creazione di un controller dei criteri di lavoro per le implementazioni di Android for Work, vedi 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 altri utenti in primo piano per l'interazione con l'utente finale. Android 14 introduce anche una modalità proprietario del dispositivo headless affiliato, che aggiunge un proprietario del profilo a tutti gli utenti affiliati diversi dall'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), solo i criteri del dispositivo con ambito globale (criteri applicabili a tutti gli utenti) vengono applicati all'utente o agli utenti in primo piano. Per i 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 dei tipi di app che potrebbero utilizzare l'API Device Administration:

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

Come funziona?

Utilizzi l'API Device Administration per scrivere app di amministrazione dei dispositivi che gli utenti installano sui propri 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 criteri di sicurezza del dispositivo remoti/locali. Queste norme potrebbero essere codificate nell'app oppure l'app potrebbe recuperarle dinamicamente da un server di terze parti.
• L'app è installata sui dispositivi degli utenti. Android al momento non dispone di una soluzione di provisioning automatizzata. Alcuni modi in cui un amministratore di sistema potrebbe distribuire l'app agli utenti sono i seguenti:
  • Google Play.
  • Attivazione dell'installazione da un altro negozio.
  • Distribuire l'app con altri mezzi, ad esempio email o siti web.
• Il sistema chiede all'utente di attivare l'app di amministrazione del dispositivo. Il modo e il momento in cui ciò avviene dipende da come viene implementata l'app.
• Una volta che gli utenti attivano l'app di amministrazione del dispositivo, sono soggetti ai relativi criteri. Il rispetto di queste norme in genere comporta vantaggi, come l'accesso a sistemi e dati sensibili.

Se gli utenti non attivano l'app di amministrazione dispositivo, questa rimane sul dispositivo, ma in stato inattivo. Gli utenti non saranno soggetti alle sue norme e, viceversa, non riceveranno nessuno 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), spetta all'app decidere come gestire la situazione. Tuttavia, in genere ciò comporta l'impossibilità per l'utente di 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. L'API Device Administration non consente attualmente il provisioning parziale. In altre parole, se un dispositivo (ad esempio, un dispositivo legacy) non supporta tutti i criteri indicati, non è possibile consentire la connessione del dispositivo.

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

Per disinstallare un'app di amministrazione dispositivo esistente, gli utenti devono prima annullarne la registrazione come amministratore.

Norme

In un ambiente 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 attualmente supporta solo le password per il blocco schermo:

Tabella 1. Norme supportate dall'API Device Administration.

Altre funzionalità

Oltre a supportare i criteri elencati nella tabella precedente, l'API Device Administration ti consente di:

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

App di esempio

Gli esempi utilizzati in questa pagina si basano sull'esempio dell'API Device Administration, incluso negli esempi dell'SDK (disponibili tramite Android SDK Manager) e presente 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 agli utenti un'interfaccia utente che consente loro di attivare l'app di amministrazione del dispositivo. Una volta attivata l'app, possono utilizzare i pulsanti dell'interfaccia utente per eseguire 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 ai criteri specificati, il sistema restituisce un errore.
• Imposta il numero di tentativi di inserimento password non riusciti che possono verificarsi prima della cancellazione dei dati del dispositivo (ovvero il ripristino delle impostazioni di fabbrica).
• Imposta il periodo di tempo a partire da ora in cui la password scadrà.
• 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 utilizzate in precedenza.
• Specifica che l'area di archiviazione deve essere criptata, se il dispositivo lo supporta.
• Imposta la quantità massima di tempo di inattività che può trascorrere prima che il dispositivo si blocchi.
• Bloccare immediatamente il dispositivo.
• Cancella i dati del dispositivo (ovvero ripristina le impostazioni di fabbrica).
• Disattiva la videocamera.

Figura 1. Screenshot dell'app di esempio

Sviluppare un'app di amministrazione del dispositivo

Gli amministratori di sistema possono utilizzare l'API Device Administration per scrivere un'app che applica l'applicazione dei criteri di sicurezza dei dispositivi remoti/locali. Questa sezione riepiloga i passaggi per creare un'app di amministrazione dispositivi.

Creazione del manifest

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

• Una sottoclasse di DeviceAdminReceiver che include quanto segue:
  • L'autorizzazione BIND_DEVICE_ADMIN.
  • La possibilità di rispondere all'intent ACTION_DEVICE_ADMIN_ENABLED, espresso nel manifest come filtro per intent.
• Una dichiarazione delle norme di sicurezza utilizzate nei metadati.

Ecco un estratto del manifest di esempio di amministrazione del dispositivo:

<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 saperne di più sulle risorse, vedi Risorse dell'applicazione.
  • android:label="@string/activity_sample_device_admin" si riferisce 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 alla descrizione dell'autorizzazione leggibile dall'utente. Una descrizione è in genere più lunga e più informativa di un'etichetta.
• android:permission="android.permission.BIND_DEVICE_ADMIN" è un'autorizzazione che una sottoclasse DeviceAdminReceiver deve avere per garantire che solo il sistema possa interagire con il ricevitore (a nessuna app può essere concessa questa autorizzazione). In questo modo, le altre app non possono utilizzare in modo improprio l'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 dispositivo. Il tuo codice in genere gestisce questa operazione 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 dispositivo, il destinatario ha l'autorizzazione a eseguire azioni in risposta alla trasmissione di determinati eventi di sistema. Quando si verifica un evento adatto, l'app può imporre una norma. Ad esempio, se l'utente tenta di impostare una nuova password che non soddisfa i requisiti dei criteri, l'app può chiedere all'utente 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ù, vedi <receiver>.
• android:resource="@xml/device_admin_sample" dichiara le norme di sicurezza utilizzate nei metadati. I metadati forniscono informazioni aggiuntive specifiche dell'amministratore del dispositivo, analizzate dalla classe DeviceAdminInfo. Di seguito sono riportati 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 devi includere tutti i criteri, ma solo quelli pertinenti per la tua app.

Implementazione del codice

L'API Device Administration include le seguenti classi:

DeviceAdminReceiver

Classe base per l'implementazione di un componente di amministrazione del dispositivo. Questa classe offre una comodità per interpretare le azioni di intent grezze inviate dal sistema. L'app di amministrazione del dispositivo deve includere una sottoclasse DeviceAdminReceiver.

DevicePolicyManager

Una classe per la gestione dei criteri applicati a un dispositivo. La maggior parte dei client di questa classe deve aver pubblicato un DeviceAdminReceiver che l'utente ha attualmente attivato. DevicePolicyManager gestisce i criteri per una o più istanze di DeviceAdminReceiver

DeviceAdminInfo

Questa classe viene utilizzata per specificare i metadati per un componente di amministrazione del dispositivo.

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

Creazione di sottoclassi di DeviceAdminReceiver

Per creare un'app di amministrazione del dispositivo, devi creare una sottoclasse di DeviceAdminReceiver. La classe DeviceAdminReceiver è costituita da una serie di callback che vengono attivati quando si verificano eventi particolari.

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

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'attivazione dell'app da parte dell'utente. L'utente deve attivare esplicitamente l'app per l'applicazione dei criteri. Se l'utente sceglie di non attivare l'app, questa sarà comunque presente 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 si verifica quando l'utente fa clic sulla casella di controllo Attiva amministratore.

Quando l'utente fa clic sulla casella di controllo Attiva amministratore, 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 amministratore. In questo modo viene attivato il callback onPreferenceChange(). Questo callback viene richiamato quando il valore di Preference è stato modificato dall'utente e sta per essere impostato e/o reso persistente. Se l'utente sta attivando l'app, il display cambia per chiedere all'utente di attivare l'app per amministratori del dispositivo, come mostrato nella figura 2. In caso contrario, l'app di amministrazione del dispositivo viene disattivata.

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 nell'aggiunta dell'amministratore del dispositivo al sistema (o consente loro di rifiutarla).

Quando l'app deve eseguire un'operazione che dipende dall'attivazione dell'app di amministrazione dispositivo, conferma che l'app è attiva. A questo scopo, utilizza il metodo DevicePolicyManager isAdminActive(). Tieni presente che il metodo DevicePolicyManager isAdminActive() accetta un componente DeviceAdminReceiver come argomento:

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 a un dispositivo. DevicePolicyManager gestisce i criteri per una o più istanze di DeviceAdminReceiver.

Ottieni un handle per DevicePolicyManager nel seguente modo:

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:

• Impostare criteri per le password
• Impostare il blocco dispositivo
• Eseguire la cancellazione dei dati

Impostare criteri per le password

DevicePolicyManager include API per impostare e applicare il criterio per la password del dispositivo. 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:

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

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 numerica e un simbolo speciale.

PASSWORD_QUALITY_SOMETHING

Il criterio richiede un tipo di password, ma non importa quale.

PASSWORD_QUALITY_UNSPECIFIED

Le norme non prevedono requisiti per la password.

Ad esempio, ecco come impostare il criterio per le password in modo da richiedere una password alfanumerica:

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 per i contenuti delle password

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

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

Impostare la lunghezza minima della password

Puoi specificare che una password deve avere almeno la lunghezza minima specificata. Ad esempio:

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

Impostare il numero massimo di tentativi password non riusciti

Puoi impostare il numero massimo di tentativi di immissione password non riusciti consentiti prima della cancellazione dei dati del dispositivo (ovvero il ripristino dei dati di fabbrica). Ad esempio:

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

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

Limitare la password in base alla cronologia

A partire da Android 3.0, puoi utilizzare il metodo setPasswordHistoryLength() per limitare la possibilità degli utenti di riutilizzare le vecchie password. Questo metodo accetta un parametro length che specifica il numero di password precedenti 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. Questa norma viene in genere utilizzata in combinazione con 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 una delle ultime 5 password:

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

Impostare il blocco dispositivo

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

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 indicare al dispositivo di bloccarsi immediatamente a livello di programmazione:

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

DevicePolicyManager dpm;
dpm.lockNow();

Esegui la cancellazione dei dati

Puoi utilizzare il metodo DevicePolicyManager wipeData() per ripristinare le impostazioni di fabbrica del dispositivo. Questa operazione è utile se il dispositivo viene smarrito o rubato. Spesso la decisione di cancellare i dati del dispositivo è il risultato del verificarsi di determinate condizioni. Ad esempio, puoi utilizzare setMaximumFailedPasswordsForWipe() per indicare che i dati di un dispositivo devono essere cancellati dopo un determinato numero di tentativi di inserimento password non riusciti.

Per cancellare i dati:

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

DevicePolicyManager dpm;
dpm.wipeData(0);

Il metodo wipeData() accetta 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 non deve essere una disattivazione permanente. La videocamera può essere attivata/disattivata dinamicamente in base al contesto, all'ora e così via.

Puoi controllare se la videocamera è disattivata utilizzando il metodo setCameraDisabled(). Ad esempio, questo snippet imposta l'attivazione o la disattivazione della videocamera in base a un'impostazione della casella di controllo:

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

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

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

Consulta l'esempio di 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.