Ritiro di Amministrazione dispositivo. A partire da Android 9 (livello API 28), alcuni criteri di amministrazione verranno contrassegnati come obsoleti quando invocati da un amministratore dispositivo. Ti consigliamo di iniziare a prepararti subito a questo cambiamento. Per saperne di più e visualizzare le opzioni di migrazione, leggi ritiro dell'amministratore dispositivo.
Android include il supporto per le app aziendali offrendo l'API Android Device Administration. L'API Device Administration fornisce funzionalità di gestione del dispositivo a livello di sistema. Queste API ti consentono di creare app attente alla sicurezza utili in ambienti aziendali, in cui i professionisti IT richiedono un controllo completo sui dispositivi dei dipendenti. Ad esempio, l'app Email integrata di Android ha sfruttato queste API per migliorare il supporto di Exchange. Tramite l'app Email, gli amministratori di Exchange possono applicare i criteri per le password, incluse le password alfanumeriche o i PIN numerici, su tutti i dispositivi. Gli amministratori possono anche cancellare da remoto (ovvero ripristinare le impostazioni predefinite di fabbrica) gli smartphone smarriti o rubati. Gli utenti di Exchange possono sincronizzare i propri dati di email e calendario.
Questo documento è rivolto agli sviluppatori che vogliono sviluppare soluzioni aziendali per dispositivi Android. Vengono descritte le varie funzionalità offerte dall'API Device Administration per garantire una maggiore sicurezza per i dispositivi dei dipendenti basati su Android.
Nota Per informazioni sulla creazione di un Work Policy Controller per i deployment di Android for Work, consulta Creare un controller dei criteri dei dispositivi.
Modalità Proprietario del dispositivo headless
Android 14 (livello API 34) introduce la modalità utente di sistema headless (dispositivi in cui UserManager.isHeadlessSystemUserMode restituisce true). In questa modalità, l'utente di sistema è un utente in background e si basa su utenti in primo piano aggiuntivi per l'interazione con l'utente finale. Android 14 introduce anche una
modalità affiliazione del proprietario del dispositivo headless,
che aggiunge un proprietario del profilo a tutti gli
utenti affiliati
tranne che all'utente di sistema su cui è impostato il proprietario del dispositivo.
Nei dispositivi configurati con un utente di sistema headless (in cui l'utente di sistema viene eseguito in background), all'utente o agli utenti in primo piano vengono applicati solo i criteri del dispositivo di ambito globale (applicabili a tutti gli utenti). Per maggiori dettagli, consulta addUserRestriction.
I produttori di dispositivi Android possono fare riferimento alle linee guida pubblicate su source.android.com.
Panoramica dell'API di amministrazione dei dispositivi
Di seguito sono riportati alcuni esempi di tipi di app che potrebbero utilizzare l'API Device Administration:
- Client di posta.
- App di sicurezza che eseguono la cancellazione dei dati da remoto.
- App e servizi di gestione dei dispositivi.
Come funziona?
L'API Device Administration viene utilizzata per scrivere app di amministrazione dei dispositivi che gli utenti installano sui propri dispositivi. L'app di amministrazione del dispositivo applica i criteri 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. Il rispetto di 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 attivate, viene applicato il criterio più restrittivo. Non è possibile scegliere come target una determinata app di amministrazione.
Per disinstallare un'app di amministrazione del dispositivo esistente, gli utenti devono prima annullarne la registrazione come amministratore.
Norme
In un contesto aziendale, capita spesso che i dispositivi dei dipendenti debbano rispettare un insieme rigoroso di criteri che regolano l'utilizzo del dispositivo. L'API Device Administration supporta i criteri elencati nella Tabella 1. Tieni presente che l'API Device Administration al momento supporta solo le password per il blocco schermo:
Tabella 1. Norme supportate dall'API Device Administration.
| Norme | Descrizione |
|---|---|
| Password attivata | Richiede che i dispositivi chiedano PIN o password. |
| Lunghezza minima della password | Imposta il numero di caratteri richiesto per la password. Ad esempio, puoi richiedere che i PIN o le password contengano almeno sei caratteri. |
| Password alfanumerica obbligatoria | Richiede che le password abbiano una combinazione di lettere e numeri. Possono includere caratteri simbolici. |
| È richiesta una password complessa | Le password devono contenere almeno una lettera, una cifra numerica e un simbolo speciale. Introdotta in Android 3.0. |
| Numero minimo di lettere richieste nella password | Il numero minimo di lettere obbligatorie nella password per tutti gli amministratori o per uno in particolare. Introdotta in Android 3.0. |
| Numero minimo di lettere minuscole richieste nella password | Il numero minimo di lettere minuscole obbligatorie nella password per tutti gli amministratori o per uno specifico. Introdotta in Android 3.0. |
| Numero minimo di caratteri non alfabetici richiesti nella password | Il numero minimo di caratteri diversi dalle lettere richiesto nella password per tutti gli amministratori o per uno specifico. Introdotta in Android 3.0. |
| Digit 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 | La data di scadenza della password, espressa come delta in millisecondi dal momento in cui un amministratore del dispositivo imposta il timeout di scadenza. Introdotta in Android 3.0. |
| Limitazione della cronologia delle password | Questo criterio impedisce agli utenti di riutilizzare le ultime n password univoche.
Questo criterio viene in genere utilizzato in combinazione con
setPasswordExpirationTimeout(), che obbliga
gli utenti ad aggiornare le proprie password dopo un determinato periodo di tempo.
Introdotta in Android 3.0. |
| Numero massimo di tentativi di inserimento della password non riusciti | Specifica il numero di volte in cui un utente può inserire la password sbagliata prima che il dispositivo resetti i dati. L'API Device Administration consente inoltre agli amministratori di eseguire il ripristino dei dati di fabbrica del dispositivo da remoto. In questo modo i dati vengono protetti in caso di smarrimento o furto del dispositivo. |
| Blocco del tempo di inattività massimo | Imposta il periodo di tempo che deve trascorrere dall'ultima volta che l'utente ha toccato lo schermo o premuto un pulsante prima che il dispositivo blocchi lo schermo. In questo caso, gli utenti devono inserire di nuovo il PIN o le password prima di poter utilizzare i dispositivi e accedere ai dati. Il valore può essere compreso tra 1 e 60 minuti. |
| Richiedere la crittografia dell'archiviazione | Specifica che l'area di archiviazione deve essere criptata, se il dispositivo lo supporta. Introdotta in Android 3.0. |
| Disattivazione della fotocamera | Specifica che la videocamera deve essere disattivata. Tieni presente che la disattivazione non deve essere obbligatoriamente permanente. La videocamera può essere attivata/disattivata dinamicamente in base al contesto, all'ora e così via. Introdotta in Android 4.0. |
Altre funzionalità
Oltre a supportare i criteri elencati nella tabella sopra, l'API Device Administration consente di eseguire le seguenti operazioni:
- Chiedi all'utente di impostare una nuova password.
- Blocca immediatamente il dispositivo.
- Resetta i dati del dispositivo (ovvero ripristina i dati di fabbrica predefiniti).
App di esempio
Gli esempi utilizzati in questa pagina si basano sul sample dell'API Device Administration, incluso nei sample dell'SDK (disponibili tramite Android SDK Manager) e che si trova sul sistema come <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java.
L'app di esempio offre una demo delle funzionalità di amministrazione del dispositivo. Presenta agli utenti un'interfaccia utente che consente loro di attivare l'app di amministrazione del dispositivo. Dopo aver attivato l'app, possono utilizzare i pulsanti dell'interfaccia utente per:
- Imposta la qualità della password.
- Specifica i requisiti per la password dell'utente, ad esempio la lunghezza minima, il numero minimo di caratteri numerici che deve contenere e così via.
- Imposta la password. Se la password non è conforme alle norme specificate, il sistema restituisce un errore.
- Imposta il numero di tentativi di inserimento password non riusciti che possono verificarsi prima che i dati del dispositivo vengano cancellati (ovvero prima che vengano ripristinate le impostazioni di fabbrica).
- Imposta il tempo che deve trascorrere prima della scadenza della password.
- Imposta la lunghezza della cronologia delle password (length si riferisce al numero di password precedenti memorizzate nella cronologia). In questo modo gli utenti non possono riutilizzare una delle ultime n password che hanno utilizzato in precedenza.
- Specifica che l'area di archiviazione deve essere criptata, se il dispositivo lo supporta.
- Imposta il tempo massimo di inattività che può trascorrere prima che il dispositivo si blocchi.
- Blocca immediatamente il dispositivo.
- Resetta i dati del dispositivo (ovvero ripristina le impostazioni di fabbrica).
- Disattivare la fotocamera.
Figura 1. Screenshot dell'app di esempio
Sviluppo di un'app di amministrazione del dispositivo
Gli amministratori di sistema possono utilizzare l'API Device Administration per scrivere un'app che applichi i criteri di sicurezza dei dispositivi remoti/locali. Questa sezione riassume i passaggi necessari per creare un'app di amministrazione del dispositivo.
Creazione del manifest
Per utilizzare l'API di amministrazione dei dispositivi, il manifest dell'app deve includere quanto segue:
- Una sottoclasse di
DeviceAdminReceiverche 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.
- L'autorizzazione
- Una dichiarazione dei criteri di sicurezza utilizzati nei metadati.
Ecco un estratto del manifest di esempio di amministrazione dei dispositivi:
<activity android:name=".app.DeviceAdminSample"
android:label="@string/activity_sample_device_admin">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.SAMPLE_CODE" />
</intent-filter>
</activity>
<receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver"
android:label="@string/sample_device_admin"
android:description="@string/sample_device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN">
<meta-data android:name="android.app.device_admin"
android:resource="@xml/device_admin_sample" />
<intent-filter>
<action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
</intent-filter>
</receiver>
Tieni presente che:
- I seguenti attributi fanno riferimento alle risorse stringa che per l'app di esempio si trovano in
ApiDemos/res/values/strings.xml. Per ulteriori informazioni sulle risorse, consulta Risorse dell'applicazione.android:label="@string/activity_sample_device_admin"fa riferimento all'etichetta leggibile dall'utente per l'attività.android:label="@string/sample_device_admin"si riferisce all'etichetta di autorizzazione leggibile dall'utente.android:description="@string/sample_device_admin_description"fa riferimento alla descrizione leggibile dall'utente dell'autorizzazione. Una descrizione è in genere più lunga e più informativa di un'etichetta.
android:permission="android.permission.BIND_DEVICE_ADMIN"è un'autorizzazione che deve avere una sottoclasseDeviceAdminReceiverper garantire che solo il sistema possa interagire con il destinatario (nessuna app può ricevere questa autorizzazione). In questo modo, altre app non potranno abusare della tua app di amministrazione del dispositivo.android.app.action.DEVICE_ADMIN_ENABLEDè l'azione principale che una sottoclasseDeviceAdminReceiverdeve 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 inonEnabled(). Per essere supportato, il destinatario deve anche richiedere l'autorizzazioneBIND_DEVICE_ADMINin 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 appropriato, l'app può imporre una norma. Ad esempio, se l'utente tenta di impostare una nuova password che non soddisfa i requisiti previsti dalle norme, l'app può chiedergli di scegliere una password diversa che soddisfi i requisiti.
- Evita di modificare il nome del destinatario dopo aver pubblicato l'app. Se il nome nel manifest cambia, l'amministrazione del dispositivo viene disattivata quando gli utenti aggiornano l'app. Per saperne di più, consulta
<receiver>. android:resource="@xml/device_admin_sample"dichiara i criteri di sicurezza utilizzati nei metadati. I metadati forniscono informazioni aggiuntive specifiche per l'amministratore del dispositivo, come analizzato dalla classeDeviceAdminInfo. Ecco i contenuti didevice_admin_sample.xml:
<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
<uses-policies>
<limit-password />
<watch-login />
<reset-password />
<force-lock />
<wipe-data />
<expire-password />
<encrypted-storage />
<disable-camera />
</uses-policies>
</device-admin>
Quando progetti l'app di amministrazione del dispositivo, non è necessario includere tutti i criteri, ma solo quelli pertinenti per la tua app.
Per ulteriori informazioni sul file manifest, consulta la Guida per gli sviluppatori Android.Implementazione del codice
L'API Device Administration include le seguenti classi:
DeviceAdminReceiver- Classe di base per l'implementazione di un componente di amministrazione del dispositivo. Questa classe consente di interpretare facilmente le azioni di intent non elaborate inviate dal sistema. L'app di amministrazione del dispositivo deve includere una sottoclasse
DeviceAdminReceiver. DevicePolicyManager- Una classe per la gestione dei criteri applicati su un dispositivo. La maggior parte dei client di questa classe deve aver pubblicato un
DeviceAdminReceiverattualmente abilitato dall'utente.DevicePolicyManagergestisce i criteri per una o più istanzeDeviceAdminReceiver DeviceAdminInfo- Questa classe viene utilizzata per specificare i metadati per un componente di amministratore del dispositivo.
Queste classi forniscono le basi per un'app di amministrazione del dispositivo completamente funzionale.
Il resto di questa sezione descrive come utilizzare le API DeviceAdminReceiver e
DevicePolicyManager per scrivere un'app di amministrazione del dispositivo.
Creazione di sottoclassi di DeviceAdminReceiver
Per creare un'app di amministrazione del dispositivo, devi sottoclassificareDeviceAdminReceiver. La classe DeviceAdminReceiver
consiste in una serie di callback che vengono attivati quando si verificano determinati eventi.
Nella sottoclasse DeviceAdminReceiver, l'app di esempio visualizza semplicemente una notifica Toast in risposta a determinati eventi. Ad esempio:
Kotlin
class DeviceAdminSample : DeviceAdminReceiver() {
private fun showToast(context: Context, msg: String) {
context.getString(R.string.admin_receiver_status, msg).let { status ->
Toast.makeText(context, status, Toast.LENGTH_SHORT).show()
}
}
override fun onEnabled(context: Context, intent: Intent) =
showToast(context, context.getString(R.string.admin_receiver_status_enabled))
override fun onDisableRequested(context: Context, intent: Intent): CharSequence =
context.getString(R.string.admin_receiver_status_disable_warning)
override fun onDisabled(context: Context, intent: Intent) =
showToast(context, context.getString(R.string.admin_receiver_status_disabled))
override fun onPasswordChanged(context: Context, intent: Intent, userHandle: UserHandle) =
showToast(context, context.getString(R.string.admin_receiver_status_pw_changed))
...
}
Java
public class DeviceAdminSample extends DeviceAdminReceiver {
void showToast(Context context, String msg) {
String status = context.getString(R.string.admin_receiver_status, msg);
Toast.makeText(context, status, Toast.LENGTH_SHORT).show();
}
@Override
public void onEnabled(Context context, Intent intent) {
showToast(context, context.getString(R.string.admin_receiver_status_enabled));
}
@Override
public CharSequence onDisableRequested(Context context, Intent intent) {
return context.getString(R.string.admin_receiver_status_disable_warning);
}
@Override
public void onDisabled(Context context, Intent intent) {
showToast(context, context.getString(R.string.admin_receiver_status_disabled));
}
@Override
public void onPasswordChanged(Context context, Intent intent, UserHandle userHandle) {
showToast(context, context.getString(R.string.admin_receiver_status_pw_changed));
}
...
}
Attivazione dell'app
Uno degli eventi principali che un'app di amministrazione del dispositivo deve gestire è l'attivazione dell'app da parte dell'utente. L'utente deve attivare esplicitamente l'app affinché i criteri vengano applicati. Se l'utente sceglie di non attivare l'app, questa rimarrà sul dispositivo, ma i relativi criteri non verranno applicati e l'utente non potrà usufruire dei vantaggi dell'app.
La procedura di attivazione dell'app inizia quando l'utente esegue un'azione che attiva l'intent ACTION_ADD_DEVICE_ADMIN. Nell'app di esempio, questo accade quando l'utente fa clic sulla casella di controllo Attiva amministratore.
Quando l'utente fa clic sulla casella di controllo Attiva amministrazione, la visualizzazione cambia per chiedere all'utente di attivare l'app di amministrazione del dispositivo, come mostrato nella figura 2.
Figura 2. App di esempio: attivazione dell'app
Di seguito è riportato il codice che viene eseguito quando l'utente fa clic sulla casella di controllo Attiva amministrazione. Ciò ha l'effetto di attivare il callback
onPreferenceChange(). Questo callback viene invocato quando il valore di Preference è stato modificato dall'utente ed è in procinto di essere impostato e/o mantenuto. Se l'utente sta attivando l'app, la visualizzazione cambia per chiedere all'utente di attivare l'app di amministrazione del dispositivo, come mostrato nella figura 2. In caso contrario, l'app di amministrazione del dispositivo viene disattivata.
Kotlin
override fun onPreferenceChange(preference: Preference, newValue: Any): Boolean {
if (super.onPreferenceChange(preference, newValue)) return true
val value = newValue as Boolean
if (preference == enableCheckbox) {
if (value != adminActive) {
if (value) {
// Launch the activity to have the user enable our admin.
val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply {
putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample)
putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
activity.getString(R.string.add_admin_extra_app_text))
}
startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN)
// return false - don't update checkbox until we're really active
return false
} else {
dpm.removeActiveAdmin(deviceAdminSample)
enableDeviceCapabilitiesArea(false)
adminActive = false
}
}
} else if (preference == disableCameraCheckbox) {
dpm.setCameraDisabled(deviceAdminSample, value)
}
return true
}
Java
@Override
public boolean onPreferenceChange(Preference preference, Object newValue) {
if (super.onPreferenceChange(preference, newValue)) {
return true;
}
boolean value = (Boolean) newValue;
if (preference == enableCheckbox) {
if (value != adminActive) {
if (value) {
// Launch the activity to have the user enable our admin.
Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample);
intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
activity.getString(R.string.add_admin_extra_app_text));
startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN);
// return false - don't update checkbox until we're really active
return false;
} else {
dpm.removeActiveAdmin(deviceAdminSample);
enableDeviceCapabilitiesArea(false);
adminActive = false;
}
}
} else if (preference == disableCameraCheckbox) {
dpm.setCameraDisabled(deviceAdminSample, value);
}
return true;
}
La riga
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample) indica che mDeviceAdminSample (che è
un componente DeviceAdminReceiver) è il criterio di destinazione.
Questa riga richiama l'interfaccia utente mostrata nella figura 2, che guida gli utenti nell'aggiungere l'amministratore del dispositivo al sistema (o consente loro di rifiutarlo).
Quando l'app deve eseguire un'operazione che dipende dall'attivazione dell'app di amministrazione del dispositivo, conferma che l'app è attiva. A tal fine, utilizza il metodo DevicePolicyManager
isAdminActive(). Tieni presente che il metodo DevicePolicyManager
isAdminActive() accetta un componente DeviceAdminReceiver come argomento:
Kotlin
private lateinit var dpm: DevicePolicyManager ... private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)
Java
DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
return dpm.isAdminActive(deviceAdminSample);
}
Gestione delle norme
DevicePolicyManager è una classe pubblica per la gestione dei criteri applicati su un dispositivo. DevicePolicyManager gestisce i criteri per una o più istanze DeviceAdminReceiver.
Puoi ottenere un handle per DevicePolicyManager come segue:
Kotlin
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
Java
DevicePolicyManager dpm =
(DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
Questa sezione descrive come utilizzare DevicePolicyManager per eseguire attività amministrative:
- Impostare i criteri relativi alle password
- Impostare il blocco del dispositivo
- Eseguire l'eliminazione dei dati
Impostare i criteri per le password
DevicePolicyManager include API per impostare e applicare il criterio per le password dei dispositivi. Nell'API Device Administration, la password si applica solo al blocco schermo. Questa sezione descrive le attività comuni relative alle password.
Imposta 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 numerica e un simbolo speciale.
PASSWORD_QUALITY_SOMETHING- Il regolamento richiede un qualche tipo di password, ma non importa quale sia.
PASSWORD_QUALITY_UNSPECIFIED- Le norme non prevedono requisiti per la password.
Ad esempio, ecco come impostare il criterio della password in modo che richieda una password alfanumerica:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
Impostare i requisiti dei contenuti delle password
A partire da Android 3.0, la classe DevicePolicyManager include metodi che ti consentono di perfezionare i contenuti della password. Ad esempio, puoi impostare un criterio che imponga che le password debbano contenere almeno n lettere maiuscole. Ecco i metodi per perfezionare i contenuti di una password:
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 deve avere almeno la lunghezza minima specificata. Ad esempio:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwLength: Int = ... ... dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwLength; ... dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);
Impostare il numero massimo di tentativi di inserimento della password non riusciti
Puoi impostare il numero massimo di tentativi di immissione password non riusciti consentiti prima della cancellazione dei dati del dispositivo (ovvero del ripristino dei dati di fabbrica). Ad esempio:
Kotlin
val dPM:DevicePolicyManager private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val maxFailedPw: Int = ... ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int maxFailedPw; ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
Impostare il timeout della scadenza della password
A partire da Android 3.0, puoi utilizzare il metodo
setPasswordExpirationTimeout()
per impostare la scadenza di una password, espressa come delta in millisecondi dal momento in cui un amministratore del dispositivo imposta il timeout di scadenza. Ad esempio:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwExpiration: Long = ... ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; long pwExpiration; ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);
Limitare la password in base alla cronologia
A partire da Android 3.0, puoi utilizzare il metodosetPasswordHistoryLength()
per limitare la possibilità degli utenti di riutilizzare le vecchie password. Questo metodo accetta un parametro length, che specifica quante password vecchie vengono archiviate. Quando questo criterio è attivo, gli utenti non possono inserire una nuova password che corrisponda alle ultime n password. In questo modo, gli utenti non possono utilizzare la stessa password più volte. Questo criterio viene in genere utilizzato insieme a setPasswordExpirationTimeout(), che impone agli utenti di aggiornare le proprie password dopo un determinato periodo di tempo.
Ad esempio, questo snippet impedisce agli utenti di riutilizzare le ultime 5 password:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwHistoryLength = 5 ... dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwHistoryLength = 5; ... dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength);
Impostare il blocco del dispositivo
Puoi impostare il periodo massimo di inattività dell'utente che può verificarsi prima che il dispositivo si blocchi. Ad esempio:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val timeMs: Long = 1000L * timeout.text.toString().toLong() ... dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... long timeMs = 1000L*Long.parseLong(timeout.getText().toString()); dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);
Puoi anche chiedere al dispositivo di bloccarsi immediatamente tramite programmazione:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Eseguire l'eliminazione dei dati
Puoi utilizzare il metodo DevicePolicyManager
wipeData() per ripristinare le impostazioni di fabbrica del dispositivo. Questa opzione è utile se il dispositivo viene smarrito o rubato. Spesso la decisione di resettare il dispositivo è il risultato del verificarsi di determinate condizioni. Ad esempio, puoi utilizzare
setMaximumFailedPasswordsForWipe() per indicare che un dispositivo deve essere
ripulito dopo un numero specifico di tentativi di inserimento password non riusciti.
Puoi cancellare i dati nel seguente modo:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Java
DevicePolicyManager dpm; dpm.wipeData(0);
Il metodo wipeData() prende come parametro una maschera di bit di opzioni aggiuntive. Al momento il valore deve essere 0.
Disattivazione della fotocamera
A partire da Android 4.0, puoi disattivare la fotocamera. Tieni presente che la disattivazione non deve essere necessariamente permanente. La videocamera può essere attivata/disattivata in modo dinamico in base al contesto, all'ora e così via.
Puoi controllare se la videocamera è disattivata utilizzando il metodosetCameraDisabled(). Ad esempio, questo snippet imposta la fotocamera su attivata o disattivata in base a un'impostazione della casella di controllo:
Kotlin
private lateinit var disableCameraCheckbox: CheckBoxPreference private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)
Java
private CheckBoxPreference disableCameraCheckbox; DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked());
Crittografia dell'archiviazione
A partire da Android 3.0, puoi utilizzare il metodo
setStorageEncryption()
per impostare un criterio che richieda la crittografia dell'area di archiviazione, se supportata.
Ad esempio:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setStorageEncryption(deviceAdminSample, true)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setStorageEncryption(deviceAdminSample, true);
Consulta l'esempio dell'API Device Administration per un esempio completo di come attivare la crittografia dello spazio di archiviazione.
Altri esempi di codice
Gli esempi Android AppRestrictionEnforcer e DeviceOwner dimostrano ulteriormente l'utilizzo delle API trattate in questa pagina.