Configuration du mode kiosque Android : Que faire lorsque le propriétaire de l’appareil vous empêche d’accéder aux paramètres

Atablette Android de 10,1 pouces avait été configurée pour une utilisation en mode kiosque avec ADB, un lanceur personnalisé et le rôle « Device Owner ». Après redémarrage, l’application s’est lancée comme prévu, mais l’appareil ne pouvait plus accéder à l’interface normale des paramètres Android.

Cela a posé un défi courant dans le déploiement de kiosques : une fois que la navigation système et les contrôles de gestion de l’appareil sont restreints, comment récupérer la tablette pour des tests supplémentaires ? Et si l’application doit activer le Wi-Fi ou d’autres fonctions système, quels Intent Android peuvent encore être utilisés ?

Le client a tout d’abord utilisé des commandes ADB pour modifier le comportement de l’interface utilisateur système :

adb shell settings put system hide_navbar 1

adb shell settings put system statusbar_disp 1

adb shell settings put system swipe_show_nav_bar 0

adb shell settings put system power_button_show 0

L’application a ensuite été définie comme écran d’accueil par défaut, puis configurée comme Device Owner activer les fonctions de gestion des appareils requises.

Après le redémarrage, la Tablette Android en mode kiosque a automatiquement démarré l’application comme prévu. Toutefois, le client ne pouvait plus quitter l’écran principal de l’application pour accéder aux paramètres Android ou à d’autres fonctions système. Les boutons Paramètres et Wi-Fi intégrés à l’application ont également cessé d’ouvrir les pages système correspondantes.

La question immédiate n’était pas simplement de savoir comment quitter l’application. Le client avait besoin d’un moyen fiable de récupérer la Tablette Android tablette Android en mode kiosque pour des tests supplémentaires et souhaitait aussi comprendre quels Intents système pouvaient être utilisés par son application.

Pourquoi la tablette Android est devenue difficile d’accès

Le problème résultait de plusieurs couches de contrôle de l’appareil appliquées simultanément.

Le lanceur personnalisé déterminait quelle application apparaissait comme écran d’accueil, tandis que le propriétaire de l’appareil accordait à cette application un contrôle beaucoup plus étendu sur la stratégie de l’appareil. La documentation Android dédiée aux appareils spécialisés prend en charge ce type de configuration pour les déploiements en mode kiosque ou en mode appareil géré, notamment le contrôle de l’application d’accueil par défaut et la restriction de l’accès aux fonctions système.

Les commandes ADB ajoutaient une couche supplémentaire en modifiant le comportement de l’interface utilisateur système. Ces paramètres particuliers dépendent de l’appareil ou du micrologiciel, et non d’API Android universelles ; leur effet exact dépend donc de la manière dont le micrologiciel de la tablette les implémente.

Cela signifie qu’un Tablette Android utilisée comme dispositif kiosque peut devenir difficile à récupérer lorsque le lanceur, la configuration du propriétaire de l’appareil, les restrictions de l’interface utilisateur système et la navigation au sein de l’application sont tous modifiés simultanément.

Le fait que le bouton Paramètres ou Wi-Fi de l’application ne fonctionne plus ne signifie pas nécessairement que l’intention (Intent) elle-même est incorrecte. L’activité cible Paramètres peut être indisponible, restreinte ou autrement inaccessible dans la configuration actuelle de l’appareil. Android recommande également de vérifier si une intention peut être résolue avant d’essayer de la lancer.

Procédures de récupération pour une tablette Android en mode kiosque verrouillée

Si l’application est déjà configurée comme propriétaire de l’appareil (Device Owner), il convient d’envisager en premier lieu une récupération logicielle.

Android DevicePolicyManager fournit des fonctions de gestion d’appareil pouvant être utilisées par un propriétaire d’appareil (Device Owner). Selon la version d’Android et la configuration de l’application, une application propriétaire d’appareil peut recourir au mécanisme d’effacement adapté afin de réinitialiser la tablette à un état propre, utile pour les tests. wipeData() est l’API établie pour effacer les données utilisateur, tandis que les versions plus récentes d’Android offrent des fonctionnalités supplémentaires d’effacement d’appareil.

L’API obsolète clearDeviceOwnerApp() cette méthode ne doit pas être considérée comme une méthode générale de récupération en production. La documentation Android la présente comme une API destinée aux tests et recommande la réinitialisation d’usine comme moyen normal de supprimer une relation « propriétaire de l’appareil ».

ADB fournit également des commandes de gestion des stratégies d’appareil, mais celles-ci comportent des restrictions. Par exemple, adb shell dpm remove-active-admin n’est pas une méthode universelle pour supprimer un « propriétaire de l’appareil » ; la documentation ADB d’Android précise des exigences telles que la déclaration testOnly de l’application.

Si la récupération logicielle n’est pas disponible parce que l’application ne peut pas exécuter l’opération requise, la seule voie restante est une réinitialisation d’usine matérielle ou une procédure de récupération Android .

La combinaison exacte de touches ne doit pas être déduite d’un autre modèle de tablette Android. Le comportement en mode récupération dépend du micrologiciel et de l’implémentation matérielle de la tablette. Pour un projet de tablette Android personnalisée, la procédure de récupération appropriée doit donc être confirmée pour le modèle et le micrologiciel réels avant le déploiement.

Pour ce type de Tablette Android en mode kiosque , disposer d’une méthode de récupération définie est particulièrement utile pendant les tests d’intégration, car la configuration au niveau système peut supprimer intentionnellement la navigation habituelle de l’utilisateur.

