Guia para programadores do SDK da Aplicação do Microsoft Intune para Android

Nota

Pode ser útil ler primeiro a Descrição geral do SDK da Aplicação do Intune, que abrange as funcionalidades atuais do SDK e descreve como preparar a integração em cada plataforma suportada.

Para descarregar o SDK, consulte baixar os ficheiros SDK.

Se tiver problemas em integrar o Intune App SDK nas suas apps, envie um pedido de assistência sobre GitHub.

O SDK da Aplicação do Microsoft Intune para Android permite-lhe incorporar as políticas de proteção de aplicações do Intune (também conhecidas como políticas de APLICAÇÕES ou MAM) na aplicação Android nativa. Uma aplicação gerida pelo Intune é uma aplicação que está integrada com o SDK da Aplicação Intune. Os administradores do Intune podem facilmente implementar políticas de proteção de aplicações na sua aplicação gerida pelo Intune quando este está a gerir a aplicação de forma ativa.

O que está no SDK

O SDK da Aplicação do Intune é constituído pelos seguintes ficheiros:

• Microsoft.Intune.MAM.SDK.aar: os componentes do SDK, com exceção dos ficheiros JAR da Biblioteca de Suporte.
• Microsoft.Intune.MAM.SDK.Support.v4.jar: as classes necessárias para ativar a MAM nas aplicações que utilizam a biblioteca de suporte v4 do Android.
• Microsoft.Intune.MAM.SDK.Support.v7.jar: as classes necessárias para ativar a MAM nas aplicações que utilizam a biblioteca de suporte v7 do Android.
• Microsoft.Intune.MAM.SDK.Support.v17.jar: as classes necessárias para ativar a MAM nas aplicações que utilizam a biblioteca de suporte v17 do Android.
• Microsoft.Intune.MAM.SDK.Support.Text.jar: as classes necessárias para ativar a MAM nas aplicações que utilizam classes da biblioteca de suporte do Android no pacote android.support.text.
• Microsoft.Intune.MAM.SDK.DownlevelStubs.aar: Este AAR contém canhotos para classes de sistema Android que estão presentes apenas em dispositivos mais recentes mas que são referenciados por métodos em MAMActivity. Os dispositivos mais recentes ignorarão estas classes de stub. Este AAR só é necessário se a sua app realizar reflexões sobre as aulas que derivam de , e a maioria das MAMActivity aplicações não precisa incluí-la. A AAR contém regras ProGuard para excluir todas as suas classes.
• com.microsoft.Intune.mam.Build.JAR: um plug-in do Gradle que ajuda a integrar o SDK.
• CHANGELOG.md: Fornece um registo de alterações efetuadas em cada versão SDK.
• THIRDPARTYNOTICES.TXT: aviso de atribuição que reconhece código de terceiros e/ou OSS que será compilado na sua aplicação.

Requisitos

Versões Android

O SDK suporta totalmente o Android API 23 (Android 6.0) através do Android API 30 (Android 11.0). Para direcionar o Android API 30, deve utilizar o Intune App SDK v7.0 ou mais tarde. Pode ser incorporado numa aplicação com um MinSDKVersion Android até 14, mas nas versões de SISTEMA mais antigas será impossível instalar a aplicação Portal da Empresa do Intune ou utilizar as políticas do MAM.

Aplicação do Portal da Empresa

O SDK da Aplicação do Intune para Android baseia-se na presença da aplicação Portal da Empresa no dispositivo para ativar as políticas de proteção. O Portal da Empresa obtém as políticas de proteção de aplicações do serviço Intune. Quando a aplicação é inicializada, é carregada a política e o código para impor essa política a partir do Portal da Empresa.

Nota

Quando a aplicação Portal da Empresa não está no dispositivo, uma aplicação gerida pelo Intune tem o mesmo comportamento que uma aplicação normal que não suporta as políticas de proteção de aplicações do Intune.

Para a proteção de aplicações sem inscrição de dispositivos, o utilizador não é obrigado a inscrever o dispositivo através da aplicação Portal da Empresa.

Integração do SDK

Importante

Intune lança regularmente atualizações para o Intune App SDK. Verifique regularmente o SDK da Aplicação Intune para Android para obter atualizações e incorpore o ciclo de lançamento do seu software para garantir que as suas aplicações suportam as definições mais recentes da Política de Proteção de Aplicações.

Exemplos de aplicações

Exemplos de como integrar-se com a App Intune SDK incluem corretamente:

• Taskr - Um Microsoft Intune Exemplo Android MAM SDK. Este exemplo utiliza o plugin de construção Gradle.
• Taskr - Um Microsoft Intune React Native + Android MAM SDK Exemplo

Fazer referência a bibliotecas da Aplicação do Intune

O SDK da Aplicação do Intune é uma biblioteca do Android padrão sem dependências externas. O Microsoft.Intune.MAM.SDK.aar contém as interfaces necessárias para a ativação da política de proteção de aplicações e o código necessário para interagir com a aplicação Portal da Empresa do Microsoft Intune.

O Microsoft.Intune.MAM.SDK.aar tem de ser especificado como uma referência da biblioteca do Android. Para tal, abra o projeto de aplicação no Android Studio e aceda a Ficheiro > Novo > Novo módulo e selecione Importar Pacote .JAR/.AAR. Em seguida, selecione o nosso pacote de arquivo Android Microsoft.Intune.MAM.SDK.aar para criar um módulo para o . Tipo de ficheiro AAR. Clique com o botão direito no módulo ou módulos que contenham o seu código de aplicação e vá para o separador Dedesecação Definições > Dependencies > + icon Module > > Selecione o módulo AAR MAM SDK que acabou de criar > OK. Esta ação irá garantir que o seu módulo é compilado com o SDK de MAM quando criar o seu projeto.

Além disso, as bibliotecas do Microsoft.Intune.MAM.SDK.Support.XXX.jar contêm variantes do Intune das bibliotecas do android.support.XXX correspondentes. Não são compiladas no Microsoft.Intune.MAM.SDK.aar, caso uma aplicação não necessite de depender das bibliotecas de suporte.

ProGuard

Se o ProGuard (ou qualquer outro mecanismo de redução/ocultação) for utilizado como um passo de compilação, o SDK tem regras de configuração adicionais que têm de ser incluídas. Ao incluir o . AAR na sua construção, as nossas regras são automaticamente integradas no passo proguard e os ficheiros de classe necessários são mantidos.

A Microsoft Authentication Library (MSAL) pode ter as suas próprias restrições ProGuard. Se a sua aplicação integrar o MSAL, deve seguir a documentação da MSAL sobre estas restrições.

Aplicação da política

O SDK da Aplicação do Intune é uma biblioteca do Android que permite que a sua aplicação suporte e participe na imposição de políticas do Intune.

A maioria das políticas são aplicadas semi-automáticamente, mas certas políticas requerem a participação explícita da sua app para fazer cumprir. Independentemente de realizar a integração de fontes ou utilizar ferramentas de construção para integração, as políticas que requerem participação explícita terão de ser codificadas.

Para políticas que são automaticamente aplicadas, as aplicações são necessárias para substituir a herança de várias classes base Android por herança de equivalentes MAM e substituir igualmente chamadas para certas classes de serviços de sistema Android por chamadas para equivalentes MAM. As substituições específicas necessárias são detalhadas abaixo e podem ser realizadas manualmente com integração de fontes ou executadas automaticamente através de ferramentas de construção.

Ferramentas de compilação

O SDK fornece ferramentas de construção (um plugin para construções Gradle e uma ferramenta de linha de comando para construções não gradle) que executam substituições equivalentes MAM automaticamente. Estas ferramentas transformam os ficheiros de classe gerados pela compilação de Java e não modificam o código fonte original.

As ferramentas realizam apenas substituições diretas. Não realizam integrações SDK mais complexas, como a Save-As Policy, Multi-Identity, App-WE, modificações AndroidManifest ou configuração MSAL, pelo que estas devem ser concluídas antes de a sua aplicação estar totalmente ativada. Leia atentamente o resto deste documento para ver os pontos de integração relevantes para a sua aplicação.

Nota

Pode executar as ferramentas num projeto que já realizou a integração da origem parcial ou completa do SDK de MAM através de substituições manuais. O seu projeto tem de continuar a apresentar o SDK de MAM como uma dependência.

Plug-in de Compilação do Gradle

Se a compilação da sua aplicação não for efetuada com o Gradle, avance para Integrar com a Ferramenta de Linha de Comandos.

O plug-in do SDK da Aplicação é distribuído integrado no SDK como GradlePlugin/com.microsoft.intune.mam.build.jar. Para que o Gradle possa localizar o plug-in, este tem de ser adicionado ao caminho da classe (classpath) do script de compilação (buildscript). O plug-in depende do Javassist, que também tem de ser adicionado. Para adicionar ambos ao caminho da classe, adicione o seguinte ao seu build.gradle de raiz

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "org.javassist:javassist:3.27.0-GA"
        classpath files("$PATH_TO_MAM_SDK/GradlePlugin/com.microsoft.intune.mam.build.jar")
    }
}

Em seguida, no ficheiro build.gradle do seu projeto APK, aplique simplesmente o plug-in como

apply plugin: 'com.microsoft.intune.mam'

Por predefinição, o plug-in irá funcionar apenas em dependências do project. A compilação de teste não é afetada. Poderá ser fornecida uma configuração para apresentar o seguinte:

• Projetos a excluir
• Dependências externas a incluir
• Classes específicas a excluir do processamento
• Variantes a excluir do processamento. Estas podem ser referentes a um nome de variante completo ou a um único tipo. Por exemplo
  • Se a sua aplicação tiver os tipos de compilação debug e release com os tipos {savory, sweet} e {vanilla, chocolate} poderá especificar
  • savory para excluir todas as variantes com o tipo savory ou savoryVanillaRelease para excluir apenas esta variante específica.

Exemplo de build.gradle parcial

apply plugin: 'com.microsoft.intune.mam'

dependencies {
    implementation project(':product:FooLib')
    implementation project(':product:foo-project')
    implementation fileTree(dir: "libs", include: ["bar.jar"])
    implementation fileTree(dir: "libs", include: ["zap.jar"])
    implementation "com.contoso.foo:zap-artifact:1.0.0"
    implementation "com.microsoft.bar:baz:1.0.0"
    implementation "com.microsoft.qux:foo:2.0"

    // Include the MAM SDK
    implementation files("$PATH_TO_MAM_SDK/Microsoft.Intune.MAM.SDK.aar")
}
intunemam {
    excludeProjects = [':product:FooLib']
    includeExternalLibraries = ['bar.jar', "com.contoso.foo:zap-artifact", "com.microsoft.*", "!com.microsoft.qux*"]
    excludeClasses = ['com.contoso.SplashActivity']
    excludeVariants=['savory']
}

Este exemplo teria os seguintes efeitos:

• :product:FooLib não é reescrito porque está incluído em excludeProjects
• :product:foo-project é reescrito, exceto para com.contoso.SplashActivity, que é ignorado porque está em excludeClasses
• bar.jar é reescrito porque está incluído em includeExternalLibraries
• zap.jarnão é reescrito porque não é um projeto e não está incluído em includeExternalLibraries
• com.contoso.foo:zap-artifact:1.0.0 é reescrito porque está incluído em includeExternalLibraries
• com.microsoft.bar:baz:1.0.0 é reescrito porque está incluído em includeExternalLibraries através de um caráter universal (com.microsoft.*).
• com.microsoft.qux:foo:2.0 não é reescrito, mesmo que corresponda ao mesmo wildcard que o item anterior, porque é explicitamente excluído através de um padrão de negação.

Utilização de includeExternalLibraries

Uma vez que o plugin funciona apenas em dependências de projetos (geralmente fornecidos pela project() função) por padrão, quaisquer dependências obtidas a partir de maven ou outras fontes de pacote (por exemplo, " com.contoso.bar:baz:1.2.0 " ) devem ser fornecidas à propriedade se o processamento de includeExternalLibraries MAM deles for necessário com base nos critérios abaixo explicados. Os AARs locais (referenciados como ficheiros e não com notação de artefactos) são automaticamente incluídos.

São suportados carateres universais ("*"). Um item que começa ! com é uma negação e pode ser usado para excluir bibliotecas que de outra forma seriam incluídas por um wildcard.

Ao especificar dependências externas com a notação de artefacto, é aconselhável omitir o componente da versão no valor includeExternalLibraries. Se decidir incluir a versão, esta tem de ser exata. Não são suportadas especificações de versão dinâmicas (por exemplo, 1.+).

A regra geral que deve utilizar para determinar se tem de incluir as bibliotecas em includeExternalLibraries baseia-se em duas perguntas:

1. A biblioteca tem classes para as quais existem equivalentes de MAM? Exemplos: Activity, Fragment, ContentProvider, Service, etc.
2. Se sim, a sua aplicação utiliza essas classes?

Se responder "sim" a ambas as perguntas, tem de incluir essa biblioteca em includeExternalLibraries.

Scenario	Deve Incluir-se?
Inclui uma biblioteca de visualizador de PDFs na sua aplicação e utiliza o visualizador Activity na aplicação quando os utilizadores tentam ver PDFs	Yes
Inclui uma biblioteca HTTP na sua aplicação para obter um melhor desempenho na Web	No
Inclui uma biblioteca, como o React Native, que contém classes derivadas de Activity, Application e Fragment, e utiliza ou efetua uma derivação adicional dessas classes na sua aplicação	Yes
Inclui uma biblioteca, como o React Native, que contém classes derivadas de Activity, Application e Fragment, mas utiliza apenas auxiliares estáticos ou classes de utilitários	No
Inclui uma biblioteca que contém classes derivadas de TextView e utiliza ou efetua uma derivação adicional dessas classes na sua aplicação	Yes

Relatórios

O plugin de construção pode gerar um relatório html das alterações que faz. Para solicitar a geração deste relatório, especifique report = true no intunemam bloco de configuração. Se gerado, o relatório será escrito outputs/logs no diretório de construção.

intunemam {
    report = true
}

Verificação

O plugin de construção pode executar verificação adicional para procurar possíveis erros nas classes de processamento. Para solicitar isto, especifique verify = true no intunemam bloco de configuração. Note que isto pode adicionar alguns segundos ao tempo que a tarefa do plugin.

intunemam {
    verify = true
}

Construções incrementais

Para ativar o suporte para a construção incremental, especifique incremental = true no intunemam bloco de configuração. Esta é uma funcionalidade experimental que visa aumentar o desempenho da construção, processando apenas os ficheiros de entrada que mudaram. A configuração predefinida é false .

intunemam {
    incremental = true
}

Dependências

O plug-in do Gradle tem uma dependência no Javassist que tem de estar disponível para a resolução de dependências do Gradle (conforme descrito acima). O Javassist é utilizado apenas no momento da compilação ao executar o plug-in. Não será adicionado nenhum código do Javassist à sua aplicação.

Nota

Deve estar a utilizar a versão 3.6.1 ou a mais recente do plugin Android Gradle e Gradle 5.6.4 ou mais recente.

Ferramenta de Compilação de Linha de Comandos

Se a sua compilação utilizar o Gradle, avance para a secção seguinte.

A ferramenta de compilação de linha de comandos está disponível na pasta BuildTool do menu pendente do SDK. Executa a mesma função do plug-in do Gradle detalhado acima, mas pode ser integrada em sistemas de compilação personalizados ou que não sejam do Gradle. Uma vez que é mais genérica, é mais complexo invocá-la, pelo que o plug-in do Gradle deve ser utilizado sempre que possível.

Utilização da Ferramenta Command-Line

A ferramenta de linha de comando pode ser invocada utilizando os scripts de ajuda fornecidos localizados no BuildTool\bin diretório.

A ferramenta espera os parâmetros seguintes.

Parâmetro	Descrição
--input	Uma lista delimitada por pontos e vírgulas de ficheiros jar e diretórios de ficheiros de classe a modificar. Esta lista deve incluir todos os jars/diretórios que pretende reescrever.
--output	Uma lista delimitada por pontos e vírgulas de ficheiros jar e diretórios nos quais as classes modificadas devem ser armazenadas. Deve existir um valor de saída por cada valor de entrada, com apresentação por ordem.
--classpath	O caminho de classe de compilação. Isto pode conter tanto frascos como diretórios de classes.
--excludeClasses	Uma lista delimitada por pontos e vírgulas que contém os nomes das classes que devem ser excluídas do processo de reescrita.

