Visão geral da administração de dispositivos

Suspensão de uso do administrador do dispositivo. Do Android 9 em diante (nível 28 da API), algumas políticas de administrador serão marcadas como descontinuadas quando invocado pelo administrador do dispositivo. Recomendamos que você comece a se preparar agora para essa mudança. Para saber mais e ver 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 dispositivos de administração de recursos no nível do sistema. Essas APIs permitem criar apps com reconhecimento de segurança que são úteis em ambientes corporativos, em que o departamento de TI profissionais exigem amplo controle sobre os dispositivos dos funcionários. Por exemplo, o o aplicativo de e-mail integrado do Android aproveitou essas APIs para melhorar Suporte para Exchange. Com o aplicativo E-mail, os administradores do Exchange podem aplique políticas de senha, incluindo senhas alfanuméricas ou numéricas. PINs em vários dispositivos. Os administradores também podem apagar (ou seja, restaurar os padrões de fábrica em celulares perdidos ou roubados. Os usuários do Exchange podem sincronizar o e-mail e os dados da agenda.

Este documento é destinado a desenvolvedores que desejam desenvolver aplicativos para dispositivos com tecnologia Android. Ele discute os vários recursos da API Device Administration para reforçar a segurança dispositivos para funcionários com tecnologia Android.

Observação: informações sobre como criar uma política de trabalho 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 no quais UserManager.isHeadlessSystemUserMode retorna true). No modo de usuário do sistema headless, o usuário do sistema é um usuário em segundo plano e conta com outros usuários em primeiro plano interação. O Android 14 também apresenta modo afiliado para proprietário de dispositivo headless, que adiciona um proprietário do perfil usuários afiliados diferente do usuário do sistema para o qual o Proprietário do Dispositivo está definido.

