Affichage dynamique ADB ouvert : Déploiement d'une application Android appartenant au client

Lorsqu'un projet d'affichage dynamique implique une application Android appartenant au client, le choix d'un écran d'affichage dynamique Android n'est plus seulement une question de taille d'écran, de résolution ou de méthode de montage. La question la plus importante est de savoir si la plateforme Android offre à l'intégrateur suffisamment de contrôle pour déployer et exécuter son propre logiciel.

Cela est devenu évident lorsqu'un distributeur d'affichage dynamique basé en Bosnie nous a contactés avec une exigence pour un écran Android compact. L'application prévue impliquait l'affichage d'informations, mais le client avait déjà sa propre application Android et ne voulait pas être limité par un lanceur installé en usine. La demande comprenait l'ouverture de l'ADB, l'installation d'APK côté client, la possibilité d'utiliser l'application du client comme lanceur, et un support adapté à différentes orientations d'installation.

Pour ce type de projet, nous examinons d'abord l'exigence de déploiement logiciel. Les questions pratiques sont simples : l'APK du client peut-il être installé indépendamment ? Son application peut-elle devenir le lanceur de l'appareil ? Cette configuration restera-t-elle après un redémarrage ? Et quel niveau d'accès système est disponible si l'intégrateur a besoin de gérer l'environnement Android ?

Ces questions nous ont amenés à évaluer l'écran comme une plateforme Android plutôt que simplement comme un appareil de lecture de contenu.

Le client avait besoin de plus qu'un environnement Android d'usine

Un déploiement d'affichage dynamique conventionnel peut s'appuyer fortement sur le logiciel fourni avec l'écran. Le contenu peut être livré via un CMS, lancé via une application d'usine et géré dans le flux de travail prévu par le fabricant.

Un intégrateur avec sa propre application a une exigence différente. L'écran devient une partie de l'environnement logiciel existant de l'intégrateur, de sorte que la capacité de déployer un APK auto-installé fait partie du processus de sélection du matériel.

Dans ce cas, l'exigence n'était pas simplement d'installer une application une fois. Le client voulait que son propre logiciel devienne l'interface normale présentée aux utilisateurs.

Cette distinction a changé notre approche de la demande. Au lieu de considérer "Android" comme une spécification suffisante, nous avons séparé le déploiement en plusieurs couches pratiques : accès ADB, installation d'APK, comportement du lanceur personnalisé, comportement au démarrage et accès Root.

Notre configuration d'affichage dynamique Android confirmée prend en charge ces exigences. L'ADB est pris en charge, le client peut installer son propre APK via l'ADB, une application avec la propriété de lanceur requise peut remplacer le lanceur d'origine, et le lanceur configuré reste le point d'entrée par défaut après un redémarrage. Le Root est également ouvert par défaut, avec adb shell fonctionnant avec les privilèges Root.

Pour un environnement d'application compact, l' écran d'affichage dynamique Android 13 RK3588 de 10,1 pouces fournit un exemple matériel pertinent d'un écran d'affichage dynamique Android 13 RK3588. Il utilise un processeur RK3588 et Android 13 et est positionné comme un écran Android pour les applications nécessitant une intégration et une personnalisation logicielles.

Le produit lui-même n'est pas le point principal de l'affaire. Ce qui compte, c'est que le matériel puisse accueillir un environnement logiciel contrôlé par le client au lieu d'obliger l'intégrateur à construire son application autour d'une interface d'usine fixe.

L'ouverture de l'ADB permet le déploiement d'APK côté client

Pour un intégrateur disposant d'une application Android existante, la première question pratique est de savoir si le logiciel peut être déployé sans s'appuyer sur l'environnement d'application préinstallé par le fabricant. Pour un écran d'information, par exemple, ce déploiement peut commencer à partir d'un ordinateur tactile tout-en-un / tablette Android RK3399 de 21 pouces qui exécute l'APK du client.

L'ouverture de l'ADB fournit le canal de communication utilisé pour interagir avec l'appareil Android depuis un ordinateur. Dans ce scénario de déploiement, la capacité pertinente est que le client peut utiliser l'ADB pour installer son propre APK.

Ceci est parfois décrit comme un déploiement d'APK par side-loading. L'application est fournie par le client plutôt que d'être limitée aux logiciels préchargés par le fabricant de l'écran.

L'ADB, l'installation d'APK et le Root doivent toujours être considérés comme des capacités distinctes. L'ADB est le mécanisme de communication. L'installation d'APK est l'opération de déploiement. Le Root détermine le niveau de privilège disponible dans le système Android.

La distinction est importante lors de l'achat, car un écran peut prendre en charge Android et même permettre l'installation d'applications sans fournir nécessairement le niveau d'accès système requis par un intégrateur.

Dans la configuration confirmée pour notre gamme de produits d'affichage dynamique Android, le client peut utiliser l'ADB pour installer son propre APK, tandis que l'accès Root est disponible par défaut. Cela donne à l'intégrateur un chemin de déploiement clair pour son propre logiciel et, si nécessaire, un accès plus approfondi à l'environnement Android.

