SDK do Aplicativo do Intune para Android – Fundamentos da Integração MAM

O SDK do aplicativo do Microsoft Intune para Android permite incorporar políticas de proteção do aplicativo do Intune (também conhecidas como políticas de MAM) em seu aplicativo nativo Java/Kotlin para Android. Um aplicativo gerenciado do Intune é aquele que é integrado ao SDK do aplicativo do Intune. Os administradores do Intune podem facilmente implantar políticas de proteção de aplicativo em seu aplicativo gerenciado pelo Intune quando o Intune gerencia ativamente o aplicativo.

Estágio 4: Fundamentos de integração de MAM

Objetivos do Estágio

• Habilite o modo estrito do MAM.
• Registre-se para receber notificações críticas do SDK.
• Implemente e registre um retorno de chamada de autenticação para fornecer tokens do Microsoft Entra da MSAL para o SDK.
• Registre novas contas para gerenciamento de MAM após autenticar com o MSAL.
• Cancelar o registro de contas no logoff para remover dados corporativos.
• (Recomendado) Incorpore o registro em log do MAM em seu aplicativo.
• (Recomendado) Saiba como usar a caixa de diálogo de diagnóstico do SDK.

Histórico

Agora que você baixou o SDK do Aplicativo do Intune, integrou-o ao build e executou com êxito as substituições de classe e método, é hora de fazer as alterações de código essenciais para começar a impor as configurações de política de proteção do aplicativo para contas protegidas por MAM.

Este estágio instrui você sobre como se conectar ao log do SDK, invocar uma caixa de diálogo de diagnóstico, habilitar o modo estrito do MAM para identificar possíveis bugs de integração, registrar-se para receber notificações do SDK e, o mais importante, como registrar uma conta do Intune MAM para começar a receber a política.

Modo Estrito do MAM

O Modo Estrito do MAM pode identificar possíveis bugs na integração do aplicativo SDK do aplicativo do Intune em seu aplicativo. Esses bugs de integração podem resultar em falhas na aplicação adequada da política de proteção do aplicativo e deixar os dados corporativos desprotegidos. Como resultado, o uso do Modo Estrito do MAM é obrigatório.

O Modo Estrito do MAM procura anomalias no uso de APIs do MAM e APIs de plataforma restritas ao MAM pelo aplicativo. Vagamente padronizado após o StrictMode do Android, o Modo Estrito do MAM executa um conjunto predefinido de verificações que geram erros de tempo de execução quando eles falham. O Modo Estrito do MAM não se destina a ser deixado habilitado em builds de produção; Em vez disso, use-o nos builds internos de desenvolvimento, depuração e/ou dogfood do seu aplicativo.