Todos os parâmetros são necessários, com exceção de --excludeClasses, que é opcional.

Nota

Nos sistemas unix-like semi-cólon é um separador de comando. Para evitar que a casca separe comandos, certifique-se de que escapa a cada ponto-e-vírgula com ' ' ou embrulhe todo o parâmetro em aspas.

Invocação de ferramenta Command-Line exemplo

> BuildTool\bin\BuildTool.bat --input build\product-foo-project;libs\bar.jar --output mam-build\product-foo-project;mam-build\libs\bar.jar --classpath build\zap.jar;libs\Microsoft.Intune.MAM.SDK\classes.jar;%ANDROID_SDK_ROOT%\platforms\android-27\android.jar --excludeClasses com.contoso.SplashActivity

Este exemplo teria os seguintes efeitos:

• O diretório product-foo-project é reescrito para mam-build\product-foo-project
• bar.jar é reescrito para mam-build\libs\bar.jar
• zap.jarnão é reescrito porque é apenas apresentado em --classpath
• A classe com.contoso.SplashActivitynão é reescrita, mesmo que se encontre em --input

Nota

Atualmente, a ferramenta de compilação não suporta ficheiros aar. Se o seu sistema de compilação não extrair o classes.jar ao processar ficheiros aar, terá de fazê-lo antes de invocar a ferramenta de compilação.

Substituições de classes e métodos

Nota

