Configurations gérées sur Android : configurer les applications pour les collaborateurs avant leur ouverture

Un ticket de support classique du premier jour ressemble à ceci. Un employé ouvre l'application de l'entreprise, l'application demande l'adresse d'un serveur, et personne sur le terrain ne la connaît. Quelqu'un de l'informatique saisit alors la même URL, le même nom de compte ou le même réglage sur chaque appareil, et tôt ou tard l'un d'eux se retrouve avec une faute de frappe.

Android Enterprise propose un moyen standard d'éviter cela, appelé les configurations gérées. Vous définissez les valeurs d'une application une seule fois dans votre politique MDM. Elles sont transmises à chaque appareil couvert par cette politique, et l'application les lit à son lancement. Lorsqu'un employé ouvre Chrome, le client de messagerie, une application de scanner ou votre propre application métier, elle sait déjà où se connecter et ce qui est autorisé.

Ce tutoriel aborde les deux volets de cette configuration. Vous apprendrez à trouver et à appliquer des configurations gérées pour les applications courantes dans l'éditeur de politiques de votre MDM. Vous découvrirez également ce qu'il faut demander à vos développeurs internes pour que vos propres APK prennent en charge ce même mécanisme.

Ce qu'est une configuration gérée et qui en définit les champs

Une configuration gérée est un ensemble de paramètres clé-valeur qu'une organisation déploie sur une application installée sur un appareil Android géré. La documentation d'Android Enterprise de Google décrit la chaîne ainsi :

1. Le développeur de l'application définit le schéma. Dans le fichier res/xml/app_restrictions.xml de l'application, le développeur déclare chaque paramètre que l'application acceptera : sa clé, son type (chaîne, booléen, entier, choix, sélection multiple, bundle, etc.), un titre et une valeur par défaut.
2. Google Play publie le schéma. Lorsque l'application est importée sur Google Play, Play lit ce fichier. Le Google Play d'entreprise (Managed Google Play) peut alors présenter ces champs aux consoles EMM sous forme de formulaire.
3. Votre MDM envoie les valeurs. Par l'intermédiaire de l'API Android Management, l'entrée de l'application dans la politique de l'appareil transmet les valeurs choisies.
4. L'application les lit. Sur l'appareil, l'application appelle RestrictionsManager.getApplicationRestrictions() et applique ce qu'elle trouve.

C'est donc le développeur de l'application qui décide des champs existants, et non votre MDM. Si le développeur n'a pas publié de clé « URL du serveur », aucune console ne peut préconfigurer cette URL. La console ne peut que renseigner les champs mis à disposition par le développeur.

Remarque : Les configurations gérées sont distinctes des politiques d'appareils. Une politique d'appareil contrôle Android lui-même, par exemple l'appareil photo, l'USB ou le Wi-Fi. Une configuration gérée contrôle les paramètres au sein d'une application spécifique. En règle générale, vous avez besoin des deux.

Avant de commencer

• Les appareils sont enrôlés dans votre MDM avec Android Enterprise (entièrement gérés ou avec profil professionnel).
• Les applications que vous souhaitez configurer sont approuvées dans le Google Play d'entreprise, ou sont des applications privées que vos développeurs y ont publiées.
• Vous disposez d'un appareil de test enrôlé sous une politique de test, et non sous votre politique de production.
• Vous connaissez les valeurs que vous souhaitez déployer, telles que les noms d'hôtes de serveurs, les URL autorisées et les formats de comptes.

Étape 1 : Vérifier si l'application prend en charge la configuration gérée

Avant d'entreprendre quoi que ce soit, confirmez que l'application publie un schéma. Vous pouvez vérifier cela à trois endroits :

1. L'éditeur de politiques de votre MDM. Ajoutez l'application à une politique de test et voyez si un formulaire de configuration apparaît. Si c'est le cas, le développeur a publié un schéma.
2. La documentation d'entreprise de l'éditeur. De nombreux éditeurs publient leurs clés. Par exemple, Google répertorie les politiques d'entreprise de Chrome, avec la prise en charge des plateformes pour chacune d'elles, sur chromeenterprise.google/policies.
3. Le support technique de l'éditeur. Demandez : « Votre application Android prend-elle en charge les configurations gérées d'Android Enterprise, et quelles sont les clés exposées ? »

Notez chaque clé nécessaire et son type. Les types de schéma comprennent string, bool, integer, choice, multi-select, hidden, bundle et bundle_array. Un champ bool attend true ou false, et non le texte "true", et un champ multi-select attend des valeurs issues d'une liste fixe.

