Synthèse
Le développement d'applications professionnelles pour les Rokid AI Glasses commence par la documentation du Sprite Enterprise SDK de Rokid et sa démo Android. La FAQ entreprise oriente les firmwares entreprise vers Rokid AI Enterprise ou la démo entreprise. Android Studio sert d'environnement de codage ; le Glasses SDK donne accès aux fonctionnalités de l'appareil, et le Phone SDK prend en charge l'application Android associée.
La compatibilité passe avant tout. Ces instructions publiques visent les Rokid Glass3 Enterprise. Une désignation commerciale telle que « Rokid Enterprise RV101 » ne suffit pas, à elle seule, à établir la compatibilité avec le SDK. Obtenez une confirmation écrite pour votre matériel, votre firmware, votre région et vos droits commerciaux exacts sur le SDK avant de suivre les étapes d'intégration. Si Rokid fournit un autre SDK entreprise pour votre appareil, utilisez ce package et les exemples correspondants.
Ce tutoriel enrichit la démo entreprise officielle pour capturer une photo, afficher un statut et tester des notes dictées. Il s'agit d'un prototype de développement. L'envoi d'un enregistrement métier et la gestion d'une flotte nécessitent le backend de votre entreprise ainsi qu'une méthode de distribution entreprise confirmée séparément.
Documentation du SDK entreprise : Ouvrir la source officielle
Pourquoi créer une application sur mesure pour les Rokid AI Glasses
Une application sur mesure peut relier les inspections sur le terrain, la maintenance ou les contrôles en entrepôt aux informations dont l'entreprise a réellement besoin. Une courte consigne à l'écran indique à l'opérateur ce qu'il doit faire, la caméra capture les preuves, et la saisie vocale peut limiter la frappe pour les tâches qui s'y prêtent.
Le résultat utile est un enregistrement métier fiable, avec le bon identifiant d'équipement ou d'ordre de travail et un statut d'enregistrement clair. Commencez par créer le flux de capture et de vérification le plus simple possible, puis connectez-le au système opérationnel une fois le comportement du matériel et le traitement des données testés.
Choisir les composants entreprise
Android Studio, JDK et Gradle :
- Rôle : Modifier, compiler et déboguer des projets Android.
- Exigence métier : Utiliser un poste de développement géré et la chaîne d'outils approuvée pour le projet.
Sprite Enterprise Glasses SDK :
- Rôle : Caméra, voix, logique applicative liée à l'affichage et services de l'appareil.
- Exigence métier : Nécessite un matériel et un firmware entreprise pris en charge ; confirmez les conditions commerciales.
Sprite Enterprise Phone SDK :
- Rôle : Appairage, messagerie et échange de médias avec un téléphone Android.
- Exigence métier : À utiliser lorsque votre architecture comprend un téléphone géré par l'entreprise.
Rokid AI Enterprise ou démo entreprise :
- Rôle : Connexion entreprise et tests de développement.
- Exigence métier : Obtenir la version adaptée et les comptes via le canal entreprise.
Backend de l'entreprise :
- Rôle : Authentification et stockage des enregistrements métier.
- Exigence métier : Utiliser des endpoints approuvés, des contrôles d'accès et des règles de conservation.
Ce dont vous avez besoin avant de commencer
Préparez les lunettes entreprise prises en charge, un câble de débogage de données Glass3, un téléphone Android de test, Android Studio, JDK 17, Git et la démo du SDK. Git télécharge le code source ; Gradle le compile ; un APK est le fichier d'installation Android. Utilisez les versions de la configuration de démo approuvée. Le Quick Start et la FAQ de Rokid divergent sur les versions minimales d'Android : vérifiez donc l'exigence dans le package qui vous a été fourni plutôt que de retenir la valeur la plus basse.
Étape 1 : confirmer l'appareil entreprise et les accès
• Notez la cible. Sur les lunettes, ouvrez Paramètres (Settings) et notez le modèle, la version du système et le numéro de série. Demandez à Rokid de confirmer que cette version prend en charge le Sprite Enterprise SDK ainsi que les services de caméra et de voix requis ici.
• Obtenez le package entreprise. Demandez Rokid AI Enterprise ou la démo entreprise, la version du SDK correspondante et les identifiants professionnels à votre fournisseur ou à votre contact Rokid. Confirmez les droits de développement et de déploiement commerciaux ; un simple téléchargement public ne règle pas la question des licences.
• Préparez la connexion. Chargez les appareils et connectez les lunettes au poste de travail à l'aide du câble de débogage de données. Suivez les instructions d'intégration entreprise fournies pour votre version afin de préparer le téléphone géré et les lunettes.
• Définissez le flux de données. Décidez où les photos et les notes dictées peuvent être traitées et stockées. Utilisez un environnement de test de l'entreprise et des données de test non sensibles pendant la validation de la démo.
Configuration requise pour le système et les applications entreprise : Ouvrir la source officielle
Étape 2 : ouvrir et exécuter la démo Android entreprise
• Téléchargez le code source. Dans un terminal du poste de développement, exécutez la commande ci-dessous. Enregistrez le dépôt cloné dans le dossier de développement habituel de votre équipe et notez son commit avec git rev-parse HEAD.
git clone https://github.com/RokidSuuport/glass3_sdk_demo.git
• Ouvrez les projets. Dans Android Studio, choisissez File > Open et sélectionnez glass3_sdk_demo/glassdemo. Ouvrez séparément glass3sdkphonedemo pour le téléphone. Attendez la synchronisation Gradle, puis sélectionnez JDK 17 dans Settings > Build, Execution, Deployment > Build Tools > Gradle.
• Vérifiez les dépendances. Dans le panneau Project, ouvrez settings.gradle et app/build.gradle dans chaque projet. Conservez la configuration fonctionnelle de la démo. Pour un projet distinct basé sur Groovy, fusionnez ces entrées de dépôt et de dépendance dans les blocs existants ; ne créez pas de blocs en double. Le Quick Start publié indique la version 2.2.0-E, mais utilisez celle approuvée pour votre firmware.
// settings.gradle, dans dependencyResolutionManagement {
repositories { maven { url 'https://maven.rokid.com/repository/maven-public/' }
}
}
// Application lunettes : app/build.gradle, dans dependencies dependencies {
implementation('com.rokid.security:glass3.open.sdk:2.2.0-E') {
exclude group: 'org.slf4j'
}
}
// Application téléphone uniquement : app/build.gradle, dans dependencies dependencies {
implementation('com.rokid.security:phone.sdk:2.2.0-E') {
exclude group: 'org.slf4j'
}
}
• Configurez et lancez. Dans le projet téléphone, ouvrez MainPhoneActivity et repérez UserAuthInfo. Fournissez l'AK et le SK délivrés à l'entreprise via une configuration locale approuvée, hors du contrôle de version. Avant d'exécuter la démo des lunettes, ouvrez HomeActivity.initSDK() et remplacez l'appel d'exemple setCameraLedEnable(false) par setCameraLedEnable(true). Redémarrez si le firmware de l'appareil l'exige. Lancez d'abord l'application téléphone, puis sélectionnez les lunettes dans Android Studio et exécutez glassdemo. Connectez-vous depuis la démo téléphone et vérifiez l'initialisation du SDK ainsi que l'envoi d'un message texte avant toute modification.
• Ajustez la configuration. L'URL du dépôt télécharge l'exemple, pas un programme d'installation. Les deux dépendances appartiennent à des applications différentes. Ne modifiez les versions ensemble qu'après avoir consulté les recommandations de compatibilité de Rokid ; conservez les helpers d'initialisation de la démo et les imports nécessaires.
Configuration de la démo et chemins du code source : Ouvrir la source officielle
Dépôt et dépendances du SDK : Ouvrir la source officielle
Étape 3 : rendre la première commande de capture claire
• Repérez l'écran. Dans le projet glassdemo, ouvrez app/src/main/java/com/rokid/glass/SdkMediaActivity.kt. Son fichier de mise en page se trouve dans app/src/main/res/layout/activity_test_media.xml. Il s'agit d'un écran Android natif existant doté de commandes de caméra, et non d'une page web.
• Modifiez d'abord un seul bouton. Dans ce fichier XML, repérez l'élément AppCompatButton existant portant l'ID android:id="@+id/btPhoto480P". Conservez son ID d'origine et ses contraintes de mise en page afin que le view binding Kotlin existant (binding.btPhoto480P) continue de fonctionner sans casser les références.
• La mise en page d'origine de la démo fixe la largeur du bouton à 50dp et sa hauteur à 36dp, avec un libellé de 10sp, ce qui tronquera le nouveau texte. Ne modifiez que les attributs indiqués ci-dessous et laissez le reste de l'élément tel quel (l'arrière-plan, la couleur du texte, les marges et les deux lignes app: layout_constraint) ; sans ses contraintes, le bouton perd sa place dans le ConstraintLayout :
XML
<androidx.appcompat.widget.AppCompatButton
android:id="@+id/btPhoto480P"
android:layout_width="120dp"
android:layout_height="wrap_content"
android:text="Capture"
android:contentDescription="Capture photo"
android:textSize="16sp" />
• Explication des attributs.
• android:text="Capture" : Définit le libellé visible affiché directement à l'écran.
• android:contentDescription="Capture photo" : Fournit une description d'accessibilité pour les lecteurs d'écran et l'inspection de la hiérarchie de l'interface. Notez que définir contentDescription sur les appareils Rokid ne crée ni n'enregistre automatiquement de commande vocale ; le contrôle vocal nécessite une intégration explicite avec le service de reconnaissance vocale/commandes hors ligne du Sprite Enterprise SDK.
• android:textSize="16sp" : Garantit la lisibilité sur l'écran optique monoculaire.
• Concevez l'écran de travail. Pour la version professionnelle, gardez une interface minimale : un indicateur de statut clair, un seul bouton de capture principal et un parcours d'annulation ou de vérification bien défini. Suivez les recommandations d'affichage entreprise de Rokid en utilisant un texte à fort contraste (par exemple un texte vert lisible superposé aux scènes réelles), et ne comptez pas uniquement sur la couleur pour signaler les erreurs ou les états de capture. Vérifiez toujours le positionnement et la troncature du texte sur l'écran physique des lunettes, plutôt que de vous fier uniquement à l'aperçu de mise en page d'Android Studio.
Recommandations d'affichage et de mise en page entreprise : Ouvrir la source officielle
Étape 4 : tester la saisie vocale entreprise
• Ouvrez l'exemple de reconnaissance vocale. Dans le projet des lunettes, ouvrez app/src/main/java/com/rokid/glass/SendMessageActivity.kt. Repérez la branche R.id.btnOnlineAsr et la fonction speechCallback(token). ASR signifie reconnaissance automatique de la parole (automatic speech recognition) : elle convertit la parole en texte.
• Lancez une session vocale. Utilisez la commande ASR de la démo entreprise pour démarrer une session. Conservez la gestion de son jeton de session et de son callback. L'exemple utilise l'ASR dans le cloud, qui ne fonctionne qu'une fois que la démo téléphone a initialisé le SDK avec votre AK et votre SK : confirmez donc les droits d'accès au service, la langue prise en charge, l'accès réseau et les conditions de traitement des données professionnelles avant d'utiliser la voix des opérateurs.
• Séparez le texte final des commandes. Dans le bloc de livraison onAsrComplete existant, traitez le texte final avec une logique applicative comme dans l'exemple ci-dessous. Il s'agit d'un ajout dans le callback existant, et non d'un remplacement de l'implémentation complète de SpeechCallback. Ce code enregistre une note en vue de sa vérification ; il ne déclenche ni la caméra ni l'envoi.
// Ajoutez ce champ dans SendMessageActivity : private var pendingBusinessNote: String? = null
// Dans le bloc existant de livraison du résultat final : pendingBusinessNote = content?.trim()?.takeIf { it.isNotEmpty() } // Affichez pendingBusinessNote dans votre interface de vérification avant l'enregistrement.
• Ajoutez les commandes de façon réfléchie. Pour une capture mains libres, utilisez l'exemple de commandes hors ligne entreprise ou un gestionnaire de transcription finale validé et relié à l'écran de capture. Les deux doivent appeler la même fonction de capture que le bouton visible. Vérifiez la configuration linguistique et phonétique avec le SDK fourni. Une note dictée est du texte libre et ne doit pas être traitée comme une commande.
• Prévoyez l'arrêt et la reprise. Conservez l'appel stopSpeech et le nettoyage de session de l'exemple lorsque l'écran passe en arrière-plan. Testez le silence, le refus de l'autorisation du microphone, la perte de réseau et les sessions répétées. Prévoyez une solution de repli via un bouton physique ou une commande visible.
Exemple entreprise d'ASR et de commandes hors ligne : Ouvrir la source officielle
Étape 5 : ajouter le gestionnaire de caméra et le retour sur le résultat
• Réutilisez l'initialisation existante. Revenez à SdkMediaActivity.kt. Conservez la configuration du SDK, les imports et le callback photo de la démo. Dans initView(), remplacez uniquement le bloc binding.btPhoto480P.setOnClickListener par l'appel ci-dessous, puis ajoutez la fonction dans la même classe Activity. Ce code utilise l'enum de résolution 480P existante et l'emplacement partagé Pictures de la démo.
binding.btPhoto480P.setOnClickListener { captureBusinessPhoto() }
private fun captureBusinessPhoto() { val service = GlassSdk.getGlassMediaService() if (service == null) { binding.btPhoto480P.text = "Unavailable" return } val folder = Environment.getExternalStoragePublicDirectory( Environment.DIRECTORY_PICTURES ) if (!folder.exists() && !folder.mkdirs()) { binding.btPhoto480P.text = "Storage error" return } val output = File(folder, "inspection_${System.currentTimeMillis()}.png") binding.btPhoto480P.text = "Capturing" try { service.takePhoto(PhotoResolution.RESOLUTION_480P, output.absolutePath) } catch (e: Exception) { binding.btPhoto480P.text = "Try again" } }
• Affichez la réussite depuis le callback. Repérez l'objet mPhotoFileCallback existant. Ajoutez la fonction ci-dessous dans l'Activity, puis appelez showBusinessPhoto(path) depuis onTakePhoto et onTakePhotoV2. Conservez getCallbackId et l'enregistrement de callback existant. Dans mICameraStateLister.onCameraError, mettez à jour la commande pour afficher « Try again » sur le thread UI.
private var capturedBusinessPhoto: String? = null
private fun showBusinessPhoto(path: String) { runOnUiThread { if (!isFinishing && !isDestroyed) { capturedBusinessPhoto = path binding.btPhoto480P.text = "Captured" } } }
• Comprenez et personnalisez. takePhoto demande une capture ; son callback fournit le chemin du fichier. Captured signifie qu'un fichier local existe, et non qu'un enregistrement métier a été sauvegardé. Pour cet écran de développement, élargissez le bouton afin d'afficher le texte de statut. Dans l'écran de production, utilisez une vue de statut distincte. Ne remplacez PhotoResolution que par des valeurs prises en charge par votre SDK, et vérifiez le cadrage et les dimensions réelles du fichier produit.
• Gérez les autorisations et le cycle de vie. Utilisez le flux d'autorisations de la démo avant la capture. La caméra et le microphone nécessitent des déclarations dans le manifeste et, le cas échéant, une autorisation à l'exécution. Conservez removePhotoCallback et removeMediaStateLister dans le nettoyage onDestroy existant de l'Activity. Ajoutez une protection contre les captures en attente et un délai d'expiration avant de connecter la voix, afin que des événements répétés ne puissent pas produire de captures en double.
• Choisissez un stockage sûr. La démo utilise le stockage partagé, ce qui peut exposer les photos de test à d'autres logiciels de l'appareil. Validez avec Rokid l'accès au service et une conception de stockage adaptée avant de traiter des enregistrements réels. Définissez la suppression après vérification, envoi ou annulation. Ne partez pas du principe que le service de caméra distinct du SDK peut écrire dans le répertoire privé de l'application.
Exemple multimédia entreprise : Ouvrir la source officielle
Code source caméra correspondant et imports : Ouvrir la source officielle
Autorisations d'exécution Android : Ouvrir la source officielle
Étape 6 : connecter le prototype à un processus métier
• Définissez l'enregistrement. Convenez avec le responsable du système métier de l'identifiant d'équipement, de l'identifiant d'ordre de travail, de l'identité de l'opérateur, du format de photo, du champ de note, de l'endpoint et de la taille de fichier acceptée. Utilisez un compte de test géré par l'entreprise. Un chemin de fichier local ne peut pas être envoyé au backend comme s'il s'agissait de l'image elle-même.
• Mettez en place une vérification avant l'envoi. Créez un écran de vérification présentant la photo capturée et la note finale. Ajoutez des commandes Confirmer et Annuler. Seule la commande Confirmer doit lancer l'envoi. Annuler doit effacer l'enregistrement en attente et appliquer la politique de suppression convenue.
• Précisez la requête. Implémentez l'API de l'entreprise dans l'application (téléphone ou lunettes) chargée de l'envoi. Envoyez les octets de la photo avec les métadonnées et l'authentification convenues. Utilisez une opération réseau en arrière-plan, un identifiant de soumission unique et un nombre limité de nouvelles tentatives. Conservez les identifiants à longue durée de vie sur le backend ; déterminez avec le service informatique le flux d'authentification client pris en charge.
• Affichez le bon état. Utilisez les états Ready, Capturing, Captured, Review, Uploading, Saved et Retry. Ne passez à Saved qu'après une réponse réussie du serveur contenant un identifiant d'enregistrement. Le code d'exemple de ce tutoriel s'arrête à la capture locale et à la collecte de notes ; l'envoi nécessite votre contrat d'API et votre implémentation réels.
Étape 7 : vérifier sur le matériel entreprise
• Compilez et exécutez. Depuis le répertoire glassdemo, utilisez la commande ci-dessous, ou la commande Run d'Android Studio avec les lunettes prises en charge sélectionnées. Sous Windows, utilisez gradlew.bat assembleDebug. Corrigez les erreurs Gradle avant les tests sur l'appareil ; un émulateur Android standard ne permet pas de valider les services de l'appareil Rokid.
./gradlew assembleDebug
• Testez la capture et le nettoyage. Sélectionnez la commande de capture. Vérifiez le fichier produit, la lisibilité du statut, le chemin d'erreur de la caméra et le refus d'autorisation. Quittez puis rouvrez l'écran, et vérifiez que les callbacks sont retirés puis réattachés sans résultats en double. Confirmez que le voyant de la caméra reste allumé pendant la capture.
• Testez la voix séparément. Dictez une courte note de test, vérifiez le texte final et annulez. Recommencez dans un bruit ambiant représentatif du lieu de travail et dans chaque langue approuvée. Si vous ajoutez des commandes, testez des paroles sans rapport et des énoncés répétés face à la protection contre les captures en double.
• Testez la version intégrée. Une fois l'envoi implémenté, testez les déconnexions, les délais d'expiration, les accès révoqués et les confirmations répétées. Vérifiez qu'une requête échouée n'affiche pas Saved et qu'une nouvelle tentative pour la même soumission ne crée pas d'enregistrement supplémentaire.
Étape 8 : packager et déployer via le canal professionnel
• Préparez une version de production. Remplacez l'habillage de démonstration et supprimez les fonctionnalités d'exemple sans rapport ainsi que les identifiants de test. Examinez avec Rokid les conditions de réutilisation du SDK et des exemples. Utilisez un nom de package, un versionnage et des identifiants de signature contrôlés par l'entreprise.
• Générez un APK signé. Dans Android Studio, ouvrez Build > Generate Signed Bundle / APK, choisissez APK, sélectionnez le keystore de l'entreprise et compilez la variante release. Conservez la clé de signature en lieu sûr : les mises à jour ultérieures devront utiliser la bonne identité de signature.
• Confirmez l'installation privée. Utilisez la méthode d'installation et de gestion des applications que Rokid confirme pour votre firmware entreprise. Obtenez la méthode de distribution d'APK prise en charge, le provisionnement des comptes et la procédure de mise à jour/retour arrière. Ne partez pas du principe qu'un logiciel générique de gestion d'appareils Android prend en charge ce modèle de lunettes.
• Menez un pilote et testez à nouveau. Déployez auprès d'un petit groupe géré, mesurez la qualité de capture, la précision de la reconnaissance et le temps de réponse, puis testez à nouveau après toute modification du SDK ou du firmware. Consignez les versions des builds et conservez un package de retour arrière fonctionnel avant d'étendre le déploiement.
Signature des applications Android : Ouvrir la source officielle
Erreurs courantes à éviter
• Considérer un nom de produit comme une preuve de compatibilité. Vérifiez le firmware entreprise réel et la version du SDK prise en charge avant l'implémentation.
• Déployer la démo sans modification. L'exemple sert à démontrer des fonctionnalités. Son stockage multimédia partagé, ses exemples de phrases et ses fonctionnalités sans rapport doivent être revus avant un déploiement en entreprise.
• Confondre capture et enregistrement. Une photo locale et une transcription ne constituent pas un ordre de travail enregistré. Confirmez l'enregistrement côté backend avant d'afficher un succès.
Conclusion
Une application professionnelle Rokid utile repose d'abord sur un matériel entreprise et un accès au SDK confirmés, une démo Android fonctionnelle et un flux restreint de capture et de vérification. Les développeurs y ajoutent ensuite un retour visuel clair, une saisie vocale validée et l'intégration authentifiée au backend de l'entreprise. Les tests sur l'appareil cible et le déploiement via le canal professionnel pris en charge transforment le prototype en un outil capable d'améliorer la documentation terrain et de réduire la saisie manuelle.