Pour les acheteurs à la recherche de la capacité d'installation d'APK sur un écran d'affichage dynamique Android — ou prévoyant d'installer votre propre APK sur un écran d'affichage dynamique — c'est une distinction plus utile que de simplement rechercher une version Android dans la fiche technique.

L'étape importante vient après l'installation de l'APK

L'installation d'un APK ne rend pas automatiquement cette application l'interface principale de l'appareil.

C'était une partie importante de l'exigence du client. Le client avait déjà sa propre application et ne voulait pas que les utilisateurs passent par le lanceur d'usine avant d'atteindre cette application.

Une application Android avec la propriété appropriée de lanceur/accueil peut être configurée comme le lanceur par défaut de l'appareil. Une fois qu'elle devient le lanceur par défaut, l'application du client devient le point d'entrée normal du système Android.

La configuration confirmée prend en charge cette approche. Lorsque l'application du client possède la propriété de lanceur requise, elle peut remplacer le lanceur d'origine, transformant l'appareil en écran d'affichage dynamique avec lanceur personnalisé Android. Après le redémarrage de l'appareil, le lanceur configuré reste le lanceur par défaut et l'appareil peut à nouveau accéder à l'application du client.

Cela crée une différence significative entre deux types de projets d'affichage dynamique Android avec installation d'APK par le client.

Dans un modèle, le client installe simplement une application aux côtés du logiciel du fabricant. Dans l'autre, l'application du client devient l'interface principale de l'appareil. Le second modèle est plus proche de ce dont de nombreux intégrateurs ont besoin lorsque l'écran est destiné à fonctionner dans le cadre d'un environnement logiciel propriétaire.

La distinction est également la raison pour laquelle "installation d'APK prise en charge" ne doit pas être considérée comme la réponse complète lors de l'évaluation d'un projet d'affichage dynamique avec lanceur personnalisé.

L'accès Root offre à l'intégrateur une option de niveau système plus approfondie

L'exigence du client comprenait également un accès système ouvert, c'est là que le Root devient pertinent.

La configuration confirmée fournit l'accès Root par défaut. Plus précisément, adb shell fonctionne en tant que Root plutôt qu'en tant qu'utilisateur de shell restreint.

Cela ne signifie pas que le Root est requis simplement pour installer l'APK du client. Le déploiement d'APK et le Root sont des parties distinctes du système.

La raison de clarifier le Root lors de l'achat est différente : un intégrateur peut avoir besoin d'un accès plus approfondi lors de l'adaptation, de la configuration, du débogage ou de la gestion de son propre environnement logiciel. Pour ces tâches, un tablette industrielle Android RK3288 de 12 pouces avec NFC et montage mural offre une plateforme compacte et murale avec prise en charge du SDK pour une intégration personnalisée.

Pour ce type de projet, la distinction peut être exprimée simplement :

C'est aussi pourquoi nous ne décrivons pas les exigences d'un écran de kiosque ADB ouvert simplement comme une exigence Root. Un projet peut nécessiter l'ADB et un lanceur personnalisé sans nécessiter que toutes les fonctions système soient exposées à l'utilisateur.

Lanceur personnalisé et Kiosque sont liés, mais pas identiques

Un lanceur personnalisé résout une partie importante de l'expérience utilisateur : il permet à l'application du client de devenir l'interface d'accueil normale.

Un déploiement de kiosque plus strict peut nécessiter plus que cela. L'application peut devoir rester le seul environnement pratique face à l'utilisateur, tandis que la navigation normale vers le bureau Android ou les paramètres système est restreinte — un schéma pertinent pour les déploiements en libre-service tels que notre série de caisses enregistreuses POS.

Ces exigences doivent être définies séparément.

Pour la configuration confirmée discutée dans ce cas, l'application du client peut devenir le lanceur par défaut lorsqu'elle possède la propriété de lanceur requise, et l'appareil peut revenir à cette application après le redémarrage. Cela établit la position de l'application en tant qu'interface principale de l'appareil.

Si un projet nécessite en outre un verrouillage d'application strict, une navigation système restreinte ou une implémentation de gestion d'appareil spécifique, ces exigences doivent être évaluées en fonction de l'application et de la méthode de déploiement du client plutôt que d'être supposées incluses simplement parce qu'un lanceur personnalisé est pris en charge.

Cette distinction est particulièrement pertinente pour les intégrateurs qui construisent leur propre environnement logiciel de kiosque. La bonne question n'est pas simplement de savoir si l'écran est annoncé comme un écran de kiosque Android pour des applications personnalisées, mais quelles parties de l'expérience utilisateur Android l'application du client doit réellement contrôler. Un déploiement en libre-service tel qu'un kiosque Android POS de 11,6 pouces montre une application client fonctionnant comme interface principale sur une base Android.

L'écran physique doit toujours correspondre à l'application