As aplicações devem integrar-se com a ferramenta de construçãoSDK, que irá realizar todas estas substituições automaticamente (exceto para substituições manifestas

As classes base Android têm de ser substituídas pelos respetivos equivalentes de MAM para ativar a gestão do Intune. As classes do SDK estão entre a classe base Android e a própria versão derivada da aplicação dessa classe. Por exemplo, a atividade de uma aplicação poderá terminar com uma hierarquia de herança semelhante à seguinte: Activity > MAMActivity > AppSpecificActivity. A camada MAM filtra chamadas para operações do sistema, para fornecer uma vista gerida global à sua aplicação de forma totalmente integrada.

Além das classes base, algumas classes que a sua aplicação pode utilizar sem derivação (por exemplo, MediaPlayer) também exigem equivalentes de MAM e algumas chamadas de método também têm de ser substituídas. Os detalhes exatos são indicados abaixo.

Nota

Se a sua aplicação estiver a integrar-se com a ferramenta de construçãoSDK, as seguintes substituições de classe e método são executadas automaticamente.

Classe base Android	Substituição do SDK da Aplicação do Intune
android.app.Activity	MAMActivity
android.app.ActivityGroup	MAMActivityGroup
android.app.AliasActivity	MAMAliasActivity
android.app.Application	MAMApplication
android.app.Diálogo	MAMDialog
android.app.AlertDialog.Builder	MAMAlertDialogBuilder
android.app.DialogFragment	MAMDialogFragment
android.app.ExpandableListActivity	MAMExpandableListActivity
android.app.Fragment	MAMFragment
android.app.IntentService	MAMIntentService
android.app.LauncherActivity	MAMLauncherActivity
android.app.ListActivity	MAMListActivity
android.app.ListFragment	MAMListFragment
android.app.NativeActivity	MAMNativeActivity
android.app.PendingIntent	MAMPendingIntent (veja PendingIntent)
android.app.Service	MAMService
android.app.TabActivity	MAMTabActivity
android.app.TaskStackBuilder	MAMTaskStackBuilder
android.app.backup.BackupAgent	MAMBackupAgent
android.app.backup.BackupAgentHelper	MAMBackupAgentHelper
android.app.backup.FileBackupHelper	MAMFileBackupHelper
android.app.backup.SharePreferencesBackupHelper	MAMSharedPreferencesBackupHelper
android.content.BroadcastReceiver	MAMBroadcastReceiver
android.content.ContentProvider	MAMContentProvider
android.os.Binder	MAMBinder (Necessário apenas se o Enlaçamento não for gerado a partir de uma interface Android Interface Definition Language (AIDL))
android.media.MediaPlayer	MAMMediaPlayer
android.media.MediaMetadataRetriever	MAMMediaMetadataRetriever
android.media.MediaRecorder	MAMMediaRecorder
android.provider.DocumentsProvider	MAMDocumentsProvider
android.preference.PreferenceActivity	MAMPreferenceActivity
android.support.multidex.MultiDexApplication	MAMMultiDexApplication
android.widget.PopupWindow	MAMPopupMenu
android.widget.PopupWindow	MAMPopupWindow
android.widget.ListPopupWindow	MAMListPopupWindow
android.widget.TextView	MAMTextView
android.widget.AutoCompleteTextView	MAMAutoCompleteTextView
android.widget.CheckedTextView	MAMCheckedTextView
android.widget.EditText	MAMEditText
android.inputmethodservice.ExtractEditText	MAMExtractEditText
android.widget.MultiAutoCompleteTextView	MAMMultiAutoCompleteTextView
android.view.ViewGroup	Grupo MAMView

Nota

Mesmo que a sua aplicação não tenha necessidade da sua própria classe Application derivada, veja MAMApplication abaixo

Microsoft.Intune.MAM.SDK.Suppout.v4.jar:

Classe Android	Substituição do SDK da Aplicação do Intune
android.support.v4.app.DialogFragment	MAMDialogFragment
android.support.v4.app.FragmentActivity	MAMFragmentActivity
android.support.v4.app.Fragment	MAMFragment
android.support.v4.app.JobIntentService	MAMJobIntentService
android.support.v4.app.TaskStackBuilder	MAMTaskStackBuilder
android.support.v4.content.FileProvider	MAMFileProvider
android.support.v4.content.WakefulBroadcastReceiver	MAMWakefulBroadcastReceiver

Microsoft.Intune.MAM.SDK.Suppout.v7.jar:

Classe Android	Substituição do SDK da Aplicação do Intune
android.support.v7.app.AlertDialog.Builder	MAMAlertDialogBuilder
android.support.v7.app.AppCompatActivity	MAMAppCompatActivity
android.support.v7.widget.AppCompatAutoCompleteTextView	MAMAppCompatAutoCompleteTextView
android.support.v7.widget.AppCompatCheckedTextView	MAMAppCompatCheckedTextView
android.support.v7.widget.AppCompatEditText	MAMAppCompatEditText
android.support.v7.widget.AppCompatMultiAutoCompleteTextView	MAMAppCompatMultiAutoCompleteTextView
android.support.v7.widget.AppCompatTextView	MAMAppCompatTextView

Microsoft.Intune.MAM.SDK.Support.v17.jar:

Classe Android	Substituição do SDK da Aplicação do Intune
android.support.v17.leanback.widget.SearchEditText	MAMSearchEditText

Microsoft.Intune.MAM.SDK.Support.Text.jar:

Classe Android	Substituição do SDK da Aplicação do Intune
android.support.text.emoji.widget.EmojiAppCompatEditText	MAMEmojiAppCompatEditText
android.support.text.emoji.widget.EmojiAppCompatTextView	MAMEmojiAppCompatTextView
android.support.text.emoji.widget.EmojiEditText	MAMEmojiEditText
android.support.text.emoji.widget.EmojiTextView	MAMEmojiTextView

Métodos renomeados

Em muitos casos, um método disponível na classe Android foi marcado como final na classe de substituição da MAM. Neste caso, a classe de substituição de MAM proporciona um método com um nome semelhante (geralmente, com o sufixo MAM), que deve ser substituído. Por exemplo, ao derivar do MAMActivity, em vez de sobrepor onCreate() e super.onCreate() chamar, Activity deve onMAMCreate() sobrepor-se e chamar super.onMAMCreate() . O compilador de Java deve impor as restrições finais para impedir a substituição acidental do método original em vez do MAM equivalente.

MAMApplication

Se a sua aplicação criar uma subclasse de android.app.Application , então o plugin de construção transformará a sua classe de aplicação. Se a sua aplicação não criar uma subclasse de android.app.Application, tem de definir "com.microsoft.intune.mam.client.app.MAMApplication" como o atributo "android:name" na etiqueta <application> de AndroidManifest.xml.

PendingIntent

Em vez de PendingIntent.get*, tem de utilizar o método MAMPendingIntent.get*. Depois disto, pode utilizar o PendingIntent resultante como habitualmente.

Serviços de Sistema Encapsulados

Para algumas classes de serviço de sistema, é necessário chamar um método estático numa classe de wrapper de MAM em vez de invocar diretamente o método pretendido na instância de serviço. Por exemplo, uma chamada para getSystemService(ClipboardManager.class).getPrimaryClip() tem de se tornar uma chamada para MAMClipboardManager.getPrimaryClip(getSystemService(ClipboardManager.class). Não é recomendado efetuar estas substituições manualmente. Em alternativa, utilize o BuildPlugin para o fazer.

Classe Android	Substituição do SDK da Aplicação do Intune
android.content.ClipboardManager	MAMClipboard
android.contentProviderClient	MAMContentProviderClientManagement
android.contentResolver	MAMContentResolverManagement
android.content.pm.PackageManager	MAMPackageManagement
android.app.DownloadManager	MAMDownloadManagement
android.print.PrintManager	MAMPrintManagement
android.support.v4.print.PrintHelper	MAMPrintRperManagement
android.view.View	MAMViewManagement
android.view.DragEvent	MAMDragEventManagement
android.app.NotificationManager	MAMNotificationManagement
android.support.v4.app.NotificationManagerCompat	MAMNotificationCompatManagement
android.app.blob.BlobStoreManager	MAMBlobStoreManager
android.app.blob.BlobStoreManager.Session	MAMBlobStoreManager.Session

Algumas classes têm a maioria dos seus métodos embrulhados, por ClipboardManager ContentProviderClient exemplo, ContentResolver e PackageManager enquanto outras classes têm apenas um ou dois métodos embrulhados, por DownloadManager exemplo, PrintManager PrintHelper View DragEvent NotificationManager NotificationManagerCompat , e ... Consulte as APIs expostas pelas classes equivalentes MAM para o método exato se não utilizar o BuildPlugin.

Substituições do manifesto

Poderá ser preciso realizar algumas das substituições de classe indicadas acima no manifesto, bem como no código Java. De destacar:

• As referências do manifesto a android.support.v4.content.FileProvider devem ser substituídas por com.microsoft.intune.mam.client.support.v4.content.MAMFileProvider.

Bibliotecas AndroidX

Com o Android P, a Google anunciou um novo conjunto (com um novo nome) de bibliotecas de suporte chamado AndroidX e a versão 28 é a versão principal mais recente das bibliotecas android.support existentes.

Ao contrário das bibliotecas de suporte do Android, não fornecemos variantes de MAM das bibliotecas AndroidX. Em alternativa, o AndroidX deve ser tratado como qualquer outra biblioteca externa e configurado para ser reescrito com o plug-in/ferramenta de compilação. Para as construções de Gradle, isto pode ser feito incluindo androidx.* no includeExternalLibraries campo do plugin config. As invocações da ferramenta de linhas de comando devem listar explicitamente todos os ficheiros do frasco.

Componentes de Arquitetura Pré-AndroidX

Muitos componentes de arquitetura Android, incluindo Room, ViewModel e WorkManager foram reembalados para AndroidX. Se a sua aplicação utilizar as variantes pré-AndroidX destas bibliotecas, certifique-se de que as reescritas são aplicáveis, incluindo android.arch.* no includeExternalLibraries campo do plugin config. Em alternativa, atualize as bibliotecas para os seus equivalentes AndroidX.

Resolução de problemas Migração AndroidX

Ao migrar a sua aplicação integrada SDK para o AndroidX, poderá encontrar um erro como o seguinte:

incompatible types: android.support.v7.app.ActionBar cannot be converted to androidx.appcompat.app.ActionBar

Estes erros podem ocorrer porque a sua aplicação refere aulas de suporte MAM. As aulas de suporte do MAM envolvem aulas de suporte Android que se mudaram para o AndroidX. Para combater tais erros, substitua todas as referências de classe de suporte MAM com os seus equivalentes AndroidX. Isto pode ser conseguido removendo primeiro as dependências da biblioteca de suporte MAM dos seus ficheiros de construção Gradle. As linhas em questão serão semelhantes:

implementation "com.microsoft.intune.mam:android-sdk-support-v4:$intune_mam_version"
implementation "com.microsoft.intune.mam:android-sdk-support-v7:$intune_mam_version"

Em seguida, corrija os erros de tempo de compilação resultantes substituindo todas as referências às classes MAM no com.microsoft.intune.mam.client.support.v7 e com.microsoft.intune.mam.client.support.v4 pacotes com os seus equivalentes AndroidX. Por exemplo, as referências MAMAppCompatActivity devem ser alteradas para AndroidX's AppCompatActivity . Como discutido acima, o MAM build plugin/tool irá reescrever automaticamente as classes nas bibliotecas AndroidX com os equivalentes MAM apropriados em tempo de compilação.

Registo

O registo deve ser inicializado antecipadamente para obter o maior valor dos dados registados. Application.onMAMCreate() é normalmente o melhor local para inicializar o registo.

Para receber registos MAM na sua aplicação, crie um Java Handler e adicione-o ao MAMLogHandlerWrapper. Este procedimento invocará publish() no processador da aplicação para todas as mensagens de registo.

/**
 * 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);
}

Informação de Diagnóstico

As aplicações podem invocar MAMPolicyManager.showDiagnostics(context) um método que inicia uma atividade que exibe UI para recolher registos de Portal da Empresa e visualizar diagnósticos de MAM. Esta é uma característica opcional que pode ajudar na depuragem.

Quando Portal da Empresa não estiver instalado no dispositivo, será solicitado um diálogo para informar o utilizador de que esta informação não está disponível atualmente. Quando as aplicações são geridas pela política do MAM, serão apresentadas definições detalhadas da política do MAM.

Modo Rígido MAM

O Modo Rígido MAM fornece um mecanismo para detetar "cheiros" no uso de apps de APIs mam ou APIs de plataforma restrita mam. É vagamente modelado após o StrictMode do Android, e executa um conjunto de verificações que levantam erros quando falham. Não se destina a ser deixado habilitado em construções de produção, mas você é fortemente encorajado a usá-lo no desenvolvimento interno da sua app, depurar e/ou construções de alimentos para cães.

Para ativar, ligue

MAMStrictMode.enable();

início da inicialização da aplicação (por Application.onCreate exemplo).

Quando uma verificação do Modo Rígido MAM falha, tente determinar se é um problema real que pode ser corrigido na sua app, ou um falso positivo. Se acredita que é um falso positivo ou não tem certeza, por favor, avise a equipa do Intune MAM. Isto permitir-nos-á assegurar que concordamos com a falsa determinação positiva e para tentar melhorar a deteção para futuras libertações. Para suprimir falsos positivos, desative a verificação de falha (mais informações abaixo).

Manipulação de Violações

Quando um cheque falha, executa um MAMStrictViolationHandler. O manipulador predefinido lança um Error , que se espera que falhe a aplicação. Isto é para tornar as falhas o mais ruidosas possível, e encaixa-se na intenção de que o modo rigoroso não deve ser ativado nas construções de produção.

Se a sua aplicação quiser lidar com as violações de forma diferente, pode fornecer o seu próprio manipulador chamando:

MAMStrictMode.global().setHandler(handler);

onde handler se MAMStrictViolationHandler implementa.

Suprimir controlos

Se um cheque falhar numa situação em que a sua aplicação não está a fazer nada de errado, por favor informe-o como mencionado acima. Em alguns momentos, porém, pode ser necessário desativar a verificação encontrando um falso positivo, pelo menos enquanto se aguarda por um SDK atualizado. A verificação que falhou será mostrada no erro levantado pelo manipulador predefinido, ou será transmitida a um manipulador personalizado se for definido.

A supressão pode ser feita globalmente, mas é preferível desativar temporariamente por fio no site de chamadas específico. Os exemplos a seguir mostram várias formas de desativar MAMStrictCheck.IDENTITY_NO_SUCH_FILE (levantadas se for feita uma tentativa de proteger um ficheiro que não existe).

Supressão Temporária Per-Thread

Este é o mecanismo de supressão preferido.

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

Supressão Permanente Per-Thread

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

Supressão global (em todo o processo)

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

Ativar funcionalidades que requerem a participação da aplicação

Existem algumas políticas de proteção de aplicações que o SDK não pode impor por si só:

• Impor restrições à poupança de ficheiros para o armazenamento local ou na nuvem.
• Impor restrições à abertura de ficheiros a partir de armazenamento local ou em nuvem.
• Impor restrições ao conteúdo nas notificações.

A sua aplicação deve utilizar os métodos na interface AppPolicy para perguntar se estas ações são permitidas. Para testar se é permitido guardar ou abrir um ficheiro/documento, utilize [getIsSaveToLocationAllowed] e [getIsOpenFromLocationAllowed]. Para determinar as restrições ao conteúdo da notificação, utilize getNotificationRestriction . Exemplos alargados para todos estes cenários são dados mais tarde nesta secção.

Note que os métodos na AppPolicy que não dizem respeito às políticas acima referidas fornecem informações que a sua app pode usar para apresentar uma melhor experiência do utilizador, mas não são necessárias para a aplicação de políticas. Por exemplo, [a AppPolicy] expõe informações sobre as políticas pin e screenshot, mas estas são aplicadas automaticamente.

Para recuperar um AppPolicy caso, use MAMPolicyManager.getPolicyMAMPolicyManager ] .

Nota

MAMPolicyManager.getPolicy devolverá sempre uma Política de Aplicação não nula, mesmo se o dispositivo ou aplicação não estiver sob uma política de gestão do Intune.

Exemplo: determinar se o PIN é necessário para a aplicação

Se a aplicação tiver a sua própria experiência de utilizador de PIN, poderá querer desativá-la caso o administrador de TI tenha configurado o SDK para solicitar um PIN da aplicação. Para determinar se o administrador de TI implementou a política de PIN da aplicação para esta aplicação, para o utilizador final atual, chame o método seguinte:

MAMPolicyManager.getPolicy(currentActivity).getIsPinRequired();

Exemplo: determinar o utilizador primário do Intune

Para além das APIs expostas na AppPolicy, o nome principal do utilizador (UPN) também é exposto pela API getPrimaryUser() API definida dentro da interface [MAMUserInfo.] Para obter o UPN, chame o seguinte:

MAMComponents.get(MAMUserInfo.class).getPrimaryUser();

Exemplo: Transferência de dados entre apps e locais de armazenamento de dispositivos ou nuvem

Muitas aplicações implementam funcionalidades que permitem ao utilizador final guardar dados ou abrir dados a partir de serviços locais de armazenamento de ficheiros ou armazenamento na nuvem. A Aplicação Intune SDK permite que os administradores de TI protejam contra a entrada de dados e fugas, aplicando restrições de política como entenderem na sua organização.

A participação da aplicação é necessária para ativar a funcionalidade. Se a sua aplicação permitir a poupança para locais pessoais ou em nuvem diretamente da app ou permitir que os dados sejam abertos diretamente na app, deve implementar a respetiva funcionalidade para garantir que o administrador de TI pode controlar se é permitida a poupança para/abertura de um local.

Poupar para dispositivo ou armazenamento em nuvem

A API abaixo permite à aplicação saber se a gravação num arquivo pessoal é permitida pela política do administrador do Intune atual.

Para determinar se a política é imposta, faça a seguinte chamada:

MAMPolicyManager.getPolicy(currentActivity).getIsSaveToLocationAllowed(
SaveLocation service, String username);

O service parâmetro deve ser um dos seguintes valores de [SaveLocation:]

• SaveLocation.ONEDRIVE_FOR_BUSINESS
• SaveLocation.SHAREPOINT
• SaveLocation.LOCAL
• SaveLocation.ACCOUNT_DOCUMENT
• SaveLocation.OTHER

Para determinar se ACCOUNT_DOCUMENT deve ou deve ser passado para ver OTHER getIsSaveToLocationAllowed locais desconhecidos ou não listados para mais informações.

Para obter o username parâmetro, consulte o nome de utilizador para obter transferência de dados para obter mais informações.

O método anterior para determinar se uma política de utilizador permitia guardar dados em várias localizações era getIsSaveToPersonalAllowed(), dentro da mesma classe AppPolicy. Esta função é agora preterida e não deve ser utilizada, a invocação seguinte é equivalente a getIsSaveToPersonalAllowed():

MAMPolicyManager.getPolicy(currentActivity).getIsSaveToLocationAllowed(SaveLocation.LOCAL, null);

Abertura de dados a partir de um local de armazenamento local ou em nuvem

A API abaixo informa a aplicação se a abertura de uma loja pessoal é permitida pela política atual do administrador intune.

Para determinar se a política é imposta, faça a seguinte chamada:

MAMPolicyManager.getPolicy(currentActivity).getIsOpenFromLocationAllowed(
OpenLocation location, String username);

O location parâmetro deve ser um dos seguintes valores de [Aberturalocalização:]

• OpenLocation.ONEDRIVE_FOR_BUSINESS
• OpenLocation.SHAREPOINT
• OpenLocation.CAMERA
• OpenLocation.LOCAL
• OpenLocation.ACCOUNT_DOCUMENT
• OpenLocation.OTHER

A OpenLocation.CAMERA localização deve ser transmitida quando a aplicação estiver a abrir dados a partir da câmara. A OpenLocation.LOCAL localização deve ser transmitida quando a aplicação estiver a abrir dados a partir do armazenamento externo no dispositivo local. A OpenLocation.ACCOUNT_DOCUMENT localização deve ser transmitida quando a app estiver a abrir dados que pertencem a uma conta AAD assinada na app.

Para determinar se ACCOUNT_DOCUMENT deve ou deve ser passado para ver OTHER getIsOpenFromLocationAllowed locais desconhecidos ou não listados para mais informações.

Para obter o username parâmetro, consulte o nome de utilizador para obter transferência de dados para obter mais informações.

Locais desconhecidos ou não listados

Quando a localização desejada não estiver listada no SaveLocation ou OpenLocation numera ou se desconhece, existem duas opções para o service / location parâmetro, ACCOUNT_DOCUMENT e OTHER . ACCOUNT_DOCUMENT devem ser utilizados quando os dados pertencem a uma conta AAD assinada na app, mas não é ONEDRIVE_FOR_BUSINESS ou SHAREPOINT OTHER enquanto não deve ser utilizado quando não é esse o caso.

É importante deixar clara a distinção entre a conta gerida e uma conta que partilha a UPN da conta gerida. Por exemplo, uma conta gerida com UPN user@contoso.com " assinada em OneDrive não é a mesma que uma conta com UPN user@contoso.com " assinada em Dropbox. Se um serviço desconhecido ou não listado for acedido através da assinatura na conta gerida (por exemplo user@contoso.com " " assinada em OneDrive), deve ser representado pela ACCOUNT_DOCUMENT localização. Se o serviço desconhecido ou não listado assinar através de outra conta (por user@contoso.com exemplo, " assinado em Dropbox), não está a aceder ao local com uma conta gerida e deve ser representado pela OTHER localização.

Nome de utilizador para transferência de dados

Ao verificar a política de salvamento, username deve ser o nome/e-mail UPN/username associado ao serviço de cloud a ser guardado (não necessariamente o mesmo que o utilizador que possui o documento que está a ser guardado). SaveLocation.LOCAL não é um serviço de nuvem e por isso deve ser sempre utilizado com um null parâmetro de nome de utilizador.

Ao verificar a política aberta, username deve ser o nome/nome de utilizador/e-mail associado ao ficheiro ou serviço de nuvem a ser aberto. OpenLocation.LOCAL não é um local de serviço na nuvem, mas pode ser marcado com uma identidade para indicar a propriedade. Ao abrir um ficheiro a partir do armazenamento local, o proprietário do ficheiro deve ser sempre considerado, porque a política de poupança do proprietário do ficheiro pode ou não permitir que outros utilizadores abram o ficheiro. Para ficheiros com marcação de identidade, username deve ser a identidade do proprietário do ficheiro. Para ficheiros sem identificação, username deve ser nulo.

Nota

Por conveniência, fornecemos um método SDK AppPolicy.isOpenFromLocalStorageAllowed que leva um parâmetro para um arquivo no armazenamento File local. Os termos da política de aplicação, são funcionalmente idênticos à AppPolicy.isOpenFromLocationAllowed(OpenLocation.LOCAL, username) chamada, exceto que lida com a análise do proprietário do ficheiro username a partir do File .

OpenLocation.CAMERA não é um local de serviço na nuvem e, por isso, deve ser sempre utilizado com um null parâmetro de nome de utilizador.

Os seguintes locais esperam sempre um nome de utilizador que contenha um mapeamento entre a UPN AAD e o nome de utilizador do serviço de nuvem: ONEDRIVE_FOR_BUSINESS SHAREPOINT , e ACCOUNT_DOCUMENT .

Se não existir um mapeamento entre a UPN AAD e o nome de utilizador do serviço de nuvem ou se não for conhecido o nome de utilizador null .

Partilha de diálogo bloqueado

O SDK fornece um diálogo para notificar o utilizador de que uma ação de transferência de dados foi bloqueada pela política do MAM.

O diálogo deve ser apresentado ao utilizador quando a chamada API [isaveToAllowedForLocation] ou [isOpenFromAllowedForLocation] resulta no bloqueio da ação de salvamento/abertura. O diálogo exibe uma mensagem genérica e voltará ao que a Activity chamou quando foi dispensada.

Para visualizar o diálogo, faça a seguinte chamada:

MAMUIHelper.showSharingBlockedDialog(currentActivity)

Permitir a partilha de ficheiros

Se não for permitida a poupança em locais de armazenamento público, a sua aplicação deverá continuar a permitir que o utilizador veja ficheiros, descarregando-os para o armazenamento privado da aplicação e, em seguida, abrindo-os com o escolhidor do sistema.

Exemplo: Determinar se as notificações com dados da organização precisam de ser restringidas

Se a sua aplicação apresentar notificações, deve verificar a política de restrição de notificação para o utilizador associado à notificação antes de mostrar a notificação. Para determinar se a apólice é aplicada, faça a seguinte chamada.

NotificationRestriction notificationRestriction =
    MAMPolicyManager.getPolicyForIdentity(notificationIdentity).getNotificationRestriction();

Se a restrição for BLOCKED , a aplicação não deve apresentar notificações para o utilizador associado a esta política. Se, BLOCK_ORG_DATA a aplicação deve apresentar uma notificação modificada que não contenha dados de organização. Se, UNRESTRICTED todas as notificações forem permitidas.

Se getNotificationRestriction não for invocado, o MAM SDK fará o melhor esforço para restringir automaticamente as notificações para aplicações de identidade única. Se o bloqueio automático estiver ativado e BLOCK_ORG_DATA estiver definido, a notificação não será mostrada de todo. Para obter um controlo mais fino, verifique o valor e modifique adequadamente as notificações da getNotificationRestriction aplicação.

Contornar restrições de lançamento condicional

Em cenários muito raros, pode ser necessário que restrições de lançamento condicional sejam contornadas para uma determinada Atividade. Por exemplo, uma aplicação de marcação pode querer permitir que uma chamada recebida seja atendida sem que o utilizador tenha de introduzir primeiro o seu PIN. Para uma aplicação multi-identidade (ver Multi-Identidade abaixo), esta pode ser realizada definindo a identidade associada à Atividade a uma identidade nãogerida. Para permitir um bypass semelhante de restrições de lançamento condicional numa aplicação de identidade única, uma Atividade pode ser registada para bypass com o MAMPolicyManager.

MAMPolicyManager.bypassConditionalLaunchChecks(this);

Este método deve ser chamado antes onMAMCreate() de ser chamado, a fim de contornar eficazmente os controlos de lançamento condicional. Por exemplo, pode ser chamado do construtor da Atividade, ou de uma sobreposição para attachBaseContext() . Se optar por se attachBaseContext() sobrepor, lembre-se de ligar para a superclasse, attachBaseContext() ou podem ocorrer fugas de dados.

Nota

Uma vez que este método permite o bypass das verificações de política de lançamento condicional, este só deve ser utilizado após consultar a Microsoft para confirmar que não existe outra forma suportada de alcançar o comportamento pretendido da sua app.

Registar para obter notificações do SDK

Descrição Geral

O SDK da Aplicação do Intune permite à sua aplicação ter controlo sobre determinadas políticas, como a eliminação seletiva, quando são implementadas pelo administrador de TI. Quando um administrador de TI implementar uma destas políticas, o serviço do Intune transmite uma notificação para o SDK.

A sua aplicação deve registar-se para notificações do SDK, criando um MAMNotificationReceiver e registando-a com mamNotificationReceiverRegistry. Isto é feito ao indicar o recetor e o tipo de notificação desejados em App.onCreate, como ilustra o exemplo abaixo:

@Override
public void onCreate() {
  super.onCreate();
  MAMComponents.get(MAMNotificationReceiverRegistry.class)
    .registerReceiver(
      new ToastNotificationReceiver(),
      MAMNotificationType.WIPE_USER_DATA);
}

MAMNotificationReceiver

A interface MAMNotificationReceiver simplesmente recebe notificações do serviço Intune. Algumas notificações são processadas diretamente pelo SDK, ao passo que outras requerem a participação da aplicação. Uma aplicação deve devolver verdadeiro ou falso de uma notificação. Deve sempre devolver verdadeiro, a menos que qualquer ação que tentou fazer como resultado da notificação tenha falhado.

• Esta falha pode ser reportada ao serviço do Intune. Um exemplo de cenário a comunicar é se a aplicação não conseguir eliminar os dados de utilizadores após o administrador de TI iniciar uma eliminação.

Nota

É seguro bloquear no MAMNotificationReceiver.onReceive, uma vez que a chamada de retorno não está em execução no thread da IU.

Tipos de notificações

As seguintes notificações são enviadas para a aplicação e algumas delas podem requerer a participação da aplicação:

• WIPE_USER_DATA: Esta notificação é enviada num [MAMUserNotification]. Quando esta notificação for recebida, a aplicação deve eliminar todos os dados associados à identidade gerida (a partir de MAMUserNotification.getUserIdentity() ). A notificação pode ocorrer por diversas razões, incluindo quando a sua aplicação chama [não registristerAccountForMAM], quando um administrador de TI inicia uma limpeza, ou quando as políticas de acesso condicional exigidas por administração não estão satisfeitas. Se a sua aplicação não se registar para esta notificação, o comportamento de limpeza padrão será realizado. O comportamento predefinido eliminará todos os ficheiros de uma aplicação de identidade única ou de todos os ficheiros marcados com a identidade gerida para uma aplicação multi-identidade. Esta notificação nunca será enviada na linha UI.

• WIPE_USER_AUXILIARY_DATA: as aplicações poderão registar-se para obter esta notificação se quiserem utilizar o SDK da Aplicação do Intune para executar o comportamento predefinido de eliminação seletiva, mas ainda quiserem remover alguns dados auxiliares quando ocorrer a eliminação. Esta notificação não está disponível para aplicações de identidade únicas -- apenas será enviada para aplicações multi-identidade. Esta notificação nunca será enviada na linha UI.

• REFRESH_POLICY: Esta notificação é enviada numa [Notação MAMUser]. Quando esta notificação for recebida, quaisquer decisões políticas da Intune em cache pela sua app devem ser invalidadas e atualizadas. Se a sua aplicação não armazenar quaisquer pressupostos de política, não precisa de se registar para esta notificação. Não são dados quais os avisos sobre o fio condutor que esta notificação será enviada.

• REFRESH_APP_CONFIG: Esta notificação é enviada num [MAMUserNotification]. Quando esta notificação for recebida, quaisquer dados de Configuração de Aplicação em cache devem ser invalidados e atualizados. Não são dados quais os avisos sobre o fio condutor que esta notificação será enviada.

• MANAGEMENT_REMOVED: Esta notificação é enviada num [MAMUserNotification] e informa a aplicação que está prestes a ficar sem gestão. Quando já não for gerida, a aplicação deixará de conseguir ler ficheiros encriptados, ler dados encriptados com MAMDataProtectionManager, interagir com a área de transferência encriptada ou participar no ecossistema de aplicações geridas. Veja mais detalhes abaixo. Esta notificação nunca será enviada na linha UI.

• MAM_ENROLLMENT_RESULT: Esta notificação é enviada numa [MAMEnrollmentNotification] para informar a app que uma tentativa de inscrição APP-WE foi concluída e fornecer o estado dessa tentativa. Não são dados quais os avisos sobre o fio condutor que esta notificação será enviada.

• COMPLIANCE_STATUS: Esta notificação é enviada numa MAMComplianceNotification para informar a aplicação do resultado de uma tentativa de remediação de conformidade. Não são dados quais os avisos sobre o fio condutor que esta notificação será enviada.

Nota

Uma aplicação nunca se deverá registar para as notificações WIPE_USER_DATA e WIPE_USER_AUXILIARY_DATA.

MANAGEMENT_REMOVED

A MANAGEMENT_REMOVED notificação indica que um utilizador previamente gerido pela política deixará de ser gerido pela política do Intune MAM. Isto não requer a eliminação dos dados do utilizador ou a assinatura do utilizador (se fosse necessária uma limpeza, seria enviada uma WIPE_USER_DATA notificação). Muitas aplicações podem não precisar de lidar com esta notificação, no entanto as aplicações que utilizam [o MAMDataProtectionManager] devem tomar nota especial desta notificação.

Quando o MAM ligar para o recetor da MANAGEMENT_REMOVED aplicação, o seguinte será verdade:

• O MAM já desencriptou ficheiros previamente encriptados (mas não protegidos) pertencentes à aplicação. Os ficheiros em locais públicos no sdcard que não pertencem diretamente à aplicação (por exemplo, as pastas Documentos ou Download) não são desencriptados.
• Novos ficheiros ou tampão de dados protegidos criados pelo método do recetor (ou qualquer outro código em execução após o início do recetor) não serão encriptados.
• A aplicação ainda tem acesso a chaves de encriptação, pelo que operações como tampão de dados de desencriptação terão sucesso.

Assim que o recetor da sua aplicação regressar, deixará de ter acesso às chaves de encriptação.

Configure a Biblioteca de Autenticação microsoft (MSAL)

Nota

Azure Active Directory A Biblioteca de Autenticação (ADAL) é depreciada. Para obter mais informações, consulte [Update your applications to use Microsoft Authentication Library (MSAL)]. Para migrar a sua aplicação de ADAL para MSAL, consulte [o ADAL Android migratório para o MSAL] e [as diferenças entre ADAL e MSAL.]

Em primeiro lugar, leia as diretrizes de integração da [MSAL encontradas no repositório MSAL em GitHub]. Para mais informações, consulte [a visão geral da Microsoft Authentication Library (MSAL)] e do MSAL Wiki.

Devido à depreciação dos ADALs, as aplicações devem integrar-se com [o MSAL.] No entanto, o SDK ainda conta com [a ADAL] para os seus cenários de autenticação e lançamento condicional. Os valores de configuração necessários são comunicados ao SDK através de AndroidManifest metadados.

Para garantir que a política de autenticação da Intune pode ser aplicada corretamente, adicione o seguinte ao nó da aplicação em AndroidManifest.xml . Algumas destas configurações só são necessárias (ver configurações msais comuns abaixo) se a sua aplicação utilizar o MSAL para autenticação em geral; nesse caso, necessitará dos valores específicos que a sua aplicação utiliza para se registar com a AAD. Esta configuração é feita para garantir que o utilizador final não recebe o pedido de autenticação duas vezes, devido ao facto de o AAD reconhecer dois valores de registo separados: um da aplicação e outro do SDK.

<meta-data
    android:name="com.microsoft.intune.mam.aad.Authority"
    android:value="https://AAD authority/" />
<meta-data
    android:name="com.microsoft.intune.mam.aad.ClientID"
    android:value="your-client-ID-GUID" />
<meta-data
    android:name="com.microsoft.intune.mam.aad.NonBrokerRedirectURI"
    android:value="your-redirect-URI" />
<meta-data
    android:name="com.microsoft.intune.mam.aad.SkipBroker"
    android:value="[true | false]" />

Metadados MSAL

• Autoridade é a autoridade do ADD em utilização. Se este valor estiver em falta, será utilizado o ambiente público do ADD.

  Nota

  Não defina este campo se a sua aplicação tiver deteção de clouds soberanas.

• ClientID é o ClienteID (também conhecido como ID de aplicação) a ser usado. Deverá utilizar o ClientID da sua própria aplicação se estiver registado no Azure AD ou alavancar a Inscrição Padrão se não integrar o MSAL.

• NonBrokerRedirectURI é o [URI redirecionado AAD] para usar em casos sem corretor. Se não for especificado nenhum, será utilizado um valor predefinido de urn:ietf:wg:oauth:2.0:oob. Esta predefinição é adequada para a maioria das aplicações.

  • O NonBrokerRedirectURI só é utilizado quando skipBroker é "verdadeiro".

• SkipBroker é usado para anular o comportamento de participação padrão do MSAL SSO. SkipBroker só deve ser especificado para aplicações que especifiquem um ClientID e não suportem sSO de autenticação intermediada/dispositivo. Neste caso, deve ser definido como "verdadeiro". A maioria das aplicações não deve definir o parâmetro SkipBroker.

  • Um ClientID deve ser especificado no manifesto para especificar um valor SkipBroker.

  • Quando um ClientID é especificado, o valor predefinido é "falso".

  • Quando skipBroker for "verdadeiro", o NonBrokerRedirectURI será usado. As aplicações que não integram o MSAL (e, portanto, não têm ClientID) também vão falhar em "verdadeiro".

Configurações comuns de MSAL

Seguem-se as formas comuns de configuração de uma aplicação com o MSAL. Encontre a configuração da sua aplicação e certifique-se de definir os parâmetros de metadados MSAL (explicados acima) para os valores necessários. Em todos os casos, a Autoridade pode ser especificada se desejar ambientes não padrão. Se não for especificada, a autoridade pública de produção AAD será utilizada.

1. App não integra MSAL ou ADAL

Os metadados MSAL/ADAL não devem estar presentes no manifesto.

2. App integra MSAL

Parâmetro MSAL necessário	Valor
ClientID	O ClientID da aplicação (gerado pelo Azure AD quando a aplicação é registada)

A autoridade pode ser especificada se necessário.

Tem de registar a sua aplicação no Azure AD e dar à sua aplicação acesso ao serviço de política de proteção de aplicações:

• Consulte [registar a sua candidatura com Azure Ative Directory] para obter informações sobre o registo de um pedido com Azure AD.
• Certifique-se de que são seguidas as medidas para dar permissões à sua aplicação Android para o serviço de proteção de aplicações (APP). Utilize as instruções no guia "Começar com o Intune App SDK" em ["Dar à sua aplicação acesso ao serviço de proteção de aplicações Intune (opcional)".]

Veja também os requisitos para Acesso Condicional abaixo.

3. App integra a MSAL mas não suporta autenticação intermediada/SSO em todo o dispositivo

Parâmetro MSAL necessário	Valor
ClientID	O ClientID da aplicação (gerado pelo Azure AD quando a aplicação é registada)
SkipBroker	Verdadeiro

Autoridade e NonBrokerRedirectURI podem ser especificados se for necessário.

Política de proteção de aplicações sem inscrição de dispositivos

Descrição Geral

A política de proteção de aplicações do Intune sem a inscrição de dispositivos, também conhecida como APP-WE ou MAM-WE, permite que as aplicações sejam geridas pelo Intune sem a necessidade de o dispositivo ser inscrito no Intune MDM. O APP-WE funciona com ou sem a inscrição do dispositivo. Apesar de ser necessário ter o Portal da Empresa instalado no dispositivo, o utilizador não precisa de iniciar sessão no Portal da Empresa e inscrever o dispositivo.

Nota

Todas as aplicações devem suportar a política de proteção de aplicações sem a inscrição de dispositivos.

Fluxo de trabalho

Quando uma aplicação cria uma nova conta de utilizador, esta deve registar a conta de gestão com o SDK da Aplicação do Intune. O SDK processará os detalhes da inscrição da aplicação no serviço APP-WE. Se necessário, este repetirá qualquer inscrição em intervalos de tempo adequados caso ocorra alguma falha.

A aplicação também pode consultar o SDK da Aplicação do Intune para obter o estado de um utilizador registado para determinar se este deve ser impedido de aceder ao conteúdo empresarial. Pode registar várias contas de gestão; contudo, de momento, pode apenas inscrever ativamente uma conta com o serviço APP-WE de cada vez. Tal significa que apenas uma conta na aplicação pode receber a política de proteção de aplicações de cada vez.

A aplicação é obrigada a fornecer uma chamada de volta para adquirir o token de acesso apropriado da Microsoft Authentication Library (MSAL) ou da Azure Ative Directory Authentication Library (ADAL) em nome do SDK. Presume-se que a app já utiliza MSAL ou ADAL para autenticação do utilizador e para adquirir os seus próprios tokens de acesso.

Quando a aplicação remove uma conta por completo, esta deve anular o registo dessa conta para indicar que a aplicação já não deve aplicar a política para esse utilizador. Se o utilizador estava inscrito no serviço MAM, a inscrição do utilizador será anulada e a aplicação será apagada.

Descrição geral dos requisitos da aplicação

Para implementar a integração APP-WE, a aplicação tem de registar a conta de utilizador com o SDK MAM:

1. A aplicação deve implementar e registar uma instância da interface [MAMServiceAuthenticationCallback.] A instância da chamada de retorno deve ser registada o mais cedo possível no ciclo de vida da aplicação (normalmente no método onMAMCreate() da classe de aplicação).

2. Quando uma conta de utilizador é criada e o utilizador assina com sucesso com a MSAL, a aplicação deve ligar para [o registoAcountForMAM].

3. Quando uma conta de utilizador é removida, a aplicação deve chamar [o não registristaAForMAM] para remover a conta da gestão intune.

   Nota

   Se um utilizador terminar a sessão temporariamente na aplicação, a aplicação não precisará chamar unregisterAccountForMAM(). A chamada pode iniciar uma eliminação para remover por completo os dados empresariais do utilizador.

MAMEnrollmentManager

Todas as APIs de autenticação e registo necessárias podem ser encontradas na interface [MAMEnrollmentManager.] Pode obter uma referência do MAMEnrollmentManager da seguinte forma:

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

// make use of mgr

Está garantido que a instância MAMEnrollmentManager devolvida não é nula. Os métodos API enquadram-se em duas categorias: autenticação e registo de conta.

Autenticação da conta

Esta secção descreve os métodos de autenticação da API no MAMEnrollmentManager e como utilizá-los.

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

1. A aplicação deve implementar a interface MAMServiceAuthenticationCallback para permitir que o SDK solicite um token AAD para o dado ID do utilizador e recursos. A instância de retorno deve ser fornecida ao método de conservação do MAMEnrollmentManager [registo.] Pode ser necessário um token no início do ciclo de vida da aplicação para as requisições de inscrição ou para a aplicação de proteção de aplicações atualização check-ins, pelo que o local ideal para registar a chamada está no onMAMCreate() método da subclasse [MAMApplication] da app.

2. O método [acquireToken] deve adquirir o token de acesso para o ID de recurso solicitado para o utilizador dado. Se não conseguir adquirir o token pedido, este deverá devolver nulo.

   Nota

   Certifique-se de que a sua aplicação utiliza resourceId os aadId parâmetros e os parâmetros passados para acquireToken() que o token correto seja adquirido. O resourceId deve ser utilizado para gerar os âmbitos adequados e o deve ser utilizado para passar ao longo da conta aadId correta.

   class MAMAuthCallback implements MAMServiceAuthenticationCallback {
       public String acquireToken(String upn, String aadId, String resourceId) {
           final String[] scopes = {resourceId + "/.default"};
   
           final IAccount account = getAccount(aadId);
           if (account == null) {
               callback.onError(
                       new MsalUiRequiredException(MsalUiRequiredException.NO_ACCOUNT_FOUND, "no account found for " + aadId));
               return;
           }
   
           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 a aplicação não consiga fornecer um símbolo quando o SDK chama acquireToken() -- por exemplo, se a autenticação silenciosa falhar e for um momento inconveniente para mostrar um UI -- a aplicação pode fornecer um token mais tarde, ligando para o método [updateToken.] Os mesmos UPN, ID de UPN, ID do AAD e ID de recurso solicitados pela chamada anterior para acquireToken() têm de ser transmitidos para updateToken(), juntamente com o token que foi, finalmente, adquirido. A aplicação deve invocar este método com o máximo de brevidade possível após ser devolvido o valor nulo da chamada de retorno fornecida.

   Nota

   O SDK ligará para o acquireToken() periodicamente para obter o token; por isso, não é estritamente necessário ligar para o updateToken(). No entanto, é fortemente recomendado, pois pode ajudar as inscrições e check-ins de proteção de aplicações completas em tempo útil.

Registo da Conta

Esta secção descreve os métodos de API de registo de conta no MAMEnrollmentManager e como utilizá-los.

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

1. Para registar uma conta de gestão, a aplicação deve chamar registerAccountForMAM(). Uma conta de utilizador é identificada pelos seus UPN e ID de utilizador do AAD. O ID do inquilino também é necessário para associar os dados de inscrição com o inquilino do AAD do utilizador. A autoridade do utilizador pode igualmente ser fornecida para permitir a inscrição contra nuvens soberanas específicas; para mais informações consulte o Registo soberano da nuvem. O SDK pode tentar inscrever a aplicação para o utilizador especificado no serviço MAM. Se a inscrição falhar, esta tentará realizar periodicamente a inscrição até que a conta fique não registada. Por norma, o período de repetição é de 12 a 24 horas. O SDK fornece o estado das tentativas de inscrição de modo assíncrono através de notificações.

2. Uma vez que a autenticação AAD é necessária, a melhor altura para registar a conta de utilizador é depois de o utilizador ter assinado a app e ser autenticado com sucesso usando o MSAL. O ID AAD do utilizador e o ID do inquilino são devolvidos da chamada de autenticação MSAL como parte da [IAccount] conexão com o [IAuthenticationResult] .

   • A conta provém do IAuthenticationResult.getAccount() método e contém as informações pertinentes do utilizador.
   • O ID do inquilino provém do método IAccount.getTenantId().
   • O ID da AAD vem do IAccount.getId() método.

3. Para anular o registo de uma conta da gestão do Intune, a aplicação deve chamar unregisterAccountForMAM(). Se a conta tiver sido inscrita com êxito e for gerida, o SDK anulará a inscrição da conta e eliminará os seus dados. As tentativas periódicas de inscrição da conta serão interrompidas. O SDK fornece o estado do pedido de não inscrição assinerróteo através da notificação.

Registo em Clouds Soberanas

As aplicações [com deteção de clouds soberanas] têm de fornecer a authority para registerAccountForMAM().

Orientação MSAL

Para o MSAL, coloque multiple_clouds_supported true a definição no ficheiro de [configuração MSAL].

{
  "multiple_clouds_supported": true,
}

Orientação ADAL

Nota

O apoio ao registo soberano requer a versão 1.14.0 (ou superior) da biblioteca ADAL.

Para a ADAL, passe instance_aware=true para um parâmetro seguido acquireToken extraQueryParameters invocando o getAuthority() AuthenticationCallback AuthenticationResult .

mAuthContext.acquireToken(this, RESOURCE_ID, CLIENT_ID, REDIRECT_URI, PromptBehavior.FORCE_PROMPT, "instance_aware=true",
        new AuthenticationCallback<AuthenticationResult>() {
            @Override
            public void onError(final Exception exc) {
                // authentication failed
            }

            @Override
            public void onSuccess(final AuthenticationResult result) {
                mAuthority = result.getAuthority();
                // handle other parts of the result
            }
        });

Nota

Não estale o com.microsoft.intune.mam.aad.Authority item meta-dados em AndroidManifest.xml.

Nota

Certifique-se de que a autoridade está corretamente definida no seu método MAMServiceAuthenticationCallback::acquireToken().

Cloud Soberanas Suportadas Atualmente

1. Nuvem do Governo dos EUA de Azure
2. Microsoft Azure operado pela 21Vianet (Azure China)

Notas de implementação importantes

Autenticação

• Quando a aplicação chamar [o registoSForMAM,]poderá receber uma chamada de retorno na sua interface MAMServiceAuthenticationCallback pouco tempo depois, num fio diferente. Idealmente, a app adquiriu o seu próprio token AAD antes de registar a conta para acelerar a aquisição do token solicitado. Se a aplicação devolver um token válido da chamada, a inscrição prosseguirá e a aplicação obterá o resultado final através de uma notificação.

• Se a aplicação não devolver um token do AAD válido, o resultado final da tentativa de inscrição será AUTHORIZATION_NEEDED. Se a aplicação receber este Resultado através de notificação, é fortemente recomendado acelerar o processo de inscrição, adquirindo o token para o utilizador e recurso previamente solicitado a partir de [AcquireToken] e chamando o método [updateToken] para iniciar o processo de inscrição novamente.

• A aplicação registada MAMServiceAuthenticationCallback também será chamada para adquirir um token para check-ins periódicos de proteção de aplicações. Se a aplicação não conseguir fornecer um token quando solicitado, não receberá uma notificação, mas deverá tentar adquirir um token e ligar updateToken() na hora conveniente para acelerar o processo de check-in. Se não for fornecido um token, a chamada de retorno será realizada na mesma na próxima tentativa de registo.

• O suporte para cloud soberanas requer que forneça a autoridade.

Registo

• Para sua conveniência, os métodos de registo são idempotentes; por exemplo, [o registerAccountForMAM] apenas registará uma conta e tentará inscrever a aplicação se a conta ainda não estiver registada, e [o não registroAccountForMAM] só irá não registar uma conta se estiver atualmente registada. As chamadas subsequentes efetuadas são não operativas, por isso, não há qualquer problema em chamar esses métodos mais do que uma vez. Além disso, a correspondência entre as chamadas para esses métodos e as notificações dos resultados não são garantidas, isto é, se registerAccountForMAM() for chamado para uma identidade que já esteja registada, a notificação poderá não ser enviada novamente para essa identidade. É possível que sejam enviadas notificações que não correspondem a qualquer chamada para esses métodos, dado que o SDK pode tentar periodicamente realizar inscrições em segundo plano. Adicionalmente, podem ser acionadas anulações de inscrições com a eliminação dos pedidos recebidos do serviço Intune.

• Os métodos de registo podem ser chamados para um qualquer número de identidades diferentes, mas, atualmente, apenas uma conta de utilizador pode ser inscrita com êxito. Se estiverem registadas várias contas de utilizador licenciadas para o Intune e estas forem visadas pela política de proteção de aplicações na mesma altura ou próxima desta, não haverá qualquer garantia sobre qual será a escolhida.

• Finalmente, pode consultar o MAMEnrollmentManager para ver se uma determinada conta está registada e para obter o seu estado atual usando o método [GetRegisteredAccountStatus.] Se a conta fornecida não estiver registada, este método devolverá nulo. Se a conta estiver registada, este método devolverá o estado da conta como um dos membros da enumeração [MAMEnrollmentManager.Resultado.]

Códigos de estados e de resultados

Quando uma conta é registada pela primeira vez, esta começa no estado PENDING, o qual indica que a tentativa inicial de inscrição do serviço MAM está incompleta. Depois de concluída a tentativa de inscrição, será enviada uma notificação com um dos Códigos de resultados da tabela abaixo. Além disso, o método [getRegisteredAccountStatus] irá devolver o estado da conta para que a aplicação possa sempre determinar se o acesso a conteúdos corporativos está bloqueado para esse utilizador. Se a tentativa de inscrição falhar, o estado da conta poderá mudar ao longo do tempo, uma vez que o SDL volta a tentar a inscrição em segundo plano.

Código do resultado	Explicação
AUTHORIZATION_NEEDED	Este resultado indica que um token não foi fornecido pela instância MAMServiceAuthenticationCallback registada da aplicação, ou o token fornecido foi inválido. A aplicação deve adquirir um token válido e chamar [atualizaçãoToken,] se possível.
NOT_LICENSED	O utilizador não está licenciado para o Intune ou a tentativa de contacto do serviço da MAM do Intune falhou. A aplicação deve continuar num estado não gerido (normal) e o utilizador não deve estar bloqueado. As tentativas de inscrição serão repetidas periodicamente caso o utilizador se torne licenciado no futuro.
ENROLLMENT_SUCCEEDED	A tentativa de inscrição foi concluída com êxito ou o utilizador já está inscrito. No caso de uma inscrição com êxito, será enviada uma notificação de atualização da política antes desta notificação. O acesso a dados empresariais deve ser permitido.
ENROLLMENT_FAILED	A tentativa de inscrição falhou. Pode encontrar mais detalhes nos registos do dispositivo. A aplicação não deve permitir o acesso a dados corporativos neste estado, uma vez que foi previamente determinado que o utilizador está licenciado para a Intune. Todas as aplicações devem garantir que o acesso a dados corporativos não é autorizado, até ENROLLMENT_SUCCEEDED ser obtido pela sua app.
WRONG_USER	Apenas um utilizador por dispositivo pode inscrever uma aplicação com o serviço MAM. Este resultado indica que o utilizador para quem este resultado foi entregue (o segundo utilizador) é direcionado para a política do MAM, mas um utilizador diferente já está inscrito. Como a política do MAM não pode ser aplicada ao segundo utilizador, a sua aplicação não deve permitir o acesso aos dados deste utilizador (possivelmente removendo o utilizador da sua app) a menos que/até que a inscrição para este utilizador seja bem sucedida mais tarde. Em simultâneo com a entrega deste WRONG_USER resultado, o MAM solicitará a opção de remover a conta existente. Se o utilizador humano responder afirmativamente, será de facto possível inscrever o segundo utilizador pouco tempo depois. Enquanto o segundo utilizador permanecer registado, o MAM tentará a inscrição periodicamente.
UNENROLLMENT_SUCCEEDED	Anulação da inscrição concluída com êxito.
UNENROLLMENT_FAILED	O pedido de anulação da inscrição falhou. Pode encontrar mais detalhes nos registos do dispositivo. Em geral, isso não ocorrerá enquanto a aplicação passar uma UPN válida (nem nula nem vazia). Não existe uma reparação direta e fiável que a aplicação possa ter. Se este valor for recebido ao não registar uma UPN válida, por favor reporte como um bug à equipa do MAM intune.
PENDING	A tentativa inicial de inscrição do utilizador está em curso. A aplicação pode bloquear o acesso a dados empresariais até que o resultado da inscrição seja conhecido, mas não é necessário fazê-lo.
COMPANY_PORTAL_REQUIRED	O utilizador está licenciado para o Intune, mas a aplicação não pode ser inscrita até que a aplicação Portal da Empresa seja instalada no dispositivo. O SDK da Aplicação do Intune tentará bloquear o acesso à aplicação ao utilizador especificado e direcioná-lo para a instalação da aplicação Portal da Empresa (veja abaixo para obter detalhes).

Ignorar pedido de requisito do Portal da Empresa (opcional)

Se receber o Resultado COMPANY_PORTAL_REQUIRED, o SDK bloqueará a utilização das atividades que utilizam a identidade para a qual a inscrição foi solicitada. Em vez disso, o SDK fará com que essas atividades apresentem um pedido para transferir o Portal da Empresa. Se quiser evitar este comportamento na sua aplicação, as atividades podem implementar [MAMActivity.onMAMCompanyPortalRequired].

Este método é chamado antes de o SDK apresentar as suas IUs de bloqueio predefinidas. Se a aplicação alterar a identidade da atividade ou anular o registo do utilizador que tentou inscrever-se, o SDK não bloqueará a atividade. Nesta situação, cabe à aplicação evitar a fuga de dados empresariais. Apenas as aplicações de várias identidades (abordadas mais tarde) poderão alterar a identidade de atividade.

Se não herdar explicitamente [o MAMActivity] (porque a ferramenta de construção fará essa alteração), mas ainda assim tiver de lidar com esta notificação, poderá, em vez disso, implementar [o MAMActivityBlockingListener].

Notificações

Se a aplicação se registar para notificações de tipo MAM_ENROLLMENT_RESULT, será enviada uma [MAMEnrollmentNotification] para informar a app que o pedido de inscrição foi concluído. O MAMEnrollmentNotification serão recebidos através da interface [MAMNotificationReceiver,] conforme descrito no Registo para notificações da secção SDK.

public interface MAMEnrollmentNotification extends MAMUserNotification {
    MAMEnrollmentManager.Result getEnrollmentResult();
}

O [método getEnrollmentResult] devolve o resultado do pedido de inscrição. Uma vez que MAMEnrollmentNotification expande MAMUserNotification, a identidade do utilizador para o qual foi tentada a inscrição também está disponível. A aplicação deve implementar a interface MAMNotificationReceiver para receber estas notificações, detalhadas na secção Registar para obter notificações do SDK.

O estado da conta de utilizador registada pode alterar-se quando uma notificação de inscrição é recebida, mas não altera em todos os casos (por exemplo, se a AUTHORIZATION_NEEDED notificação for recebida após um resultado mais informativo, WRONG_USER como, por exemplo, o resultado mais informativo será mantido como o estado da conta). Uma vez que a conta esteja inscrita com sucesso, o estado permanecerá até ENROLLMENT_SUCCEEDED que a conta seja desenrolada ou limpa.

Acesso Condicional

O Acesso Condicional (AC) é uma funcionalidade do Azure Active Directory que pode ser utilizada para controlar o acesso aos recursos do AAD. Os administradores do Intune podem definir regras de AC que permitem aceder aos recursos apenas a partir de dispositivos ou aplicações que são geridos pelo Intune. Para garantir que a sua aplicação pode aceder aos recursos quando for adequado, tem de seguir os passos abaixo. Se a aplicação não adquirir tokens de acesso do AAD, ou aceder apenas a recursos que não podem ser protegidos por AC, pode ignorar estes passos.

1. Registe a sua aplicação com o Azure Active Directory. Isto irá gerar um ID do Cliente para a sua aplicação.
2. Siga os passos para [utilizar a MSAL] e [Configure MSAL para utilizar um corretor].
3. Desaprote os parâmetros de meta-dados manifestos por configurações MSAL comuns para a App Integra o MSAL,ver acima.

App Protection CA

Descrição Geral

Com a App Protection CA (Acesso Condicional), o acesso aos recursos está condicionado na aplicação das Políticas de Proteção de Aplicações Intune. A AAD aplica-o exigindo que a app seja matriculada e gerida pela APP antes de conceder um token para aceder a um recurso protegido pela AC.

Nota

O suporte para a App Protection CA requer a versão 1.0.0 (ou maior) da biblioteca MSAL.

Lidar com o incumprimento da MSAL

Ao adquirir um símbolo para um utilizador, a biblioteca MSAL pode devolver ou lançar um MsalIntuneAppProtectionPolicyRequiredException para indicar o incumprimento da gestão da APP. Podem ser extraídos parâmetros adicionais da exceção para utilização na correção da conformidade (ver MAMComplianceManager). Uma vez que a remediação seja bem sucedida, a aplicação pode tentar a aquisição de token através da MSAL.

MAMComplianceManager

A interface MAMComplianceManager é utilizada quando o erro exigido pela política é recebido da MSAL. Contém o método remediateCompliance que deve ser chamado para tentar colocar a app em um estado compatível. Pode obter uma referência do MAMComplianceManager da seguinte forma:

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

// make use of mgr

Está garantido que a instância MAMComplianceManager devolvida não é nula.

package com.microsoft.intune.mam.policy;

public interface MAMComplianceManager {
    void remediateCompliance(String upn, String aadId, String tenantId, String authority, boolean showUX);
}

O remediateCompliance() método é chamado para tentar colocar a app sob gestão para satisfazer as condições para a AAD conceder o token solicitado. Os primeiros quatro parâmetros podem ser extraídos da exceção recebida pelo método MSAL AuthenticationCallback.onError() (ver amostra de código abaixo). O parâmetro final é um booleano que controla se um UX é mostrado durante a tentativa de conformidade. Esta é uma interface de estilo de progresso de bloqueio simples fornecida como um padrão para apps que não têm necessidade de mostrar UX personalizado durante esta operação. Só bloqueará enquanto a correção de conformidade estiver em curso e não apresentará o resultado final. A aplicação deve registar um recetor de notificação para lidar com o sucesso ou falha da tentativa de remediação da conformidade (ver abaixo).

O remediateCompliance() método pode fazer uma inscrição no MAM como parte do estabelecimento do cumprimento. A aplicação pode receber uma notificação de inscrição se tiver registado um recetor de notificação para notificações de inscrição. O MAMServiceAuthenticationCallback registado da aplicação terá o seu método [de aquisiçãoToken] chamado para obter um símbolo para a inscrição no MAM. acquireToken() será chamado antes de a app ter adquirido o seu próprio token, pelo que quaisquer tarefas de contabilidade ou criação de conta que a app faz após uma aquisição de token bem sucedida podem ainda não ter sido feitas. A chamada deve ser capaz de adquirir um símbolo neste caso. Se não puder devolver um token de, a tentativa de reparação de acquireToken() conformidade falhará. Se ligar para [actualizaçãoToken] mais tarde com um token válido para o recurso solicitado, a remediação de conformidade será novamente julgada com o token dado.

Nota

A aquisição de token silencioso ainda será possível acquireToken() porque o utilizador já terá sido guiado para instalar o corretor e registar o dispositivo antes de a MsalIntuneAppProtectionPolicyRequiredException exceção ser recebida. Isto resulta em que o corretor tenha um token de atualização válido na sua cache, permitindo que a aquisição silenciosa do token solicitado tenha sucesso.

Aqui está uma amostra de receber o erro exigido pela política no AuthenticationCallback.onError() método, e chamando o MAMComplianceManager para lidar com o erro.

public void onError(@Nullable MsalException exc) {
    if (exc instanceof MsalIntuneAppProtectionPolicyRequiredException) {

        final MsalIntuneAppProtectionPolicyRequiredException policyRequiredException =
            (MsalIntuneAppProtectionPolicyRequiredException) ex;

        final String upn = policyRequiredException.getAccountUpn();
        final String aadId = policyRequiredException.getAccountUserId();
        final String tenantId = policyRequiredException.getTenantId();
        final String authority = policyRequiredException.getAuthorityURL();

        MAMComplianceManager complianceManager = MAMComponents.get(MAMComplianceManager.class);
        complianceManager.remediateCompliance(upn, aadId, tenantId, authority, showUX);
    }
}

Notificações de Estado

Se a aplicação se registar para notificações de tipo COMPLIANCE_STATUS, será enviada uma MAMComplianceNotification para informar a aplicação do estado final da tentativa de remediação de conformidade. O MAMComplianceNotification serão recebidos através da interface [MAMNotificationReceiver,] conforme descrito no Registo para notificações da secção SDK.

public interface MAMComplianceNotification extends MAMUserNotification {
    MAMCAComplianceStatus getComplianceStatus();
    String getComplianceErrorTitle();
    String getComplianceErrorMessage();
}

O getComplianceStatus() método devolve o resultado da tentativa de reparação de conformidade como um valor do MAMCAComplianceStatus enum.

Código de estado	Explicação
DESCONHECIDO	O estado é desconhecido. Isto pode indicar uma razão de falha inesperada. Informações adicionais podem ser encontradas nos registos Portal da Empresa.
EM CONFORMIDADE	A remediação de conformidade foi bem sucedida e a app está agora em conformidade com a política. A aquisição do token MSAL deve ser novamente julgada.
NOT_COMPLIANT	A tentativa de remediar a conformidade falhou. A aplicação não está em conformidade e a aquisição de fichas MSAL não deve ser novamente julgada até que a condição de erro seja corrigida. Informações adicionais de erro são enviadas com a MAMComplianceNotification.
SERVICE_FAILURE	Houve uma falha ao tentar obter dados de conformidade do Serviço Intune. Informações adicionais podem ser encontradas nos registos Portal da Empresa.
NETWORK_FAILURE	Houve um erro de ligação ao Serviço Intune. A aplicação deve tentar novamente a sua aquisição de fichas quando a ligação à rede for restaurada.
CLIENT_ERROR	A tentativa de remediar a conformidade falhou por alguma razão relacionada com o cliente. Por exemplo, nenhum token ou utilizador errado. Informações adicionais de erro são enviadas com a MAMComplianceNotification.
PENDING	A tentativa de remediar o cumprimento falhou porque a resposta ao estado ainda não tinha sido recebida do serviço quando o prazo foi ultrapassado. A aplicação deve tentar a sua aquisição de ficha novamente mais tarde.
COMPANY_PORTAL_REQUIRED	O Portal da Empresa deve ser instalado no aparelho para que a correção da conformidade seja bem sucedida. Se o Portal da Empresa já se encontra instalado no dispositivo, a aplicação tem de ser reiniciada. Neste caso, será mostrado um diálogo pedindo ao utilizador que reinicie a aplicação.

Se o estado de conformidade MAMCAComplianceStatus.COMPLIANT for, a aplicação deve relançar a sua aquisição original de token (para o seu próprio recurso). Se a tentativa de correção de conformidade falhar, os getComplianceErrorTitle() getComplianceErrorMessage() e métodos devolverão as cordas localizadas que a aplicação pode exibir ao utilizador final, se assim o desejar. A maioria dos casos de erro não são remediados pela app, pelo que, no caso geral, é melhor falhar a criação de conta ou fazer login e permitir que o utilizador tente novamente mais tarde. Se uma falha for persistente, os registos MAM podem ajudar a determinar a causa. O utilizador final pode submeter os registos. Para mais informações, consulte upload e registos de e-mail.

Uma MAMComplianceNotification vez que se MAMUserNotification estende, está também disponível a identidade do utilizador para quem foi tentada a reparação.

Aqui está um exemplo de registo de um recetor usando uma classe anónima para implementar a interface MAMNotificationReceiver:

final MAMNotificationReceiverRegistry notificationRegistry = MAMComponents.get(MAMNotificationReceiverRegistry.class);
// create a receiver
final MAMNotificationReceiver receiver = new MAMNotificationReceiver() {
    public boolean onReceive(MAMNotification notification) {
        if (notification.getType() == MAMNotificationType.COMPLIANCE_STATUS) {
            MAMComplianceNotification complianceNotification = (MAMComplianceNotification) notification;
            
            // take appropriate action based on complianceNotification.getComplianceStatus()
            
            // unregister this receiver if no longer needed
            notificationRegistry.unregisterReceiver(this, MAMNotificationType.COMPLIANCE_STATUS);
        }
        return true;
    }
};
// register the receiver
notificationRegistry.registerReceiver(receiver, MAMNotificationType.COMPLIANCE_STATUS);

Nota

O recetor de notificação deve ser registado antes de ligar remediateCompliance() para evitar uma condição de corrida que possa resultar na falta da notificação.

Declarando apoio à App CA

Uma vez que a sua aplicação esteja pronta para lidar com a remediação da App CA, pode dizer ao Microsoft Identity que a sua aplicação está pronta para a App CA. Para isso na sua aplicação MSAL, construa o seu Cliente Público utilizando as Capacidades do Cliente de "protapp"

{
      "client_id" : "4b0db8c2-9f26-4417-8bde-3f0e3656f8e0",
      "authorization_user_agent" : "DEFAULT",
      "redirect_uri" : "msauth://com.microsoft.identity.client.sample.local/1wIqXSqBj7w%2Bh11ZifsnqwgyKrY%3D",
      "multiple_clouds_supported":true,
      "broker_redirect_uri_registered": true,
      "account_mode": "MULTIPLE",
      "client_capabilities": "protapp",
      "authorities" : [
        {
          "type": "AAD",
          "audience": {
            "type": "AzureADandPersonalMicrosoftAccount"
          }
        }
      ]
    }

Notas de implementação

Nota

O método da aplicação MAMServiceAuthenticationCallback.acquireToken() deve passar falso para a bandeira forceRefresh para acquireTokenSilentAsync() .

AcquireTokenSilentParameters acquireTokenSilentParameters =
        builder.withScopes(Arrays.asList(scopes))
               .forceRefresh(false)
               .build();

acquireTokenSilentAsync(acquireTokenSilentParameters);

Nota

Se pretender mostrar um UX de bloqueio personalizado durante a tentativa de reparação, deve passar falso para o parâmetro showUX para remediateCompliance() . Tem de se certificar de que mostra o seu UX e regista primeiro o seu ouvinte de notificação antes de ligar remediateCompliance() . Isto evitará uma condição de corrida em que a notificação pode ser perdida se remediateCompliance() falhar muito rapidamente. Por exemplo, o onCreate() ou método de uma onMAMCreate() subclasse de Atividade é o local ideal para registar o ouvinte de notificação e, em seguida, ligar remediateCompliance() . Os parâmetros para remediateCompliance() podem ser passados para o seu UX como extras de intenção. Quando a notificação do estado de conformidade for recebida, pode apresentar o resultado ou simplesmente terminar a atividade.

Nota

remediateCompliance() registará a conta e tentará a inscrição. Uma vez adquirido o símbolo principal, a vocação registerAccountForMAM() não é necessária, mas não há mal nenhum em fazê-lo. Por outro lado, caso a app não adquira o seu token e pretenda remover a conta do utilizador, deve ligar unregisterAccountForMAM() para remover a conta e evitar que as retrações de matrícula de fundo.

Proteger dados de cópias de segurança

A partir do Android Marshmallow (API 23), o Android disponibiliza duas formas de as aplicações fazerem cópias de segurança dos dados. Cada opção está disponível para a sua aplicação e requer passos diferentes para garantir que a proteção de dados do Intune é implementada corretamente. Pode ver na tabela abaixo as ações correspondentes necessárias para o comportamento de proteção de dados correto. Pode ler mais informações sobre os métodos de cópia de segurança no Guia de API do Android.

Cópia de Segurança Automática para Aplicações

O Android começou a disponibilizar cópias de segurança automáticas completas para o Google Drive aplicações em dispositivos Android Marshmallow, independentemente da API de destino da aplicação. Em AndroidManifest.xml, se definir explicitamente android:allowBackup como falso, a sua aplicação nunca será colocada em fila de espera para cópias de segurança pelo Android e os dados "empresariais" permanecerão na aplicação. Neste caso, não são necessárias mais ações.

No entanto, por predefinição, o atributo android:allowBackup é definido como verdadeiro, mesmo que android:allowBackup não seja especificado no ficheiro de manifesto. Isto significa que todos os dados de aplicações são automaticamente colocados em cópia de segurança na conta do Google Drive do utilizador, um comportamento predefinido que constitui um risco de fuga de dados. Por essa razão, o SDK precisa das alterações descritas abaixo para assegurar que a proteção de dados é aplicada. É importante seguir as orientações abaixo para proteger devidamente os dados de clientes, se quiser que a aplicação seja executada em dispositivos Android Marshmallow.

O Intune permite-lhe utilizar todas as funcionalidades da Cópia de Segurança Automática disponíveis em Android, incluindo a capacidade de definir regras personalizadas no XML, mas tem de seguir os passos abaixo para proteger os seus dados:

1. Se a sua aplicação não utilizar o seu próprio BackupAgent personalizado, utilize o MAMBackupAgent predefinido para permitir cópias de segurança automáticas completas, que estejam em conformidade com a política do Intune. Coloque o seguinte no manifesto da aplicação:

   android:fullBackupOnly="true"
   android:backupAgent="com.microsoft.intune.mam.client.app.backup.MAMDefaultBackupAgent"
   

2. [Opcional] Se implementou um BackupAgent personalizado opcional, tem de se certificar de que utiliza [o MAMBackupAgent] ou [o MAMBackupAgentHelper]. Veja as secções seguintes. Considere mudar para o MAMDefaultBackupAgentda Intune, descrito no passo 1, que fornece um back-up fácil no Android M e acima.

3. Quando decidir que tipo de cópia de segurança completa a sua aplicação deve receber (não filtrada, filtrada ou nenhuma), terá de definir o atributo android:fullBackupContent para verdadeiro, falso ou um recurso XML na sua aplicação.

4. Assim, deve copiar o que colocar em android:fullBackupContent para uma etiqueta de metadados com o nome com.microsoft.intune.mam.FullBackupContent no manifesto.

   Exemplo 1: se pretender que a aplicação possua cópias de segurança completas sem exclusões, defina o atributo android:fullBackupContent e a etiqueta de metadados com.microsoft.intune.mam.FullBackupContent como verdadeiro:

   android:fullBackupContent="true"
   ...
   <meta-data android:name="com.microsoft.intune.mam.FullBackupContent" android:value="true" />  
   

   Exemplo 2: se pretender que a aplicação utilize o seu BackupAgent personalizado e recuse a utilização de cópias de segurança automáticas em total conformidade com a política do Intune, terá de definir o atributo e a etiqueta de metadados como falso:

   android:fullBackupContent="false"
   ...
   <meta-data android:name="com.microsoft.intune.mam.FullBackupContent" android:value="false" />  
   

   Exemplo 3: se quiser que a sua aplicação tenha cópias de segurança completas de acordo com as suas regras personalizadas definidas num ficheiro XML, defina o atributo e a etiqueta de metadados para o mesmo recurso XML:

   android:fullBackupContent="@xml/my_scheme"
   ...
   <meta-data android:name="com.microsoft.intune.mam.FullBackupContent" android:resource="@xml/my_scheme" />  
   

Cópia de segurança Chave/Valor

A opção Key/Value Backup (Cópia de Segurança Chave/Valor) está disponível para todas as APIs 8 e posterior e carrega dados da aplicação para o Android Backup Service (Serviço de Cópia de Segurança do Android). A quantidade de dados por utilizador da aplicação está limitada a 5 MB. Se utilizar a Chave/Cópia de Segurança de Valor, deve utilizar um [BackupAgentHelper] ou um [BackupAgent].

BackupAgentHelper

[BackupAgentHelper] é mais fácil de implementar do que [BackupAgent] tanto em termos de funcionalidade nativa do Android como integração do Intune MAM. BackupAgentHelper permite que o desenvolvedor registe ficheiros inteiros e preferências partilhadas a um FileBackupHelper e SharedPreferencesBackupHelper (respectivamente) que são adicionados ao BackupAgentHelper após a criação. Siga os passos abaixo para utilizar um BackupAgentHelper com a MAM do Intune:

1. Para utilizar backup multi-identidade com um BackupAgentHelper , siga o guia Android para estender o BackupAgentHelper.

2. Recorra à sua classe para expandir a MAM equivalente ao BackupAgentHelper, FileBackupHelper e SharedPreferencesBackupHelper.

Classe Android	MAM equivalente
BackupAgentHelper	MAMBackupAgentHelper
FileBackupHelper	MAMFileBackupHelper
SharedPreferencesBackupHelper	MAMSharedPreferencesBackupHelper

Se seguir estas orientações obterá uma cópia de segurança e um restauro de várias identidades com êxito.

BackupAgent

Um BackupAgent permite-lhe ser muito mais explícito sobre os dados que farão parte da cópia de segurança. Uma vez que cabe ao programador uma boa parte de responsabilidade quanto à implementação, existem mais passos necessários para garantir a proteção de dados adequada a partir do Intune. Uma vez que a maior parte do trabalho é feita por si, o programador, a integração do Intune é ligeiramente mais envolvida.

Integrar a MAM:

1. Leia atentamente Key/Value Backup (Cópia de Segurança Chave/Valor) no guia Android, mais concretamente, Extending BackupAgent (Expandir o BackupAgent) para garantir que a sua implementação do BackupAgent segue as diretrizes do Android.

2. Que a sua classe estenda [o MAMBackupAgent].

Cópia de segurança de várias identidades:

1. Antes de iniciar a cópia de segurança, verifique se os ficheiros ou as memórias intermédias pretendidas têm efetivamente permissão do administrador de TI para serem guardados em cópia de segurança em cenários de várias identidades. Fornecemos-lhe a isBackupAllowed função em MAMFileProtectionManager e MAMDataProtectionManager para determinar isto. Se não for permitida a cópia de segurança de ficheiros ou memórias intermédias de dados, não deverá continuar a inclui-los na sua cópia de segurança.

2. Se em algum momento durante a cópia de segurança pretender fazer uma cópia de segurança das identidades dos ficheiros selecionados no passo 1, terá de chamar backupMAMFileIdentity(BackupDataOutput data, File … files) com os ficheiros a partir dos quais planeia extrair dados. Esta ação irá criar automaticamente novas entidades de cópia de segurança e escrevê-las em BackupDataOutput por si. Estas entidades serão consumidas automaticamente após o restauro.

Restauro de várias identidades:

O guia de Cópia de Segurança de Dados especifica um algoritmo geral para restaurar os dados da aplicação e fornece um exemplo de código na secção Extending BackupAgent (Expandir o BackupAgent). Para realizar um restauro de várias identidades com êxito, tem de seguir a estrutura geral fornecida neste exemplo de código dando especial atenção ao seguinte:

1. Deve utilizar um ciclo while(data.readNextHeader())* para percorrer as entidades de cópia de segurança.

2. Terá de chamar data.skipEntityData()* se data.getKey()* não corresponder à chave que escreveu na onBackup. Sem realizar este passo, os seus restauros podem não ter êxito.

3. Evite a devolução enquanto está a consumir entidades de cópia de segurança na construção while(data.readNextHeader())*, uma vez que as entidades com que escrevemos automaticamente serão perdidas.

• Em que data é o nome da variável local do MAMBackupDataInput que é transmitido para a aplicação após o restauro.

Multi-Identidade (opcional)

Descrição Geral

Por predefinição, o SDK da Aplicação do Intune aplica a política à aplicação como um todo. As várias identidades são uma funcionalidade de proteção opcional da aplicação do Intune que pode ser ativada para permitir que a política seja aplicada num nível por identidade. Esta opção requer uma participação da aplicação significativamente maior do que outras funcionalidades de proteção da aplicação.

Nota

A falta de participação correta da aplicação pode resultar na perda de dados e noutros problemas de segurança.

Quando o utilizador inscrever o dispositivo ou a aplicação, o SDK regista esta identidade e considera-a a identidade gerida primária do Intune. Os outros utilizadores na aplicação serão tratados como não geridos, com definições de política não restrita.

Nota

Atualmente, apenas é suportada uma identidade gerida do Intune por dispositivo.

Uma identidade é definida como uma cadeia de carateres. As identidades são insensíveis a caso, e os pedidos ao SDK para uma identidade não podem devolver o mesmo invólucro que foi originalmente usado na definição da identidade.

A aplicação tem de informar o SDK quando tenciona alterar a identidade ativa. Em alguns casos, o SDK também notifica a aplicação quando é necessária uma alteração de identidade. No entanto, na maioria dos casos, a MAM não consegue reconhecer os dados que são apresentados na IU ou que são utilizados a dada altura num thread e baseia-se na aplicação para definir a identidade correta, de forma a evitar a fuga de dados. Nas secções seguintes, serão destacados alguns cenários específicos que requerem uma ação por parte da aplicação.

Ativar Identidades Múltiplas

Por predefinição, todas as aplicações são consideradas aplicações de identidade única. Pode declarar que uma aplicação tem conhecimento de várias identidades ao colocar os seguintes metadados no ficheiro AndroidManifest.xml.

  <meta-data
    android:name="com.microsoft.intune.mam.MAMMultiIdentity"
    android:value="true" />

Definir a Identidade

Os programadores podem definir a identidade do utilizador da aplicação nos seguintes níveis por ordem decrescente de prioridade:

1. Nível de thread
2. Context``Activity(geralmente) nível
3. Nível de processo

Uma identidade definida no nível de thread prevalece sobre uma identidade definida no nível Context, que prevalece sobre uma identidade definida no nível de processo. Uma identidade definida num Context só é usada em cenários associados apropriados. As operações de IO de ficheiro, por exemplo, não têm uma associada Context . Mais comummente, as aplicações vão definir a Context identidade num Activity . Uma aplicação não deve exibir dados para uma identidade gerida a menos que a Activity identidade esteja definida para essa mesma identidade. Em geral, a identidade ao nível do processo só é útil se a aplicação funcionar apenas com um utilizador de cada vez em todos os threads. É possível que muitas das aplicações não precisem de a utilizar.

Se a sua aplicação utilizar o Application contexto para adquirir serviços de sistema, certifique-se de que o fio ou identidade do processo foi definido, ou que definiu a identidade da UI no contexto da sua aplicação. Application

Se a sua aplicação utilizar um Service contexto para lançar intenções, use os problemas de conteúdo ou aproveite outros serviços do sistema, certifique-se de definir a identidade no Service contexto.

Para lidar com casos especiais ao atualizar a identidade da UI com [a setUIPolicyIdentity] ou [comutmamidentity,]ambos os métodos podem ser aprovados um conjunto de valores [de IdentitySwitchOption.]

• IGNORE_INTENT: Utilize se solicitar um interruptor de identidade que ignore a intenção associada à atividade atual. Por exemplo:

  1. A sua aplicação recebe uma intenção de uma identidade gerida que contém um documento gerido, e a sua aplicação exibe o documento.
  2. O utilizador muda para a sua identidade pessoal, pelo que a sua aplicação solicita um interruptor de identidade UI. Na identidade pessoal, a sua aplicação já não exibe o documento, pelo que utiliza IGNORE_INTENT quando solicita o interruptor de identidade.

• DATA_FROM_INTENT: Utilize se solicitar um interruptor de identidade quando os dados da intenção forem apresentados na atividade. O oposto de IGNORE_INTENT . Isto fará com que a nova identidade trate a intenção como dados recebidos.

  Por exemplo: A sua aplicação recebe uma intenção de conter metadados que a correlaciona com uma conta específica. A sua aplicação solicita um interruptor de identidade, mas irá apresentar dados a partir da intenção original.

Se nenhum dos dois for definido, o comportamento padrão está algures no meio para a compatibilidade histórica. O MAM irá assumir que a mais recente intenção ainda se encontra a ser utilizada na aplicação como com DATA_FROM_INTENT , no entanto, uma série de condições especiais, incluindo a intenção de ter sido enviada a partir da mesma app ou do lançador do sistema, irá contornar a verificação de dados.

Nota

Como CLIPBOARD_SERVICE é usado para operações de UI, o SDK usa a identidade uI da atividade de primeiro plano para ClipboardManager operações.

Os seguintes métodos no MAMPolicyManager podem ser utilizados para definir a identidade e recuperar os valores de identidade previamente definidos.

public static void setUIPolicyIdentity(final Context context, final String identity, final MAMSetUIIdentityCallback mamSetUIIdentityCallback,
final EnumSet<IdentitySwitchOption> options);

public static String getUIPolicyIdentity(final Context context);

public static MAMIdentitySwitchResult setProcessIdentity(final String identity);

public static String getProcessIdentity();

public static MAMIdentitySwitchResult setCurrentThreadIdentity(final String identity);

public static String getCurrentThreadIdentity();

/**
 * Get the current app policy. This does NOT take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use the overload below.
 */
public static AppPolicy getPolicy();

/**
 * Get the current app policy. This DOES take the UI (Context) identity into account.
 * If the current operation has any context (e.g. an Activity) associated with it, use this function.
 */
public static AppPolicy getPolicy(final Context context);


public static AppPolicy getPolicyForIdentity(final String identity);

public static boolean getIsIdentityManaged(final String identity);

Nota

Pode limpar a identidade da aplicação ao defini-la como nula.

A cadeia vazia pode ser utilizada como uma identidade que nunca terá uma política de proteção de aplicações.

Resultados

Todos os métodos utilizados para definir os valores de resultados do relatório de identidade através do MAMIdentitySwitchResult. Existem quatro valores que podem ser devolvidos:

Valor devolvido	Scenario
SUCCEEDED	A alteração de identidade foi concluída com êxito.
NOT_ALLOWED	A alteração de identidade não é permitida. Isto ocorre se for feita uma tentativa de definir a identidade UI Context () quando uma identidade diferente é definida no fio atual.
CANCELLED	O utilizador cancelou a alteração de identidade, geralmente ao premir o botão Anterior num pedido de PIN ou autenticação.
FAILED	A alteração de identidade falhou por um motivo não especificado.

A aplicação deve garantir que um interruptor de identidade seja bem sucedido antes de exibir ou usar dados corporativos. Atualmente, as alterações de identidade de processos e threads serão sempre concluídas com êxito numa aplicação com várias identidades. No entanto, reservamos o direito de adicionar condições de falha. A alteração de identidade da IU poderá falhar no caso de argumentos inválidos, se a mesma entrar em conflito com a identidade do thread ou se o utilizador cancelar os requisitos de início condicional (por exemplo, o utilizador prime o botão Anterior no ecrã de PIN). O comportamento padrão para um interruptor de identidade de UI falhado numa atividade é terminar a atividade (ver onSwitchMAMIdentityComplete abaixo).

No caso de definir uma Context identidade através da [setUIPolicyIdentity,]o resultado é reportado de forma assíncronea. Se Context for um Activity , o SDK não sabe se a mudança de identidade foi bem sucedida até que o lançamento condicional seja realizado -- o que pode exigir que o utilizador introduza um PIN ou credenciais corporativas. A aplicação pode implementar um MAMSetUIIdentityCallback para receber este resultado, ou pode passar nulo para o objeto de retorno. Note que se uma chamada for feita setUIPolicyIdentity enquanto o resultado de uma chamada anterior para setUIPolicyIdentity o mesmo contexto ainda não tiver sido entregue, a nova chamada substituirá a antiga e a chamada original nunca receberá um resultado.

Também pode definir a identidade de uma atividade diretamente através de um método em MAMActivity em vez de ligar MAMPolicyManager.setUIPolicyIdentity . Utilize o método seguinte para tal:

     public final void switchMAMIdentity(final String newIdentity, final EnumSet<IdentitySwitchOption> options);

Poderá também substituir um método no MAMActivity se pretender que a aplicação seja notificada do resultado de tentativas para alterar a identidade dessa atividade.

    public void onSwitchMAMIdentityComplete(final MAMIdentitySwitchResult result);

Se não se sobrepor onSwitchMAMIdentityComplete (ou chamar o super método), um interruptor de identidade falhado numa atividade resultará no fim da atividade. Se anular o método, deve ter cuidado para que os dados corporativos não apresentem depois de um interruptor de identidade falhado.

Nota

Alterar a identidade pode requerer a recriação da atividade. Neste caso, a chamada de retorno onSwitchMAMIdentityComplete será entregue na nova instância da atividade.

Alterações de Identidade Implícitas

Além da capacidade da aplicação de definir a identidade, a identidade de um contexto ou thread poderá mudar com base na entrada de dados de outra aplicação gerida pelo Intune com uma política de proteção de aplicações.

Exemplos

1. Se uma atividade for lançada a partir de uma Intent outra aplicação MAM, a identidade da atividade será definida com base na identidade efetiva na outra app no momento em que Intent foi enviada.

2. Para serviços, a identidade do thread será definida de forma semelhante durante uma chamada onStart ou onBind. As chamadas para Binder devolvidas do onBind também irão definir temporariamente a identidade do thread.

3. De forma semelhante, as chamadas para um ContentProvider irão definir a identidade do thread na duração das mesmas.

Além disso, interação do utilizador com uma atividade poderá causar uma mudança de identidade implícita.

Exemplo: um utilizador que desista de um pedido de autorização durante Resume resultará numa mudança implícita para uma identidade vazia.

Esta aplicação tem uma oportunidade de ter conhecimento destas alterações e, se necessário, a aplicação pode proibi-las. MAMService e MAMContentProvider expõem o seguinte método que as subclasses podem sobrepor::

public void onMAMIdentitySwitchRequired(final String identity,
        final AppIdentitySwitchResultCallback callback);

Na classe MAMActivity, um parâmetro adicional está presente no método:

public void onMAMIdentitySwitchRequired(final String identity,
        final AppIdentitySwitchReason reason,
        final AppIdentitySwitchResultCallback callback);

• A AppIdentitySwitchReason captura a origem do interruptor implícito e pode aceitar os valores CREATE , e RESUME_CANCELLED NEW_INTENT . O motivo RESUME_CANCELLED é utilizado quando a retoma da atividade gera a apresentação de PIN, autenticação ou outra IU de conformidade e o utilizador tenta desistir dessa IU, normalmente através do botão de retrocesso.

  • O AppIdentitySwitchResultCallback é o seguinte:

    public interface AppIdentitySwitchResultCallback {
        /**
          * @param result
          *            whether the identity switch can proceed.
          */
        void reportIdentitySwitchResult(AppIdentitySwitchResult result);
      }
    

    Onde [AppIdentitySwitchResult] é ou SUCCESS FAILURE .

O método onMAMIdentitySwitchRequired é chamado para todas as alterações de identidade implícitas, exceto nas que forem efetuadas através de um Enlaçamento devolvido de MAMService.onMAMBind. As implementações predefinidas de onMAMIdentitySwitchRequired chamam de imediato:

• callback.reportIdentitySwitchResult(FAILURE) quando a razão é RESUME_CANCELLED .

• callback.reportIdentitySwitchResult(SUCCESS) em todos os outros casos.

  Não é esperado que a maioria das aplicações precise de bloquear ou atrasar uma mudança de identidade numa forma diferente, mas se uma aplicação precisar de o fazer, os seguintes pontos têm de ser tidos em conta:

  • Se a alteração de identidade é bloqueada, o resultado é o mesmo como se as definições de partilha de Receive tivessem proibido a entrada de dados.

  • Se um Serviço estiver a funcionar no fio principal, reportIdentitySwitchResult deve ser chamado de sincronização ou o fio de UI deixa de responder.

  • Para Activity a criação, [o onMAMIdentitySwitchRequired] será chamado antes onMAMCreate . Se a aplicação tiver de mostrar uI para determinar se permite o interruptor de identidade, essa UI deve ser mostrada usando uma atividade diferente.

  • Num Activity , quando é solicitada uma mudança para a identidade vazia com a razão em que RESUME_CANCELLED , a aplicação deve modificar a atividade retomada para exibir dados consistentes com esse interruptor de identidade. Se tal não for possível, a aplicação deverá recusar a mudança e será novamente pedido ao utilizador que fique em conformidade com a política da identidade retomada (por exemplo, ao ver o ecrã de introdução de PIN da aplicação).

    Nota

    Uma aplicação com várias identidades irá sempre receber dados de aplicações geridas e não geridas. É da responsabilidade da aplicação tratar dados de identidades geridas de forma gerida.

  Se uma identidade solicitada for gerida (use MAMPolicyManager.getIsIdentityManaged to check), mas a aplicação não pode usar essa conta (por exemplo, porque as contas, como contas de e-mail, devem ser configuradas na app primeiro) então o interruptor de identidade deve ser recusado.

Considerações sobre o plug-in/ferramenta de compilação

Se não herdar explicitamente da [MAMActivity,] MAMServiceou MAMContentProvider (porque permite que a ferramenta de construção faça essa alteração), mas ainda assim precisar de processar comutadores de identidade, poderá, em vez disso, implementar [o MAMActivityIdentityRequirementListener] para Activity um ou MAMIdentityRequirementListener para um Service ou ContentProviders . O comportamento predefinido para MAMActivity.onMAMIdentitySwitchRequired pode ser acedido ao chamar o método estático MAMActivity.defaultOnMAMIdentitySwitchRequired(activity, identity, reason, callback).

Da mesma forma, se necessitar de substituir MAMActivity.onSwitchMAMIdentityComplete, poderá implementar MAMActivityIdentitySwitchListener sem herdar explicitamente de MAMActivity.

Preservar a Identidade em Operações Assíncronas

É comum as operações na thread de IU distribuírem tarefas em segundo plano para outra thread. Uma aplicação com várias identidades quererá confirmar que estas tarefas em segundo plano operam com a identidade adequada. Muitas vezes, essa é a mesma identidade que foi utilizada pela atividade que as distribuiu. O MAM SDK fornece [os executivos da MAMAsyncTask] e [da MAMIdentity] Como uma conveniência para ajudar na preservação da identidade. Estes devem ser utilizados se a operação assíncronia puder escrever dados corporativos para um ficheiro ou se puder comunicar com outras apps.

MAMAsyncTask

Para MAMAsyncTask utilizar, simplesmente herdar dele em vez de AsyncTask e substituir sobreposições de doInBackground e onPreExecute com doInBackgroundMAM e, onPreExecuteMAM respectivamente. O construtor MAMAsyncTask adquire um contexto de atividade. Por exemplo:

AsyncTask<Object, Object, Object> task = new MAMAsyncTask<Object, Object, Object>(thisActivity) {

    @Override
    protected Object doInBackgroundMAM(final Object[] params) {
        // Do operations.
    }

    @Override
    protected void onPreExecuteMAM() {
        // Do setup.
    };
}

MAMIdentityExecutors

O MAMIdentityExecutors permite-lhe encapsular uma instância existente do Executor ou do ExecutorService como um Executor/ExecutorService que preserva a identidade com métodos wrapExecutor e wrapExecutorService. Por exemplo

Executor wrappedExecutor = MAMIdentityExecutors.wrapExecutor(originalExecutor, activity);
ExecutorService wrappedService = MAMIdentityExecutors.wrapExecutorService(originalExecutorService, activity);

Proteção de Ficheiros

Todos os ficheiros têm uma identidade associada na altura da criação, com base na identidade de processo e thread. Esta identidade será utilizada para encriptação de ficheiros e eliminação seletiva. Apenas os ficheiros cuja identidade é gerida e tenha uma política que requeira encriptação serão encriptados. A funcionalidade de eliminação seletiva predefinida do SDK irá eliminar apenas ficheiros associados à identidade gerida para a qual uma eliminação tenha sido solicitada. A aplicação pode consultar ou alterar a identidade de um ficheiro utilizando a classe [MAMFileProtectionManager.]

Responsabilidade da Aplicação

O MAM não pode inferir automaticamente uma relação entre os ficheiros que estão a ser lidos e os dados exibidos num Activity . Apps must set the UI identity appropriately before displaying corporate data. This includes data read from files. If a file comes from outside the app (either from a ContentProvider or read from a publicly writable location), the app must attempt to determine the file identity (using the correct MAMFileProtectionManager.getProtectionInfo overload for the data source) before displaying information read from the file. If getProtectionInfo reports a non-null, non-empty identity, the UI identity must be set to match this identity (using [MAMActivity.switchMAMIdentity][switchMAMIdentity] or MAMPolicyManager.setUIPolicyIdentity ). Se a alteração de identidade falhar, os dados do ficheiro não podem ser apresentados.

Um fluxo de exemplo deverá ser semelhante ao seguinte:

• O utilizador seleciona um documento para abrir na aplicação.

• Durante o fluxo aberto, antes de ler dados do disco, a aplicação confirma a identidade que deve ser usada para exibir o conteúdo:

  MAMFileProtectionInfo info = MAMFileProtectionManager.getProtectionInfo(docPath)
  if (info != null)
      MAMPolicyManager.setUIPolicyIdentity(activity, info.getIdentity(), callback, EnumSet.noneOf<IdentitySwitchOption.class>)
  

• A aplicação aguarda até que um resultado seja reportado para o retorno.

• Se o resultado comunicado for uma falha, a aplicação não apresentará o documento.

• A aplicação abre e torna o ficheiro.

Se uma aplicação utilizar o Android DownloadManager para descarregar ficheiros, o MAM SDK tentará proteger esses ficheiros automaticamente utilizando a identidade do processo. Se os ficheiros descarregados contiverem dados corporativos, é da responsabilidade da app chamar proteger se os ficheiros forem movidos ou recriados após o download.

Single-Identity à transição multi-identidade

Se uma aplicação que previamente foi lançada com uma integração intune de identidade única mais tarde integrar multi-identidade, aplicações previamente will experience a transition (not visible to the user, there is no associated UX). The app is not required to do anything explicit to handle this transition. All files created before the transition will continue being regarded as managed (so they will stay encrypted if encryption policy is on). If desired, you can detect the upgrade and use [MAMFileProtectionManager.protect][protect] instaladas para marcar ficheiros ou diretórios específicos com a identidade vazia (que removerá a encriptação se forem encriptadas).

Cenários Offline

A etiquetagem de identidade de ficheiros é sensível ao modo offline. Os seguintes pontos deverão ser levados em consideração:

• Se o Portal da Empresa não estiver instalado, a etiquetagem de identidade dos ficheiros não poderá ser efetuada.

• Se o Portal da Empresa estiver instalado, mas a aplicação não estiver a política da MAM do Intune instalada, os ficheiros não poderão ter uma etiquetagem de identidade de forma fiável.

• Quando a etiquetagem de identidade for disponibilizada, todos os ficheiros anteriormente criados serão tratados como pessoais/não geridos (pertencentes à identidade de cadeia vazia), a menos que a aplicação tenha sido anteriormente instalada como aplicação gerida com identidade única. Nesse caso, serão tratados como pertencentes ao utilizador inscrito.

Proteção de Diretório

Os diretórios podem ser protegidos utilizando o mesmo método [de proteção] utilizado para proteger ficheiros. A proteção do diretório é aplicada recursivamente a todos os ficheiros e subdiretórios contidos no diretório e a novos ficheiros criados no diretório. Como a proteção de diretório é aplicada recursivamente, a chamada protect pode demorar algum tempo a concluir no caso de diretórios grandes. Por esse motivo, as aplicações a aplicar proteção num diretório que contém um grande número de ficheiros poderão querer executar a função protect de modo assíncrono no thread de segundo plano.

Proteção de Dados

Não é possível etiquetar um ficheiro como pertencente a identidades múltiplas. As aplicações que devem armazenar dados pertencentes a diferentes utilizadores no mesmo ficheiro podem fazê-lo manualmente, utilizando as funcionalidades fornecidas pelo MAMDataProtectionManager. Isto permite à aplicação encriptar dados e associá-los a um utilizador específico. Os dados encriptados são adequados para armazenamento no disco de um ficheiro. Pode consultar os dados associados à identidade e os dados podem ser desencriptados posteriormente.

As aplicações que utilizam [o MAMDataProtectionManager] devem implementar um recetor para a MANAGEMENT_REMOVED notificação. Após a conclusão desta notificação, as memórias intermédias que estavam protegidas através desta classe deixarão de ser legíveis caso a encriptação de ficheiros tenha sido ativada quando as memórias intermédias foram protegidas. Uma aplicação pode remediar esta situação chamando MAMDataProtectionManager.unprotect todos os buffers durante esta notificação. Também é seguro chamar a função proteger durante esta notificação se quiser manter as informações de identidade – a encriptação desativada é garantida durante a notificação.

Fornecedores de Conteúdo

Se a aplicação fornecer dados corporativos que não a ParcelFileDescriptor através de um , a ContentProvider aplicação deve ligar para o método isProvideContentAllowed(String) no MAMContentProvider, passando a UPN (nome principal do utilizador) do proprietário para o conteúdo. Se esta função devolver "falso", os conteúdos não podem ser devolvidos ao chamador. Os descritores de ficheiros devolvidos através de um fornecedor de conteúdos são processados automaticamente, com base na identidade do ficheiro.

Se não herdar MAMContentProvider explicitamente e, em vez disso, permitir que a ferramenta de construção faça essa alteração, poderá chamar uma versão estática do mesmo método: MAMContentProvider.isProvideContentAllowed(provider, contentIdentity) .

eliminação seletiva

Se uma aplicação multi-identidade se registar para o WIPE_USER_DATA notification, it is the app's responsibility to remove all data for the user being wiped, including all files that have been identity-tagged as belonging to that user. If the app removes user data from a file but wishes to leave other data in the file, it must change the identity of the file (via [MAMFileProtectionManager.protect][protect] a um utilizador pessoal ou à identidade vazia). Se estiver a ser utilizada uma política de encriptação, os ficheiros restantes pertencentes ao utilizador que está a ser eliminado não serão desencriptados e ficarão inacessíveis para a aplicação após a eliminação.

Se uma aplicação se registar para WIPE_USER_DATA, não terá o benefício do comportamento predefinido de eliminação seletiva por parte do SDK. Para aplicações com conhecimento de várias identidades, esta perda pode ser mais significativa, dado que a eliminação seletiva predefinida da MAM elimina apenas os ficheiros cuja identidade é visada para eliminação. Se uma aplicação de conhecimento multi-identidade desejar que a limpeza seletiva padrão do MAM seja feita e deseja executar as suas próprias ações em limpeza, deverá registar-se para WIPE_USER_AUXILIARY_DATA notificações. Esta notificação será enviada imediatamente pelo SDK antes de executar a eliminação seletiva predefinida do SDK. Uma aplicação nunca deve registar-se para ambos WIPE_USER_DATA e WIPE_USER_AUXILIARY_DATA .

A limpeza seletiva padrão fechará a app graciosamente, terminando as atividades e matando o processo da aplicação. Se a sua aplicação sobrepor a limpeza seletiva predefinida, pode considerar fechar a sua aplicação manualmente para evitar que o utilizador aceda a dados na memória após a ocorrência de uma limpeza.

Ativar a configuração de MAM direcionada para aplicações Android (opcional)

Os pares de valores-chave específicos da aplicação podem ser configurados na consola Intune para MAM-WE e Android Enterprise. Estes pares chave-valor não são interpretados pelo Intune, mas são enviados para a aplicação. As aplicações que pretendam receber tal configuração podem utilizar as classes MAMAppConfigManager e MAMAppConfig para o fazer. Se houver múltiplas políticas direcionadas para a mesma aplicação, poderão existir múltiplos valores em conflito disponíveis para a mesma chave.

Nota

As configurações de configuração para entrega via MAM-WE não podem ser entregues offline (quando a Portal da Empresa não estiver instalada). Apenas aplicações android Enterprise As aplicações serão entregues através de uma MAMUserNotification identidade vazia neste caso.

Obtenha a App Config Para um Utilizador

App config pode ser recuperado da seguinte forma:

MAMAppConfigManager configManager = MAMComponents.get(MAMAppConfigManager.class);
String identity = "user@contoso.com"
MAMAppConfig appConfig = configManager.getAppConfig(identity);

Se não houver um utilizador registado no MAM, mas a sua aplicação ainda gostaria de recuperar a configuração do Android Enterprise (que não será direcionada a um utilizador específico), pode passar uma cadeia nula ou vazia.

Conflitos

Um valor definido na app config da aplicação MAM irá sobrepor-se a um valor com a mesma chave definida no Android Enterprise config.

Se um administrador configurar valores contraditórios para a mesma tecla (por exemplo, direcionando diferentes conjuntos de configuração de aplicações com a mesma chave para vários grupos que contenham o mesmo utilizador), o Intune não tem qualquer forma de resolver este conflito automaticamente e disponibilizará todos os valores à sua aplicação.

A sua aplicação pode solicitar todos os valores para uma determinada chave a partir de um objeto [MAMAppConfig:]

List<Boolean> getAllBooleansForKey(String key)
List<Long> getAllIntegersForKey(final String key)
List<Double> getAllDoublesForKey(final String key)
List<String> getAllStringsForKey(final String key)

ou solicitar um valor a ser escolhido:

Boolean getBooleanForKey(String key, BooleanQueryType queryType)
Long getIntegerForKey(String key, NumberQueryType queryType)
Double getDoubleForKey(String key, NumberQueryType queryType)
String getStringForKey(String key, StringQueryType queryType)

A sua aplicação também pode solicitar os dados brutos como uma lista de conjuntos de pares de valores-chave.

List<Map<String, String>> getFullData()

Exemplo completo

MAMAppConfigManager configManager = MAMComponents.get(MAMAppConfigManager.class);
String identity = "user@contoso.com"
MAMAppConfig appConfig = configManager.getAppConfig(identity);
String fooValue = null;
if (appConfig.hasConflict("foo")) {
    List<String> values = appConfig.getAllStringsForKey("foo");
    fooValue = chooseBestValue(values);
} else {
    valueToUse = appConfig.getStringForKey("foo", MAMAppConfig.StringQueryType.Any);
}
Long barValue = appConfig.getIntegerForKey("bar", MAMAppConfig.NumberQueryType.Min);

Notificação

A configuração da aplicação adiciona um novo tipo de notificação:

• REFRESH_APP_CONFIG: Esta notificação é enviada num [MAMUserNotification] e informa a aplicação de que estão disponíveis novos dados de config da app.

Ler Mais

Para obter mais informações sobre como criar uma política de configuração de aplicações de MAM direcionada no Android, veja a secção na configuração de aplicação de MAM direcionada em Como utilizar as políticas de configuração de aplicações do Microsoft Intune para Android.

A app config também pode ser configurada usando a API Graph. Para obter informações, consulte os Graph os docs da API para mam targeted Config.

Temas personalizados (opcional)

Um tema personalizado pode ser fornecido ao MAM SDK que será aplicado a todos os ecrãs e diálogos MAM. Se um tema não for fornecido, será utilizado um tema MAM predefinido.

Como fornecer um tema

Para fornecer um tema, é necessário adicionar a seguinte linha de código no Application.onCreate método:

MAMThemeManager.setAppTheme(R.style.AppTheme);

No exemplo acima, é necessário substituir R.style.AppTheme pelo tema de estilo que pretende que o SDK se aplique.

Personalização de estilo (depreciada)

Este é agora precotado e Temas Personalizados (acima) é a forma preferida de personalizar vistas.

As vistas geradas pelo SDK da MAM podem ser personalizadas visualmente para ficarem mais parecidos com a aplicação na qual este está integrado. Pode personalizar as cores primárias, secundárias e de fundo, assim como o tamanho do logótipo da aplicação. Esta personalização do estilo é opcional e serão utilizadas as predefinições caso não seja configurado qualquer estilo personalizado.

Como personalizar

Para aplicar alterações de estilo às vistas da MAM do Intune, deve primeiro criar um ficheiro XML de substituição do estilo. Este ficheiro deve ser colocado no diretório "/res/xml" da sua aplicação e pode nomeá-lo como quiser. Abaixo pode ver um exemplo de formato que este ficheiro tem de seguir.

<?xml version="1.0" encoding="utf-8"?>
<styleOverrides>
    <item
        name="foreground_color"
        resource="@color/red"/>
    <item
        name="accent_color"
        resource="@color/blue"/>
    <item
        name="background_color"
        resource="@color/green"/>
    <item
        name="logo_image"
        resource="@drawable/app_logo"/>
</styleOverrides>

Tem de reutilizar os recursos já existentes na sua aplicação. Por exemplo, tem de definir a cor verde no ficheiro colors.xml e mencioná-la aqui. Não pode usar o código de cor Hex "#0000ff". O tamanho máximo do logótipo da aplicação é de 110 dip (dp). Pode utilizar uma imagem do logótipo mais pequena, mas ao manter o tamanho máximo obterá os melhores resultados. Se exceder o limite de 110 dip, a qualidade da imagem será reduzida e, possivelmente, ficará esbatida.

Abaixo pode ver uma lista completa de atributos de estilo permitidos, os elementos de IU que estes controlam, os seus nomes de item do atributo XML e o tipo de recursos esperados de cada um.

Atributo do estilo	Elementos da IU afetados	Nome do item do atributo	Tipo de recurso esperado
Cor de fundo	Cor de fundo do ecrã de PIN Cor de preenchimento da caixa do PIN	background_color	Cor
Cor de primeiro plano	Cor do texto de primeiro plano Limite da caixa do PIN no estado predefinido Carateres (incluindo carateres oculto) na caixa do PIN quando o utilizador introduz um PIN	foreground_color	Cor
Cor de destaque	Limite da caixa do PIN quando realçado Hiperligações	accent_color	Cor
Logótipo da aplicação	Ícone grande que aparece no ecrã de PIN da aplicação Intune	logo_image	Desenhável

Inscrição predefinida (opcional)

Seguem-se orientações para exigir pedidos de início de sessão ao utilizador ao iniciar aplicações para uma inscrição automática no serviço APP-WE (isto é denominado inscrição predefinida nesta secção), exigir políticas de proteção de aplicações do Intune para permitir que apenas os utilizadores protegidos pelo Intune utilizem a sua aplicação LOB para Android integrada com SDK. Também abrangem a ativação do SSO para a sua aplicação LOB para Android integrada com SDK. Tal não é suportado pelas aplicações da loja que podem ser utilizadas por utilizadores sem Intune.

Nota

As vantagens da inscrição predefinida incluem um método simplificado de obtenção de políticas do serviço APP-WE para uma aplicação no dispositivo.

Nota

A inscrição predefinida é uma nuvem soberana consciente.

Permitir a inscrição predefinida com os seguintes passos:

1. Se a sua aplicação integrar o MSAL ou precisar de ativar o SSO, configure a MSAL seguindo as configurações comuns do MSAL #2. Caso contrário, pode saltar este passo.

2. Permitir a inscrição predefinida adicionando o seguinte valor no manifesto sob a <application> etiqueta:

   <meta-data android:name="com.microsoft.intune.mam.DefaultMAMServiceEnrollment" android:value="true" />
   

   Nota

   Esta tem de ser a única integração da MAM-WE na aplicação. Irão surgir conflitos se existirem outras tentativas de chamar as APIs MAMEnrollmentManager.

3. Ativar a política de MAM exigida adicionando o seguinte valor no manifesto sob a <application> etiqueta:

   <meta-data android:name="com.microsoft.intune.mam.MAMPolicyRequired" android:value="true" />
   

   Nota

   Esta ação força o utilizador a transferir o Portal da Empresa para o dispositivo e a concluir o fluxo da inscrição predefinida antes da utilização.

Limitações

Limitações de imposição de políticas

• Utilizar Resoluções de Conteúdos: a política do Intune de “transferência ou receção” pode bloquear ou bloquear parcialmente a utilização de uma resolução de conteúdos para aceder ao fornecedor de conteúdos noutra aplicação. Isto fará com que ContentResolver os métodos devolvam nulos ou atirem um valor de avaria (por exemplo, openOutputStream atirarão FileNotFoundException se estiverem bloqueados). A aplicação pode determinar se uma falha ao escrever dados através de uma resolução de conteúdos foi causada pela política (ou seria causada pela política) ao efetuar a chamada:

  MAMPolicyManager.getPolicy(currentActivity).getIsSaveToLocationAllowed(contentURI);
  

  ou se não houver atividade associada:

  MAMPolicyManager.getPolicy().getIsSaveToLocationAllowed(contentURI);
  

  No segundo caso, as aplicações com várias identidades devem definir corretamente a identidade do thread (ou passar uma identidade explícita para a chamada getPolicy).

Serviços exportados

O ficheiro AndroidManifest.xml incluído no SDK da Aplicação Intune contém MAMNotificationReceiverService, que tem de ser um serviço exportado para permitir ao Portal da Empresa enviar notificações para uma aplicação gerida. O serviço verifica o autor da chamada para assegurar que apenas o Portal da Empresa está autorizado a enviar notificações.

Limitações da reflexão

Algumas das classes base MAM (por MAMActivity exemplo, MAMDocumentsProvider ) contêm métodos (baseados nas classes base originais do Android) que utilizam parâmetros ou tipos de devolução apenas presentes acima de determinados níveis de API. Por este motivo, poderá nem sempre ser possível utilizar reflexões para enumerar todos os métodos de componentes de aplicações. Esta restrição não está limitada a MAM. É a mesma restrição que seria aplicada caso a própria aplicação implementasse estes métodos a partir de classes base de Android.

Robolectric

Não é suportado testar o comportamento do SDK de MAM no Robolectric. Existem problemas conhecidos que executam o MAM SDK sob robolétrico devido a comportamentos presentes sob Robolectric que não imitam com precisão aqueles em dispositivos reais ou emuladores.

Se precisar de testar a sua aplicação sob robolétrica, a solução recomendada é mover a lógica da classe de aplicação para um ajudante e produzir a sua apk de teste unitário com uma classe de aplicação que não herda do MAMApplication.

Expectativas do consumidor do SDK

O SDK do Intune mantém o contrato fornecido pela API Android, embora possam ser acionadas condições de falha mais frequentemente como resultado da imposição de políticas. Estas melhores práticas para Android reduzirão a probabilidade de falhas:

• As funções do SDK Android que podem devolver valores nulos têm uma maior probabilidade de ter um valor nulo agora. Para minimizar os problemas, certifique-se de que as verificações de valores nulos estão nos locais corretos.

• As funcionalidades que podem ser verificadas têm de o ser através das respetivas APIs de substituição da MAM.

• As funções derivadas têm de fazer chamadas através das respetivas versões de superclasses.

• Evitar utilizar qualquer API de uma forma ambígua. Por exemplo, utilizar Activity.startActivityForResult sem verificar o requestCode causará um comportamento estranho.

Serviços

A aplicação das políticas pode afetar as interações de serviço. Métodos que estabeleçam uma ligação de serviço vinculada, tais como Context.bindService podem falhar devido à aplicação da política subjacente e podem resultar em ou Service.onBind ServiceConnection.onNullBinding ServiceConnection.onServiceDisconnected . A interação com um serviço vinculado estabelecido pode ser SecurityException devida à aplicação da lei em Binder.onTransact .

Telemetria

O SDK da Aplicação Intune para Android não controla a coleção de dados da sua aplicação. A aplicação Portal da Empresa regista dados gerados pelo sistema por padrão. Estes dados são enviados para o Microsoft Intune. De acordo com a Microsoft Policy, não recolhemos quaisquer dados pessoais.

Nota

Se os utilizadores finais não enviarem estes dados, têm de desativar a telemetria em Definições na aplicação Portal da Empresa. Para saber mais, veja Desativar a recolha de dados da Microsoft.

Melhores práticas recomendadas para Android

• Todos os projetos de biblioteca devem partilhar o mesmo android:package sempre que possível. Assim, não falhará esporadicamente no tempo de execução, uma vez que se trata puramente de um problema de tempo de compilação. As versões mais recentes do SDK da Aplicação do Intune irão remover algumas das redundâncias.

• Utilizar as ferramentas de compilação do SDK Android.

• Remover todas as bibliotecas desnecessárias e não utilizadas (por exemplo, android.support.v4)

Testar

Consulte o Guia de Testes.