Résultat attendu : Pour chaque application, vous savez si elle prend en charge la configuration gérée et quels champs vous allez définir.

Avertissement : Si une application ne possède pas de schéma, il n'existe aucune solution de contournement au sein du système de configuration gérée. Vos options consistent à demander à l'éditeur d'en ajouter un, à changer d'application ou à conserver une procédure d'installation manuelle documentée pour cette application.

Étape 2 : Ajouter l'application à la politique et ouvrir sa configuration

1. Ouvrez la politique qui couvre les appareils cibles. Utilisez d'abord votre politique de test.
2. Ajoutez l'application depuis le Google Play d'entreprise si elle ne figure pas déjà dans la politique.
3. Ouvrez le formulaire de configuration de l'application.

Dans Nomid MDM, la carte de l'application dans l'éditeur de politiques ouvre sa configuration gérée. Il s'agit des paramètres que le développeur publie via Google Play, présentés sous forme de champs à remplir. Les applications Android de Nomid lisent leurs propres paramètres de la même manière.

Résultat attendu : Vous voyez un formulaire dont les champs correspondent aux clés répertoriées à l'étape 1.

Remarque : Google Play lit le schéma dans l'application téléversée : le formulaire apparaît donc pour les applications distribuées via Google Play d'entreprise, publiques comme privées. Dans Nomid, les applications privées hébergées dans le Nomid Store affichent aussi un formulaire de configuration lorsque l'application téléversée déclare un schéma. Pour tout autre mode de distribution, vérifiez le fonctionnement de la configuration avant de vous y fier.

Étape 3 : Renseigner la configuration pour les applications courantes

Avant de remplir les valeurs, lisez les étapes 4 et 5. Déterminez quelles valeurs sont identiques pour tous les appareils de la politique et lesquelles varient selon le site ou l'appareil, pour ne pas avoir à refaire les formulaires plus tard.

Vous trouverez ci-dessous les trois cas de figure dont la plupart des flottes ont besoin. Les noms de champs varient selon les éditeurs : considérez donc ces clés comme des exemples et vérifiez-les dans le formulaire spécifique de chaque application.

3a. Navigateur : page d'accueil et listes d'URL (Chrome)

Chrome sur Android accepte un grand nombre des mêmes politiques d'entreprise que la version de bureau de Chrome, distribuées sous forme de configuration gérée. Les politiques fréquemment utilisées sur les appareils des employés comprennent :

Avant de vous appuyer sur une politique, consultez la liste des politiques Chrome Enterprise pour vérifier qu'elle est bien prise en charge sur Android. Certaines politiques de la version de bureau, notamment concernant le comportement au démarrage et la page d'accueil, se comportent différemment ou ne sont pas disponibles sur Android. Si vous avez besoin d'un écran de démarrage fixe, les favoris gérés ou un raccourci web dans un lanceur de kiosque sont souvent plus prévisibles. Si vous bloquez tout avec URLBlocklist ["*"], ajoutez aussi les pages de connexion de votre fournisseur d'identité à URLAllowlist, sinon les sites de travail qui demandent une connexion ne se chargeront pas.

3b. Client de messagerie : serveur et compte

Les applications de messagerie d'entreprise proposent couramment des champs tels que :

• Adresse e-mail ou nom d'utilisateur
• Nom d'hôte du serveur (par exemple, un hôte Exchange ActiveSync)
• Exigence SSL/TLS
• Autorisation ou non d'ajouter des comptes personnels

Les valeurs propres à chaque utilisateur, comme l'adresse e-mail, sont abordées à l'étape 5. Pour le moment, renseignez les champs identiques pour tous, tels que le serveur hôte et les options de sécurité.

3c. Applications de scan et applications métier : URL du serveur et comportement

Les utilitaires pour appareils durcis, les applications de numérisation et les applications métier proposent généralement :

• L'URL de base du backend ou de l'API, par exemple https://wms.example.com/api
• Le code du tenant, du site ou de l'entrepôt
• Des boutons d'activation de fonctionnalités, comme le mode hors ligne, la numérisation par appareil photo plutôt que par lecteur matériel, ou la désactivation des journaux de débogage

Enregistrez la politique. Vérifiez ensuite que votre appareil de test lui est affecté. Résultat attendu : Le formulaire de chaque application contient les valeurs communes de cette politique, la politique est enregistrée et l'appareil de test l'utilise.

Avertissement : Évitez d'insérer des mots de passe ou des secrets à longue durée de vie dans une configuration gérée. Les valeurs sont stockées sur l'appareil et lisibles par l'application. Privilégiez des flux où la configuration oriente l'application vers le bon serveur, après quoi l'employé ou l'application s'authentifie.