La configuration logicielle n'était qu'une partie de la demande initiale. Le client avait également besoin d'un écran compact et d'un support pouvant accueillir différentes orientations.

Cette exigence se situe en dehors de la configuration du lanceur. Une application peut être conçue pour une présentation portrait ou paysage, mais la structure physique détermine toujours la façon dont l'écran est positionné.

Pour un environnement d'application compact, l' écran d'affichage dynamique Android 13 RK3588 de 10,1 pouces fournit un exemple matériel pertinent. Il utilise un processeur RK3588 et Android 13 et est positionné comme un écran Android pour les applications nécessitant une intégration et une personnalisation logicielles.

Le produit lui-même n'est pas le point principal de l'affaire. Ce qui compte, c'est que le matériel puisse accueillir un environnement logiciel contrôlé par le client au lieu d'obliger l'intégrateur à construire son application autour d'une interface d'usine fixe.

Pour un écran d'affichage dynamique Android compact, la configuration de 10,1 pouces est plus proche de l'exigence initiale. La tablette Android tout-en-un de 15,6 pouces FHD IPS avec RK3288 et la tablette Android tout-en-un de 13,3 pouces avec écran FHD IPS et RK3288 se situent entre les formats compacts et grands pour les applications d'affichage dynamique et de kiosque. Pour les applications qui nécessitent une surface interactive plus grande et une installation mobile, l' écran Android Stand By Me de 21,5 pouces RK3588 offre un format physique différent tout en utilisant la même approche générale de plateforme Android.

La raison de séparer ces deux considérations est pratique. La flexibilité logicielle ne détermine pas automatiquement l'installation mécanique. Un projet nécessitant un placement paysage et portrait a toujours besoin de la structure physique, du mécanisme de rotation ou de la configuration du support appropriés.

Pour cette raison, notre gamme d'écrans publicitaires Android comprend différents formats d'écrans commerciaux qui peuvent être évalués en fonction de l'environnement d'application — y compris les grands panneaux intérieurs fixes tels que la tablette Android tout-en-un RJ45 PoE de 24 pouces avec une luminosité de 350 cd/m².

Comment nous avons aidé à traduire l'exigence en une configuration déployable

La partie utile de ce type de projet n'est pas simplement de confirmer qu'un écran exécute Android. Le défi est de connecter le logiciel existant du client à l'environnement matériel dans lequel il fonctionnera.

Pour le distributeur basé en Bosnie, l'exigence a pu être traduite en une séquence de questions pratiques : comment l'APK atteindra-t-il l'appareil, l'application peut-elle devenir le lanceur, que se passe-t-il après le redémarrage, et quel niveau d'accès Android l'intégrateur a-t-il ?

Une fois ces questions séparées, l'exigence matérielle est devenue beaucoup plus claire.

La capacité confirmée peut être résumée comme suit :

C'est la partie du processus qui peut réduire l'incertitude pour un intégrateur. Au lieu de choisir un écran d'abord et de découvrir les restrictions logicielles plus tard, l'exigence logicielle peut être utilisée pour déterminer si la plateforme convient à un projet d'écran d'affichage dynamique Android avec ADB ouvert et accès root avant de passer au déploiement. La même approche peut être utilisée pour un projet d'affichage dynamique ADB ouvert dans lequel l'application du client existe déjà et l'exigence principale est de déployer ce logiciel sur un écran Android commercial.

Un point de départ pratique pour votre propre projet d'affichage dynamique Android

Un APK appartenant au client modifie la façon dont un écran Android doit être évalué. La taille de l'écran et les spécifications d'affichage sont toujours importantes, mais elles ne sont qu'une partie de la décision de déploiement.

Pour un intégrateur, l'évaluation la plus utile commence par l'application : si l'APK doit être installé indépendamment, si l'application doit devenir le lanceur, si elle doit apparaître automatiquement après le redémarrage, et si un accès système plus approfondi est requis.

C'était la base de notre approche de la demande bosniaque. Au lieu de considérer l'ADB ouvert, l'installation d'APK, le comportement du lanceur et le Root comme des spécifications sans rapport, nous les avons évalués comme des parties de la même exigence de déploiement logiciel.

Si votre projet possède déjà son propre APK Android, la prochaine étape consiste à définir le comportement attendu de l'application et à le faire correspondre à la configuration appropriée de l' écran d'affichage dynamique Android. Un appareil d'échantillon peut ensuite être utilisé pour valider l'APK, le comportement du lanceur, le comportement au redémarrage et l'accès système requis avant de passer à un déploiement plus large. Le même modèle de déploiement s'applique aux applications d'écrans Android, des panneaux de réservation de salles de réunion aux écrans de commande de restaurant, comme en témoignent nos séries de tablettes de réservation de salles de conférence et de tablettes de commande de restaurant. Si vous évaluez un déploiement d'écran Android similaire, contactez notre équipe pour discuter de vos exigences en matière d'APK et de configuration de l'appareil.