Ritiro dell'amministrazione 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 per questo cambiamento. Per saperne 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 relative alla sicurezza utili in ambienti 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 anche cancellare da remoto i dati dei telefoni smarriti o rubati, ovvero ripristinare le impostazioni di fabbrica predefinite. Gli utenti di Exchange possono sincronizzare i dati di email e calendario.
Questo documento è destinato agli sviluppatori che vogliono sviluppare soluzioni aziendali per i dispositivi Android. Illustra le varie funzionalità fornite dall'API Device Administration per offrire una sicurezza più efficace ai dispositivi dei dipendenti con tecnologia Android.
Nota: per informazioni sulla creazione di un controller dei criteri di lavoro per le distribuzioni di Android for Work, consulta l'articolo Creare un controller dei criteri dei dispositivi.
Modalità proprietario dispositivo headless
Android 14 (livello API 34) introduce la modalità Utente di sistema senza testa (dispositivi in cui UserManager.isHeadlessSystemUserMode restituisce true). In modalità Utente di sistema senza testa, l'utente del sistema è un utente in background e si affida ad altri utenti in primo piano per le interazioni con l'utente finale. Android 14 introduce anche una
modalità affiliato proprietario di dispositivi headless,
che aggiunge un proprietario del profilo a tutti gli
utenti affiliati
diversi dall'utente del sistema per 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), solo i criteri relativi ai dispositivi di ambito globale (criteri applicabili a tutti gli utenti) vengono applicati agli utenti o agli utenti in primo piano. Per informazioni dettagliate, visita la pagina addUserRestriction.
I produttori di dispositivi Android possono fare riferimento alle linee guida pubblicate sul sito source.android.com.
Panoramica dell'API Device Administration
Di seguito sono riportati alcuni esempi di tipi di app che potrebbero usare l'API Device Administration:
- Client di posta.
- App di sicurezza che eseguono la cancellazione dei dati da remoto.
- App e servizi di gestione dei dispositivi.
Come funziona?
Puoi usare l'API Device Administration per scrivere le 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 dei dispositivi da remoto/locali. Questi criteri possono essere impostati come hardcoded nell'app oppure l'app può recuperare dinamicamente i criteri da un server di terze parti.
- L'app è installata sui dispositivi degli utenti. Android non dispone
al momento di una soluzione di provisioning automatizzato. Ecco alcuni modi in cui un amministratore di sistema
può distribuire l'app agli utenti:
- Google Play.
- Abilitazione dell'installazione da un altro store.
- La 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. Le modalità e i tempi di attivazione dipendono da come è implementata l'app.
- Una volta abilitata l'app di amministrazione del dispositivo, gli utenti sono soggetti ai relativi criteri. Il rispetto di questi criteri offre in genere vantaggi come l'accesso a sistemi e dati sensibili.
Se gli utenti non attivano l'app di amministrazione del dispositivo, questa rimarrà sul dispositivo, ma in stato non attivo. Gli utenti non saranno soggetti ai suoi criteri 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 le norme (ad esempio, se un utente imposta una password che viola le linee guida), spetta all'app decidere come gestire il problema. Tuttavia, in genere questo 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 non consente al momento il provisioning parziale. In altre parole, se un dispositivo (ad esempio un dispositivo precedente) non supporta tutti i criteri indicati, non è possibile consentire al dispositivo di connettersi.
Se un dispositivo contiene più app di amministrazione attivate, viene applicato il criterio più severo. Non è possibile scegliere come target una determinata app di amministrazione.
Per disinstallare un'app di amministrazione del dispositivo esistente, gli utenti devono prima annullare la registrazione dell'app come amministratore.
Norme
In ambito aziendale, spesso capita che i dispositivi dei dipendenti debbano rispettare un insieme rigoroso di criteri che ne regolano l'utilizzo. L'API Device Administration supporta i criteri elencati nella Tabella 1. Tieni presente che attualmente l'API Device Administration supporta solo le password per il blocco schermo:
Tabella 1. Criteri supportati dall'API Device Administration.
| Norme | Descrizione |
|---|---|
| Password abilitata | 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 il 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. |
| Password complessa obbligatoria | Richiede che le password contengano almeno una lettera, una cifra numerica e un simbolo speciale. Introdotta in Android 3.0. |
| Numero minimo di lettere richieste per la password | Il numero minimo di lettere richieste nella password per tutti gli amministratori o per uno specifico. Introdotta in Android 3.0. |
| Numero minimo di lettere minuscole richieste per la password | Il numero minimo di lettere minuscole richieste nella password per tutti gli amministratori o per uno specifico. Introdotta in Android 3.0. |
| Numero minimo di caratteri non costituiti da lettere richiesti per la password | Il numero minimo di caratteri non costituiti da lettere richiesti nella password per tutti gli amministratori o per un amministratore in particolare. Introdotta in Android 3.0. |
| Cifre numeriche minime richieste per la 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 per la password | Il numero minimo di simboli richiesti nella password per tutti gli amministratori o per uno specifico. Introdotta in Android 3.0. |
| Numero minimo di lettere maiuscole richieste per la password | Il numero minimo di lettere maiuscole richiesto per la password per tutti gli amministratori o per uno specifico. Introdotta in Android 3.0. |
| Timeout scadenza password | La scadenza della password, espressa come delta in millisecondi dal momento in cui l'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 una volta trascorso un determinato periodo di tempo.
Introdotta in Android 3.0. |
| Numero massimo di tentativi di inserimento password non riusciti | Consente di specificare il numero di volte in cui un utente può inserire la password errata prima che il dispositivo cancelli i dati. L'API Device Administration consente inoltre agli amministratori di ripristinare da remoto le impostazioni di fabbrica del dispositivo. In questo modo i dati sono protetti in caso di smarrimento o furto del dispositivo. |
| Blocco del tempo di inattività massimo | Imposta il periodo di tempo 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 nuovamente il PIN o la password per poter utilizzare i dispositivi e accedere ai dati. Il valore può essere compreso tra 1 e 60 minuti. |
| Richiedi crittografia dello spazio di archiviazione | Consente di specificare che l'area di archiviazione deve essere criptata, se il dispositivo la supporta. Introdotta in Android 3.0. |
| Disattivazione della fotocamera | Specifica che la fotocamera deve essere disattivata. Tieni presente che non deve essere necessariamente una disattivazione permanente. La videocamera può essere attivata/disattivata dinamicamente in base al contesto, all'ora e così via. Introdotto in Android 4.0. |
Altre funzionalità
Oltre a supportare i criteri elencati nella tabella precedente, l'API Device Administration ti consente di:
- Richiesta all'utente di impostare una nuova password.
- Blocca il dispositivo immediatamente.
- Cancellare i dati del dispositivo (ovvero ripristinare le impostazioni di fabbrica).
App di esempio
Gli esempi utilizzati in questa pagina si basano sull'esempio di API Device Administration, che è incluso negli esempi di 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. Offre agli utenti un'interfaccia utente che consente loro di abilitare l'app di amministrazione del dispositivo. Dopo aver abilitato l'app, gli utenti possono utilizzare i pulsanti nell'interfaccia utente per eseguire 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 prima della cancellazione dei dati del dispositivo (ovvero il ripristino delle impostazioni di fabbrica).
- Imposta la scadenza della password.
- Consente di impostare la lunghezza della cronologia delle password. Con lunghezza si intende il numero di vecchie password memorizzate nella cronologia. Questo impedisce agli utenti di 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 di inattività massimo che può trascorrere prima che il dispositivo si blocchi.
- Imposta il blocco del dispositivo immediatamente.
- Cancellare i dati del dispositivo (ovvero ripristinare le impostazioni di fabbrica).
- Disattiva 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 l'applicazione forzata dei criteri di sicurezza dei dispositivi da remoto/locali. Questa sezione riassume i passaggi della creazione di 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
DeviceAdminReceiverche include quanto segue:- L'autorizzazione
BIND_DEVICE_ADMIN. - La capacità di rispondere all'intent
ACTION_DEVICE_ADMIN_ENABLED, espressa nel manifest sotto forma di filtro per intent.
- L'autorizzazione
- Una dichiarazione relativa alle norme di sicurezza utilizzate nei metadati.
Ecco un estratto del file manifest di esempio per l'amministrazione dei dispositivi:
<activity android:name=".app.DeviceAdminSample"
android:label="@string/activity_sample_device_admin">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.SAMPLE_CODE" />
</intent-filter>
</activity>
<receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver"
android:label="@string/sample_device_admin"
android:description="@string/sample_device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN">
<meta-data android:name="android.app.device_admin"
android:resource="@xml/device_admin_sample" />
<intent-filter>
<action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
</intent-filter>
</receiver>
Tieni presente che:
- I seguenti attributi fanno riferimento alle risorse stringa che per l'app di esempio si trovano in
ApiDemos/res/values/strings.xml. Per ulteriori informazioni sulle risorse, consulta Risorse per l'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 leggibile dell'autorizzazione. In genere, una descrizione è 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 ricevitore (a nessuna app può essere concessa questa autorizzazione). In questo modo puoi impedire ad altre app di usare in modo illecito la tua app di amministrazione del dispositivo.android.app.action.DEVICE_ADMIN_ENABLEDè l'azione principale che una sottoclasseDeviceAdminReceiverdeve gestire per poter gestire un dispositivo. È impostato sul destinatario quando l'utente attiva l'app di amministrazione del dispositivo. In genere, il codice gestisce l'accesso inonEnabled(). Per essere supportato, il destinatario deve anche richiedere l'autorizzazioneBIND_DEVICE_ADMINin modo che altre app non possano utilizzarlo in modo illecito.- L'attivazione dell'app di amministrazione del dispositivo da parte di un utente concede al destinatario l'autorizzazione a eseguire azioni in risposta alla trasmissione di determinati eventi di sistema. Quando si verifica un evento idoneo, l'app può applicare 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 scoprire di più, visita la pagina
<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 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 dei dispositivi, non è necessario includere tutti i criteri, solo quelli pertinenti.
Per ulteriori informazioni sul file manifest, consulta la Guida per gli sviluppatori Android.Implementazione del codice
L'API Device Administration comprende 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 non elaborate inviate dal
sistema. L'app di amministrazione dei dispositivi deve includere una sottoclasse
DeviceAdminReceiver. DevicePolicyManager- Una classe per la gestione dei criteri applicati a un dispositivo. La maggior parte dei clienti di questo corso deve aver pubblicato un
DeviceAdminReceiverche l'utente ha attualmente attivato. L'elementoDevicePolicyManagergestisce i criteri per una o più istanzeDeviceAdminReceiver 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 del dispositivo.
Sottoclasse DeviceAdminRicevir
Per creare un'app di amministrazione del dispositivo, devi sottoclasse
DeviceAdminReceiver. La classe DeviceAdminReceiver
costituisce 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 eventi specifici. Ecco alcuni esempi:
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 abilitare esplicitamente l'app affinché vengano applicati i criteri. Se l'utente sceglie di non abilitare l'app, sarà comunque presente sul dispositivo, ma i suoi criteri non verranno applicati in modo forzato e l'utente non usufruirà di nessuno dei vantaggi dell'app.
Il processo di abilitazione 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 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 Attiva amministratore. Questo ha l'effetto di attivare il callback onPreferenceChange(). Questo callback viene richiamato quando il valore di Preference è stato modificato dall'utente e sta per essere impostato e/o mantenuto. Se l'utente attiva l'app, il display cambia per richiedere all'utente di attivare l'app di amministrazione del dispositivo, come mostrato nella figura 2. In caso contrario, l'app di amministrazione del dispositivo viene disattivata.
Kotlin
override fun onPreferenceChange(preference: Preference, newValue: Any): Boolean {
if (super.onPreferenceChange(preference, newValue)) return true
val value = newValue as Boolean
if (preference == enableCheckbox) {
if (value != adminActive) {
if (value) {
// Launch the activity to have the user enable our admin.
val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply {
putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample)
putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
activity.getString(R.string.add_admin_extra_app_text))
}
startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN)
// return false - don't update checkbox until we're really active
return false
} else {
dpm.removeActiveAdmin(deviceAdminSample)
enableDeviceCapabilitiesArea(false)
adminActive = false
}
}
} else if (preference == disableCameraCheckbox) {
dpm.setCameraDisabled(deviceAdminSample, value)
}
return true
}
Java
@Override
public boolean onPreferenceChange(Preference preference, Object newValue) {
if (super.onPreferenceChange(preference, newValue)) {
return true;
}
boolean value = (Boolean) newValue;
if (preference == enableCheckbox) {
if (value != adminActive) {
if (value) {
// Launch the activity to have the user enable our admin.
Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample);
intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
activity.getString(R.string.add_admin_extra_app_text));
startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN);
// return false - don't update checkbox until we're really active
return false;
} else {
dpm.removeActiveAdmin(deviceAdminSample);
enableDeviceCapabilitiesArea(false);
adminActive = false;
}
}
} else if (preference == disableCameraCheckbox) {
dpm.setCameraDisabled(deviceAdminSample, value);
}
return true;
}
La riga intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample) indica che mDeviceAdminSample (che è un componente DeviceAdminReceiver) è il criterio di destinazione.
Questa riga richiama l'interfaccia utente mostrata nella Figura 2, che guida gli utenti attraverso l'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, conferma che l'app è attiva. A questo scopo, viene utilizzato il metodo DevicePolicyManager
isAdminActive(). Tieni presente che il metodo DevicePolicyManager isAdminActive() utilizza un componente DeviceAdminReceiver come argomento:
Kotlin
private lateinit var dpm: DevicePolicyManager ... private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)
Java
DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
return dpm.isAdminActive(deviceAdminSample);
}
Gestione delle norme
DevicePolicyManager è una classe pubblica per la gestione dei criteri
applicati su un dispositivo. DevicePolicyManager gestisce i criteri per una
o più istanze DeviceAdminReceiver.
Puoi ottenere un handle per DevicePolicyManager nel seguente modo:
Kotlin
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
Java
DevicePolicyManager dpm =
(DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
Questa sezione descrive come utilizzare DevicePolicyManager per eseguire attività amministrative:
- Configurare i criteri relativi alle password
- Impostare il blocco del dispositivo
- Eseguire la cancellazione dei dati
Impostare i criteri per le password
DevicePolicyManager include le API per impostare e applicare i 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 mostra un'interfaccia utente che richiede 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à 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 altri simboli).
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- Le norme richiedono una password, ma non importa di cosa sia.
PASSWORD_QUALITY_UNSPECIFIED- Il criterio non prevede requisiti per la password.
Ad esempio, ecco come puoi impostare i criteri relativi alle 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 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 specifichi che le password devono contenere almeno n lettere maiuscole. Ecco i metodi per regolare il contenuto
di una password:
setPasswordMinimumLetters()setPasswordMinimumLowerCase()setPasswordMinimumUpperCase()setPasswordMinimumNonLetter()setPasswordMinimumNumeric()setPasswordMinimumSymbols()
Ad esempio, questo snippet indica che la password deve contenere almeno 2 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 debba avere almeno la lunghezza minima specificata. Ecco alcuni esempi:
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);
Imposta il numero massimo di tentativi di inserimento della password non riusciti
Puoi impostare il numero massimo di tentativi di inserimento della password non riusciti prima che il dispositivo venga cancellato (ovvero ripristinare le impostazioni di fabbrica). Ecco alcuni esempi:
Kotlin
val dPM:DevicePolicyManager private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val maxFailedPw: Int = ... ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int maxFailedPw; ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
Imposta timeout scadenza password
A partire da Android 3.0, puoi usare il metodo setPasswordExpirationTimeout() per impostare la scadenza di una password, espressa come delta in millisecondi da quando l'amministratore del dispositivo imposta il timeout di scadenza. Ecco alcuni esempi:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwExpiration: Long = ... ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; long pwExpiration; ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);
Limita 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 vecchie password. Questo metodo richiede un parametro length, che specifica quante vecchie password sono archiviate. Se il criterio è attivo, gli utenti non possono inserire una nuova password corrispondente alle ultime n password. In questo modo, gli utenti non potranno utilizzare la stessa password più volte. Questo criterio viene in genere utilizzato insieme a setPasswordExpirationTimeout(), che obbliga gli utenti ad aggiornare le password dopo un determinato periodo di tempo.
Ad esempio, questo snippet impedisce agli utenti di riutilizzare una qualsiasi delle 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);
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:
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 indicare in modo programmatico al dispositivo di bloccarsi immediatamente:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Esegui la cancellazione dei dati
Puoi utilizzare il DevicePolicyManagermetodo wipeData() per ripristinare le impostazioni di fabbrica del dispositivo. È utile in caso di furto o smarrimento del dispositivo. Spesso la decisione di cancellare i dati dal dispositivo
è il risultato del raggiungimento di determinate condizioni. Ad esempio, puoi utilizzare setMaximumFailedPasswordsForWipe() per indicare che i dati di un dispositivo devono essere cancellati dopo un numero specifico di tentativi di inserimento della password non riusciti.
La cancellazione dei dati avviene 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. Attualmente il valore deve essere 0.
Disattivazione della fotocamera
A partire da Android 4.0, puoi disattivare la fotocamera. Tieni presente che non deve essere necessariamente 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 con il
metodo setCameraDisabled(). Ad esempio, questo snippet imposta la videocamera in modo che venga attivata o disattivata in base a un'impostazione della casella di controllo:
Kotlin
private lateinit var disableCameraCheckbox: CheckBoxPreference private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)
Java
private CheckBoxPreference disableCameraCheckbox; DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked());
Crittografia dello spazio di archiviazione
A partire da Android 3.0, puoi utilizzare il metodo setStorageEncryption() per impostare un criterio che richieda la crittografia dell'area di archiviazione, se supportata.
Ecco alcuni esempi:
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 di API Device Administration per un esempio completo di come abilitare la crittografia dello spazio di archiviazione.
Altri esempi di codice
Gli esempi di Android AppRestrictionEnforcer e DeviceOwner mostrano ulteriormente l'uso delle API trattate in questa pagina.