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 administração 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 de Administração de Dispositivo Android. A API Device Administration oferece recursos de administração de dispositivos no nível do sistema. Essas APIs permitem criar apps com reconhecimento de segurança que são úteis em ambientes corporativos, em que os profissionais de TI precisam de 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 o suporte ao Exchange. No app de e-mails, os administradores do Exchange podem aplicar políticas de senha, incluindo senhas alfanuméricas ou PINs numéricos, em todos os dispositivos. Os administradores também podem limpar remotamente (ou seja, restaurar os padrões de fábrica) os aparelhos perdidos ou roubados. Os usuários do Exchange podem sincronizar os dados de e-mail e agenda.

Este documento é destinado a desenvolvedores que querem criar soluções empresariais para dispositivos Android. Ele aborda os vários recursos fornecidos pela API Device Administration para oferecer mais segurança aos dispositivos de funcionários com tecnologia Android.

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

Modo de proprietário do dispositivo headless

O Android 14 (nível 34 da API) apresenta o modo de usuário do sistema headless (dispositivos em que 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 interagir com o usuário final. O Android 14 também apresenta um modo afiliado de proprietário do dispositivo headless, que adiciona um proprietário do 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), apenas as políticas do dispositivo que são globais em escopo (políticas aplicáveis a todos os usuários) são aplicadas ao usuário ou 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?

Use a API Device Administration para criar aplicativos para o administrador de dispositivos que os usuários instalam nos próprios dispositivos. O app de administração do dispositivo aplica as políticas desejadas. Veja como funciona:

• Um administrador do sistema cria um aplicativo para o administrador do dispositivo que aplica políticas de segurança remotas/locais. Essas políticas podem ser codificadas no app ou buscadas 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 que um sysadmin pode distribuir o app aos 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 aplicativo para o administrador do dispositivo. Como e quando isso acontece depende de como o app é implementado.
• Depois que os usuários ativam o aplicativo para o administrador do dispositivo, eles ficam sujeitos às políticas dele. A conformidade com essas políticas geralmente confere benefícios, como 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 um usuário não obedecer às políticas (por exemplo, se ele definir uma senha que viole as diretrizes), cabe ao app decidir como lidar com isso. No entanto, isso geralmente impede que o usuário sincronize dados.

Se um dispositivo tentar se conectar a um servidor que exige políticas não compatí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 legado) não for compatível com todas as políticas declaradas, não será possível permitir que ele se conecte.

Se um dispositivo tiver vários aplicativos para o administrador ativados, a política mais rigorosa será aplicada. Não é possível segmentar um aplicativo para o administrador específico.

Para desinstalar um app de administração de dispositivo, os usuários precisam primeiro cancelar o registro do app como administrador.

Políticas

Em um ambiente empresarial, é comum que os dispositivos dos funcionários precisem aderir a 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 só aceita senhas para bloqueio de tela:

Tabela 1. Políticas compatíveis com a API Device Administration.

Outros recursos

Além de oferecer suporte às políticas listadas na tabela acima, a API Device Administration permite que você faça 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 nos exemplos do SDK (disponíveis no 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 do usuário que permite ativar o aplicativo para o administrador do dispositivo. Depois de ativar o aplicativo, eles podem usar os botões na interface do usuário para fazer o seguinte:

• Definir a qualidade da senha.
• Especifique os requisitos para a senha do usuário, como o tamanho mínimo, o número mínimo de caracteres numéricos que ela precisa conter e assim por diante.
• Definir a senha. Se a senha não estiver em conformidade com as políticas especificadas, o sistema retornará um erro.
• Defina quantas tentativas malsucedidas de digitação da 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 impede que os usuários reutilizem uma das últimas n senhas que usaram 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 que pode decorrer 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 aplique 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 dispositivos.

Criar o manifesto

Para usar a API Device Administration, o manifesto do app precisa incluir o seguinte:

• Uma subclasse de DeviceAdminReceiver que inclui o seguinte:
  • A permissão BIND_DEVICE_ADMIN;
  • A capacidade de responder à intent ACTION_DEVICE_ADMIN_ENABLED, expressa no manifesto como um filtro de intent.
• 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>

Observações:

• Os atributos a seguir se referem a 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 da permissão legível pelo usuário. Uma descrição geralmente é 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 apenas o sistema possa interagir com o receptor (nenhum app pode receber essa permissão). Isso impede que outros apps abusem do seu aplicativo para o administrador do 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. Isso é definido para o receptor quando o usuário ativa o aplicativo para o administrador do dispositivo. Seu código normalmente processa isso em onEnabled(). Para que haja suporte, o receptor também precisa exigir a permissão BIND_DEVICE_ADMIN para que outros apps não possam abusar dela.
• Quando um usuário ativa o aplicativo para o administrador do dispositivo, o receptor recebe permissão para realizar ações em resposta à transmissão de determinados eventos 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 ele escolha uma senha diferente que atenda aos requisitos.
• Evite mudar o nome do receptor 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 fornecem mais informações específicas ao 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 dispositivos, não é necessário incluir todas as políticas, apenas as que são relevantes para o app.

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 facilita a interpretação das ações de intent brutas enviadas pelo sistema. O app de administração de dispositivos 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 que o usuário tenha ativado. O DevicePolicyManager gerencia políticas para uma ou mais instâncias do DeviceAdminReceiver

DeviceAdminInfo

Essa classe é usada para especificar metadados de um componente de administrador do dispositivo.

Essas classes fornecem a base para um aplicativo para o administrador de dispositivos totalmente funcional. O restante desta seção descreve como usar as APIs DeviceAdminReceiver e DevicePolicyManager para criar um aplicativo para o administrador de dispositivos.

Subclasse DeviceAdminReceiver

Para criar um aplicativo para o administrador do dispositivo, é necessário criar uma subclasse de DeviceAdminReceiver. A classe DeviceAdminReceiver consiste em uma série de callbacks que são acionados quando determinados eventos ocorrem.

Na subclasse DeviceAdminReceiver, o app de exemplo simplesmente mostra uma notificação Toast em resposta a eventos específicos. Exemplo:

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))
...
}

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 aplicativo para o administrador de dispositivo precisa processar é a ativação do app pelo usuário. 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 vai estar presente no dispositivo, mas as políticas não serão aplicadas, e o usuário não vai receber nenhum dos benefícios 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 Ativar administrador, a tela muda para solicitar que o usuário ative o aplicativo para o administrador, 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 ele ative o aplicativo para o administrador do dispositivo, como mostrado na Figura 2. Caso contrário, o app de administração de dispositivo será desativado.

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
}

