Ritiro dell'amministratore del dispositivo. A partire da Android 9 (livello API 28), alcuni criteri amministrativi verranno contrassegnati come deprecati quando richiamato da un amministratore del dispositivo. Ti consigliamo di iniziare subito a prepararti a questo cambiamento. Per ulteriori informazioni ed esaminare le opzioni di migrazione, Ritiro dell'amministrazione del dispositivo.
Android include il supporto per le app aziendali offrendo il API Android Device Administration. L'API di amministrazione dei dispositivi fornisce funzionalità di amministrazione a livello di sistema. Queste API consentono di creare per la sicurezza e per la sicurezza che sono utili in contesti aziendali, in cui i professionisti richiedono un ampio controllo sui dispositivi dei dipendenti. Ad esempio, l'app email Android integrata ha sfruttato queste API per migliorare Supporto di Exchange. Tramite l'app Email, gli amministratori di Exchange possono applicare criteri relativi alle password, incluse password alfanumeriche o numeriche PIN su tutti i dispositivi. Gli amministratori possono anche cancellare da remoto i dati (ovvero attivi (ripristinare le impostazioni di fabbrica) dei telefoni smarriti o rubati. Gli utenti di Exchange possono sincronizzare le email e i dati del calendario.
Questo documento è rivolto agli sviluppatori che vogliono sviluppare soluzioni per i dispositivi Android. Illustra le varie funzionalità forniti dall'API di amministrazione dei dispositivi per garantire una maggiore sicurezza dispositivi per i dipendenti basati su Android.
Nota: per informazioni sulla creazione di una norma relativa al lavoro per le implementazioni Android for Work, vedi Crea un controller dei criteri dei dispositivi.
Modalità proprietario dispositivo headless
Android 14 (livello API 34) introduce la modalità Utente di sistema headless (i dispositivi in
quale
UserManager.isHeadlessSystemUserMode
restituisce true
). Nella modalità Utente di sistema senza testa, l'utente del sistema
utente in background e si affida ad altri utenti in primo piano per l'utente finale
un'interazione. Android 14 introduce anche
modalità affiliato del proprietario del dispositivo headless,
che aggiunge un proprietario del profilo a tutti
utenti affiliati
diverso dall'utente del sistema su cui è impostato il proprietario del dispositivo.
Nei dispositivi configurati con un utente di sistema headless (in cui l'utente del sistema
vengono eseguiti in background), solo i criteri relativi ai dispositivi con ambito globale
(criteri applicabili a tutti gli utenti) vengono applicati all'utente in primo piano
o utenti. Consulta
addUserRestriction
per maggiori dettagli.
I produttori di dispositivi Android possono fare riferimento alle indicazioni pubblicato su source.android.com.
Panoramica dell'API Device Administration
Di seguito sono riportati alcuni esempi di tipi di app che potrebbero utilizzare l'API Device Administration:
- Client di posta.
- App per la sicurezza che eseguono la cancellazione da remoto.
- App e servizi di gestione dei dispositivi.
Come funziona?
Puoi utilizzare l'API di amministrazione del dispositivo per scrivere le app di amministrazione del dispositivo che gli utenti installare sui propri dispositivi. L'app di amministrazione del dispositivo applica in modo forzato criteri. Ecco come funziona:
- Un amministratore di sistema scrive un'app di amministrazione del dispositivo che applica criteri di sicurezza dei dispositivi remoti/locali. Questi criteri possono essere hard-coded in l'app oppure l'app potrebbe recuperare dinamicamente i criteri da una terza parte o server web.
- L'app è installata sul dispositivo dispositivi mobili. Android
al momento non dispongono di una soluzione
di provisioning automatizzato. Alcuni modi in cui un amministratore di sistema
per distribuire l'app agli utenti:
- Google Play.
- Attivazione dell'installazione da un altro store.
- Distribuzione dell'app tramite altri mezzi, ad esempio email o siti web.
- Il sistema chiede all'utente di attivare l'app di amministrazione del dispositivo. Come e quando questo avviene dipende da come è implementata l'app.
- Una volta attivata l'app di amministrazione del dispositivo, gli utenti sono soggetti alle le relative norme. Il rispetto di queste norme in genere conferisce vantaggi, l'accesso a dati e sistemi sensibili.
Se gli utenti non abilitano l'app di amministrazione del dispositivo, questa rimane sul dispositivo, ma in stato inattivo. Gli utenti non saranno soggetti alle relative norme e, al contrario, non usufruiranno dei vantaggi dell'app (ad esempio, potrebbero non essere in grado di sincronizzare i dati).
Se un utente non rispetta i criteri (ad esempio, se imposta una password che viola le linee guida), spetta all'app decidere gestire la situazione. Tuttavia, in genere ciò impedisce all'utente in grado di sincronizzare i dati.
Se un dispositivo tenta di connettersi a un server che richiede criteri non supportata nell'API di amministrazione del dispositivo, la connessione non essere consentite. L'API Device Administration al momento non consente per eseguire il provisioning. In altre parole, se un dispositivo (ad esempio, un dispositivo legacy) non supportano tutti i criteri dichiarati, non c'è modo di consentire dispositivo per la connessione.
Se un dispositivo contiene più app di amministrazione abilitate, il criterio più severo è in modo forzato. Non è possibile scegliere come target un amministratore specifico dell'app.
Per disinstallare un'app di amministrazione del dispositivo esistente, gli utenti devono: annulla prima la registrazione dell'app come amministratore.
Norme
In ambito aziendale, i dispositivi dei dipendenti spesso devono rispettare una serie di norme rigorose che regolano l'utilizzo del dispositivo. La L'API di amministrazione dei dispositivi supporta i criteri elencati nella Tabella 1. Tieni presente che l'API Device Administration attualmente supporta solo le password per lo schermo blocco:
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, può richiedere un PIN o una password di almeno sei caratteri. |
Password alfanumerica obbligatoria | Richiede che le password includano un combinazione di lettere e numeri. Possono includere caratteri simbolici. |
È richiesta una password complessa | Richiede che le password contengano almeno una lettera, una cifra numerica e un simbolo speciale. Introdotto 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. Introdotto in Android 3.0. |
Numero minimo di lettere minuscole richieste nella password | Il numero minimo di lettere minuscole lettere richieste nella password per tutti gli amministratori o per uno specifico. Introdotto in Android 3.0. |
Nella password sono richiesti almeno caratteri non costituiti da lettere | Il numero minimo di caratteri non costituiti da lettere richiesti nella password per tutti gli amministratori o per uno specifico. Introdotto in Android 3.0. |
Numero minimo di cifre richieste nella password | Il numero minimo di cifre numeriche richiesto nella password per tutti gli amministratori o per uno specifico. Introdotto 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. Introdotto in Android 3.0. |
Numero minimo di lettere maiuscole richieste nella password | Il numero minimo di lettere maiuscole richiesto nella password per tutti gli amministratori o per uno specifico. Introdotto in Android 3.0. |
Timeout scadenza password | Data di scadenza della password, espressa come delta in millisecondi dal momento in cui un amministratore del dispositivo imposta il timeout per la scadenza. Introdotto in Android 3.0. |
Restrizione cronologia password | Questo criterio impedisce agli utenti di riutilizzare le ultime n password univoche.
Questo criterio viene in genere utilizzato insieme a
setPasswordExpirationTimeout() , che forza
agli utenti di aggiornare le proprie password dopo che è trascorso un determinato periodo di tempo.
Introdotto in Android 3.0. |
Numero massimo di tentativi per la password non riusciti | Specifica quante volte un utente può inserire una password errata prima del dispositivo cancella i propri dati. L'API di amministrazione dei dispositivi consente inoltre agli amministratori ripristinare da remoto le impostazioni di fabbrica del dispositivo. In questo modo i dati sono protetti se il dispositivo è stato smarrito o rubato. |
Blocco del tempo di inattività massimo | Consente di impostare l'intervallo di tempo trascorso dall'ultima volta che l'utente ha toccato lo schermo oppure premuto un pulsante prima che il dispositivo blocchi lo schermo. In questi casi, gli utenti dovrà inserire nuovamente il PIN o la password prima di poter utilizzare i dispositivi 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 la supporta. Introdotto in Android 3.0. |
Disattiva videocamera | Specifica che la fotocamera deve essere disattivata. Tieni presente che non sono state una disattivazione permanente. La videocamera può essere attivata/disattivata in modo dinamico in base al contesto, all'ora e così via. Introdotto in Android 4.0. |
Altre funzionalità
Oltre a supportare le norme elencate nella tabella precedente, il Dispositivo L'API di amministrazione ti consente di:
- Chiedi all'utente di impostare una nuova password.
- Blocca immediatamente il dispositivo.
- Cancellare i dati del dispositivo (ripristinare le impostazioni di fabbrica del dispositivo).
App di esempio
Gli esempi utilizzati in questa pagina si basano sull'API Device Administration
esempio, che è incluso negli esempi dell'SDK (disponibili tramite
Android SDK Manager) e che si trova nel sistema come
<sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java
.
L'app di esempio offre una demo delle funzionalità di amministrazione del dispositivo. Presenta gli utenti con un'interfaccia utente che consente di abilitare l'app di amministrazione del dispositivo. Una volta dopo aver attivato l'app, possono usare i pulsanti nell'interfaccia utente effettuare 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 a criteri, 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 per quanto tempo la password scadrà.
- Imposta la lunghezza della cronologia delle password (lunghezza si riferisce al numero di password precedenti memorizzate nella cronologia). In questo modo gli utenti non possono riutilizzare una delle ultime n password usate in precedenza.
- Specifica che l'area di archiviazione deve essere criptata, se il dispositivo la supporta.
- Imposta il tempo massimo di inattività che può trascorrere prima che il dispositivo serrature.
- Attiva immediatamente il blocco del dispositivo.
- Cancellare i dati del dispositivo (ripristinare le impostazioni di fabbrica).
- Disattiva la fotocamera.
Sviluppo di un'app di amministrazione dei dispositivi
Gli amministratori di sistema possono utilizzare l'API di amministrazione dispositivo per scrivere un'app che applica i criteri di sicurezza dei dispositivi remoti/locali. Questa sezione riassume i passaggi necessari per la creazione di un'amministrazione dispositivi dell'app.
Creazione del manifest
Per utilizzare l'API Device Administration, l'app il file manifest deve includere quanto segue:
- Una sottoclasse di
DeviceAdminReceiver
che include quanto segue:- L'autorizzazione
BIND_DEVICE_ADMIN
. - La possibilità di rispondere al
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 file manifest di esempio per l'amministrazione dei dispositivi:
<activity android:name=".app.DeviceAdminSample" android:label="@string/activity_sample_device_admin"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.SAMPLE_CODE" /> </intent-filter> </activity> <receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver" android:label="@string/sample_device_admin" android:description="@string/sample_device_admin_description" android:permission="android.permission.BIND_DEVICE_ADMIN"> <meta-data android:name="android.app.device_admin" android:resource="@xml/device_admin_sample" /> <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter> </receiver>
Tieni presente che:
- I seguenti attributi si riferiscono alle risorse stringa che risiedono nell'app di esempio
ApiDemos/res/values/strings.xml
. Per ulteriori informazioni sulle risorse, consulta Risorse per le applicazioni.android:label="@string/activity_sample_device_admin"
si riferisce al un'etichetta leggibile per l'attività.android:label="@string/sample_device_admin"
si riferisce al un'etichetta leggibile per l'autorizzazione.android:description="@string/sample_device_admin_description"
si riferisce a la descrizione leggibile dell'autorizzazione. Una descrizione è in genere più lunga e più lunga informativo rispetto un'etichetta.
android:permission="android.permission.BIND_DEVICE_ADMIN"
è un'autorizzazione che una sottoclasseDeviceAdminReceiver
deve per garantire che solo il sistema possa interagire con il destinatario (non è possibile concedere questa autorizzazione a nessuna app). Questo impedisce ad altre app di utilizzare in modo illecito l'app di amministrazione del dispositivo.android.app.action.DEVICE_ADMIN_ENABLED
è il livello principale che una sottoclasseDeviceAdminReceiver
deve gestire per autorizzati a gestire un dispositivo. Viene impostato sul destinatario quando l'utente abilita l'app di amministrazione del dispositivo. Il tuo codice solitamente gestisce questa operazioneonEnabled()
. Per essere supportato, il destinatario deve anche richiedono l'autorizzazioneBIND_DEVICE_ADMIN
affinché altre app non possono abusarne.- Quando un utente attiva l'app di amministrazione del dispositivo, il destinatario l'autorizzazione a eseguire azioni in risposta alla trasmissione di un particolare sistema eventi. Quando si verifica un evento adatto, l'app può imporre delle norme. Per Ad esempio, se un utente tenta di impostare una nuova password che non soddisfa il criterio, requisiti, l'app può chiedere all'utente di scegliere una password diversa che soddisfano i requisiti.
- Evita di modificare il nome del destinatario dopo aver pubblicato l'app. Se il nome nel campo
modifiche al file manifest, l'amministrazione del dispositivo viene disattivata quando gli utenti aggiornano l'app. Per saperne di più, vedi
<receiver>
android:resource="@xml/device_admin_sample"
dichiara i criteri di sicurezza usati nei metadati. I metadati forniscono informazioni specifiche per l'amministratore del dispositivo, come analizzate dalla classeDeviceAdminInfo
. Ecco i contenutidevice_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>
Durante la progettazione dell'app di amministrazione dei dispositivi, non è necessario includere tutte le norme, solo quelle pertinenti per la tua app.
Per ulteriori discussioni sul file manifest, consulta la Guida per gli sviluppatori Android.Implementazione del codice
L'API di amministrazione dei dispositivi include le seguenti classi:
DeviceAdminReceiver
- Classe di base per l'implementazione di un componente di amministrazione del dispositivo. Questo corso fornisce
è utile per interpretare le azioni di intent non elaborate inviate dal
di un sistema operativo completo. L'app Amministrazione dispositivo deve includere un
DeviceAdminReceiver
sottoclasse. DevicePolicyManager
- Un corso per la gestione dei criteri applicati a un dispositivo. La maggior parte dei clienti di
questo corso deve aver pubblicato un
DeviceAdminReceiver
che l'utente è attualmente abilitato. L'DevicePolicyManager
gestisce i criteri per una o più istanzeDeviceAdminReceiver
DeviceAdminInfo
- Questa classe viene utilizzata per specificare i metadati per un componente per l'amministratore del dispositivo.
Questi corsi forniscono le basi per un'app di amministrazione dei dispositivi completamente funzionale.
Il resto di questa sezione descrive come utilizzi DeviceAdminReceiver
e
DevicePolicyManager
API per scrivere un'app di amministrazione del dispositivo.
Creazione di sottoclassi DeviceAdminReceiver
Per creare un'app di amministrazione del dispositivo, devi sottoclasse
DeviceAdminReceiver
. Il corso DeviceAdminReceiver
consiste in una serie di callback che vengono attivati quando determinati eventi
che si verificano.
Nella sottoclasse DeviceAdminReceiver
, l'app di esempio
mostra semplicemente una notifica Toast
in risposta a un
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'utente attivare l'app. L'utente deve abilitare esplicitamente l'app per: i criteri da applicare. Se l'utente sceglie di non attivare l'app sarà comunque presente sul dispositivo, ma i relativi criteri non verranno applicati e usufruire dei vantaggi dell'app.
Il processo di abilitazione dell'app inizia quando l'utente esegue un
azione che attiva ACTION_ADD_DEVICE_ADMIN
l'intento. Nella
app di esempio, questo accade quando l'utente fa clic sul pulsante Attiva
Console di amministrazione.
Quando l'utente fa clic sulla casella di controllo Attiva amministratore, la visualizzazione cambia per richiedere all'utente di attivare l'app di amministrazione del dispositivo, come mostrato nella figura 2.
Di seguito è riportato il codice che viene eseguito quando l'utente fa clic sulla casella di controllo Abilita amministratore. Ciò ha l'effetto di attivare
onPreferenceChange()
di Google. Questo callback viene attivato quando il valore di questo Preference
è stato modificato dall'utente e sta per essere impostato e/o mantenuto. Se l'utente attiva l'app, lo schermo
cambia per richiedere all'utente di attivare l'app di amministrazione del dispositivo, come mostrato nella figura
2. In caso contrario, l'app di amministrazione del dispositivo è disattivata.
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 linea
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample)
indica che mDeviceAdminSample
(ovvero
DeviceAdminReceiver
) è il criterio di destinazione.
Questa riga richiama l'interfaccia utente mostrata nella Figura 2, che guida gli utenti attraverso
aggiungere l'amministratore del dispositivo al sistema (o consentire agli utenti di rifiutarlo).
Quando l'app deve eseguire un'operazione che dipende dal
l'app di amministrazione del dispositivo viene attivata, conferma che l'app sia
attivo. Per farlo utilizza il metodo DevicePolicyManager
isAdminActive()
. Nota che l'DevicePolicyManager
metodo isAdminActive()
richiede un 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
in modo forzato su un dispositivo. DevicePolicyManager
gestisce i criteri per uno
o più istanze di DeviceAdminReceiver
.
Per ottenere un handle per DevicePolicyManager
:
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
Imposta criteri per le password
DevicePolicyManager
include le API per l'impostazione e l'applicazione delle
criteri relativi alle password del dispositivo. Nell'API Device Administration, la password si applica solo a
blocco schermo. Questa sezione descrive le attività comuni relative alle password.
Imposta una password per il dispositivo
Questo codice visualizza un'interfaccia utente in cui viene chiesto all'utente di impostare una password:
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 un password contenente almeno caratteri alfabetici (o altri simboli).
PASSWORD_QUALITY_ALPHANUMERIC
- L'utente deve inserire un password contenente almeno sia numerici e alfabetici (oppure (altro simbolo).
PASSWORD_QUALITY_NUMERIC
- L'utente deve inserire una password contenente almeno caratteri numerici.
PASSWORD_QUALITY_COMPLEX
- L'utente deve essere stata inserita una password contenente almeno una lettera, una cifra numerica un simbolo speciale.
PASSWORD_QUALITY_SOMETHING
- Il richiede una sorta di della password, ma non gli importa cosa sia.
PASSWORD_QUALITY_UNSPECIFIED
- Il criterio non ha requisiti per la password.
Ad esempio, ecco come puoi impostare i criteri relativi alle password in modo che richiedano una password alfanumerica:
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 requisiti per i contenuti delle password
A partire da Android 3.0, la classe DevicePolicyManager
include metodi che consentono di ottimizzare il contenuto della password. Per
Ad esempio, puoi impostare un criterio per stabilire che le password debbano contenere almeno
n lettere maiuscole. Di seguito sono riportati i metodi per il perfezionamento
contenuti:
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);
Impostare la lunghezza minima della password
Puoi specificare che una password debba essere almeno del valore minimo specificato lunghezza. 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 consentito di tentativi di inserimento della password non riusciti prima del i dati del dispositivo (ovvero il ripristino delle 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 timeout scadenza password
A partire da Android 3.0, puoi utilizzare
setPasswordExpirationTimeout()
per impostare la scadenza di una password, espressa come delta in millisecondi dalla data in cui l'amministratore del dispositivo imposta il timeout per la 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 password in base alla cronologia
A partire da Android 3.0, puoi utilizzare
setPasswordHistoryLength()
per limitare l'accesso
di riutilizzare le vecchie password. Questo metodo richiede una lunghezza
, che specifica quanti
vengono memorizzate. Quando questo criterio è attivo, gli utenti non possono inserirne uno nuovo
che corrisponda alle ultime n password. In questo modo
di usare la stessa password più volte. Questo criterio viene in genere utilizzato
in combinazione con
setPasswordExpirationTimeout()
,
che obbliga gli utenti
di aggiornare le password una volta trascorso un determinato periodo di tempo.
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 del i blocchi del dispositivo. 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 impostare in modo programmatico il dispositivo in modo che venga bloccato immediatamente:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Esegui la cancellazione dei dati
Puoi usare il metodo DevicePolicyManager
wipeData()
per ripristinare le impostazioni di fabbrica del dispositivo. È utile
in caso di smarrimento o furto del dispositivo. Spesso la decisione di cancellare i dati dal dispositivo
risultato del soddisfacimento di determinate condizioni. Ad esempio, puoi utilizzare
setMaximumFailedPasswordsForWipe()
per indicare che un dispositivo dovrebbe essere
cancellazione dei dati dopo un determinato numero 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()
utilizza come suo
una maschera di bit con opzioni aggiuntive. Attualmente il valore deve essere 0.
Disattiva videocamera
A partire da Android 4.0, puoi disattivare la fotocamera. Tieni presente che questa disattivazione non deve necessariamente comportare una disattivazione definitiva. La videocamera può essere attivata/disattivata in modo dinamico in base al contesto, all'ora e così via.
Puoi controllare se la videocamera è disattivata utilizzando il
setCameraDisabled()
. Ad esempio, questo snippet consente di attivare o disattivare la videocamera in base all'impostazione di una 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
setStorageEncryption()
per impostare un criterio che richieda la crittografia dell'area di archiviazione, se supportato.
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);
Per un esempio completo di come attivare la crittografia dello spazio di archiviazione, vedi l'esempio dell'API di amministrazione dei dispositivi.
Altri esempi di codice
Android AppRestrictionEnforcer e DeviceOwner esempi dimostrano ulteriormente l'uso delle API trattate in questa pagina.