Étape 4 : Définir la configuration une seule fois par politique

La configuration gérée est rattachée à la politique, et non à un appareil individuel. Chaque appareil soumis à la politique reçoit les mêmes valeurs. Tirez-en parti :

1. Regroupez les appareils selon leurs différences. Si le magasin A et le magasin B utilisent des URL de backend différentes, ils ont besoin d'une configuration différente. Organisez vos politiques ou vos groupes de politiques autour de cette distinction.
2. Réutilisez une base de référence éprouvée. Créez une politique entièrement configurée et utilisez-la comme point de départ pour les nouveaux sites, afin de ne pas avoir à reconstruire la configuration manuellement. Dans Nomid, les modèles de politiques et les groupes de politiques répondent à ce besoin.
3. Modifiez une fois, déployez partout. Lorsque l'URL du serveur change, modifiez-la dans la politique. Les appareils récupèrent la nouvelle valeur lors de leur prochaine synchronisation de politique.

Résultat attendu : Chaque ensemble distinct de valeurs correspond à exactement une politique ou un groupe de politiques, et rien n'est configuré manuellement par appareil.

Étape 5 : Gérer les valeurs spécifiques à chaque appareil

Certaines valeurs sont différentes sur chaque appareil : l'adresse e-mail d'un utilisateur, le nom de l'appareil, un numéro d'inventaire ou un numéro de série requis par votre application pour les licences. Depuis Android 10, les applications standard ne peuvent plus lire elles-mêmes le numéro de série matériel ; le transmettre par une configuration gérée est donc une pratique courante.

Il existe deux approches générales :

• Les variables. L'API Android Management permet à une console d'associer des variables de configuration à un modèle de configuration gérée. Un modèle unique peut ensuite renvoyer des valeurs différentes sur chaque appareil. La manière dont une console présente cette option et les variables qu'elle propose varient selon les produits. Vérifiez auprès de votre éditeur quels attributs d'appareil ou d'utilisateur peuvent être insérés avant de baser votre architecture là-dessus.
• Des périmètres de politiques plus réduits. Si la valeur par appareil correspond en réalité à un site ou à une équipe, attribuez à ce groupe sa propre politique. Pour quelques appareils, cette méthode est simple. Pour des centaines, elle n'est pas viable à grande échelle, ce qui indique que vous devez recourir à des variables ou modifier l'application.

Une troisième option se situe du côté de l'application. L'application peut extraire une valeur partagée telle qu'un identifiant de locataire (tenant ID) depuis la configuration, puis récupérer les paramètres propres à l'appareil auprès de son propre backend après la connexion. Cette solution s'avère souvent plus robuste que d'injecter chaque détail par appareil via le MDM.

Résultat attendu : Vous avez déterminé, champ par champ, si la valeur est partagée (au niveau de la politique), variable (résolue par appareil) ou récupérée par l'application après la connexion.

Étape 6 : Vérifier que l'application a pris en compte la modification

1. Vérifiez que l'appareil a reçu la politique. Vérifiez son état de dernière connexion ou de synchronisation dans votre console. Dans Nomid, la liste des appareils affiche l'état de dernière connexion et de contact.
2. Vérifiez que l'application est installée. Une configuration envoyée avant la fin de l'installation s'applique dès que l'application est présente, mais celle-ci doit réellement être installée. Consultez la liste des applications de l'appareil dans votre console ou sur l'appareil lui-même.
3. Forcez l'arrêt de l'application et rouvrez-la. Beaucoup d'applications ne lisent leur configuration qu'au démarrage. Forcez l'arrêt depuis la page de l'application dans les Paramètres. Si la politique bloque les Paramètres, comme sur un kiosque, redémarrez plutôt l'appareil, ce qui peut se faire à distance.
4. Vérifiez au sein de l'application. Le champ du serveur doit être prérempli et verrouillé, le site bloqué doit être inaccessible, etc. Une capture d'écran à distance vous permet de vérifier cela sans manipuler l'appareil.

Résultat attendu : Sur l'appareil de test, chaque application configurée affiche les valeurs envoyées sans aucune saisie. Déployez ensuite par étapes : notez les valeurs actuelles pour pouvoir revenir en arrière, reportez les valeurs testées dans la politique de production, appliquez-la d'abord à un petit groupe pilote, puis élargissez quand les appareils pilotes affichent les bonnes valeurs.

Remarque : Si l'application affiche toujours les anciennes valeurs après un arrêt forcé, consultez la FAQ de dépannage ci-dessous. La cause réside généralement dans la façon dont l'application gère la configuration, et non dans sa distribution.

