Executive summary
Rokid AI Glasses app development for business starts with Rokid’s Sprite Enterprise SDK documentation and its Android demo. The enterprise FAQ directs enterprise firmware to Rokid AI Enterprise or the enterprise demo. Android Studio is the coding workspace; the Glasses SDK exposes device capabilities, and the Phone SDK supports the paired Android application.
Compatibility comes first. These public instructions target Rokid Glass3 Enterprise. A sales label such as “Rokid Enterprise RV101” does not by itself establish SDK compatibility. Obtain written confirmation for your exact hardware, firmware, region and commercial SDK rights before following the integration steps. If Rokid supplies a different enterprise SDK for your device, use that package and its matching samples.
The tutorial extends the official enterprise demo to capture one photo, show a status and test dictated notes. It is a development prototype. Uploading a business record and managing a fleet require your company’s backend and a separately confirmed enterprise distribution method.
Enterprise SDK documentation: Open official source
Why build a custom app for Rokid AI Glasses
A custom application can connect field inspections, maintenance or warehouse checks to the information a company actually needs. A short display prompt tells the worker what to do, a camera captures evidence, and speech input can reduce typing during suitable tasks.
The useful result is a reliable business record, with the correct asset or work-order ID and a clear saved status. Build the smallest capture-and-review workflow first, then connect it to the operational system after hardware behavior and data handling have been tested.
Choose the enterprise components
Android Studio, JDK and Gradle:
- Role: Edit, compile and debug Android projects.
- Business requirement: Use a managed developer workstation and the approved project toolchain.
Sprite Enterprise Glasses SDK:
- Role: Camera, speech, display-related application logic and device services.
- Business requirement: Requires supported enterprise hardware and firmware; confirm commercial terms.
Sprite Enterprise Phone SDK:
- Role: Pairing, messaging and media exchange with an Android phone.
- Business requirement: Use when your architecture includes a company-managed phone.
Rokid AI Enterprise or enterprise demo:
- Role: Enterprise connection and development testing.
- Business requirement: Obtain the appropriate build and accounts through the enterprise channel.
Company backend:
- Role: Authentication and storage of business records.
- Business requirement: Use approved endpoints, access controls and retention rules.
What you need before starting
Prepare the supported enterprise glasses, a Glass3 data debug cable, an Android test phone, Android Studio, JDK 17, Git and the SDK demo. Git downloads source code; Gradle builds it; an APK is the Android installation file. Use the versions in the approved demo configuration. Rokid’s Quick Start and FAQ differ on minimum Android versions, so confirm the requirement against your supplied package rather than choosing the lower value.
Step 1: confirm the enterprise device and access
• Record the target. On the glasses, open Settings and record the model, system version and serial number. Ask Rokid to confirm that this build supports the Sprite Enterprise SDK and the camera and speech services required here.
• Obtain the enterprise package. Request Rokid AI Enterprise or the enterprise demo, the matching SDK release and business credentials from your supplier or Rokid contact. Confirm commercial development and deployment rights; a public download alone does not settle licensing.
• Prepare the connection. Charge the devices and connect the glasses to the workstation with the data debug cable. Use the enterprise onboarding instructions supplied for your build to prepare the managed phone and glasses.
• Agree the data flow. Decide where photos and dictated notes may be processed and stored. Use a company test environment and non-sensitive test material while validating the demo.
Enterprise system and app requirements: Open official source
Step 2: open and run the enterprise Android demo
• Download the source. In a terminal on the developer workstation, run the command below. Save the checkout in your team’s normal development folder and record its commit with git rev-parse HEAD.
git clone https://github.com/RokidSuuport/glass3_sdk_demo.git
• Open the projects. In Android Studio, choose File > Open and select glass3_sdk_demo/glassdemo. Open glass3sdkphonedemo separately for the phone. Wait for Gradle sync, then select JDK 17 in Settings > Build, Execution, Deployment > Build Tools > Gradle.
• Check the dependencies. In the Project pane, open settings.gradle and app/build.gradle in each project. Keep the demo’s working configuration. For a separate Groovy-based project, merge these repository and dependency entries into the existing blocks; do not create duplicate blocks. The published Quick Start lists 2.2.0-E, but use the version approved for your firmware.
// settings.gradle, inside dependencyResolutionManagement {
repositories { maven { url 'https://maven.rokid.com/repository/maven-public/' }
}
}
// Glasses app: app/build.gradle, inside dependencies dependencies {
implementation('com.rokid.security:glass3.open.sdk:2.2.0-E') {
exclude group: 'org.slf4j'
}
}
// Phone app only: app/build.gradle, inside dependencies dependencies {
implementation('com.rokid.security:phone.sdk:2.2.0-E') {
exclude group: 'org.slf4j'
}
}
• Configure and launch. In the phone project, open MainPhoneActivity and find UserAuthInfo. Supply the business-issued AK and SK through approved local configuration, outside version control. Before running the glasses demo, open HomeActivity.initSDK() and replace the sample call setCameraLedEnable(false) with setCameraLedEnable(true). Reboot as required by the device firmware. Run the phone app first, then select the glasses device in Android Studio and run glassdemo. Connect from the phone demo and verify SDK initialization and a text message before editing.
• Adjust the setup. The repository URL downloads the sample, not an installer. The two dependencies belong to different applications. Change versions together only after checking Rokid’s compatibility guidance; retain the demo’s initialization helpers and required imports.
Demo setup and source paths: Open official source
SDK repository and dependencies: Open official source
Step 3: make the first capture control clear
• Find the screen. In the glassdemo project, open app/src/main/java/com/rokid/glass/SdkMediaActivity.kt. Its layout file is located at app/src/main/res/layout/activity_test_media.xml. This is an existing native Android screen with camera controls, not a web page.
• Edit one button first. In that XML file, locate the existing AppCompatButton element with the ID android:id="@+id/btPhoto480P". Keep its original ID and layout constraints so the existing Kotlin view binding (binding.btPhoto480P) continues to work without breaking references.
• The original demo layout sets the button width to 50dp wide and 36dp high with a 10sp label, which will truncate the new text. Change only the attributes shown below and keep the rest of the element as it is (the background, text colour, margins and the two app: layout_constraint lines); without its constraints the button loses its place in the 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" />
• Explain the label.
• android:text="Capture": Sets the visible label displayed directly on the screen.
• android:contentDescription="Capture photo": Provides an accessibility description for screen readers and UI hierarchy inspection. Note that setting contentDescription on Rokid devices does not automatically create or register a voice command; speech control requires explicit integration with the Sprite Enterprise SDK's speech/offline-command service.
• android:textSize="16sp": Ensures readability on the monocular optical display.
• Design the working screen. For the business version, keep the interface minimal: a clear status indicator, a single primary capture button, and a defined cancel or review path. Follow Rokid's enterprise display guidance by using high-contrast text (such as readable green text overlaying real-world scenes), and avoid relying on color alone to signal errors or capture states. Always verify positioning and text truncation on the physical glasses display rather than relying solely on the Android Studio layout preview.
Enterprise display and layout guidance: Open official source
Step 4: test enterprise speech input
• Open the speech sample. In the glasses project, open app/src/main/java/com/rokid/glass/SendMessageActivity.kt. Find the R.id.btnOnlineAsr branch and the speechCallback(token) function. ASR means automatic speech recognition: it converts speech into text.
• Run one speech session. Use the enterprise demo’s ASR control to start a session. Preserve its session token and callback handling. The sample uses cloud ASR, which only works once the phone demo has initialized the SDK with your AK and SK, so confirm service entitlement, supported language, network access and business data processing terms before using worker speech.
• Keep final text separate from commands. Inside the existing onAsrComplete delivery block, handle the final text with application logic such as the example below. This is an insertion into the existing callback, not a replacement for the complete SpeechCallback implementation. It stores a note for review; it does not trigger the camera or upload.
// Add this field inside SendMessageActivity: private var pendingBusinessNote: String? = null
// Inside the existing final-result delivery block: pendingBusinessNote = content?.trim()?.takeIf { it.isNotEmpty() } // Display pendingBusinessNote in your review UI before saving.
• Add commands deliberately. For hands-free capture, use the enterprise offline-command sample or a validated final-transcript handler wired to the capture screen. Both must call the same capture function used by the visible button. Verify the language and phonetic configuration with the supplied SDK. A dictated note is free text and must not be treated as a command.
• Stop and recover. Retain the sample’s stopSpeech and session cleanup when the screen leaves the foreground. Test silence, denied microphone permission, loss of network and repeated sessions. Keep a hardware or visible-control fallback.
Enterprise ASR and offline command sample: Open official source
Step 5: add the camera handler and result feedback
• Reuse the existing initialization. Return to SdkMediaActivity.kt. Keep the demo’s SDK setup, imports and photo callback. In initView(), replace only the binding.btPhoto480P.setOnClickListener block with the call below, then add the function inside the same Activity class. This uses the existing 480P resolution enum and the demo’s shared Pictures location.
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" } }
• Show success from the callback. Find the existing mPhotoFileCallback object. Add the function below inside the Activity, then call showBusinessPhoto(path) from both onTakePhoto and onTakePhotoV2. Keep getCallbackId and the existing callback registration. In mICameraStateLister.onCameraError, update the control to “Try again” on the UI thread.
private var capturedBusinessPhoto: String? = null
private fun showBusinessPhoto(path: String) { runOnUiThread { if (!isFinishing && !isDestroyed) { capturedBusinessPhoto = path binding.btPhoto480P.text = "Captured" } } }
• Understand and customize. takePhoto requests a capture; its callback supplies the file path. Captured means a local file exists, not that a business record was saved. For this development screen, widen the button for status text. In the production screen use a separate status view. Change PhotoResolution only to values supported by your SDK and verify framing and actual output dimensions.
• Handle permissions and lifecycle. Use the demo’s permission flow before capture. Camera and microphone need manifest declarations and applicable runtime approval. Keep removePhotoCallback and removeMediaStateLister in the Activity’s existing onDestroy cleanup. Add a pending-capture guard and timeout before connecting voice, so repeated events cannot produce duplicate captures.
• Choose safe storage. The demo uses shared storage, which can expose test photos to other device software. Validate service access and a suitable storage design with Rokid before processing real records. Define deletion after review, upload or cancellation. Do not assume that the separate SDK camera service can write to the app’s private directory.
Enterprise media sample: Open official source
Matching camera source and imports: Open official source
Android runtime permissions: Open official source
Step 6: connect the prototype to a business workflow
• Define the record. Agree the asset ID, work-order ID, operator identity, photo format, note field, endpoint and accepted file size with the business-system owner. Use a company-managed test account. A local file path cannot be sent to the backend as if it were the image itself.
• Implement review before upload. Create a review screen containing the captured photo and final note. Add Confirm and Cancel controls. Only Confirm should start the upload. Cancel should clear the pending record and apply the agreed deletion policy.
• Specify the request. Implement the company’s API in the phone or glasses app that owns the upload. Send the photo bytes with the agreed metadata and authentication. Use a background network operation, a unique submission ID and bounded retries. Keep long-lived credentials on the backend; determine the supported client authentication flow with IT.
• Show the correct state. Use Ready, Capturing, Captured, Review, Uploading, Saved and Retry. Move to Saved only after a successful server response with a record ID. This tutorial’s sample code stops at local capture and note collection; the upload needs your actual API contract and implementation.
Step 7: verify on the enterprise hardware
• Build and run. From the glassdemo directory, use the command below, or Android Studio’s Run control with the supported glasses selected. On Windows use gradlew.bat assembleDebug. Resolve Gradle errors before device testing; a standard Android emulator cannot validate the Rokid device services.
./gradlew assembleDebug
• Test capture and cleanup. Select the capture control. Verify the result file, readable status, camera error path and permission denial. Leave and reopen the screen and check that callbacks are removed and reattached without duplicate results. Confirm the camera indicator remains active during capture.
• Test speech separately. Dictate a short test note, check the final text and cancel. Repeat in representative workplace noise and each approved language. If adding commands, test unrelated speech and repeated utterances against the duplicate-capture guard.
• Test the integrated build. Once upload is implemented, test disconnects, timeouts, revoked access and repeated confirmation. Check that a failed request does not show Saved and retrying the same submission does not create another record.
Step 8: package and deploy through the business channel
• Prepare a release. Replace the demonstration branding and remove unrelated sample features and test credentials. Review SDK and sample reuse terms with Rokid. Use company-controlled package naming, versioning and signing credentials.
• Build a signed APK. In Android Studio, open Build > Generate Signed Bundle / APK, choose APK, select the company keystore and build the release variant. Keep the signing key secure: later updates must use the correct signing identity.
• Confirm private installation. Use the installation and application-management route Rokid confirms for your enterprise firmware. Obtain the supported APK delivery method, account provisioning and update/rollback procedure. Do not assume that general Android device-management software supports this glasses model.
• Pilot and retest. Deploy to a small managed group, measure capture quality, recognition accuracy and response time, then retest after SDK or firmware changes. Record build versions and keep a working rollback package before expanding the rollout.
Android application signing: Open official source
Common mistakes to avoid
• Treating a product name as compatibility evidence. Check the actual enterprise firmware and supported SDK release before implementation.
• Shipping the demo unchanged. The sample demonstrates capabilities. Its shared media storage, example phrases and unrelated features need review before a business rollout.
• Confusing capture with saving. A local photo and a transcript are not a saved work order. Confirm the backend record before showing success.
Conclusion
A useful Rokid business application starts with confirmed enterprise hardware and SDK access, a working Android demo and a small capture-and-review workflow. Developers then add clear display feedback, validated speech input and the company’s authenticated backend integration. Testing on the target device and deploying through the supported business channel turn the prototype into a tool that can improve field documentation and reduce manual entry.