Em dispositivos configurados com um usuário de sistema headless (em que o usuário do sistema forem executadas 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 em primeiro plano ou usuários. Consulte addUserRestriction para mais detalhes.

Os fabricantes de dispositivos Android podem consultar o orientação publicado 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 criar apps de administração de dispositivo que os usuários que instalam nos dispositivos deles. O app de administração de dispositivos aplica políticas. Veja como funciona:

• Um administrador do sistema cria um app de administração de dispositivo que aplica e políticas de segurança de dispositivos remotos/locais. Essas políticas podem ser codificadas o app ou ele poderia buscar políticas dinamicamente de um terceiro servidor.
• O app é instalado nos dispositivos dos usuários. O Android faz não tem uma solução de provisionamento automatizada. Algumas das maneiras pelas quais um administrador para 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 pede 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 ativarem o app de administração de dispositivo, eles estarão sujeitos à as políticas dele. A conformidade com essas políticas geralmente traz 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 estiver em conformidade com as políticas (por exemplo, se um usuário definir um que viole as diretrizes), cabe ao app decidir como lidar com isso. No entanto, isso normalmente faz com que o usuário possam sincronizar dados.

Se um dispositivo tentar se conectar a um servidor que exija políticas que não compatível com a API Device Administration, a conexão não ser permitida. No momento, a API Device Administration não permite na nuvem. Em outras palavras, se um dispositivo (por exemplo, um dispositivo legado) não oferece suporte a todas as políticas estabelecidas, não é possível permitir que o dispositivo para se conectar.

Se um dispositivo tiver vários apps de administração ativados, a política mais rigorosa será aplicadas. Não é possível segmentar um administrador específico app.

Para desinstalar um app de administração de dispositivo, os usuários precisam fazer o seguinte: cancele a inscrição do app como administrador.

Políticas

Em um ambiente corporativo, é comum que os dispositivos de funcionários precisem seguem um conjunto rigoroso de políticas que regem o uso do dispositivo. A 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 cadeado:

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, o plano A API 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 API Device Administration , que está incluído nas amostras do SDK (disponíveis por meio do 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. Ela apresenta aos usuários com uma interface do usuário que permite ativar o aplicativo de administração de dispositivo. Uma vez ele ativar o aplicativo, poderá usar os botões na interface do usuário faça o seguinte:

• Definir a qualidade da senha.
• Especificar requisitos para a senha do usuário, como tamanho mínimo, número mínimo de caracteres numéricos que ela deve conter e assim por diante.
• Definir a senha. Se a senha não for compatível com o políticas, o sistema retornará um erro.
• Definir quantas tentativas de senha podem ocorrer antes que o dispositivo seja excluído permanentemente ou seja, restauradas 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.
• Definir o tempo máximo de inatividade antes do dispositivo fechaduras.
• 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 de sistema podem usar a API Device Administration para criar um app que aplica políticas de segurança de dispositivos remotos/locais. Esta seção resume as etapas envolvidas na criação de um sistema de administração de dispositivo app.

Criar o manifesto

Para usar a API Device Administration, o manifesto deve incluir o seguinte:

• Uma subclasse de DeviceAdminReceiver que inclui o seguinte:
  • a permissão BIND_DEVICE_ADMIN;
  • A capacidade de responder ao 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>

Algumas considerações:

• Os atributos a seguir se referem aos recursos de string que, para o app de exemplo, estão em ApiDemos/res/values/strings.xml: Para mais informações sobre recursos, consulte Recursos do aplicativo.
  • android:label="@string/activity_sample_device_admin" refere-se ao um rótulo legível pelo usuário para a atividade.
  • android:label="@string/sample_device_admin" refere-se ao legível pelo usuário para a permissão.
  • android:description="@string/sample_device_admin_description" refere-se a a 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 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 é o principal que uma subclasse DeviceAdminReceiver precisa processar para ser tem permissão para gerenciar um dispositivo. Isso é definido para o receptor quando o usuário ativa o app de administração de dispositivos. Normalmente, seu código lida com isso onEnabled(): Para ser suportado, o receptor também precisa exigem a permissão BIND_DEVICE_ADMIN para que outros apps não pode abusar dele.
• Quando um usuário ativa o app de administração de dispositivo, o receptor permissão para executar ações em resposta à transmissão de um sistema específico eventos. Quando um evento adequado surgir, o app poderá impor uma política. Para exemplo, se o usuário tentar definir uma nova senha que não atenda à política do aplicativo, o app pode solicitar que o usuário escolha uma senha diferente que atenda aos requisitos.
• Evite mudar o nome do receptor depois de publicar o app. Se o nome no campo alterações no manifesto, o administrador do dispositivo é desativado quando os usuários atualizam o aplicativo. 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 para o administrador do dispositivo, conforme analisado pela classe DeviceAdminInfo. Aqui está 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 seu app de administração de dispositivo, você não precisa inclua todas as políticas, somente 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 fornece 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 um DeviceAdminReceiver.

DevicePolicyManager

Uma classe de gerenciamento de políticas implementadas em um dispositivo. A maioria dos clientes de essa classe precisa ter publicado um DeviceAdminReceiver que o usuário está ativada no momento. O DevicePolicyManager gerencia as políticas uma ou mais instâncias DeviceAdminReceiver

DeviceAdminInfo

Classe usada para especificar metadados para um componente de administrador de dispositivo.

Essas classes fornecem a base para um app de administração de dispositivo totalmente funcional. O restante desta seção descreve como você usa o DeviceAdminReceiver e APIs DevicePolicyManager para criar um app de administração de dispositivo.

Subclasse DeviceAdminReceiver

Para criar um app de administração de dispositivo, é preciso criar uma subclasse DeviceAdminReceiver: A classe DeviceAdminReceiver consiste em uma série de callbacks acionados quando eventos específicos antes que ocorram mudanças.

Na subclasse DeviceAdminReceiver, o app de exemplo simplesmente exibe uma notificação Toast em resposta a eventos. 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 app de administração de dispositivo precisa processar é o ativar o app. O usuário precisa ativar explicitamente o app para as políticas que serão aplicadas. Se o usuário escolher 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 aproveitar os benefícios do app.

O processo de ativação do app começa quando o usuário realiza uma ação que aciona o ACTION_ADD_DEVICE_ADMIN intenção. Na aplicativo de exemplo, isso acontece quando o usuário clica no botão Ativar Admin.

Quando o usuário clica na caixa de seleção Ativar administrador, a exibição mudanças para solicitar que o usuário ative o app de administração de dispositivo, como 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 onPreferenceChange() o retorno de chamada. 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 mudanças 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.

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) 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 adicionar o administrador do dispositivo ao sistema (ou permitir que ele o rejeite).

Quando o aplicativo precisa realizar uma operação que depende da aplicativo de administração do dispositivo, ele confirma que o aplicativo está ativos. Para fazer isso, ele usa o método DevicePolicyManager. isAdminActive(). Observe que o DevicePolicyManager método isAdminActive() usa um DeviceAdminReceiver como argumento:

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

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

Gerenciar políticas

DevicePolicyManager é uma classe pública para gerenciamento de políticas aplicada a um dispositivo. DevicePolicyManager gerencia as políticas de um ou mais instâncias 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);