Tester les intentions relatives aux paramètres et les fonctions système sur une tablette Android

La deuxième question du client portait sur la possibilité pour l’application de lancer directement des fonctions système telles que les Paramètres et le Wi-Fi.

Android fournit des actions standard relatives aux paramètres pour ces fonctions. Par exemple :

Fonction	Intention standard Android
Paramètres principaux	Settings.ACTION_SETTINGS
Paramètres Wi-Fi	Settings.ACTION_WIFI_SETTINGS
Paramètres sans fil	Settings.ACTION_WIRELESS_SETTINGS
Paramètres Bluetooth	Settings.ACTION_BLUETOOTH_SETTINGS
Paramètres d'affichage	Settings.ACTION_DISPLAY_SETTINGS
Paramètres de localisation	Settings.ACTION_LOCATION_SOURCE_SETTINGS
Paramètres sonores	Settings.ACTION_SOUND_SETTINGS
Paramètres de sécurité	Settings.ACTION_SECURITY_SETTINGS
Paramètres des applications	Settings.ACTION_APPLICATION_SETTINGS
Paramètres spécifiques de l’application	Settings.ACTION_APPLICATION_DETAILS_SETTINGS

 

Il s’agit d’actions standard des paramètres Android, et non d’interfaces propres à un fabricant particulier De tablette Android . Toutefois, la simple existence d’un Intent ne garantit pas qu’il s’ouvrira avec succès sur tous les appareils ou dans toutes les configurations de kiosque. Android recommande de vérifier l’Intent à l’aide de resolveActivity() avant de le lancer.

Pour une tablette Android intégrée au système, les tests d’Intent doivent donc être effectués sur le micrologiciel réel et la version d’Android utilisés pour le déploiement. Le test doit non seulement vérifier l’existence de l’Intent, mais aussi déterminer si l’activité correspondante reste accessible une fois les restrictions liées au propriétaire de l’appareil, au lanceur et à l’interface système appliquées.

Si vous travaillez sur une tablette Android en mode kiosque ou sur un projet d’intégration système et que vous avez besoin d’aide concernant la récupération du propriétaire de l’appareil (Device Owner), les intentions (Intents) des paramètres ou d’autres problèmes liés à la configuration, veuillez nous contacter en indiquant le modèle de votre tablette et la version d’Android utilisée. Nous pourrons ainsi examiner ensemble les options de support technique et de personnalisation disponibles.

 

Le même principe s’applique à d’autres fonctions système. Une API Android standard peut exister, mais le comportement réel d’une tablette personnalisée dépend de sa version d’Android, de sa configuration du micrologiciel (firmware) et de ses politiques de gestion des appareils.

Et les demandes d’activation (« wake requests ») ?

La question du client concernant les « demandes d’activation » diffère légèrement de l’ouverture d’une page des paramètres.

Intent.ACTION_SCREEN_ON représente une diffusion système (broadcast) indiquant que l’écran est devenu interactif. Il s’agit d’une diffusion système protégée ; une application ne doit donc pas la traiter comme une intention ordinaire qu’elle pourrait simplement envoyer pour activer (« réveiller ») la tablette.

Si la demande consiste à activer l’écran, maintenir l’écran allumé ou contrôler le comportement d’activation de l’écran , le mécanisme approprié dépend des exigences précises de l’application. Android fournit des API de gestion de l’alimentation et des fenêtres/activités pour ces scénarios, notamment PowerManager et la fonctionnalité de verrouillage d’éveil (wake lock) lorsque cela est pertinent.

Cette distinction est importante lors du développement d’applications destinées à un Tablette Android en mode kiosque . « Lancer une fonction système » et « contrôler l’état d’alimentation de l’appareil » sont des opérations système différentes et doivent être gérées via des API distinctes.

Assistance technique pour l’intégration de tablettes Android

Ce cas illustre également pourquoi le déploiement en mode kiosque peut nécessiter plus que la simple configuration matérielle de base d’une tablette Android.

Lorsqu’une tablette est intégrée à une application dédiée, un système de point de vente (POS), un kiosque, un système industriel ou tout autre appareil géré, la configuration logicielle peut impliquer simultanément le lanceur (launcher), le propriétaire de l’appareil (Device Owner), l’interface utilisateur système, les autorisations des applications, les intentions de paramètres (Settings Intents) et le comportement de récupération.

Pour les projets nécessitant tablettes Android personnalisées configurations, ces exigences doivent être évaluées conjointement avec la configuration matérielle et celle du système Android, plutôt que d’être traitées comme des problèmes distincts lors des tests finaux.

La solution appropriée dépend de la version d’Android, du micrologiciel de la tablette, de la configuration de l’application et des fonctions que l’intégrateur système doit contrôler. Une documentation technique peut également être rédigée autour des interfaces système disponibles, des Intentions prises en charge, des autorisations et des limitations spécifiques à l’appareil.

Si vous testez une Tablette Android destinée au déploiement en mode kiosque ou à l’intégration système et que vous rencontrez des problèmes similaires avec Device Owner, les lanceurs personnalisés, le mode kiosque, les Intentions de paramètres, les restrictions de l’interface utilisateur système ou la récupération de l’appareil , s'il te plaît contactez-nous pour obtenir une assistance technique .

Vous pouvez fournir le modèle de votre tablette, la version d’Android, la configuration de déploiement et la fonction précise que vous tentez de mettre en œuvre. Nous pourrons alors examiner les Personnalisation des tablettes Android et assistance technique options disponibles pour votre projet.