Panoramica dell'amministrazione del dispositivo

Ritiro dell'amministratore del dispositivo. A partire da Android 9 (livello API 28), alcuni criteri amministrativi verranno contrassegnati come deprecati quando richiamati da un amministratore del dispositivo. Ti consigliamo di iniziare subito a prepararti a questo cambiamento. Per scoprire di più e visualizzare le opzioni di migrazione, leggi l'articolo Ritiro dell'amministrazione 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 consentono di creare app incentrate sulla sicurezza, utili in contesti aziendali, in cui i professionisti IT richiedono un controllo avanzato 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, incluse password alfanumeriche o PIN numerici, su tutti i dispositivi. Gli amministratori possono inoltre cancellare da remoto i dati (ripristinare le impostazioni di fabbrica) dei dispositivi smarriti o rubati. Gli utenti di Exchange possono sincronizzare i dati di email e calendario.

Questo documento è rivolto agli sviluppatori che desiderano sviluppare soluzioni aziendali per i dispositivi basati su 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 controller dei criteri di lavoro per le implementazioni di Android for Work, consulta Creazione di 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). Nella modalità Utente di sistema senza testa, l'utente di sistema è un utente in background e si basa su utenti in primo piano aggiuntivi per l'interazione dell'utente finale. Android 14 introduce anche una modalità affiliato del proprietario del dispositivo headless, che aggiunge un proprietario di 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 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 informazioni dettagliate, visita la pagina addUserRestriction.

I produttori di dispositivi Android possono fare riferimento alle linee guida pubblicate su source.android.com.

Panoramica dell'API Device Administration

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

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

Come funziona?

Puoi utilizzare l'API 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. Questi criteri possono essere impostati come hardcoded nell'app oppure l'app potrebbe recuperare dinamicamente i criteri da un server di terze parti.
• L'app viene installata sui dispositivi degli utenti. Android al momento non dispone di una soluzione di provisioning automatizzato. Ecco alcuni modi in cui un amministratore di sistema può distribuire l'app agli utenti:
  • Google Play.
  • Attivazione dell'installazione da un altro store.
  • Distribuzione dell'app tramite altri mezzi, ad esempio email o siti web.
• Il sistema chiede all'utente di attivare l'app di amministrazione del dispositivo. Come e quando ciò avviene dipendono da come l'app è implementata.
• Una volta abilitata l'app di amministrazione del dispositivo, gli utenti sono soggetti ai relativi criteri. Il rispetto di questi criteri in genere offre vantaggi come l'accesso a sistemi e dati sensibili.

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

Se un utente non rispetta i criteri (ad esempio, se un utente imposta una password che viola le linee guida), spetta all'app decidere come gestire il problema. Tuttavia, in genere ciò impedisce all'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 attualmente non consente il provisioning parziale. In altre parole, se un dispositivo (ad esempio quello legacy) non supporta tutti i criteri dichiarati, non è possibile in alcun modo connettersi.

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 annullare la registrazione dell'app come amministratore.

Norme

In un ambiente aziendale, i dispositivi dei dipendenti spesso devono rispettare un insieme rigoroso di criteri che ne regolano l'utilizzo. L'API di amministrazione dei dispositivi supporta i criteri elencati nella tabella 1. Tieni presente che l'API Device Administration attualmente supporta solo le password per il blocco schermo:

Tabella 1. Criteri supportati dall'API Device Administration.

Altre funzionalità

Oltre a supportare i criteri elencati nella tabella precedente, l'API di amministrazione dei dispositivi consente di:

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

App di esempio

Gli esempi utilizzati in questa pagina si basano sull'esempio dell'API di amministrazione dei dispositivi, che è incluso negli esempi dell'SDK (disponibili tramite Android SDK Manager) e si trova nel tuo 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 che hanno attivato l'app, possono utilizzare i pulsanti nell'interfaccia utente per effettuare le seguenti operazioni:

• Imposta la qualità della password.
• Specifica i requisiti per la password dell'utente, come 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 della password non riusciti che possono verificarsi prima che i dati del dispositivo vengano cancellati (ossia il ripristino delle impostazioni di fabbrica).
• Imposta per quanto tempo la password scadrà.
• Imposta la lunghezza della cronologia delle password (lunghezza si riferisce al numero di password precedenti memorizzate nella cronologia). In questo modo gli utenti non possono riutilizzare una delle ultime n password che hanno usato in precedenza.
• Specifica che l'area di archiviazione deve essere criptata, se il dispositivo la supporta.
• Imposta il tempo massimo di inattività che può trascorrere prima che il dispositivo si blocchi.
• Attiva immediatamente il blocco del dispositivo.
• Cancellare i dati del dispositivo (ripristinare le impostazioni di fabbrica).
• Disattiva la fotocamera.

Figura 1. Screenshot dell'app di esempio

Sviluppo di un'app di amministrazione dei dispositivi