Para habilitar o Modo Estrito do MAM, chame o método a seguir no início da inicialização do aplicativo (por exemplo: Application.onCreate

MAMStrictMode.enable();

Quando um marcar de modo estrito do MAM falhar, tente determinar se é um problema real que pode ser corrigido em seu aplicativo ou um falso positivo. Se você acredita que é um falso positivo ou não tem certeza, informe a equipe do Intune MAM. Isso nos permitirá ter certeza de que concordamos com a determinação de falsos positivos e tentar melhorar a detecção para versões futuras. Para suprimir falsos positivos, desabilite a marcação com falha seguindo as instruções abaixo.

Tratamento de violações

Quando uma marcar falha, ela executa um MAMStrictViolationHandler. O manipulador padrão lança um Error, que deve travar o aplicativo. Isso é para tornar as falhas o mais barulhentas possível e se encaixa na intenção de que o modo estrito não seja habilitado em builds de produção.

Se o aplicativo quiser lidar com violações de maneira diferente, ele poderá fornecer seu próprio manipulador chamando o método a seguir em que handler implementa MAMStrictViolationHandler:

MAMStrictMode.global().setHandler(handler);

Suprimindo verificações

Se uma marcação falhar em uma situação em que seu aplicativo não está fazendo nada incorreto, relate-a conforme mencionado acima. Enquanto isso, pode ser necessário desabilitar a marca que encontrar um falso positivo, pelo menos enquanto aguarda um SDK atualizado. A marcação que falhou será mostrada no erro gerado pelo manipulador padrão ou será passada para um manipulador personalizado, se definida.

Embora as supressões possam ser feitas globalmente, é preferível desabilitar temporariamente o per-thread no site de chamada específico. Os exemplos a seguir mostram várias maneiras de desabilitar o MAMStrictCheck.IDENTITY_NO_SUCH_FILE (gerado se for feita uma tentativa de proteger um arquivo que não existe).

Per-Thread Supressão temporária

Esse é o mecanismo de supressão preferencial.

try (StrictScopedDisable disable = MAMStrictMode.thread().disableScoped(MAMStrictCheck.IDENTITY_NO_SUCH_FILE)) {
    // Perform the operation which raised a violation here
}
// The check is no longer disabled once the block exits

Per-Thread Supressão permanente

MAMStrictMode.thread().disable(MAMStrictCheck.IDENTITY_NO_SUCH_FILE);

Supressão global (em todo o processo)

MAMStrictMode.global().disable(MAMStrictCheck.IDENTITY_NO_SUCH_FILE);

Registre-se para receber notificações do SDK

O SDK do aplicativo do Intune emite muitos tipos diferentes de notificações para informar os aplicativos sobre operações de gerenciamento sensíveis ao tempo. Seu aplicativo pode se registrar e tomar medidas ao receber qualquer uma dessas notificações.

Por exemplo, sempre que um administrador de TI emite um comando de apagamento seletivo para um dispositivo, o serviço do Intune envia uma notificação para o SDK, que é passada para o aplicativo como WIPE_USER_DATA. Seu aplicativo pode escutar essa notificação e controlar quais dados são apagados; ou pode contar com o comportamento de apagamento padrão do SDK.

Muitas das notificações são opcionais. Dependendo dos recursos do SDK que seu aplicativo usa, algumas notificações podem ser necessárias. Consulte Registrar-se para notificações do SDK no Estágio 7: Recursos de participação no aplicativo para obter detalhes sobre como se registrar para notificações, quais notificações o SDK fornece e como lidar com tipos de notificação específicos.

Registrando-se na Política de Proteção do Aplicativo

Quando os administradores criam políticas de proteção de aplicativo, eles direcionam essas políticas para contas específicas em sua organização. No cliente, o SDK precisa saber qual conta está usando o aplicativo para que ele possa recuperar a política dessa conta e impor as configurações adequadamente. Seu aplicativo é responsável por fornecer ao SDK essas informações de conta. Esse processo é chamado de registro.

Sempre que seu aplicativo adiciona uma nova conta, ele deve registrar a conta no SDK, mesmo que outras contas já estejam registradas. Seu aplicativo pode registrar várias contas. No entanto, atualmente apenas uma conta pode ser registrada ou ter uma política de proteção de aplicativo aplicada. No Android, essa limitação de conta gerenciada única abrange todo o dispositivo.

Registro x Registro

O registro é o processo em que seu aplicativo informa ao SDK que uma nova conta está em uso. O SDK contém funções que seu aplicativo deve chamar para registrar e cancelar o registro de contas.

O registro é o processo em que o SDK registra a conta registrada no serviço do Intune para que possa aplicar a política da conta. Seu aplicativo não precisa chamar nenhuma função para registro. O SDK lida totalmente com o registro depois que uma conta é registrada.

Se uma conta já estiver registrada para seu aplicativo, quando ele registrar outra conta, mesmo que essa conta seja direcionada com políticas de proteção de aplicativo, essa segunda conta não será registrada e a política não será aplicada.

Implementando o registro

Seu aplicativo deve fazer três alterações de código para registrar uma conta com êxito:

1. O aplicativo deve implementar e registrar uma instância da interface MAMServiceAuthenticationCallback ou MAMServiceAuthenticationCallbackExtended . A instância de retorno de chamada deve ser registrada no onCreate() método (ou onMAMCreate()) da subclasse Application.

2. Quando uma conta é criada e o usuário entra com êxito na MSAL, o aplicativo deve chamar registerAccountForMAM.

3. Quando uma conta é removida, o aplicativo deve chamar unregisterAccountForMAM para remover a conta do gerenciamento do Intune.

   Cuidado

   A chamada pode iniciar um apagamento para remover completamente os dados corporativos da conta.

Todas as APIs de autenticação e registro necessárias podem ser encontradas na interface MAMEnrollmentManager . Uma referência ao MAMEnrollmentManager pode ser obtida da seguinte maneira:

MAMEnrollmentManager mgr = MAMComponents.get(MAMEnrollmentManager.class);

// make use of mgr

A MAMEnrollmentManager instância retornada tem a garantia de não ser nula. Os métodos de API se enquadram em duas categorias: autenticação e registro de conta.

MAMEnrollmentManager e Autenticação

O SDK frequentemente se comunica com o serviço do Intune: para registrar contas registradas, para obter atualizações nas configurações da Política de Proteção do Aplicativo e para obter ações administrativas pendentes, como limpar seletivamente dados protegidos dentro do seu aplicativo. Para se comunicar com êxito com o serviço do Intune, o SDK requer novos tokens de acesso de aplicativos que integraram a MSAL.

Se o SDK não conseguir recuperar um token novo, ele não poderá se comunicar com o serviço do Intune, o que pode atrasar a recuperação e a imposição de novas configurações de política ou ações de administrador. É fundamental que seu aplicativo conclua essas etapas para garantir a imposição perfeita da política.

No Estágio 2, você integrou a MSAL ao seu aplicativo para autenticação e aquisição de tokens de acesso. Aqui, você implementa um retorno de chamada de autenticação para permitir que o SDK solicite os tokens necessários.

MAMEnrollmentManager tem os seguintes métodos de autenticação:

interface MAMServiceAuthenticationCallback {
    String acquireToken(String upn, String aadId, String resourceId);
}
interface MAMServiceAuthenticationCallbackExtended extends MAMServiceAuthenticationCallback {
    String acquireToken(String upn, String aadId, String tenantId, String authority, String resourceId);
}
void registerAuthenticationCallback(MAMServiceAuthenticationCallback callback);
void updateToken(String upn, String aadId, String resourceId, String token);

1. O aplicativo deve implementar a interface MAMServiceAuthenticationCallback ou a interface MAMServiceAuthenticationCallbackExtended para permitir que o SDK solicite um token do Microsoft Entra para a conta e o ID do recurso fornecidos. A instância de retorno de MAMEnrollmentManager chamada deve ser fornecida ao chamando seu método registerAuthenticationCallback . Um token pode ser necessário no início do ciclo de vida do aplicativo para novas tentativas de registro ou marcações de atualização da política de proteção do aplicativo, portanto, o retorno de chamada deve ser registrado no onCreate() método (ouonMAMCreate()) da subclasse do Application aplicativo.

2. O acquireToken método deve adquirir o token de acesso para a ID de recurso solicitada para a conta especificada. Se não puder adquirir o token solicitado, ele deverá retornar nulo.

   Dica

   Certifique-se de que seu aplicativo utilize o resourceId e os aadId parâmetros passados para acquireToken() para que o token correto seja adquirido. O upn parâmetro é apenas para uso informativo; ele não deve ser usado para identificar uma conta sem considerar também o aadId. O resourceId deve ser usado para gerar os escopos adequados e o aadId deve ser usado para passar a conta correta. Se os tokens forem retornados para a conta errada e/ou o recurso errado, eles poderão causar atrasos ou falhas no registro do aplicativo e nas políticas de recuperação. Se o aplicativo precisar do Microsoft Entra Authority para adquirir o token corretamente, implemente a MAMServiceAuthenticationCallbackExtended interface.

   class MAMAuthCallback implements MAMServiceAuthenticationCallbackExtended {
       public String acquireToken(String upn, String aadId,
                   String tenantId, String authority, String resourceId) {
           final String[] scopes = {resourceId + "/.default"};
   
           final IAccount account = getAccount(aadId);
           if (account == null) {
               // Log error or warning here about: "no account found for " + aadId
               return null;
           }
   
           AcquireTokenSilentParameters params =
               new AcquireTokenSilentParameters.Builder()
                       .forAccount(account)
                       .fromAuthority(account.getAuthority())
                       .withScopes(Arrays.asList(scopes))
                       .withCallback(callback)
                       .build();
   
           return mMsalClientApplication.acquireTokenSilent(params);
       }
   
       private static IAccount getAccount(String aadId) throws InterruptedException, MsalException {
         IAccount account = null;
   
         if (mMsalClientApplication instanceof IMultipleAccountPublicClientApplication) {
             IMultipleAccountPublicClientApplication multiAccountPCA =
                     (IMultipleAccountPublicClientApplication) mMsalClientApplication;
   
             account = multiAccountPCA.getAccount(aadId);
         } else {
             ISingleAccountPublicClientApplication singleAccountPCA =
                     (ISingleAccountPublicClientApplication) mMsalClientApplication;
   
             ICurrentAccountResult accountResult = singleAccountPCA.getCurrentAccount();
             if (accountResult != null) {
                 account = accountResult.getCurrentAccount();
                 // make sure this is the correct user
                 if (account != null && !account.getId().equals(aadId))
                     account = null;
             }
         }
         return account;
     }
   }
   

3. Caso o aplicativo não consiga fornecer um token quando o SDK chamar acquireToken() , por exemplo, se a autenticação silenciosa falhar e for um momento inconveniente para mostrar uma interface do usuário, o aplicativo poderá fornecer um token posteriormente chamando o método updateToken . O mesmo UPN, o Microsoft Entra ID e a ID do recurso solicitados pela chamada anterior devem acquireToken() ser passados para updateToken(), juntamente com o token que foi finalmente adquirido. O upn parâmetro é apenas para fins informativos e geralmente é ignorado pelo SDK do MAM. O aplicativo deve chamar esse método assim que possível depois de retornar null do retorno de chamada fornecido.

   Aviso

   Não chame updateToken() de dentro de sua implementação de acquireToken(). updateToken() deve ser usado no caso acquireToken() em que não é possível adquirir um token.

   Observação

   O SDK chamará acquireToken() periodicamente para obter o token, portanto, a chamada updateToken() não é estritamente necessária. No entanto, é altamente recomendável, pois pode ajudar os registros e os marcar-ins da política de proteção do aplicativo a serem concluídos em tempo hábil.

Notas de implementação de autenticação

• Os aplicativos são incentivados a adquirir tokens do Microsoft Entra antes de chamar registerAccountForMAM. Depois de registrar uma conta, os aplicativos receberão um retorno de chamada para o método do acquireToken() registrado MAMServiceAuthenticationCallbackem um thread diferente. Fornecer um token válido nesse retorno de chamada permite que o registro prossiga. O aplicativo obtém o resultado do registro por meio de notificação.

• Se o aplicativo não retornar um token válido do Microsoft Entra, o resultado final da tentativa de registro será AUTHORIZATION_NEEDED. Se o aplicativo receber esse Resultado por meio de notificação, é recomendável agilizar o processo de registro adquirindo o token para a conta e o recurso solicitados anteriormente de acquireToken e chamando o método updateToken para iniciar o processo de registro novamente.

• Os aplicativos registrados MAMServiceAuthenticationCallback também serão chamados para adquirir um token para atualização periódica da política de proteção do aplicativo marcar-ins. Se o aplicativo não puder fornecer um token quando solicitado, ele não receberá uma notificação, mas deverá tentar adquirir um token e ligar updateToken() no próximo momento conveniente para agilizar o processo de marcar. Se um token não for fornecido, o retorno de chamada ainda poderá ser chamado na próxima tentativa de check-in de marcar.

• O suporte para nuvens soberanas requer fornecer a autoridade.

• Se MAMServiceAuthenticationCallbackExtended a interface for implementada, o método herdado acquireToken() de MAMServiceAuthenticationCallback não precisará ser implementado, pois a MAMServiceAuthenticationCallbackExtended interface fornece uma implementação padrão.

MAMEnrollmentManager e Registro

Sempre que o aplicativo adiciona uma conta, ele deve registrar a conta no SDK. Da mesma forma, sempre que o aplicativo remover uma conta, ele deverá cancelar o registro dessa conta para indicar que o aplicativo não deve mais aplicar a política para essa conta. Se a conta foi registrada no serviço MAM, a conta terá o registro cancelado e o aplicativo será apagado.

MAMEnrollmentManager tem os seguintes métodos de registro de conta:

void registerAccountForMAM(String upn, String aadId, String tenantId);
void registerAccountForMAM(String upn, String aadId, String tenantId, String authority);
void unregisterAccountForMAM(String upn, String aadId);
Result getRegisteredAccountStatus(String upn, String aadId);

1. Para registrar uma conta para gerenciamento, o aplicativo deve chamar registerAccountForMAM(). Uma conta é identificada por seu UPN e sua ID de usuário do Microsoft Entra. A ID do locatário também é necessária para associar os dados de registro ao locatário do Microsoft Entra da conta. A autoridade da conta também pode ser fornecida para permitir o registro em nuvens soberanas específicas; para obter mais informações, consulte Registro do Sovereign Cloud. O SDK pode tentar registrar o aplicativo para a conta especificada no serviço MAM; Se o registro falhar, ele repetirá periodicamente o registro até que o registro seja bem-sucedido ou a conta tenha o registro cancelado. O período de repetição normalmente será de 12 a 24 horas. O SDK fornece o status das tentativas de registro de forma assíncrona por meio de notificações.

2. O melhor momento para ligar registerAccountForMAM é depois que o usuário tiver entrado no aplicativo e for autenticado com êxito usando a MSAL. A ID de usuário, a ID do locatário e a IAccount autoridade do Microsoft Entra da conta são retornadas da chamada de autenticação MSAL como parte do relacionado ao IAuthenticationResult.

   • A conta vem do IAuthenticationResult.getAccount() método e contém as informações pertinentes da conta.
   • A ID AAD (também conhecida como Microsoft Entra ID ou OID) vem do IAccount.getId() método.
   • A ID do locatário vem do IAccount.getTenantId() método.
   • A autoridade vem do IAccount.getAuthority() método.

3. Para cancelar o registro de uma conta do gerenciamento do Intune, o aplicativo deve chamar unregisterAccountForMAM(). Se a conta tiver sido registrada com êxito e for gerenciada, o SDK cancelará o registro da conta e apagará seus dados. As novas tentativas de registro periódicas para a conta serão interrompidas. O SDK fornece o status das solicitações de cancelamento de registro de forma assíncrona por meio de notificação.

Notas de implementação do registro

• Os métodos de registro são idempotentes. Por exemplo, registerAccountForMAM só registrará uma conta e tentará registrar o aplicativo se a conta ainda não estiver registrada, e unregisterAccountForMAM só cancelará o registro de uma conta se ela estiver registrada no momento. As chamadas subsequentes não são operacionais, portanto, não há mal nenhum em chamar esses métodos mais de uma vez.

• Não há garantia de que cada chamada de registro/cancelamento de registro tenha uma notificação de resultado correspondente. Por exemplo, se registerAccountForMAM() for chamado para uma conta que já está registrada, a notificação não poderá ser enviada novamente para essa identidade. Como alternativa, o SDK pode enviar notificações mesmo quando seu aplicativo não chamou esses métodos, pois o SDK pode tentar periodicamente registros em segundo plano e os cancelamentos de registro podem ser disparados por solicitações de apagamento recebidas do serviço do Intune.

• Os métodos de registro podem ser chamados para qualquer número de contas diferentes, mas atualmente apenas uma conta pode ser inscrita com êxito. Se várias contas licenciadas para o Intune e direcionadas com a política de proteção do aplicativo forem registradas ao mesmo tempo ou quase ao mesmo tempo, não há garantia de qual delas vencerá a corrida.

• Você pode consultar MAMEnrollmentManager para ver se uma conta específica está registrada e obter seu status atual usando o método getRegisteredAccountStatus. Se a conta fornecida não estiver registrada, esse método retornará nulo. Se a conta estiver registrada, esse método retornará o status da conta como um dos membros da enumeração MAMEnrollmentManager.Result .

Sovereign Cloud Registration

O Azure dá suporte a várias nuvens fisicamente isoladas, conhecidas como Nuvens Soberanas ou Nacionais. Se o aplicativo tiver reconhecimento de nuvem soberana, ele deverá fornecer o authority parâmetro para registerAccountForMAM().

Diretrizes da MSAL

Para MSAL, defina multiple_clouds_supported como true no arquivo de configuração MSAL.

{
  "multiple_clouds_supported": true,
}

Resultado do registro e códigos de status

Quando uma conta é registrada pela primeira vez, ela começa no PENDING estado, indicando que a tentativa inicial de registro no serviço de MAM está incompleta. Após a tentativa de inscrição terminar, uma notificação será enviada com um dos códigos de resultado na tabela abaixo. Além disso, o método getRegisteredAccountStatus retorna o status da conta para que o aplicativo sempre possa determinar se essa conta tem políticas de proteção de aplicativo impostas. Se a tentativa de registro falhar, o status da conta poderá mudar ao longo do tempo, à medida que o SDK tentar novamente o registro em segundo plano.

(Recomendado) Registro em log

O registro em log deve ser inicializado antecipadamente para obter o máximo valor dos dados registrados. Application.onMAMCreate() normalmente é o melhor local para inicializar o registro em log.

Para receber logs MAM em seu aplicativo, crie um Java Handler e adicione-o ao MAMLogHandlerWrapper. Isso invoca no manipulador de aplicativos para cada mensagem de publish() log.

/**
 * Global log handler that enables fine grained PII filtering within MAM logs.
 * To start using this you should build your own log handler and add it via
 * MAMComponents.get(MAMLogHandlerWrapper.class).addHandler(myHandler, false);
 * You may also remove the handler entirely via
 * MAMComponents.get(MAMLogHandlerWrapper.class).removeHandler(myHandler);
 */
public interface MAMLogHandlerWrapper {
    /**
     * Add a handler, PII can be toggled.
     * @param handler handler to add.
     * @param wantsPII if PII is desired in the logs.
     */
    void addHandler(final Handler handler, final boolean wantsPII);

    /**
     * Remove a handler.
     * @param handler handler to remove.
     */
    void removeHandler(final Handler handler);
}

(Recomendado) Informações de diagnóstico

O aplicativo Portal da Empresa do Portal do Intune tem várias opções para coletar informações de diagnóstico. O Portal da Empresa inclui interface do usuário que:

• Permite que os usuários finais coletem logs do Portal da Empresa.
• Exibe metadados do dispositivo e da conta.
• Inclui informações por aplicativo sobre a política atual de MAM.

do Intune

Para obter uma explicação detalhada dos dados incluídos nos logs do Portal da Empresa e na interface do usuário do diagnóstico, consulte Noções básicas sobre logs do Portal da Empresa no Apêndice.

Os aplicativos podem iniciar essa interface do usuário de diagnóstico invocando MAMPolicyManager.showDiagnostics(context)o . Os usuários finais também podem iniciar o console de diagnóstico do Portal da Empresa por meio do Microsoft Edge, inserindo about:intunehelp na barra de endereços. Esse é um recurso opcional que pode ajudar na depuração.

Essas informações de diagnóstico só estão disponíveis quando o Portal da Empresa está instalado no dispositivo. Uma caixa de diálogo de aviso aparecerá sempre que showDiagnostics for chamado sem o Portal da Empresa instalado.

Critérios de Saída

Neste ponto da integração, seu aplicativo agora pode receber e impor a Política de Proteção do Aplicativo. Execute os testes a seguir para validar a integração.

Primeiro teste de aplicativo de política

Execute o seguinte teste primeiro para se familiarizar com a experiência completa do usuário final do aplicativo de política em seu aplicativo:

1. Crie uma Política de Proteção de Aplicativo Android no centro de administração do Microsoft Intune (consulte Criar uma política de proteção de aplicativo Android de teste no Estágio 1 para obter detalhes). Para este teste, configure a política:
   • Em Proteção de dados, defina "Captura de tela e Google Assistente" como "Bloquear".
   • Em Requisitos de acesso, mantenha as configurações padrão. Notavelmente, "PIN para Acesso" deve ser "Exigir".
2. Verifique se a Política de Proteção do Aplicativo está direcionada ao seu aplicativo. Você provavelmente precisará adicionar manualmente o nome do pacote no assistente de criação de política.
3. Atribua a Política de Proteção do Aplicativo a um grupo de usuários que contém sua conta de teste.
4. Em um dispositivo Android de teste, desinstale outros aplicativos integrados ao SDK, como Microsoft Outlook, Teams, OneDrive e Office. Desinstale também o aplicativo Portal da Empresa do Portal da Empresa do Intune e o aplicativo Microsoft Authenticator.

   • Dica

     Desinstalar outros aplicativos integrados ao SDK ajuda a garantir que você esteja testando exclusivamente a integração do seu próprio aplicativo.

5. Instale o aplicativo.
6. Faça logon no aplicativo com sua conta de teste direcionada à Política de Proteção do Aplicativo.
7. Confirme que você foi solicitado a instalar o Portal da Empresa do Intune no Google Play.

   • Observação

     Se o dispositivo de teste não tiver o aplicativo Google Play Store, confirme se você foi solicitado a instalar o Portal da Empresa do Intune de outra loja de aplicativos ou de um site da Microsoft.

8. Instale o Portal da Empresa. Você não precisa iniciar o Portal da Empresa ou fazer logon no Portal da Empresa.
9. Retorne ao seu aplicativo e faça logon novamente, se necessário.
10. Confirme que será exibida uma tela Obter Acesso. Isso indica que o SDK recuperou com êxito a política para esta conta.
11. Você deve ser solicitado a definir um PIN do aplicativo. Crie um PIN.
12. Navegue pelo seu aplicativo e tente fazer capturas de tela. Considerando que o SDK tem política, ela deve ser bloqueada consistentemente em qualquer tela.
13. Faça logoff da conta gerenciada do aplicativo.
14. Se possível, sem fazer logon, navegue pelo aplicativo e tente fazer capturas de tela. Agora que a conta foi removida, ela não deve ser bloqueada.

Esse é um teste mínimo para confirmar se o aplicativo registrou corretamente a conta, registrou o retorno de chamada de autenticação e cancelou o registro da conta. Execute os testes a seguir para validar mais detalhadamente como outras configurações de Política de Proteção de Aplicativo modificam o comportamento do seu aplicativo.

Testes de Proteção de Dados

Os testes a seguir abrangem configurações específicas de proteção de dados definidas na Política de Proteção do Aplicativo. Quando você altera as configurações da Política de Proteção do Aplicativo no centro de administração do Microsoft Intune, o cliente não é atualizado imediatamente. Consulte Teste rápido com alteração da política para obter dicas sobre como acelerar os testes.

Para estes testes:

1. Instale seu aplicativo.
2. Instale o Portal da Empresa do Portal da Empresa do Intune.
3. Instale outro aplicativo gerenciado, direcionado com a mesma política que seu aplicativo, que possa copiar e colar dados (como o Microsoft Office).
4. Instale (ou reutilize) qualquer aplicativo não gerenciado que possa copiar e colar dados.
5. Faça logon no aplicativo com a conta gerenciada de teste.
6. Faça logon no outro aplicativo gerenciado com a conta de teste gerenciada.

Testes de transferência de dados

As configurações de transferência de dados são um subconjunto dos recursos de proteção de dados da Política de Proteção de Aplicativos que controlam a entrada e saída de dados de aplicativos gerenciados. A maioria dos aplicativos que suportam o envio ou recebimento de dados de outros aplicativos também têm a capacidade de salvar dados e abrir dados do armazenamento local ou em nuvem. Se o aplicativo tiver esses recursos, você precisará implementar suporte adicional. Consulte a Política para limitar a transferência de dados entre aplicativos e dispositivos ou locais de armazenamento em nuvem para obter detalhes.

Seu aplicativo pode importar ativamente dados de outros aplicativos, como o Microsoft Outlook anexando um arquivo do Microsoft OneDrive. Seu aplicativo também pode receber passivamente dados de outros aplicativos, como o Microsoft Office abrindo um documento de um anexo do Microsoft Outlook. A configuração de política "receber dados de outros aplicativos" abrange ambos os cenários.

Para estes testes:

1. Instale seu aplicativo.
2. Instale o Portal da Empresa do Portal da Empresa do Intune.
3. Instale outro aplicativo gerenciado, direcionado com a mesma política que seu aplicativo, que possa enviar e receber dados (como o Microsoft Outlook).
4. Instale (ou reutilize) qualquer aplicativo não gerenciado que possa enviar e receber dados.
5. Faça logon no aplicativo com a conta gerenciada de teste.
6. Faça logon no outro aplicativo gerenciado com a conta de teste gerenciada.

Outras configurações de proteção de dados

As configurações de proteção de dados a seguir não serão impostas até que seu aplicativo faça alterações adicionais. Você não precisa testar essas configurações neste estágio. Consulte Estágio 7: Recursos de participação no aplicativo para obter mais detalhes.

Testes de inicialização condicional

As configurações de inicialização condicional são um subconjunto dos recursos da Política de Proteção do Aplicativo que restringem o acesso ao seu aplicativo com base em critérios configuráveis em todo o dispositivo ou específicos do aplicativo. Essas configurações incluem condições (como "versão mínima do sistema operacional") e ações (como "bloquear acesso"). As ações de inicialização condicional podem ser:

• Avisar: o usuário final verá uma caixa de diálogo de aviso quando seu dispositivo ou aplicativo falhar nos critérios. Eles ainda terão acesso a todos os dados do aplicativo.
• Bloquear acesso: o usuário final verá uma caixa de diálogo de aviso quando seu dispositivo ou aplicativo falhar nos critérios. Eles não terão permissão para entrar no aplicativo e acessar dados do aplicativo até que atendam aos critérios ou removam a conta gerenciada do aplicativo.
• Apagar dados: todos os dados corporativos associados à conta gerenciada serão apagados quando o dispositivo ou aplicativo falhar nos critérios. O usuário não terá a oportunidade de atender aos critérios antes que os dados sejam removidos.

Algumas configurações de inicialização condicional podem ser definidas com vários valores e ações. Por exemplo:

• Versão mínima do sistema operacional, valor de "10.0", ação definida como "Avisar".
• Versão mínima do sistema operacional, valor de "9.0", ação definida como "Bloquear acesso"
• Versão mínima do sistema operacional, valor de "8.0", ação definida como "Wipe data".

Ao concluir as etapas de integração neste estágio, seu aplicativo agora dá suporte a todos os recursos de inicialização condicional. Familiarize-se com a funcionalidade de inicialização condicional alterando os itens de política de modo que seu dispositivo de teste:

• Transmite todas as configurações de inicialização condicional definidas.
• Falha em uma configuração de inicialização condicional definida como a ação "Avisar".
• Falha em uma configuração de inicialização condicional definida para a ação "Bloquear acesso".
• Falha em uma configuração de inicialização condicional definida para a ação "Apagar dados".

Solução de problemas

Solução de problemas de teste do aplicativo First Policy

Seguindo as etapas do Primeiro Teste de Aplicativo de Política acima, você poderá encontrar os seguintes comportamentos inesperados:

Depois de fazer logon com uma conta gerenciada, não sou solicitado a instalar o Portal da Empresa (etapa 7)

Primeiro, visite o centro de administração do Intune e marque se a Política de Proteção do Aplicativo está direcionada à sua conta de teste.

Em segundo lugar, marque novamente seu código-fonte para chamadas registerAccountForMAM e implementação de MAMServiceAuthenticationCallback. Se o primeiro não for chamado no momento certo e/ou o último não tiver fornecido corretamente um token válido, você não verá o prompt do Portal da Empresa.

Por fim, procure nos logs (ou na depuração) o código do resultado do registro ou chame getRegisteredAccountStatus explicitamente a conta. Códigos como NOT_LICENSED podem indicar problemas de configuração com a conta de teste.

Não vi a tela Obter Acesso depois de fazer logon (etapa 10)

Se o Portal da Empresa não tiver sido instalado anteriormente, talvez seja necessário retomar ou reiniciar totalmente o aplicativo para ver a tela Obter Acesso e ter a política aplicada corretamente. Esse é um resultado esperado com base em como os aplicativos integrados ao SDK aproveitam o código dentro do aplicativo do Portal da Empresa.

Se você ainda não vir a tela Obter Acesso, mesmo depois de reiniciar seu aplicativo e fazer logon novamente, o SDK pode estar falhando ao registrar a conta ou recuperar a política para a conta. Marque novamente a implementação do MAMServiceAuthenticationCallbackcódigo-fonte do .

Não vi a tela para definir ou inserir um PIN de aplicativo depois de fazer logon (etapa 11)

Existem outros aplicativos integrados ao SDK em seu dispositivo de teste? O PIN do aplicativo é compartilhado entre todos os aplicativos gerenciados e o SDK tem um temporizador global para impedir que os usuários finais sejam solicitados a fornecer o PIN em cada inicialização ou retomada do aplicativo gerenciado.

Caso contrário, visite o centro de administração do Intune e Marque se a Política de Proteção do Aplicativo tem o PIN do aplicativo habilitado e está direcionada à sua conta de teste.

Como último recurso, reiniciar o dispositivo redefinirá o temporizador do PIN. Se a tela do PIN não for exibida após a reinicialização do dispositivo, é provável que ele não esteja configurado corretamente na política.

Eu vi a tela Obter Acesso, mas as capturas de tela ainda são permitidas (etapa 12)

Enquanto a política está sendo recuperada, a política errada está sendo aplicada. Primeiro, visite o centro de administração do Intune e marque se a Política de Proteção do Aplicativo desabilita capturas de tela e é direcionada à sua conta de teste. Em segundo lugar, use o console de diagnóstico (descrito acima) para marcar a política que foi removida para seu aplicativo. Se ambas as políticas confirmarem que as capturas de tela devem ser bloqueadas, Marque a configuração do plug-in de build do Gradle para garantir que as substituições de MAM sejam feitas.

Meu aplicativo pareceu falhar ou fechar após fazer logoff (etapa 13)

Quando você cancela o registro de uma conta que foi registrada anteriormente e teve a política aplicada, os dados associados a essa conta serão apagados pelo SDK. Espera-se o encerramento do processo do aplicativo.

As capturas de tela continuam bloqueadas mesmo depois que eu saí (etapa 14)

Marque novamente o código-fonte para chamadas para unregisterAccountForMAM(). Se a política ainda for aplicada após o logout, é provável que a conta não tenha sido devidamente cancelada e cancelada.

Solução de problemas de teste de proteção de dados

Seguindo as etapas dos Testes de Proteção de Dados acima, você poderá encontrar os seguintes comportamentos inesperados:

Meu aplicativo não está recebendo nem impondo nenhuma política

Primeiro, confirme se a Política de Proteção do Aplicativo está direcionada a um grupo que contém sua conta de teste. Consulte Como validar a configuração da política de proteção do aplicativo no Microsoft Intune para obter detalhes.

Em segundo lugar, Marque as Informações de Diagnóstico do cliente para confirmar se o SDK recebeu a política configurada. Em caso negativo, inspecione a implementação do MAMServiceAuthenticationCallback aplicativo e as chamadas para registerAccountForMAM. Além disso, Marque logs ou depurar para verificar o MAMEnrollmentManager.Result.

Meu aplicativo pode compartilhar dados com um aplicativo não gerenciado

Confirme a opção "Enviar dados da organização para outros aplicativos" definida como "Aplicativos gerenciados pela política". Verifique o centro de administração do Microsoft Intune para confirmar se a política está configurada e direcionada corretamente. Verifique as Informações de Diagnóstico do cliente para confirmar se o SDK recebeu a política configurada.

Em seguida, se a política estiver configurada e recuperada corretamente, marcar se alguma política está sendo imposta: Meu aplicativo não está recebendo nem impondo nenhuma política.

Meu aplicativo não pode compartilhar dados com outro aplicativo gerenciado

Confirme as configurações da Política de Proteção do Aplicativo direcionadas ao seu aplicativo e ao outro aplicativo gerenciado. É recomendável ter a mesma política direcionada a ambos os aplicativos. A política direcionada ao seu aplicativo deve ter "Enviar dados da organização para outros aplicativos" definido como "Aplicativos gerenciados por política". Verifique a política direcionada ao outro aplicativo; se ele tiver "Receber dados de outros aplicativos" definido como "Nenhum", esse comportamento será esperado.

Meu aplicativo pode receber dados de um aplicativo não gerenciado

Confirme a opção "Receber dados de outros aplicativos" definida como "Aplicativos gerenciados pela política". Verifique o centro de administração do Microsoft Intune para confirmar se a política está configurada e direcionada corretamente. Verifique as Informações de Diagnóstico do cliente para confirmar se o SDK recebeu a política configurada.

Em seguida, se a política estiver configurada e recuperada corretamente, marcar se alguma política está sendo imposta: Meu aplicativo não está recebendo nem impondo nenhuma política.

Meu aplicativo não pode receber dados de outro aplicativo gerenciado

Confirme as configurações da Política de Proteção do Aplicativo direcionadas ao seu aplicativo e ao outro aplicativo gerenciado. É recomendável ter a mesma política direcionada a ambos os aplicativos. A política direcionada para seu aplicativo deve ter "Receber dados de outros aplicativos" definido como "Aplicativos gerenciados por política". Verifique a política direcionada ao outro aplicativo; se ele tiver "Enviar dados da organização para outros aplicativos" definido como "Nenhum", esse comportamento será esperado.

Próximas etapas

Depois de concluir todos os critérios de saída acima, seu aplicativo agora está integrado com êxito como identidade única e pode impor todas as políticas básicas de proteção de aplicativo. As seções subsequentes, Estágio 5: Identidade Múltipla, Estágio 6: Configuração de Aplicativos e Estágio 7: Participação no Aplicativos Os recursos podem ou não ser necessários, dependendo do suporte desejado da política de proteção do aplicativo do aplicativo. Se você não tiver certeza se alguma dessas seções se aplica ao seu aplicativo, consulte as principais decisões para integração ao SDK.