Ritiro di Amministrazione dispositivo. A partire da Android 9 (livello API 28), alcune policy di amministrazione verranno contrassegnate come deprecate quando vengono richiamate da un amministratore del dispositivo. Ti consigliamo di iniziare a prepararti fin da ora a questo cambiamento. Per saperne di più e visualizzare le opzioni di migrazione, leggi Ritiro della funzionalità di amministratore dispositivo.
Android include il supporto per le app aziendali offrendo l'API Android Device Administration. L'API Device Administration fornisce funzionalità di amministrazione dei dispositivi a livello di sistema. Queste API ti consentono di creare app sensibili alla sicurezza utili in contesti aziendali, in cui i professionisti IT richiedono un controllo completo sui dispositivi dei dipendenti. Ad esempio, l'app Email integrata di Android ha utilizzato queste API per migliorare il supporto di Exchange. Tramite l'app email, gli amministratori di Exchange possono applicare policy relative alle password, tra cui password alfanumeriche o PIN numerici, su tutti i dispositivi. Gli amministratori possono anche cancellare da remoto i dati (ovvero ripristinare le impostazioni di fabbrica) dei telefoni smarriti o rubati. Gli utenti di Exchange possono sincronizzare i dati di email e calendario.
Questo documento è rivolto agli sviluppatori che vogliono sviluppare soluzioni aziendali per i dispositivi Android. Vengono illustrate le varie funzionalità fornite dall'API Device Administration per fornire una maggiore sicurezza per i dispositivi dei dipendenti con Android.
Nota Per informazioni sulla creazione di un Work Policy Controller per i deployment di Android for Work, consulta Crea un controller dei criteri dei dispositivi.
Modalità device owner headless
Android 14 (livello API 34) introduce la modalità utente di sistema headless (dispositivi in cui UserManager.isHeadlessSystemUserMode restituisce true). In modalità utente di sistema headless, l'utente di sistema è un utente in background e si affida ad altri utenti in primo piano per l'interazione con l'utente finale. Android 14 introduce anche una
modalità affiliata del proprietario del dispositivo headless,
che aggiunge un proprietario del profilo a tutti gli
utenti affiliati
diversi dall'utente di sistema su cui è impostato il proprietario del dispositivo.
Sui dispositivi configurati con un utente di sistema headless (in cui l'utente di sistema viene eseguito in background), solo le policy per i dispositivi con ambito globale (policy applicabili a tutti gli utenti) vengono applicate all'utente o agli utenti in primo piano. Per i dettagli, consulta addUserRestriction.
I produttori di dispositivi Android possono fare riferimento alle indicazioni pubblicate su source.android.com.
Panoramica dell'API Device Administration
Ecco alcuni esempi di tipi di app che potrebbero utilizzare l'API Device Administration:
- Client di posta.
- App di sicurezza che eseguono la cancellazione da remoto.
- Servizi e app di gestione dei dispositivi.
Come funziona?
Utilizza l'API Device Administration per scrivere app per amministratori dei dispositivi che gli utenti installano sui propri dispositivi. L'app per amministratori del dispositivo applica le policy desiderate. Ecco come funziona:
- Un amministratore di sistema scrive un'app per amministratori di dispositivo che applica le policy di sicurezza dei dispositivi remoti/locali. Queste policy potrebbero essere hardcoded nell'app oppure l'app potrebbe recuperarle dinamicamente da un server di terze parti.
- L'app viene installata sui dispositivi degli utenti. Android al momento non dispone di una soluzione di provisioning automatico. Di seguito sono riportati alcuni dei modi in cui un sysadmin potrebbe distribuire l'app agli utenti:
- Google Play.
- Attivazione dell'installazione da un altro store.
- Distribuire l'app tramite altri mezzi, ad esempio email o siti web.
- Il sistema chiede all'utente di attivare l'app per amministratori del dispositivo. Come e quando ciò accade dipende da come viene implementata l'app.
- Una volta che gli utenti attivano l'app per amministratori dei dispositivi, sono soggetti alle relative policy. La conformità a queste policy in genere conferisce vantaggi, come l'accesso a sistemi e dati sensibili.
Se gli utenti non attivano l'app per amministratori del dispositivo, questa rimane sul dispositivo, ma in uno stato inattivo. Gli utenti non saranno soggetti alle relative policy e, di conseguenza, non usufruiranno di nessuno dei vantaggi dell'app, ad esempio potrebbero non essere in grado di sincronizzare i dati.
Se un utente non rispetta le policy (ad esempio, se imposta una password che viola le linee guida), spetta all'app decidere come gestire la situazione. Tuttavia, in genere questo impedisce all'utente di sincronizzare i dati.
Se un dispositivo tenta di connettersi a un server che richiede policy non supportate 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 legacy) non supporta tutti i criteri indicati, non è possibile consentire la connessione del dispositivo.
Se un dispositivo contiene più app per amministratori attive, viene applicato il criterio più restrittivo. Non è possibile scegliere come target un'app per amministratori specifica.
Per disinstallare un'app per amministratori di dispositivi esistente, gli utenti devono prima annullare la registrazione dell'app come amministratore.
Norme
In un contesto aziendale, spesso i dispositivi dei dipendenti devono rispettare un insieme rigoroso di policy che ne regolano l'utilizzo. L'API Device Administration supporta i criteri elencati nella Tabella 1. Tieni presente che l'API Device Administration attualmente supporta solo le password per il blocco schermo:
Tabella 1. Criteri supportati dall'API Device Administration.
| Policy | Descrizione |
|---|---|
| Password abilitata | Richiede che i dispositivi richiedano PIN o password. |
| Lunghezza minima della password | Imposta il numero di caratteri richiesti per la password. Ad esempio, puoi richiedere che i PIN o le password contengano almeno sei caratteri. |
| Password alfanumerica obbligatoria | Richiede che le password contengano 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 nella 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 nella 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 alfabetici richiesti nella password | Il numero minimo di caratteri non alfabetici richiesti nella password per tutti gli amministratori o per uno specifico. Introdotta in Android 3.0. |
| Numero minimo di cifre numeriche 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. |
| Numero minimo di simboli richiesti nella 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 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 scadenza password | Quando scadrà la 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.
Questa policy viene in genere utilizzata insieme a setPasswordExpirationTimeout(), che obbliga gli utenti ad aggiornare le proprie password dopo un periodo di tempo specificato.
Introdotta in Android 3.0. |
| Numero massimo di tentativi di inserimento della password non riusciti | Specifica quante volte 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 i dati di fabbrica del dispositivo. In questo modo i dati sono protetti in caso di smarrimento o furto del dispositivo. |
| Blocco per tempo massimo di inattività | Imposta il periodo di tempo trascorso dall'ultimo tocco dello schermo o dall'ultima pressione di un pulsante da parte dell'utente prima che il dispositivo blocchi lo schermo. In questo caso, gli utenti devono inserire nuovamente 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. |
| Richiedi crittografia dello spazio di archiviazione | Specifica che l'area di archiviazione deve essere criptata, se il dispositivo lo supporta. Introdotta in Android 3.0. |
| Disattiva videocamera | Specifica che la videocamera deve essere disattivata. Tieni presente che non deve essere una disattivazione permanente. La fotocamera può essere attivata/disattivata dinamicamente in base al contesto, all'ora e così via. Introdotta in Android 4.0. |
Altre funzionalità
Oltre a supportare i criteri elencati nella tabella precedente, l'API Device Administration consente di:
- Chiedi all'utente di impostare una nuova password.
- Blocca immediatamente il dispositivo.
- Cancellare i dati del dispositivo (ovvero ripristinare i dati di fabbrica).
App di esempio
Gli esempi utilizzati in questa pagina si basano sull'esempio dell'API Device Administration, incluso negli esempi dell'SDK (disponibili tramite SDK Manager Android) e situato sul 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 dei dispositivi. Presenta agli utenti un'interfaccia utente che consente loro di attivare l'app per amministratori del dispositivo. Una volta attivata l'app, 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, 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 policy specificate, 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 (ovvero prima che vengano ripristinate le impostazioni di fabbrica).
- Imposta il periodo di tempo dopo il quale 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 utilizzate 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.
- Bloccare immediatamente il dispositivo.
- Cancellare i dati del dispositivo (ovvero ripristinare 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 applica l'applicazione delle policy 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 manifest dell'app deve includere quanto segue:
- Una sottoclasse di
DeviceAdminReceiverche include:- L'autorizzazione
BIND_DEVICE_ADMIN. - La capacità di rispondere all'intent
ACTION_DEVICE_ADMIN_ENABLED, espressa nel manifest come filtro per intent.
- L'autorizzazione
- Una dichiarazione delle policy di sicurezza utilizzate nei metadati.
Ecco un estratto del manifest di esempio di Amministrazione dispositivo:
<activity android:name=".app.DeviceAdminSample" android:label="@string/activity_sample_device_admin"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.SAMPLE_CODE" /> </intent-filter> </activity> <receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver" android:label="@string/sample_device_admin" android:description="@string/sample_device_admin_description" android:permission="android.permission.BIND_DEVICE_ADMIN"> <meta-data android:name="android.app.device_admin" android:resource="@xml/device_admin_sample" /> <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter> </receiver>
Ricorda:
- I seguenti attributi fanno riferimento alle risorse stringa che per l'app di esempio si trovano in
ApiDemos/res/values/strings.xml. Per saperne di più sulle risorse, consulta Risorse dell'applicazione.android:label="@string/activity_sample_device_admin"si riferisce all'etichetta leggibile dall'utente per l'attività.android:label="@string/sample_device_admin"si riferisce all'etichetta leggibile dall'utente per l'autorizzazione.android:description="@string/sample_device_admin_description"si riferisce alla descrizione dell'autorizzazione leggibile dall'utente. Una descrizione è in genere più lunga e più informativa di un'etichetta.
android:permission="android.permission.BIND_DEVICE_ADMIN"è un'autorizzazione che una sottoclasseDeviceAdminReceiverdeve avere per garantire che solo il sistema possa interagire con il ricevitore (nessuna app può ricevere questa autorizzazione). In questo modo, altre app non possono utilizzare in modo improprio la tua app per amministratori 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 ricevitore quando l'utente attiva l'app per amministratori del dispositivo. Il codice in genere gestisce questa operazione inonEnabled(). Per essere supportato, il ricevitore deve anche richiedere l'autorizzazioneBIND_DEVICE_ADMINin modo che altre app non possano utilizzarla in modo improprio.- Quando un utente attiva l'app per amministratori del dispositivo, il ricevitore ottiene l'autorizzazione per eseguire azioni in risposta alla trasmissione di determinati eventi di sistema. Quando si verifica un evento idoneo, l'app può applicare una policy. Ad esempio, se l'utente tenta di impostare una nuova password che non soddisfa i requisiti delle norme, l'app può chiedergli di scegliere una password diversa che li soddisfi.
- Evita di modificare il nome del ricevitore dopo aver pubblicato l'app. Se il nome nel 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 le policy di sicurezza utilizzate nei metadati. I metadati forniscono informazioni aggiuntive specifiche per l'amministratore del dispositivo, 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 la tua 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 base per l'implementazione di un componente di amministrazione del dispositivo. Questa classe offre un modo pratico per interpretare 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 delle policy applicate su un dispositivo. La maggior parte dei client di questa classe deve aver pubblicato un
DeviceAdminReceiverattualmente attivato dall'utente.DevicePolicyManagergestisce le policy per una o più istanzeDeviceAdminReceiver DeviceAdminInfo- Questa classe viene utilizzata per specificare i metadati per un componente amministratore del dispositivo.
Queste classi forniscono la base per un'app per amministratori di dispositivi completamente funzionale.
Il resto di questa sezione descrive come utilizzare le API DeviceAdminReceiver e
DevicePolicyManager per scrivere un'app per amministratori di dispositivi.
Creazione di sottoclassi di DeviceAdminReceiver
Per creare un'app per amministratori del dispositivo, devi creare una sottoclasse di
DeviceAdminReceiver. La classe DeviceAdminReceiver è costituita da una serie di callback che vengono attivati quando si verificano determinati eventi.
Nella sua sottoclasse DeviceAdminReceiver, l'app di esempio
mostra 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 le relative policy non verranno applicate 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 seleziona la casella di controllo Attiva amministratore.
Quando l'utente seleziona la casella di controllo Attiva amministratore, la visualizzazione cambia per chiedere all'utente di attivare l'app per amministratori 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. In questo modo viene attivato il callback onPreferenceChange(). Questo callback viene richiamato quando il valore di questo Preference è stato modificato dall'utente e sta per essere impostato e/o reso persistente. Se l'utente attiva l'app, il display cambia per invitarlo ad attivare l'app per amministratori del dispositivo, come mostrato nella figura 2. In caso contrario, l'app per amministratori del dispositivo è 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) è la policy di destinazione.
Questa riga richiama l'interfaccia utente mostrata nella figura 2, che guida gli utenti nell'aggiunta dell'amministratore del dispositivo al sistema (o consente loro di rifiutarla).
Quando l'app deve eseguire un'operazione che dipende dall'attivazione dell'app per amministratori dispositivo, verifica che l'app sia attiva. Per farlo, utilizza il metodo DevicePolicyManager
isAdminActive(). Tieni presente che il metodo isAdminActive() di DevicePolicyManager 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 le policy 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:
- Imposta i criteri relativi alle password
- Imposta il blocco dispositivo
- Esegui la cancellazione dei dati
Imposta le policy relative alle password
DevicePolicyManager include API per l'impostazione e l'applicazione della policy 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);
Imposta 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 sia 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- La policy richiede un tipo di password, ma non importa quale.
PASSWORD_QUALITY_UNSPECIFIED- La policy non prevede requisiti per la password.
Ad esempio, ecco come impostare la policy relativa 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);
Imposta 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 una policy che stabilisce che le password devono contenere almeno n lettere maiuscole. Ecco i metodi per perfezionare i contenuti di una password:
setPasswordMinimumLetters()setPasswordMinimumLowerCase()setPasswordMinimumUpperCase()setPasswordMinimumNonLetter()setPasswordMinimumNumeric()setPasswordMinimumSymbols()
Ad esempio, questo snippet indica che la password deve contenere almeno 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 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);
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 consentiti prima che i dati del dispositivo vengano cancellati (ovvero prima che vengano ripristinate le impostazioni di fabbrica). Ad esempio:
Kotlin
val dPM:DevicePolicyManager private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val maxFailedPw: Int = ... ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int maxFailedPw; ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
Imposta il timeout di scadenza della password
A partire da Android 3.0, puoi utilizzare il metodo setPasswordExpirationTimeout() per impostare la scadenza di una password, espressa come delta in millisecondi dal momento in cui un amministratore del dispositivo imposta il timeout di scadenza. Ad esempio:
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 accetta un parametro length, che specifica il numero di password precedenti memorizzate. Quando questa policy è attiva, 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. In genere, questa policy viene utilizzata insieme a setPasswordExpirationTimeout(), che obbliga gli utenti ad aggiornare le proprie password dopo un periodo di tempo specificato.
Ad esempio, questo snippet impedisce agli utenti di riutilizzare una 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 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 indicare al dispositivo di bloccarsi immediatamente tramite programmazione:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Esegui la cancellazione 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 cancellare i dati dal dispositivo è il risultato del rispetto 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.
Per cancellare i dati:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Java
DevicePolicyManager dpm; dpm.wipeData(0);
Il metodo wipeData() accetta come parametro una maschera di bit di opzioni aggiuntive. Al momento il valore deve essere 0.
Disattiva videocamera
A partire da Android 4.0, puoi disattivare la fotocamera. Tieni presente che non deve trattarsi di una disattivazione permanente. La fotocamera può essere attivata/disattivata dinamicamente in base al contesto, all'ora e così via.
Puoi controllare se la fotocamera è disattivata utilizzando il metodo setCameraDisabled(). Ad esempio, questo snippet imposta l'attivazione o la disattivazione della videocamera in base a un'impostazione della casella di controllo:
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 una policy che richiede 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.