Gli amministratori di sistema possono utilizzare l'API di amministrazione dispositivi 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 dei dispositivi.

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 si riferiscono alle risorse stringa che per l'app di esempio risiedono in ApiDemos/res/values/strings.xml. Per ulteriori informazioni sulle risorse, vedi 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 dell'autorizzazione. Una descrizione è in genere più lunga e informativa rispetto a 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 è possibile impedire ad altre app di utilizzare in modo illecito 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. Viene impostata sul destinatario quando l'utente abilita l'app di amministrazione del dispositivo. Il tuo codice solitamente gestisce questa operazione in onEnabled(). Per essere supportato, il destinatario deve inoltre richiedere l'autorizzazione BIND_DEVICE_ADMIN, in modo che altre app non possano utilizzarlo in modo illecito.
• Quando un utente attiva l'app di amministrazione del dispositivo, questo concede al destinatario l'autorizzazione a eseguire azioni in risposta alla trasmissione di particolari 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 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 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 analizzate 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 la tua app di amministrazione dei dispositivi, non devi includere tutti i criteri, ma solo quelli pertinenti per la tua app.

Implementazione del codice

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

DeviceAdminReceiver

Classe di base per l'implementazione di un componente di amministrazione del dispositivo. Questa classe è utile per interpretare le azioni degli intent non elaborate inviate dal sistema. L'app Amministrazione 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 amministrazione del dispositivo.

Questi corsi 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 del dispositivo.

Creazione di sottoclassi DeviceAdminReceiver

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

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

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, che deve abilitare 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 Abilita amministrazione.

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

Figura 2. App di esempio: attivazione dell'app

Di seguito è riportato il codice che viene eseguito quando l'utente fa clic sulla casella di controllo Abilita amministratore. Questo ha l'effetto di attivare il callback onPreferenceChange(). Questo callback viene attivato quando il valore di questo Preference è stato modificato dall'utente e sta per essere impostato e/o mantenuto. Se l'utente 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 è 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 rifiutarlo).

Quando l'app deve eseguire un'operazione subordinata all'abilitazione dell'app di amministrazione del dispositivo, l'app conferma che è attiva. A questo scopo, utilizza il metodo DevicePolicyManager isAdminActive(). Tieni presente che il metodo DevicePolicyManagerisAdminActive() utilizza 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 ai dispositivi. DevicePolicyManager gestisce i criteri per una o più istanze DeviceAdminReceiver.

Per ottenere un handle per DevicePolicyManager:

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:

• Configurare i criteri relativi alle password
• Impostare il blocco del dispositivo
• Eseguire la cancellazione dei dati

Imposta criteri per le password

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

Imposta una password per il dispositivo

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

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

Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
startActivity(intent);

Impostare la qualità delle password

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

PASSWORD_QUALITY_ALPHABETIC

L'utente deve inserire una password contenente almeno caratteri alfabetici (o un altro simbolo).

PASSWORD_QUALITY_ALPHANUMERIC

L'utente deve inserire una password contenente almeno entrambi caratteri numerici e 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 qualche tipo di password, ma non gli importa quale sia.

PASSWORD_QUALITY_UNSPECIFIED

Il criterio non ha requisiti per la password.

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

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

Imposta requisiti per i contenuti delle password

A partire da Android 3.0, la classe DevicePolicyManager include metodi che consentono di ottimizzare i contenuti della password. Ad esempio, puoi impostare un criterio per stabilire che le password debbano contenere almeno n lettere maiuscole. Ecco i metodi per ottimizzare 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 abbia almeno la lunghezza minima specificata. Ecco alcuni esempi:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwLength: Int = ...
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwLength;
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);

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

Puoi impostare il numero massimo consentito di tentativi di inserimento della password non riusciti prima della cancellazione dei dati del dispositivo (ovvero, ripristinando le impostazioni di fabbrica). Ecco alcuni esempi:

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

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. Ecco alcuni esempi:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwExpiration: Long = ...
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
long pwExpiration;
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);

Limita password in base alla cronologia

A partire da Android 3.0, puoi usare il metodo setPasswordHistoryLength() per limitare la capacità 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 corrispondente 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 obbliga gli utenti ad aggiornare le proprie password una volta trascorso 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);

Imposta il blocco del dispositivo

Puoi impostare il periodo massimo di inattività dell'utente che può verificarsi prima del blocco del dispositivo. Ecco alcuni esempi:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val timeMs: Long = 1000L * timeout.text.toString().toLong()
...
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
long timeMs = 1000L*Long.parseLong(timeout.getText().toString());
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);

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

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

DevicePolicyManager dpm;
dpm.lockNow();

Esegui la cancellazione dei dati

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

Puoi cancellare i dati nel seguente modo:

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

DevicePolicyManager dpm;
dpm.wipeData(0);

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

Disattiva videocamera

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

Puoi controllare se la videocamera viene disattivata utilizzando il metodo setCameraDisabled(). Ad esempio, questo snippet consente di attivare o disattivare la videocamera in base all'impostazione di una 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 dello spazio di archiviazione

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

Ecco alcuni esempi:

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

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

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

Altri esempi di codice

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