La fonctionnalité des rôles d'application permet à un administrateur informatique d'accorder des droits spéciaux à une application gérée sur un appareil Android. En attribuant un rôle spécifique, une application peut être exemptée des restrictions d'alimentation et d'arrière-plan, de la suspension et de l'hibernation (sur Android 14 et versions ultérieures), et les commandes utilisateur (c'est-à-dire les actions utilisateur telles que l'arrêt forcé et l'effacement des données de l'application) peuvent être désactivées (sur Android 11 et versions ultérieures), ce qui lui permet d'effectuer sa fonction critique sans interruption. De plus, l'application peut être informée des rôles qui lui sont attribués, ce qui lui permet de s'amorcer sans intervention de l'utilisateur.
Prérequis
L'appareil est géré par un EMM basé sur AMAPI (les EMM utilisant un DPC personnalisé ne sont pas acceptés).
Préparer votre application à utiliser la fonctionnalité
L'intégration au SDK AMAPI n'est requise que si l'application souhaite être avertie de ses rôles attribués, ce qui lui permet de s'amorcer (c'est-à-dire de se lancer automatiquement sans interaction de l'utilisateur).
Intégrer le SDK AMAPI dans votre application
Pour en savoir plus sur le SDK AMAPI et sur la façon de l'ajouter à votre application, consultez le guide d'intégration du SDK AMAPI.
Ajouter les métadonnées requises au fichier manifeste de l'application
Android Device Policy (ADP) doit connaître le ComponentName
de votre classe qui implémente NotificationReceiverService
pour informer votre application de ses rôles attribués. Vous devez taguer votre service dans AndroidManifest.xml
de manière appropriée afin qu'il puisse être découvert automatiquement par ADP.
- Votre application doit comporter un seul service
enabled
avecmeta-data
etandroid:name
égal àcom.google.android.managementapi.notification.NotificationReceiverService.SERVICE_APP_ROLES
. - Ce service doit avoir la valeur
true
pourandroid:exported
. - Le
android:value
demeta-data
doit être défini sur une chaîne vide.
<service
android:name=".MyNotificationReceiverService"
android:exported="true">
<meta-data android:name="com.google.android.managementapi.notification.NotificationReceiverService.SERVICE_APP_ROLES" android:value="" />
</service>
Si vous testez le rôle COMPANION_APP
, vous devez également ajouter le meta-data
suivant à votre service afin qu'Android Device Policy puisse envoyer des mises à jour de l'état des commandes locales à votre application :
<meta-data android:name="com.google.android.managementapi.notification.NotificationReceiverService.SERVICE_COMMAND_STATUS" android:value="" />
Créez un service étendant NotificationReceiverService (ou mettez à jour celui existant).
Créez ou mettez à jour votre NotificationReceiverService
existant et implémentez un AppRolesListener
pour écouter les rôles attribués à votre application. Seul getAppRolesListener()
est requis pour écouter les rôles attribués à votre application. Si le rôle COMPANION_APP
est attribué à votre application, vous devez également implémenter getCommandListener()
:
import android.util.Log
import com.google.android.managementapi.approles.AppRolesListener
import com.google.android.managementapi.approles.model.AppRolesSetRequest
import com.google.android.managementapi.approles.model.AppRolesSetResponse
import com.google.android.managementapi.commands.CommandListener
import com.google.android.managementapi.commands.model.Command
import com.google.android.managementapi.notification.NotificationReceiverService
class MyNotificationReceiverService : NotificationReceiverService() {
// If your app wants to listen for roles assigned
override fun getAppRolesListener(): AppRolesListener =
object : AppRolesListener {
override fun onAppRolesSet(request: AppRolesSetRequest): AppRolesSetResponse {
val roleTypes = request.roles.map { role -> role.roleType }
Log.i(TAG, "onAppRolesSet: $roleTypes")
return AppRolesSetResponse.getDefaultInstance()
}
}
// If your app wants to listen for local command status updates
// Only relevant for COMPANION_APP role
override fun getCommandListener(): CommandListener {
return object : CommandListener {
override fun onCommandStatusChanged(command: Command) {
Log.i(TAG, "onCommandStatusChanged")
}
}
}
private companion object {
const val TAG = "MyNotificationReceiverService"
}
}
Votre application peut recevoir plusieurs notifications si ses rôles changent plusieurs fois. Si tous les rôles sont supprimés, votre application recevra toujours une notification avec une liste de rôles vide. Cette notification sortira votre application de l'état arrêté. Grâce aux exemptions accordées à votre application, celle-ci pourra s'amorcer sans aucune interaction de l'utilisateur. Grâce aux notifications et aux exemptions de rôles d'application, votre application peut écouter les diffusions ACTION_BOOT_COMPLETED
. Si votre application dépend de ses configurations gérées pour s'amorcer, consultez Configurer des configurations gérées pour savoir comment lire et écouter les modifications.
Provisionner l'appareil avec des règles de rôles d'application
Les développeurs d'applications peuvent tester l'attribution de rôles d'application à leur application à l'aide d'un EMM ou en suivant le guide de démarrage rapide de l'API Android Management. Le notebook Colab AMAPI vous permet d'enregistrer une entreprise, de créer un règlement et de provisionner un appareil.
Définir le règlement pour votre application avec des rôles d'application
Configurez un policy
avec les rôles d'application que votre application est censée avoir à l'aide de ApplicationPolicy.roles
.
L'exemple suivant montre comment configurer le rôle pour les applications MTD :
{
"applications": [
{
"packageName": "com.example.mtd",
"installType": "FORCE_INSTALLED",
"roles": [
{ "roleType": "MOBILE_THREAT_DEFENSE_ENDPOINT_DETECTION_RESPONSE" }
]
}
]
}
Avant d'attribuer les rôles spécifiés dans le règlement, le système vérifiera que l'empreinte numérique du certificat de la clé de signature de l'application sur l'appareil correspond à celle du Play Store.
Si l'empreinte digitale est différente, les rôles ne seront pas attribués à l'application et la non-conformité NonComplianceReason.APP_SIGNING_CERT_MISMATCH
sera signalée à l'EMM.
{
"applications": [
{
"packageName": "com.example.mtd",
"installType": "FORCE_INSTALLED",
"signingKeyCerts": [
{ "signingKeyCertFingerprintSha256": "base64-encoded-sha256" }
],
"roles": [
{ "roleType": "MOBILE_THREAT_DEFENSE_ENDPOINT_DETECTION_RESPONSE" }
]
}
]
}
Si votre application dispose d'une configuration gérée, l'administrateur informatique peut configurer une configuration initiale pour les restriction
concernés dans la règle d'application :
{
"applications": [
{
"packageName": "com.example.mtd",
"installType": "FORCE_INSTALLED",
"roles": [
{ "roleType": "MOBILE_THREAT_DEFENSE_ENDPOINT_DETECTION_RESPONSE" }
],
"managedConfiguration": {
"<key>": "<value>"
}
}
]
}