Pour les applications internes : demandez à vos développeurs de publier un schéma

Si votre propre application demande encore aux employés de saisir une URL de serveur, la solution se trouve dans le code de l'application. Vous pouvez transmettre les instructions suivantes à votre équipe de développement.

1. Déclarer le schéma

Créez res/xml/app_restrictions.xml :

<?xml version="1.0" encoding="utf-8"?>
<restrictions xmlns:android="http://schemas.android.com/apk/res/android">
    <restriction
        android:key="server_url"
        android:title="@string/cfg_server_url_title"
        android:description="@string/cfg_server_url_desc"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="site_code"
        android:title="@string/cfg_site_code_title"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="allow_offline"
        android:title="@string/cfg_offline_title"
        android:restrictionType="bool"
        android:defaultValue="false" />
</restrictions>

2. Le référencer dans le manifest

<application ...>
    <meta-data
        android:name="android.content.APP_RESTRICTIONS"
        android:resource="@xml/app_restrictions" />
</application>

3. Lire les valeurs et réagir aux modifications

class MainActivity : AppCompatActivity() {
    private val configReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context, intent: Intent) = applyConfig()
    }

    override fun onResume() {
        super.onResume()
        applyConfig() // picks up changes made while the app was in the background
        registerReceiver(
            configReceiver,
            IntentFilter(Intent.ACTION_APPLICATION_RESTRICTIONS_CHANGED)
        )
    }

    override fun onPause() {
        unregisterReceiver(configReceiver)
        super.onPause()
    }

    private fun applyConfig() {
        val rm = getSystemService(Context.RESTRICTIONS_SERVICE) as RestrictionsManager
        val config = rm.applicationRestrictions
        val serverUrl = config.getString("server_url", "")
        val allowOffline = config.getBoolean("allow_offline", false)
        // Apply serverUrl and allowOffline to the app's settings here
    }
}