Esta seção descreve como usar o 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

O DevicePolicyManager inclui APIs para definir e aplicar os política de senha do dispositivo. Na API Device Administration, a senha só se aplica ao um 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:

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 deve inserir um senha que contenha pelo menos caracteres alfabéticos (ou outros símbolos).

PASSWORD_QUALITY_ALPHANUMERIC

O usuário deve inserir um senha contendo pelo menos tanto numéricos quanto alfabéticos (ou outros caracteres).

PASSWORD_QUALITY_NUMERIC

O usuário precisa inserir uma senha com pelo menos caracteres numéricos.

PASSWORD_QUALITY_COMPLEX

O usuário deve ter inserido uma senha que contenha pelo menos uma letra, um dígito numérico e um símbolo especial.

PASSWORD_QUALITY_SOMETHING

O a política exige algum tipo da 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:

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. Para Por exemplo, é possível definir uma política que determina que as senhas devem conter pelo menos n letras maiúsculas. Estes são os métodos para ajustar uma senha conteúdo:

• 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

Você pode especificar que uma senha tenha pelo menos o tamanho mínimo comprimento. 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

Você pode definir o número máximo de tentativas de senha com falha antes que dispositivo for apagado, ou seja, redefinido para a configuração original. 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, você pode usar o setPasswordExpirationTimeout() para definir a data de expiração de uma senha, expresso como um delta em milissegundos a partir do momento em que um administrador do dispositivo define o tempo limite de expiração. 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, você pode usar o setPasswordHistoryLength() para limitar o número de usuários reutilizar senhas antigas. Esse método toma um objeto length que especifica a quantidade de as senhas sejam armazenadas. Quando esta política está ativa, os usuários não podem inserir um novo que corresponda às últimas n senhas. Isso evita o uso da mesma senha várias vezes. Essa política normalmente é usada em conjunto com setPasswordExpirationTimeout(), o que força os usuários depois de um determinado período.

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

Você pode definir o período máximo de inatividade do usuário que pode ocorrer antes da bloqueios do dispositivo. 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

Você pode usar o método DevicePolicyManager wipeData() para redefinir o dispositivo para as configurações originais. Isso é útil em caso de perda ou roubo do dispositivo. Muitas vezes, a decisão de limpar o dispositivo é resultado do cumprimento de certas condições. Por exemplo, é possível usar setMaximumFailedPasswordsForWipe() para declarar que um dispositivo precisa ser limpos após um número específico de tentativas de senha.

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 um bitmask 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 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, você pode usar o setStorageEncryption() para definir uma política que exige a criptografia da área de armazenamento, quando disponível.

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

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