Sintesi
Lo sviluppo di app aziendali per Rokid AI Glasses parte dalla documentazione di Rokid sullo Sprite Enterprise SDK e dalla relativa demo Android. Le FAQ enterprise indirizzano il firmware enterprise verso Rokid AI Enterprise o la demo enterprise. Android Studio è l'ambiente in cui si scrive il codice; il Glasses SDK espone le funzionalità del dispositivo e il Phone SDK supporta l'applicazione Android associata.
La compatibilità viene prima di tutto. Queste istruzioni pubbliche riguardano Rokid Glass3 Enterprise. Una denominazione commerciale come “Rokid Enterprise RV101” non basta di per sé a stabilire la compatibilità con l'SDK. Prima di seguire i passaggi di integrazione, ottieni una conferma scritta per il tuo specifico hardware, firmware, area geografica e diritti commerciali sull'SDK. Se Rokid fornisce un SDK enterprise diverso per il tuo dispositivo, usa quel pacchetto e gli esempi corrispondenti.
Il tutorial estende la demo enterprise ufficiale per scattare una foto, mostrare uno stato e testare note dettate. Si tratta di un prototipo di sviluppo. Il caricamento di un record aziendale e la gestione di una flotta di dispositivi richiedono il backend della tua azienda e un metodo di distribuzione enterprise confermato separatamente.
Documentazione dell'Enterprise SDK: Apri la fonte ufficiale
Perché creare un'app personalizzata per Rokid AI Glasses
Un'applicazione personalizzata può collegare ispezioni sul campo, manutenzione o controlli di magazzino alle informazioni di cui un'azienda ha effettivamente bisogno. Un breve messaggio sul display indica all'operatore cosa fare, la fotocamera acquisisce le prove e l'input vocale può ridurre la digitazione nelle attività adatte.
Il risultato utile è un record aziendale affidabile, con l'ID corretto dell'asset o dell'ordine di lavoro e uno stato di salvataggio chiaro. Crea prima il flusso di acquisizione e revisione più semplice possibile, poi collegalo al sistema gestionale dopo aver testato il comportamento dell'hardware e la gestione dei dati.
Scegli i componenti enterprise
Android Studio, JDK e Gradle:
- Ruolo: Modificare, compilare ed eseguire il debug di progetti Android.
- Requisito aziendale: Usa una workstation di sviluppo gestita e la toolchain di progetto approvata.
Sprite Enterprise Glasses SDK:
- Ruolo: Fotocamera, voce, logica applicativa legata al display e servizi del dispositivo.
- Requisito aziendale: Richiede hardware e firmware enterprise supportati; verifica le condizioni commerciali.
Sprite Enterprise Phone SDK:
- Ruolo: Associazione, messaggistica e scambio di contenuti multimediali con uno smartphone Android.
- Requisito aziendale: Da usare quando la tua architettura include uno smartphone gestito dall'azienda.
Rokid AI Enterprise o demo enterprise:
- Ruolo: Connessione enterprise e test di sviluppo.
- Requisito aziendale: Ottieni la build e gli account appropriati tramite il canale enterprise.
Backend aziendale:
- Ruolo: Autenticazione e archiviazione dei record aziendali.
- Requisito aziendale: Usa endpoint, controlli di accesso e regole di conservazione approvati.
Cosa serve prima di iniziare
Prepara gli occhiali enterprise supportati, un cavo dati di debug per Glass3, uno smartphone Android di test, Android Studio, JDK 17, Git e la demo dell'SDK. Git scarica il codice sorgente, Gradle lo compila e un APK è il file di installazione Android. Usa le versioni indicate nella configurazione approvata della demo. La Quick Start e le FAQ di Rokid riportano versioni minime di Android diverse, quindi verifica il requisito sul pacchetto che ti è stato fornito invece di scegliere il valore più basso.
Passaggio 1: conferma il dispositivo enterprise e l'accesso
• Registra il dispositivo di destinazione. Sugli occhiali, apri Impostazioni e annota modello, versione di sistema e numero di serie. Chiedi a Rokid di confermare che questa build supporta lo Sprite Enterprise SDK e i servizi di fotocamera e voce necessari in questo caso.
• Ottieni il pacchetto enterprise. Richiedi Rokid AI Enterprise o la demo enterprise, la release dell'SDK corrispondente e le credenziali aziendali al tuo fornitore o referente Rokid. Verifica i diritti di sviluppo e distribuzione commerciale: un download pubblico, da solo, non risolve la questione delle licenze.
• Prepara la connessione. Ricarica i dispositivi e collega gli occhiali alla workstation con il cavo dati di debug. Segui le istruzioni di onboarding enterprise fornite per la tua build per preparare lo smartphone gestito e gli occhiali.
• Concorda il flusso dei dati. Decidi dove possono essere elaborate e archiviate le foto e le note dettate. Durante la convalida della demo, usa un ambiente di test aziendale e materiale di prova non sensibile.
Requisiti di sistema e app enterprise: Apri la fonte ufficiale
Passaggio 2: apri ed esegui la demo Android enterprise
• Scarica il codice sorgente. In un terminale sulla workstation di sviluppo, esegui il comando riportato sotto. Salva il checkout nella normale cartella di sviluppo del tuo team e registra il relativo commit con git rev-parse HEAD.
git clone https://github.com/RokidSuuport/glass3_sdk_demo.git
• Apri i progetti. In Android Studio, scegli File > Open e seleziona glass3_sdk_demo/glassdemo. Apri separatamente glass3sdkphonedemo per lo smartphone. Attendi la sincronizzazione di Gradle, quindi seleziona JDK 17 in Settings > Build, Execution, Deployment > Build Tools > Gradle.
• Controlla le dipendenze. Nel pannello Project, apri settings.gradle e app/build.gradle in ciascun progetto. Mantieni la configurazione funzionante della demo. Per un progetto separato basato su Groovy, unisci queste voci di repository e dipendenze nei blocchi esistenti, senza creare blocchi duplicati. La Quick Start pubblicata indica 2.2.0-E, ma usa la versione approvata per il tuo firmware.
// settings.gradle, all'interno di dependencyResolutionManagement {
repositories { maven { url 'https://maven.rokid.com/repository/maven-public/' }
}
}
// App per occhiali: app/build.gradle, all'interno di dependencies dependencies {
implementation('com.rokid.security:glass3.open.sdk:2.2.0-E') {
exclude group: 'org.slf4j'
}
}
// Solo app per smartphone: app/build.gradle, all'interno di dependencies dependencies {
implementation('com.rokid.security:phone.sdk:2.2.0-E') {
exclude group: 'org.slf4j'
}
}
• Configura e avvia. Nel progetto per smartphone, apri MainPhoneActivity e individua UserAuthInfo. Fornisci AK e SK rilasciati per uso aziendale tramite una configurazione locale approvata, al di fuori del controllo di versione. Prima di eseguire la demo per gli occhiali, apri HomeActivity.initSDK() e sostituisci la chiamata di esempio setCameraLedEnable(false) con setCameraLedEnable(true). Riavvia se richiesto dal firmware del dispositivo. Esegui prima l'app per smartphone, poi seleziona il dispositivo occhiali in Android Studio ed esegui glassdemo. Connettiti dalla demo per smartphone e verifica l'inizializzazione dell'SDK e l'invio di un messaggio di testo prima di apportare modifiche.
• Adatta la configurazione. L'URL del repository scarica l'esempio, non un programma di installazione. Le due dipendenze appartengono ad applicazioni diverse. Modifica le versioni insieme solo dopo aver consultato le indicazioni di compatibilità di Rokid; mantieni gli helper di inizializzazione della demo e gli import necessari.
Configurazione della demo e percorsi del codice sorgente: Apri la fonte ufficiale
Repository e dipendenze dell'SDK: Apri la fonte ufficiale
Passaggio 3: rendi chiaro il primo comando di acquisizione
• Individua la schermata. Nel progetto glassdemo, apri app/src/main/java/com/rokid/glass/SdkMediaActivity.kt. Il relativo file di layout si trova in app/src/main/res/layout/activity_test_media.xml. Si tratta di una schermata Android nativa già esistente con i controlli della fotocamera, non di una pagina web.
• Modifica prima un solo pulsante. In quel file XML, individua l'elemento AppCompatButton esistente con l'ID android:id="@+id/btPhoto480P". Mantieni l'ID originale e i vincoli di layout, in modo che il view binding Kotlin esistente (binding.btPhoto480P) continui a funzionare senza interrompere i riferimenti.
• Il layout originale della demo imposta il pulsante a 50dp di larghezza e 36dp di altezza con un'etichetta da 10sp, il che troncherebbe il nuovo testo. Modifica solo gli attributi riportati sotto e lascia invariato il resto dell'elemento (sfondo, colore del testo, margini e le due righe app: layout_constraint); senza i suoi vincoli il pulsante perde la propria posizione nel 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" />
• Spiega l'etichetta.
• android:text="Capture": Imposta l'etichetta visibile mostrata direttamente sullo schermo.
• android:contentDescription="Capture photo": Fornisce una descrizione di accessibilità per gli screen reader e per l'ispezione della gerarchia dell'interfaccia. Tieni presente che impostare contentDescription sui dispositivi Rokid non crea né registra automaticamente un comando vocale: il controllo vocale richiede un'integrazione esplicita con il servizio voce/comandi offline dello Sprite Enterprise SDK.
• android:textSize="16sp": Garantisce la leggibilità sul display ottico monoculare.
• Progetta la schermata operativa. Per la versione aziendale, mantieni l'interfaccia essenziale: un indicatore di stato chiaro, un unico pulsante principale di acquisizione e un percorso definito per annullare o rivedere. Segui le linee guida di Rokid per i display enterprise usando testo ad alto contrasto (ad esempio testo verde leggibile sovrapposto alla scena reale) ed evita di affidarti solo al colore per segnalare errori o stati di acquisizione. Verifica sempre posizionamento e troncamento del testo sul display fisico degli occhiali, invece di basarti esclusivamente sull'anteprima del layout di Android Studio.
Linee guida per display e layout enterprise: Apri la fonte ufficiale
Passaggio 4: testa l'input vocale enterprise
• Apri l'esempio vocale. Nel progetto per gli occhiali, apri app/src/main/java/com/rokid/glass/SendMessageActivity.kt. Individua il ramo R.id.btnOnlineAsr e la funzione speechCallback(token). ASR sta per automatic speech recognition (riconoscimento vocale automatico): converte il parlato in testo.
• Esegui una sessione vocale. Usa il controllo ASR della demo enterprise per avviare una sessione. Mantieni la gestione del token di sessione e della callback. L'esempio usa l'ASR in cloud, che funziona solo dopo che la demo per smartphone ha inizializzato l'SDK con i tuoi AK e SK; verifica quindi il diritto di accesso al servizio, la lingua supportata, l'accesso alla rete e le condizioni di trattamento dei dati aziendali prima di usare la voce degli operatori.
• Tieni separato il testo finale dai comandi. All'interno del blocco di consegna onAsrComplete esistente, gestisci il testo finale con una logica applicativa come quella dell'esempio seguente. Si tratta di un'aggiunta alla callback esistente, non di una sostituzione dell'intera implementazione di SpeechCallback. Il codice memorizza una nota da rivedere; non attiva la fotocamera né il caricamento.
// Aggiungi questo campo all'interno di SendMessageActivity: private var pendingBusinessNote: String? = null
// All'interno del blocco esistente di consegna del risultato finale: pendingBusinessNote = content?.trim()?.takeIf { it.isNotEmpty() } // Mostra pendingBusinessNote nell'interfaccia di revisione prima del salvataggio.
• Aggiungi i comandi in modo ponderato. Per l'acquisizione a mani libere, usa l'esempio di comandi offline enterprise oppure un gestore della trascrizione finale convalidato e collegato alla schermata di acquisizione. Entrambi devono richiamare la stessa funzione di acquisizione usata dal pulsante visibile. Verifica la configurazione della lingua e della fonetica con l'SDK fornito. Una nota dettata è testo libero e non deve essere trattata come un comando.
• Interrompi e ripristina. Mantieni stopSpeech e la pulizia della sessione previste dall'esempio quando la schermata passa in background. Testa il silenzio, il permesso del microfono negato, la perdita di rete e sessioni ripetute. Prevedi un'alternativa tramite tasto fisico o controllo visibile.
Esempio enterprise di ASR e comandi offline: Apri la fonte ufficiale
Passaggio 5: aggiungi il gestore della fotocamera e il feedback sul risultato
• Riutilizza l'inizializzazione esistente. Torna a SdkMediaActivity.kt. Mantieni la configurazione dell'SDK, gli import e la callback delle foto della demo. In initView(), sostituisci solo il blocco binding.btPhoto480P.setOnClickListener con la chiamata seguente, quindi aggiungi la funzione all'interno della stessa classe Activity. Il codice usa l'enum di risoluzione 480P esistente e la posizione condivisa Pictures della demo.
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" } }
• Mostra la riuscita dalla callback. Individua l'oggetto mPhotoFileCallback esistente. Aggiungi la funzione seguente all'interno dell'Activity, quindi richiama showBusinessPhoto(path) sia da onTakePhoto sia da onTakePhotoV2. Mantieni getCallbackId e la registrazione della callback esistente. In mICameraStateLister.onCameraError, aggiorna il controllo a “Try again” sul thread dell'interfaccia utente.
private var capturedBusinessPhoto: String? = null
private fun showBusinessPhoto(path: String) { runOnUiThread { if (!isFinishing && !isDestroyed) { capturedBusinessPhoto = path binding.btPhoto480P.text = "Captured" } } }
• Comprendi e personalizza. takePhoto richiede un'acquisizione; la sua callback fornisce il percorso del file. Captured significa che esiste un file locale, non che sia stato salvato un record aziendale. Per questa schermata di sviluppo, allarga il pulsante per far spazio al testo di stato. Nella schermata di produzione usa una vista di stato separata. Cambia PhotoResolution solo con valori supportati dal tuo SDK e verifica l'inquadratura e le dimensioni effettive dell'output.
• Gestisci permessi e ciclo di vita. Usa il flusso dei permessi della demo prima dell'acquisizione. Fotocamera e microfono richiedono dichiarazioni nel manifest e, ove applicabile, l'approvazione in fase di esecuzione. Mantieni removePhotoCallback e removeMediaStateLister nella pulizia già presente in onDestroy dell'Activity. Aggiungi una protezione contro le acquisizioni in sospeso e un timeout prima di collegare la voce, in modo che eventi ripetuti non possano generare acquisizioni duplicate.
• Scegli un'archiviazione sicura. La demo usa lo storage condiviso, che può esporre le foto di test ad altri software del dispositivo. Prima di elaborare record reali, convalida con Rokid l'accesso ai servizi e una soluzione di archiviazione adeguata. Definisci l'eliminazione dopo la revisione, il caricamento o l'annullamento. Non dare per scontato che il servizio fotocamera separato dell'SDK possa scrivere nella directory privata dell'app.
Esempio multimediale enterprise: Apri la fonte ufficiale
Codice sorgente della fotocamera e import corrispondenti: Apri la fonte ufficiale
Permessi di runtime Android: Apri la fonte ufficiale
Passaggio 6: collega il prototipo a un flusso di lavoro aziendale
• Definisci il record. Concorda con il responsabile del sistema aziendale l'ID dell'asset, l'ID dell'ordine di lavoro, l'identità dell'operatore, il formato della foto, il campo della nota, l'endpoint e la dimensione di file accettata. Usa un account di test gestito dall'azienda. Un percorso di file locale non può essere inviato al backend come se fosse l'immagine stessa.
• Implementa la revisione prima del caricamento. Crea una schermata di revisione che contenga la foto acquisita e la nota finale. Aggiungi i controlli Conferma e Annulla. Solo Conferma deve avviare il caricamento. Annulla deve cancellare il record in sospeso e applicare la politica di eliminazione concordata.
• Specifica la richiesta. Implementa l'API aziendale nell'app per smartphone o per occhiali che gestisce il caricamento. Invia i byte della foto con i metadati e l'autenticazione concordati. Usa un'operazione di rete in background, un ID di invio univoco e un numero limitato di tentativi. Mantieni le credenziali di lunga durata sul backend; definisci con l'IT il flusso di autenticazione client supportato.
• Mostra lo stato corretto. Usa Ready, Capturing, Captured, Review, Uploading, Saved e Retry. Passa a Saved solo dopo una risposta positiva del server contenente l'ID del record. Il codice di esempio di questo tutorial si ferma all'acquisizione locale e alla raccolta delle note; il caricamento richiede il tuo contratto API e la tua implementazione effettivi.
Passaggio 7: verifica sull'hardware enterprise
• Compila ed esegui. Dalla directory glassdemo, usa il comando seguente oppure il comando Run di Android Studio con gli occhiali supportati selezionati. Su Windows usa gradlew.bat assembleDebug. Risolvi gli errori di Gradle prima dei test sul dispositivo: un emulatore Android standard non può convalidare i servizi del dispositivo Rokid.
./gradlew assembleDebug
• Testa acquisizione e pulizia. Seleziona il controllo di acquisizione. Verifica il file risultante, la leggibilità dello stato, il percorso di errore della fotocamera e il rifiuto dei permessi. Esci dalla schermata e riaprila, verificando che le callback vengano rimosse e ricollegate senza risultati duplicati. Conferma che l'indicatore della fotocamera resti attivo durante l'acquisizione.
• Testa la voce separatamente. Detta una breve nota di prova, controlla il testo finale e annulla. Ripeti con un rumore rappresentativo dell'ambiente di lavoro e in ciascuna lingua approvata. Se aggiungi comandi, testa frasi non pertinenti ed enunciati ripetuti rispetto alla protezione contro le acquisizioni duplicate.
• Testa la build integrata. Una volta implementato il caricamento, testa disconnessioni, timeout, accessi revocati e conferme ripetute. Verifica che una richiesta non riuscita non mostri Saved e che ripetere lo stesso invio non crei un altro record.
Passaggio 8: crea il pacchetto e distribuisci tramite il canale aziendale
• Prepara una release. Sostituisci il branding dimostrativo e rimuovi le funzionalità di esempio non pertinenti e le credenziali di test. Verifica con Rokid le condizioni di riutilizzo dell'SDK e degli esempi. Usa nomi di pacchetto, versioni e credenziali di firma controllati dall'azienda.
• Crea un APK firmato. In Android Studio, apri Build > Generate Signed Bundle / APK, scegli APK, seleziona il keystore aziendale e compila la variante release. Conserva la chiave di firma in modo sicuro: gli aggiornamenti successivi devono usare l'identità di firma corretta.
• Conferma l'installazione privata. Usa il percorso di installazione e gestione delle applicazioni che Rokid conferma per il tuo firmware enterprise. Ottieni il metodo supportato di distribuzione dell'APK, il provisioning degli account e la procedura di aggiornamento/rollback. Non dare per scontato che un software generico di gestione dei dispositivi Android supporti questo modello di occhiali.
• Avvia un progetto pilota e ripeti i test. Distribuisci a un piccolo gruppo gestito, misura la qualità delle acquisizioni, la precisione del riconoscimento e i tempi di risposta, poi ripeti i test dopo eventuali modifiche all'SDK o al firmware. Registra le versioni delle build e conserva un pacchetto di rollback funzionante prima di estendere la distribuzione.
Firma delle applicazioni Android: Apri la fonte ufficiale
Errori comuni da evitare
• Considerare il nome di un prodotto come prova di compatibilità. Verifica il firmware enterprise effettivo e la release dell'SDK supportata prima dell'implementazione.
• Distribuire la demo senza modifiche. L'esempio serve a dimostrare le funzionalità. L'archiviazione multimediale condivisa, le frasi di esempio e le funzionalità non pertinenti vanno riviste prima di una distribuzione aziendale.
• Confondere l'acquisizione con il salvataggio. Una foto locale e una trascrizione non sono un ordine di lavoro salvato. Verifica il record sul backend prima di mostrare la riuscita.
Conclusione
Un'applicazione aziendale utile per Rokid parte da hardware enterprise e accesso all'SDK confermati, da una demo Android funzionante e da un piccolo flusso di acquisizione e revisione. Gli sviluppatori aggiungono poi un feedback chiaro sul display, un input vocale convalidato e l'integrazione con il backend autenticato dell'azienda. I test sul dispositivo di destinazione e la distribuzione tramite il canale aziendale supportato trasformano il prototipo in uno strumento in grado di migliorare la documentazione sul campo e ridurre l'inserimento manuale dei dati.
