Gérer les rôles d'application

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 avec meta-data et android:name égal à com.google.android.managementapi.notification.NotificationReceiverService.SERVICE_APP_ROLES.
  • Ce service doit avoir la valeur true pour android:exported.
  • Le android:value de meta-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>"
      }
    }
  ]
}