Suspensão de uso do administrador do dispositivo. A partir do Android 9 (nível 28 da API), algumas políticas de administrador serão marcadas como obsoletas quando invocadas por um administrador do dispositivo. Recomendamos que você comece a se preparar agora para essa mudança. Para saber mais e conferir as opções de migração, leia Suspensão de uso do administrador do dispositivo.
O Android inclui suporte a apps empresariais oferecendo a API Android Device Administration. A API Device Administration oferece recursos de administração de dispositivos no sistema. Essas APIs permitem criar apps com reconhecimento de segurança que são úteis em configurações corporativas, em que os profissionais de TI exigem um controle avançado sobre os dispositivos dos funcionários. Por exemplo, o app de e-mail integrado do Android usou essas APIs para melhorar a compatibilidade com o Exchange. Por meio do app de e-mails, os administradores do Exchange podem implementar políticas de senha em vários dispositivos, incluindo senhas alfanuméricas ou PINs numéricos. Os administradores também podem apagar remotamente os dispositivos perdidos ou roubados, ou seja, redefini-los para a configuração original. Os usuários do Exchange podem sincronizar os dados de e-mails e da agenda.
Este documento é destinado a desenvolvedores que querem criar soluções empresariais para dispositivos com tecnologia Android. Ele aborda os diversos recursos oferecidos pela API Device Administration para aumentar a segurança dos dispositivos Android usados pelos funcionários.
Observação: para informações sobre como criar um controlador de políticas profissionais para implantações do Android Enterprise, consulte Criar um controlador de política de dispositivo.
Modo de proprietário do dispositivo sem cabeça
O Android 14 (nível 34 da API) apresenta o modo de usuário do sistema sem cabeça (dispositivos em
que
UserManager.isHeadlessSystemUserMode
retorna true). No modo de usuário do sistema sem cabeça, o usuário do sistema é um
usuário em segundo plano e depende de outros usuários em primeiro plano para a interação
do usuário final. O Android 14 também apresenta um
modo afiliado de proprietário do dispositivo sem cabeça,
que adiciona um proprietário do perfil a todos
usuários afiliados
que não sejam o usuário do sistema em que o proprietário do dispositivo está definido.
Em dispositivos configurados com um usuário do sistema sem cabeça (em que o usuário do sistema
é executado em segundo plano), apenas as políticas de dispositivo que têm escopo global
(políticas aplicáveis a todos os usuários) são aplicadas aos usuários
em primeiro plano. Consulte
addUserRestriction
para mais detalhes.
Os fabricantes de dispositivos Android podem consultar as orientações publicadas em source.android.com.
Visão geral da API Device Administration
Veja alguns exemplos dos tipos de apps que podem usar a API Device Administration:
- Clientes de e-mail
- Apps de segurança que fazem apagamento remoto
- Apps e serviços de gerenciamento de dispositivos
Como funciona?
A API Device Administration é usada para gravar apps de administração de dispositivo que os usuários instalam. O app de administração de dispositivo implementa as políticas desejadas. Veja como funciona:
- Um administrador do sistema cria um app de administração de dispositivo que implementa políticas de segurança de dispositivos remotos/locais. Essas políticas podem ser codificadas no app ou o app pode buscar políticas de um servidor de terceiros de forma dinâmica.
- O app é instalado nos dispositivos dos usuários. No momento, o Android
não tem uma solução automática de provisionamento. Algumas das maneiras com que um administrador do sistema distribui o app para os usuários são as seguintes:
- Google Play
- Ativação da instalação a partir de outra loja
- Distribuição do app por outros meios, como e-mails ou sites
- O sistema solicita que o usuário ative o app de administração de dispositivo. Como e quando isso acontece depende de como o app é implementado.
- Quando os usuários ativarem o app de administração de dispositivo, eles estarão sujeitos às políticas relacionadas. O cumprimento dessas políticas normalmente traz alguns benefícios, como o acesso a sistemas e dados sensíveis.
Se os usuários não ativarem o app de administração de dispositivo, ele permanecerá no dispositivo, mas em um estado inativo. O usuário não estará sujeito às políticas e, por outro lado, não receberá nenhum dos benefícios do app. Por exemplo, não será possível sincronizar dados.
Se o usuário não obedecer às políticas (por exemplo, definir uma senha que viole as diretrizes), cabe ao app decidir como lidar com isso. No entanto, isso normalmente faz com que o usuário não consiga sincronizar dados.
Se um dispositivo tentar se conectar a um servidor que exija políticas incompatíveis com a API Device Administration, a conexão não será permitida. No momento, a API Device Administration não permite o provisionamento parcial. Em outras palavras, se um dispositivo (por exemplo, um dispositivo herdado) não for compatível com todas as políticas estabelecidas, não será possível permitir que o dispositivo se conecte.
Se um dispositivo tiver vários apps de administração ativados, a política mais rigorosa será aplicada. Não há como segmentar um app de administração específico.
Para desinstalar um app de administração de dispositivo, o usuário precisa cancelar o registro do app como administrador.
Políticas
Em uma configuração empresarial, é comum que os dispositivos de funcionários precisem adotar um conjunto estrito de políticas que regem o uso do dispositivo. A API Device Administration é compatível com as políticas listadas na Tabela 1. No momento, a API Device Administration é compatível apenas com senhas para bloqueio de tela:
Tabela 1. Políticas compatíveis com a API Device Administration.
| Política | Descrição |
|---|---|
| Senha ativada | Exige que os dispositivos solicitem PIN ou senhas. |
| Tamanho mínimo da senha | Define o número de caracteres necessários para a senha. Por exemplo, você pode exigir que o PIN ou as senhas tenham pelo menos seis caracteres. |
| Senha alfanumérica necessária | Exige que as senhas tenham uma combinação de letras e números. Caracteres simbólicos podem ser usados. |
| Senha complexa necessária | Exige que as senhas contenham pelo menos uma letra, um dígito numérico e um símbolo especial. Introduzido no Android 3.0. |
| Número mínimo de letras necessário na senha | O número mínimo de letras exigido na senha para todos os administradores ou para um determinado usuário. Introduzido no Android 3.0. |
| Número mínimo de letras minúsculas necessário na senha | O número mínimo de letras minúsculas exigido na senha para todos os administradores ou para um determinado usuário. Introduzido no Android 3.0. |
| Número mínimo de caracteres diferentes de letras exigido na senha | O número mínimo de caracteres diferentes de letras exigido na senha para todos os administradores ou para um determinado usuário. Introduzido no Android 3.0. |
| Número mínimo de dígitos exigido na senha | O número mínimo de dígitos numéricos necessário na senha para todos os administradores ou para um determinado usuário. Introduzido no Android 3.0. |
| Número mínimo de símbolos necessário na senha | O número mínimo de símbolos exigido na senha para todos os administradores ou para um determinado usuário. Introduzido no Android 3.0. |
| Número mínimo de letras maiúsculas exigido na senha | O número mínimo de letras maiúsculas exigido na senha para todos os administradores ou para um determinado usuário. Introduzido no Android 3.0. |
| Tempo limite de expiração da senha | Momento de expiração da senha, expresso como um delta em milésimos de segundo a partir do momento em que um administrador do dispositivo define o tempo limite de expiração. Introduzido no Android 3.0. |
| Restrição do histórico de senhas | Essa política evita que os usuários reutilizem as últimas n senhas exclusivas.
Em geral, essa política é usada em conjunto com
setPasswordExpirationTimeout(), que força
os usuários a atualizar as senhas depois de um determinado período.
Introduzido no Android 3.0. |
| Número máximo de tentativas de senha | Especifica quantas vezes um usuário pode inserir a senha errada antes que o dispositivo exclua permanentemente os dados. A API Device Administration também permite que os administradores redefinam remotamente o dispositivo para a configuração original. Isso protege os dados caso o dispositivo seja perdido ou roubado. |
| Tempo máximo de inatividade para bloqueio | Define o tempo a partir da última vez que o usuário toca na tela ou pressiona um botão antes que o dispositivo bloqueie a tela. Quando isso acontece, os usuários precisam inserir o PIN ou as senhas novamente para usar o dispositivo e acessar os dados. O valor pode variar entre 1 e 60 minutos. |
| Exigir criptografia de armazenamento | Especifica que a área de armazenamento que deverá ser criptografada, se o dispositivo for compatível com essa ação. Introduzido no Android 3.0. |
| Desativar câmera | Especifica que a câmera deve ser desativada. Essa desativação não precisa ser permanente. A câmera pode ser ativada ou desativada de forma dinâmica com base no contexto, no horário e assim por diante. Introduzido no Android 4.0. |
Outros recursos
Além de oferecer compatibilidade com as políticas listadas na tabela acima, a API Device Administration permite fazer o seguinte:
- Solicitar que o usuário defina uma nova senha.
- Bloquear o dispositivo imediatamente.
- Excluir permanentemente os dados do dispositivo (ou seja, restaurar o dispositivo para a configuração original).
App de exemplo
Os exemplos usados nesta página são baseados no exemplo da API Device Administration, que está incluído nas amostras do SDK (disponíveis pelo
Android SDK Manager) e localizado no sistema como
<sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java.
O app de exemplo oferece uma demonstração dos recursos do administrador do dispositivo. Ele apresenta aos usuários uma interface que permite ativar o app de administração de dispositivo. Depois de ativar o app, é possível usar os botões na interface do usuário para fazer o seguinte:
- Definir a qualidade da senha.
- Especificar os requisitos para a senha do usuário, como tamanho mínimo, número mínimo de caracteres numéricos e assim por diante.
- Definir a senha. Se a senha não estiver de acordo com as políticas especificadas, o sistema retornará um erro.
- Defina quantas tentativas de senha podem ocorrer antes que o dispositivo seja apagado (ou seja, restaurado para as configurações originais).
- Definir o tempo de validade da senha.
- Definir o tamanho do histórico de senhas (tamanho se refere ao número de senhas antigas armazenadas no histórico). Isso impede que os usuários reutilizem uma das últimas n senhas usadas anteriormente.
- Especificar que a área de armazenamento deverá ser criptografada, se o dispositivo for compatível com essa ação.
- Definir o tempo máximo de inatividade antes que o dispositivo seja bloqueado.
- Fazer o dispositivo ser bloqueado imediatamente.
- Excluir permanentemente os dados do dispositivo, ou seja, redefini-lo para a configuração original.
- Desativar a câmera.
Figura 1. Captura de tela do app de exemplo.
Desenvolver um app de administração de dispositivo
Os administradores do sistema podem usar a API Device Administration para criar um app que implemente a política de segurança de dispositivos remotos/locais. Esta seção resume as etapas envolvidas na criação de um app de administração de dispositivo.
Criar o manifesto
Para usar a API Device Administration, o manifesto do app precisa incluir o seguinte:
- Uma subclasse de
DeviceAdminReceiverque inclua:- a permissão
BIND_DEVICE_ADMIN; - A capacidade de responder à intent
ACTION_DEVICE_ADMIN_ENABLED, expressa no manifesto como um filtro de intent.
- a permissão
- Uma declaração de políticas de segurança usadas em metadados.
Este é um trecho da amostra de manifesto da Device Administration:
<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>
Algumas considerações:
- Os atributos a seguir se referem aos recursos de string que, para o app de exemplo, residem em
ApiDemos/res/values/strings.xml. Para mais informações sobre recursos, consulte Recursos do aplicativo.android:label="@string/activity_sample_device_admin"se refere ao rótulo legível pelo usuário para a atividade.android:label="@string/sample_device_admin"se refere ao rótulo legível pelo usuário para a permissão.android:description="@string/sample_device_admin_description"se refere à descrição legível pelo usuário da permissão. Uma descrição normalmente é mais longa e mais informativa do que um rótulo.
android:permission="android.permission.BIND_DEVICE_ADMIN"é uma permissão que uma subclasseDeviceAdminReceiverprecisa ter para garantir que apenas o sistema possa interagir com o destinatário (nenhum app pode receber essa permissão). Isso impede que outros apps abusem do app de administrador do dispositivo.android.app.action.DEVICE_ADMIN_ENABLEDé a principal ação que uma subclasseDeviceAdminReceiverprecisa processar para ter permissão para gerenciar um dispositivo. Isso é definido para o destinatário quando o usuário ativa o app de administração de dispositivo. Em geral, seu código processa isso emonEnabled(). Para ser aceito, o destinatário também precisa exigir a permissãoBIND_DEVICE_ADMINpara que outros apps não abusem dela.- Quando um usuário ativa o app de administração de dispositivo, o destinatário recebe permissão para realizar ações em resposta à transmissão de eventos específicos do sistema. Quando um evento adequado surgir, o app poderá impor uma política. Por exemplo, se o usuário tentar definir uma nova senha que não atenda aos requisitos da política, o app poderá solicitar que o usuário escolha uma senha diferente que atenda a essas exigências.
- Evite mudar o nome do destinatário depois de publicar o app. Se o nome no
manifesto mudar, o administrador do dispositivo será desativado quando os usuários atualizarem o app. Para saber mais, consulte
<receiver>. android:resource="@xml/device_admin_sample"declara as políticas de segurança usadas nos metadados. Os metadados oferecem mais informações específicas para o administrador do dispositivo, conforme analisado pela classeDeviceAdminInfo. Confira o conteúdo dedevice_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>
Ao projetar seu app de administração de dispositivo, não é necessário incluir todas as políticas, apenas aquelas que são relevantes para o app.
Para mais discussões sobre o arquivo de manifesto, consulte o Guia para desenvolvedores Android.Implementar o código
A API Device Administration inclui as seguintes classes:
DeviceAdminReceiver- Classe básica para implementar um componente de administração do dispositivo. Essa classe oferece
conveniência para a interpretação de ações de intent brutas que são enviadas pelo
sistema. Seu app de administração de dispositivo precisa incluir uma
subclasse
DeviceAdminReceiver. DevicePolicyManager- Uma classe de gerenciamento de políticas implementadas em um dispositivo. A maioria dos clientes dessa
classe precisa ter publicado um
DeviceAdminReceiverque o usuário tenha ativado. ODevicePolicyManagergerencia políticas para uma ou mais instânciasDeviceAdminReceiver.
DeviceAdminInfo- Essa classe é usada para especificar metadados para um componente do administrador do dispositivo.
Essas classes oferecem a base para um app de administração de dispositivo totalmente funcional.
O restante desta seção descreve como usar as APIs DeviceAdminReceiver e
DevicePolicyManager para criar um app de administração de dispositivo.
Subclasse DeviceAdminReceiver
Para criar um app de administração de dispositivo, é necessário criar uma subclasse de
DeviceAdminReceiver. A classe DeviceAdminReceiver
consiste em uma série de callbacks que são acionados quando eventos específicos
ocorrem.
Na subclasse DeviceAdminReceiver, o app de exemplo
exibe apenas uma notificação Toast em resposta a eventos
específicos. Exemplo:
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));
}
...
}
Ativar o app
Um dos principais eventos que um app de administração de dispositivo precisa processar é aquele em que o usuário ativa o app. O usuário precisa ativar explicitamente o app para que as políticas sejam implementadas. Se o usuário optar por não ativar o app, ele continuará no dispositivo, mas as políticas relacionadas não entrarão em vigor, e o usuário não receberá nenhum benefício do app.
O processo de ativação do app começa quando o usuário realiza uma
ação que aciona o intent
ACTION_ADD_DEVICE_ADMIN. No
app de exemplo, isso acontece quando o usuário clica na caixa de seleção Enable
Admin.
Quando o usuário clica na caixa de seleção Enable Admin, a tela muda para solicitar que o usuário ative o app de administração de dispositivo, conforme mostrado na figura 2.
Figura 2. App de exemplo: ativação do app.
Veja abaixo o código que é executado quando o usuário clica na caixa de seleção Enable Admin. Isso tem o efeito de acionar o
callback
onPreferenceChange(). Esse callback será invocado quando o valor de Preference tiver sido alterado pelo usuário e estiver prestes a ser definido e/ou persistido. Se o usuário estiver ativando o app, a tela
vai mudar para solicitar que o usuário ative o app de administração de dispositivo, como mostrado na figura
2. Caso contrário, o app de administração de dispositivo será desativado.
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;
}
A linha
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample) declara que mDeviceAdminSample (que é
um componente DeviceAdminReceiver) é a política de destino.
Essa linha invoca a interface do usuário mostrada na Figura 2, que orienta os usuários a adicionar o administrador do dispositivo ao sistema (ou permite que o rejeitem).
Quando o app precisa realizar uma operação que depende da ativação do
app de administração de dispositivo, ele confirma se o app está
ativo. Para fazer isso, ele usa o método isAdminActive()
DevicePolicyManager. Observe que o método isAdminActive()
do DevicePolicyManager usa um componente DeviceAdminReceiver
como argumento:
Kotlin
private lateinit var dpm: DevicePolicyManager ... private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)
Java
DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
return dpm.isAdminActive(deviceAdminSample);
}
Gerenciar políticas
DevicePolicyManager é uma classe pública para gerenciar políticas
implementadas em um dispositivo. DevicePolicyManager gerencia políticas para uma
ou mais instâncias DeviceAdminReceiver.
Você consegue um identificador para o DevicePolicyManager da seguinte maneira:
Kotlin
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
Java
DevicePolicyManager dpm =
(DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
Esta seção descreve como usar DevicePolicyManager para realizar
tarefas administrativas:
- Definir políticas de senha.
- Definir o bloqueio do dispositivo.
- Realizar a exclusão permanente de dados.
Definir políticas de senha
DevicePolicyManager inclui APIs para definir e implementar a
política de senha do dispositivo. Na API Device Administration, a senha é válida apenas para
o bloqueio de tela. Esta seção descreve tarefas comuns relacionadas a senhas.
Definir uma senha para o dispositivo
Este código exibe uma interface solicitando que o usuário defina uma senha:
Kotlin
Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
startActivity(intent)
}
Java
Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); startActivity(intent);
Definir a qualidade da senha
A qualidade da senha pode ser uma das seguintes constantes DevicePolicyManager:
PASSWORD_QUALITY_ALPHABETIC- O usuário precisa inserir uma senha que contenha pelo menos caracteres alfabéticos (ou outros símbolos).
PASSWORD_QUALITY_ALPHANUMERIC- O usuário precisa inserir uma senha que contenha pelo menos tanto caracteres numéricos quanto caracteres alfabéticos (ou outros símbolos).
PASSWORD_QUALITY_NUMERIC- O usuário precisa inserir uma senha que contenha pelo menos caracteres numéricos.
PASSWORD_QUALITY_COMPLEX- O usuário precisa ter inserido uma senha que contenha pelo menos uma letra, um dígito numérico e um símbolo especial.
PASSWORD_QUALITY_SOMETHING- A política exige algum tipo de senha, mas não importa qual seja.
PASSWORD_QUALITY_UNSPECIFIED- A política não tem requisitos para a senha.
Por exemplo, é assim que você definiria a política para exigir uma senha alfanumérica:
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);
Definir requisitos de conteúdo da senha
A partir do Android 3.0, a classe DevicePolicyManager
inclui métodos que permitem ajustar o conteúdo da senha. Por
exemplo, você pode definir uma política que declare que as senhas precisam conter pelo menos
n letras maiúsculas. Confira os métodos para ajustar o conteúdo de uma
senha:
setPasswordMinimumLetters()setPasswordMinimumLowerCase()setPasswordMinimumUpperCase()setPasswordMinimumNonLetter()setPasswordMinimumNumeric()setPasswordMinimumSymbols()
Por exemplo, o snippet afirma que a senha precisa ter pelo menos duas letras maiúsculas:
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);
Definir o tamanho mínimo da senha
É possível especificar que uma senha tenha o tamanho mínimo especificado. Exemplo:
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);
Definir o número máximo de tentativas de senha
Você pode definir o número máximo de tentativas de senha antes de o dispositivo ser excluído permanentemente, ou seja, redefinido para a configuração original. Exemplo:
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);
Definir tempo limite para expiração da senha
A partir do Android 3.0, é possível usar o método
setPasswordExpirationTimeout()
para definir quando uma senha vai expirar, expresso como um delta em milésimos de segundo a partir do momento em que o administrador do dispositivo define o tempo limite de expiração. Exemplo:
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);
Restringir senha com base no histórico
A partir do Android 3.0, é possível usar o
método
setPasswordHistoryLength() para limitar a capacidade dos usuários
de reutilizar senhas antigas. Esse método usa um parâmetro length, que especifica quantas senhas
antigas são armazenadas. Quando essa política está ativa, os usuários não podem inserir uma nova
senha igual às últimas n. Isso evita que os usuários utilizem a mesma senha várias vezes. Em geral, essa política é usada
em conjunto com
setPasswordExpirationTimeout(),
que força os usuários
a atualizar as senhas depois de um determinado período.
Por exemplo, o snippet a seguir proíbe que os usuários reutilizem as últimas cinco senhas:
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);
Definir bloqueio de dispositivo
Você pode definir o período máximo de inatividade do usuário antes de o dispositivo ser bloqueado. Exemplo:
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);
Também é possível dizer programaticamente ao dispositivo para ser bloqueado imediatamente:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Realizar a exclusão permanente de dados
Você pode usar o método DevicePolicyManager
wipeData() para redefinir o dispositivo para a configuração original. Isso é útil
se o dispositivo for perdido ou roubado. Muitas vezes, a decisão de excluir permanentemente os dados do dispositivo é o
resultado do cumprimento de determinadas condições. Por exemplo, você pode usar
setMaximumFailedPasswordsForWipe() para declarar que um dispositivo deve ser
excluído permanentemente depois de um determinado número de tentativas de senha.
Para excluir os dados permanentemente, faça o seguinte:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Java
DevicePolicyManager dpm; dpm.wipeData(0);
O método wipeData() usa como parâmetro uma
máscara de bits de opções adicionais. Atualmente, o valor precisa ser zero.
Desativar câmera
A partir do Android 4.0, é possível desativar a câmera. Essa desativação não precisa ser permanente. A câmera pode ser ativada ou desativada de forma dinâmica com base no contexto, no horário e assim por diante.
Você controla se a câmera será desativada usando o
método setCameraDisabled(). Por exemplo, este snippet define a câmera como ativada ou desativada com base em uma configuração de caixa de seleção:
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());
Criptografia de armazenamento
A partir do Android 3.0, é possível usar o método
setStorageEncryption()
para definir uma política que exige a criptografia da área de armazenamento, quando compatível.
Exemplo:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setStorageEncryption(deviceAdminSample, true)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setStorageEncryption(deviceAdminSample, true);
Consulte o exemplo da API Device Administration para conferir um exemplo completo de como ativar a criptografia de armazenamento.
Outros exemplos de código
As amostras Android AppRestrictionEnforcer e DeviceOwner demonstram com mais detalhes o uso das APIs abordadas nesta página.