Visão geral da administração de dispositivos

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 descontinuadas 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 Descontinuação do administrador do dispositivo.

O Android inclui suporte para 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 úteis em configurações empresariais, em que os profissionais de TI exigem amplo controle sobre os dispositivos dos funcionários. Por exemplo, o app de e-mail integrado do Android aproveitou essas APIs para melhorar o suporte ao Exchange. Pelo app de e-mail, os administradores do Exchange podem aplicar políticas de senha, incluindo senhas alfanuméricas ou PINs numéricos, em vários dispositivos. Os administradores também podem apagar remotamente (ou seja, restaurar padrões de fábrica) celulares perdidos ou roubados. Os usuários do Exchange podem sincronizar os dados do e-mail e da agenda.

Este documento é destinado a desenvolvedores que querem desenvolver soluções empresariais para dispositivos com tecnologia Android. Ele discute os vários recursos fornecidos pela API Device Administration para reforçar a segurança dos dispositivos de funcionários com tecnologia Android.

Observação: para informações sobre como criar um controlador de políticas profissionais para implantações do Android for Work, consulte Criar um controlador de política de dispositivo.

Modo Proprietário do dispositivo headless

O Android 14 (nível 34 da API) introduz o modo de usuário do sistema headless (dispositivos em que o UserManager.isHeadlessSystemUserMode retorna true). Nesse modo, o usuário do sistema é um usuário em segundo plano e depende de outros usuários em primeiro plano para a interação com o usuário final. O Android 14 também introduz um modo afiliado para proprietário de dispositivo headless, que adiciona um proprietário de perfil a todos os usuários afiliados, exceto o usuário do sistema em que o proprietário do dispositivo está definido.

Em dispositivos configurados com um usuário do sistema headless (em que o usuário do sistema é executado em segundo plano), somente as políticas do dispositivo com escopo global (políticas aplicáveis a todos os usuários) são aplicadas ao usuário ou aos usuários em primeiro plano. Consulte addUserRestriction para ver 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?

Use a API Device Administration para gravar apps de administração de dispositivo que os usuários instalam nos dispositivos. O app de administração de dispositivo aplica as políticas desejadas. Entenda como funciona:

  • Um administrador do sistema cria um app de administração de dispositivo que aplica políticas de segurança remotas/locais do dispositivo. Essas políticas podem ser codificadas no app ou ele pode buscar políticas dinamicamente em um servidor de terceiros.
  • O app é instalado nos dispositivos dos usuários. No momento, o Android não tem uma solução de provisionamento automatizada. Algumas das maneiras pelas quais um sysadmin pode distribuir 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.
  • Depois que os usuários ativam o app de administração de dispositivo, eles ficam sujeitos às políticas correspondentes. O cumprimento dessas políticas geralmente proporciona benefícios, como o acesso a sistemas e dados confidenciais.

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 um usuário não estiver de acordo com as políticas (por exemplo, se definir uma senha que viola 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 sem suporte na 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 legado) não é compatível com todas as políticas declaradas, não há como permitir que ele 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 existente, os usuários precisam cancelar a inscrição do app como administrador.

Políticas

Em uma configuração corporativa, os dispositivos de funcionários geralmente precisam seguir um conjunto rigoroso 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, é possível 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 necessárias 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. Geralmente, esta política é usada em conjunto com setPasswordExpirationTimeout(), que força os usuários a atualizar as senhas após um determinado período. Introduzido no Android 3.0.
Máximo de tentativas de senha com falha Especifica quantas vezes um usuário pode digitar 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 em caso de perda ou roubo do dispositivo.
Tempo máximo de inatividade para bloqueio Define o tempo desde a última vez que o usuário tocou na tela ou pressionou um botão antes de o dispositivo bloquear a tela. Quando isso acontece, os usuários precisam inserir o PIN ou as senhas novamente antes de usar os dispositivos 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/desativada dinamicamente com base no contexto, no horário e assim por diante. Introduzido no Android 4.0.

Outros recursos