La diffusion ACTION_APPLICATION_RESTRICTIONS_CHANGED n'est transmise qu'aux récepteurs enregistrés au runtime (au moment de l'exécution). L'application doit également relire la configuration dans onResume() afin que les modifications effectuées lorsqu'elle était en arrière-plan soient appliquées.

4. Publier via le Google Play d'entreprise

Importez l'application sur Google Play, en tant qu'application privée pour votre organisation si elle n'est pas publique, afin que Play puisse lire le schéma et afficher le formulaire dans votre MDM. Chaque nouvelle version qui ajoute ou renomme une clé nécessite une nouvelle importation.

Check-list pour les développeurs

• Conservez des clés stables. Renommer server_url casse chaque politique qui la définit.
• Masquez un champ dans l'interface utilisateur lorsqu'il est défini par une configuration, afin que les employés ne puissent pas le remplacer.
• Prévoyez un repli adapté lorsqu'une clé est vide, par exemple en affichant un message clair invitant à « contacter le support informatique ».
• N'exigez jamais de secret dans la configuration. Utilisez-la pour localiser le serveur, puis effectuez une authentification appropriée.
• Testez avec l'application TestDPC de Google sur un appareil qui n'est pas inscrit dans votre MDM. TestDPC doit être l'application de gestion de l'appareil : elle ne peut donc pas fonctionner sur un appareil déjà géré par votre MDM.

FAQ de dépannage

L'application ne dispose d'aucun formulaire de configuration dans mon éditeur de politiques.

Le développeur n'a pas publié de schéma via Google Play, ou la version sur Play est antérieure à son ajout. Consultez la documentation de l'éditeur ou demandez-lui directement. Pour les applications internes, vérifiez que l'entrée meta-data dans le manifest existe et que la version incluant le schéma a bien été importée. Une clé ajoutée dans une nouvelle version n'apparaît dans le formulaire qu'une fois cette version téléversée sur Google Play et traitée.

J'ai modifié une valeur, mais l'application affiche toujours l'ancienne.

Procédez dans l'ordre suivant :

1. L'appareil a-t-il synchronisé la politique mise à jour ? Vérifiez l'heure de dernière connexion.
2. Forcez l'arrêt et rouvrez l'application. Si la nouvelle valeur apparaît désormais, l'application ne lit la configuration qu'au lancement et n'écoute pas la diffusion de modification.
3. Si elle n'apparaît toujours pas, l'application a peut-être conservé l'ancienne valeur dans son propre stockage. Effacer les données de l'application règle le problème, mais supprime tout ce qui n'existe que sur l'appareil, comme les scans hors ligne pas encore synchronisés : synchronisez d'abord. Sinon, le développeur doit corriger l'application.

La valeur est bien transmise, mais l'application l'ignore.

Vérifiez que le nom de la clé et son type correspondent exactement au schéma. Les clés sont sensibles à la casse, et un booléen envoyé sous forme de chaîne de caractères ne sera pas lu comme un booléen. Vérifiez également si la version de l'application sur l'appareil n'est pas antérieure à celle qui a introduit la clé. Sur un appareil avec profil professionnel, vérifiez que l'employé a ouvert la copie professionnelle de l'application, signalée par une icône de mallette. La copie personnelle ne reçoit jamais la configuration.

Certaines politiques Chrome fonctionnent et d'autres non.

Toutes les politiques Chrome Enterprise ne sont pas prises en charge sur Android. Vérifiez la prise en charge des plateformes pour chacune d'elles dans la liste des politiques Chrome Enterprise, et vérifiez la version de Chrome sur l'appareil.

Puis-je transmettre une valeur différente à chaque appareil ?

Oui, mais pas par défaut. Utilisez des variables de configuration si votre console les prend en charge pour l'attribut souhaité, répartissez les appareils dans des politiques plus restreintes, ou faites en sorte que l'application récupère ses paramètres propres auprès de son backend. Voir l'étape 5.

La configuration a été appliquée, mais l'employé peut toujours modifier le champ.

Le verrouillage d'un champ relève de l'application, pas d'Android. Demandez au développeur de désactiver ou de masquer les paramètres issus d'une configuration gérée.

Comment effectuer des tests sans impacter la production ?

Utilisez une politique de test dédiée et un appareil enrôlé. Pour les applications internes, les développeurs peuvent utiliser TestDPC avant même que l'application n'arrive dans votre MDM.

Étapes suivantes

Points clés à retenir :

• Le développeur de l'application définit ce qui peut être configuré. Votre MDM ne fait que renseigner ces champs, rien de plus.
• Confirmez d'abord la prise en charge, répertoriez les clés et les types, puis testez sur un appareil avant le déploiement général.
• Les valeurs partagées ont leur place dans la politique. Les valeurs propres à chaque appareil nécessitent des variables, des périmètres plus restreints ou des requêtes côté application.
• Pour les applications internes, l'ajout d'un schéma nécessite une modification mineure et bien documentée, et supprime l'étape de configuration manuelle pour les employés.

Commencez cette semaine par l'application qui génère le plus de tickets de configuration. Listez ses clés, créez une politique de test et validez-la sur un appareil. Envoyez ensuite la check-list pour développeurs ci-dessus à l'équipe responsable de votre application interne.

Si vous souhaitez tester ce flux avec Nomid MDM, la fiche de l'application dans l'éditeur de politiques ouvre la configuration gérée de chaque application, et le forfait gratuit couvre jusqu'à 10 appareils sans limite de temps. C'est suffisant pour une politique de test et un groupe pilote. L'accès à distance et l'API ne sont pas inclus dans le forfait gratuit.

FAQ

Qu'est-ce qu'une configuration gérée Android ?

Il s'agit d'un ensemble de paramètres clé-valeur qu'une organisation déploie sur une application installée sur un appareil Android géré. Il peut s'agir, par exemple, d'une URL de serveur, de sites web autorisés ou d'options d'activation de fonctionnalités. Le développeur de l'application définit les champs disponibles dans un schéma publié via Google Play, et le MDM transmet les valeurs par l'intermédiaire de la politique de l'appareil.

Comment savoir si une application prend en charge la configuration d'application sous Android Enterprise ?

Ajoutez l'application à une politique de test dans votre MDM et voyez si un formulaire de configuration apparaît. Vous pouvez également consulter la documentation d'entreprise de l'éditeur ou demander à son support technique quelles sont les clés de configuration gérée exposées par l'application.

Qu'est-ce que le fichier app_restrictions.xml ?

Il s'agit du fichier XML situé dans les ressources d'une application Android dans lequel le développeur déclare le schéma de configuration gérée : la clé, le type, le titre et la valeur par défaut de chaque paramètre. Ce fichier est référencé dans le manifest de l'application, et Google Play le lit lors de l'importation de l'application.

La modification d'une configuration gérée s'applique-t-elle immédiatement ?

L'appareil la reçoit lors de sa prochaine synchronisation de politique. L'application de la modification dans l'immédiat dépend de l'application elle-même. Les applications qui écoutent la diffusion de modification des restrictions se mettent à jour pendant leur exécution, tandis que d'autres ne lisent leur configuration qu'au lancement suivant.