@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) indica 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 sobre como adicionar o administrador do dispositivo ao sistema (ou permite que eles o rejeitem).

Quando o app precisa realizar uma operação que depende da ativação do aplicativo para o administrador do dispositivo, ele confirma que o app está ativo. Para isso, ele usa o método DevicePolicyManager isAdminActive(). O método DevicePolicyManager isAdminActive() usa um componente DeviceAdminReceiver como argumento:

private lateinit var dpm: DevicePolicyManager
...
private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)

DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
    return dpm.isAdminActive(deviceAdminSample);
}

Como gerenciar políticas

DevicePolicyManager é uma classe pública para gerenciar políticas aplicadas a um dispositivo. O DevicePolicyManager gerencia políticas para uma ou mais instâncias do DeviceAdminReceiver.

Você consegue um identificador para o DevicePolicyManager da seguinte maneira:

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

DevicePolicyManager dpm =
    (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);

Nesta seção, descrevemos 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 aplicar a política de senha do dispositivo. Na API Device Administration, a senha só se aplica ao bloqueio de tela. Esta seção descreve tarefas comuns relacionadas a senhas.

Definir uma senha para o dispositivo

Este código mostra uma interface do usuário que solicita que o usuário defina uma senha:

Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
    startActivity(intent)
}

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 tanto caracteres numéricos quanto 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 ter inserido uma senha com pelo menos uma letra, um número e um símbolo especial.

PASSWORD_QUALITY_SOMETHING

A política exige algum tipo de senha, mas não se importa com o que ela é.

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:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)

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, é possível definir uma política que determine 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:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwMinUppercase = 2
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase)

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwMinUppercase = 2;
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase);

Definir o tamanho mínimo da senha

É possível especificar que uma senha precisa ter pelo menos o tamanho mínimo especificado. Exemplo:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwLength: Int = ...
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwLength;
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);

Definir o número máximo de tentativas de senha

É possível definir o número máximo de tentativas de senha incorretas permitidas antes que o dispositivo seja excluído permanentemente (ou seja, redefinido para as configurações originais). Exemplo:

val dPM:DevicePolicyManager
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val maxFailedPw: Int = ...
...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)

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, expressa como um delta em milissegundos a partir do momento em que um administrador do dispositivo define o tempo limite de validade. Exemplo:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwExpiration: Long = ...
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)

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 impede que os usuários usem a mesma senha repetidamente. Essa política geralmente é usada com setPasswordExpirationTimeout(), que força os usuários a atualizar as senhas após um período especificado.

Por exemplo, o snippet a seguir proíbe que os usuários reutilizem as últimas cinco senhas:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwHistoryLength = 5
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwHistoryLength = 5;
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength);

Definir bloqueio de dispositivo

É possível definir o período máximo de inatividade do usuário que pode ocorrer antes que o dispositivo seja bloqueado. Exemplo:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val timeMs: Long = 1000L * timeout.text.toString().toLong()
...
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)

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:

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

DevicePolicyManager dpm;
dpm.lockNow();

Realizar a exclusão permanente de dados

Use o método DevicePolicyManager wipeData() para redefinir o dispositivo para as configurações originais. Isso é útil se o dispositivo for perdido ou roubado. Muitas vezes, a decisão de excluir permanentemente o dispositivo é o resultado de determinadas condições serem atendidas. Por exemplo, é possível usar setMaximumFailedPasswordsForWipe() para declarar que um dispositivo precisa ser limpo após um número específico de tentativas de senha com falha.

Para excluir os dados permanentemente, faça o seguinte:

private lateinit var dpm: DevicePolicyManager
dpm.wipeData(0)

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 está 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:

private lateinit var disableCameraCheckbox: CheckBoxPreference
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)

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 exija a criptografia da área de armazenamento, quando houver suporte.

Exemplo:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setStorageEncryption(deviceAdminSample, true)

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

Os exemplos Android AppRestrictionEnforcer e DeviceOwner demonstram com mais detalhes o uso das APIs abordadas nesta página.