Além de oferecer suporte às 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 na amostra da API Device Administration, que está incluída nas amostras do SDK (disponíveis no Android SDK Manager) e localizada no seu 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 para fazer o seguinte:

  • Definir a qualidade da senha.
  • Especifique 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 obedecer às políticas especificadas, o sistema retornará um erro.
  • Defina quantas tentativas de senha podem ocorrer antes que o dispositivo seja excluído permanentemente, 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 evita 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.
  • Defina o tempo máximo de inatividade antes do bloqueio do dispositivo.
  • 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 aplique a aplicação da 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:

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 abaixo 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 de 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" refere-se 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 subclasse DeviceAdminReceiver precisa ter para garantir que somente o sistema possa interagir com o receptor (nenhum app pode receber essa permissão). Isso impede que outros apps abusem do seu app de administração de dispositivo.
  • android.app.action.DEVICE_ADMIN_ENABLED é a ação principal que uma subclasse DeviceAdminReceiver precisa processar para ter permissão para gerenciar um dispositivo. É definido para o receptor quando o usuário ativa o app de administração de dispositivo. Seu código normalmente processa isso em onEnabled(). Para ter suporte, o receptor também precisa exigir a permissão BIND_DEVICE_ADMIN para que outros apps não abordem dela.
  • Quando um usuário ativa o app de administração de dispositivo, ele dá ao receptor permissão para executar 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 aos requisitos.
  • Evite mudar o nome do receptor após a publicação do 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>.
  • O android:resource="@xml/device_admin_sample" declara as políticas de segurança usadas nos metadados. Os metadados fornecem mais informações específicas para o administrador do dispositivo, conforme analisado pela classe DeviceAdminInfo. Este é o conteúdo de device_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 o app de administração de dispositivo, você não precisa incluir todas as políticas, apenas as relevantes para o app.

Para mais informações sobre o arquivo de manifesto, consulte o Guia do desenvolvedor 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 uma conveniência para interpretar as ações de intent brutas que são enviadas pelo sistema. O 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 DeviceAdminReceiver ativado pelo usuário no momento. O DevicePolicyManager gerencia as políticas de uma ou mais instâncias de DeviceAdminReceiver
DeviceAdminInfo
Essa classe é usada para especificar metadados para um componente do administrador do dispositivo.

Essas classes fornecem 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, você precisa criar uma subclasse DeviceAdminReceiver. A classe DeviceAdminReceiver consiste em uma série de callbacks que são acionados quando ocorrem eventos específicos.

Na subclasse DeviceAdminReceiver, o app de exemplo simplesmente exibe uma notificação Toast em resposta a eventos específicos. Por 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 é o usuário ativar o app. O usuário precisa ativar explicitamente o app para que as políticas sejam aplicadas. Se o usuário optar por não ativar o app, ele ainda estará presente no dispositivo, mas as políticas não serão aplicadas 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 a intent ACTION_ADD_DEVICE_ADMIN. No app de exemplo, isso acontece quando o usuário clica na caixa de seleção Ativar administrador.

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 aciona 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, conforme 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 o usuário na adição do administrador do dispositivo ao sistema (ou permite que ele o rejeite).

Quando o app precisa executar uma operação que depende da ativação do app de administração de dispositivo, ele confirma que o app está ativo. Para fazer isso, ele usa o método DevicePolicyManager isAdminActive(). Observe que o método DevicePolicyManager isAdminActive() 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 aplicadas em um dispositivo. DevicePolicyManager gerencia políticas para uma ou mais instâncias DeviceAdminReceiver.

Você recebe um handle 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 o DevicePolicyManager para executar tarefas administrativas:

Definir políticas de senha

O DevicePolicyManager inclui APIs para definir e aplicar a política de senha do dispositivo. Na API Device Administration, a senha se aplica apenas ao 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 contendo pelo menos ambos caracteres numéricos e caracteres alfabéticos (ou outros símbolos).
PASSWORD_QUALITY_NUMERIC
O usuário precisa inserir uma senha com pelo menos caracteres numéricos.
PASSWORD_QUALITY_COMPLEX
O usuário precisa inserir 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. Estes são os métodos para ajustar o conteúdo de uma senha:

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 pelo menos o tamanho mínimo especificado. Por 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 com falha antes que o dispositivo seja excluído permanentemente, ou seja, seja redefinido para a configuração original. Por 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

No Android 3.0 e versões mais recentes, é possível usar o método setPasswordExpirationTimeout() para definir quando uma senha expira, expresso como um delta em milissegundos a partir do momento em que um administrador do dispositivo define o tempo limite de expiração. Por 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 que corresponda às últimas n senhas. Isso evita que os usuários usem a mesma senha várias vezes. Geralmente, esta política é usada em conjunto com setPasswordExpirationTimeout(), que força os usuários a atualizar as senhas após 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 que o dispositivo seja bloqueado. Por 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 wipeData() do DevicePolicyManager para redefinir o dispositivo para as configurações originais. Isso será útil se o dispositivo for perdido ou roubado. Muitas vezes, a decisão de excluir permanentemente o dispositivo é resultado do cumprimento de determinadas condições. Por exemplo, você pode usar setMaximumFailedPasswordsForWipe() para declarar que um dispositivo precisa ser excluído após um número específico 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 bitmask de outras opções. 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

No Android 3.0 e versões mais recentes, é possível usar o método setStorageEncryption() para definir uma política que exija a criptografia da área de armazenamento, quando houver suporte.

Por 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 ver um exemplo completo de como ativar a criptografia de armazenamento.

Outros exemplos de código

As amostras Android AppRestrictionEnforcer e DeviceOwner (links em inglês) demonstram com mais detalhes o uso das APIs abordadas nesta página.