Device testing
Use the same complete Studio-generated ZIP to walk through the full user workflow on the target App and glasses.
Basic functionality#
- Sign in to MemoMind App with the application's owning developer account, scan the Studio QR code, and check the application name and version.
- After authorization, confirm glasses startup. If Web is included, verify page loading and interaction with the glasses.
- Run each core feature and record its inputs and actual results.
- Stop and start again. Reboot and reconnect the glasses, then start again from the local entry.
- Keep the current Studio combination, scan and download the same ZIP again, and verify installation and runtime.
Packages, permissions and platform boundaries#
| Checkpoint | Suggested test | Completion criteria |
|---|---|---|
| Package and version consistency | Check the App's name/version, Studio selection, and current ZIP. For paired applications, verify that both phone and glasses components come from the same build. | The physical device runs the current version, without stale cache or a one-sided update. |
| Account and application ownership | On the same LAN, scan the same Studio QR code with both the owning account and another developer account. Switch accounts and check saved entries. | Only the owning account can open, save, and start the application. LAN reachability grants no access to other accounts, and switching accounts does not transfer saved applications. |
| Interrupted download or installation | Interrupt network or Bluetooth during QR download, file validation, and Bluetooth installation separately, then reconnect and retry. | Failures are not shown as running. Retry completes installation and lets you verify the actual running version. |
| Minimum permissions | Compare manifest declarations, page prompts, and actual calls. Deny or revoke permissions, then retry the corresponding feature. | Request only permissions actually used. Do not continue access without authorization; explain which features are affected. |
| Data, credentials, and logs | Inspect debug logs, errors, local saved content, and test network requests on success and failure paths. | Do not output access tokens, passwords, real user data, or complete user files. Data destinations must match the feature description. |
| Start and Load | Repeat cold starts, starts after stopping, and glasses reconnections. For Web applications, also test ready, entry-file, and asset-loading failures. | No persistent blank/black screen or endless loading. Failures provide actionable recovery instructions. |
| System resource recovery | While using recording, playback, location, system display, or event listeners, test exit, disconnection, and forced stop. Then test the original system features and restart the application. | Release only the application's own resources. Leave no listeners or altered system state, and allow system features to work again. |
| Compatibility and fallbacks | Test target App, firmware, and device combinations, including missing Host APIs, permissions, or hardware capabilities. | Clearly report unsupported functionality and stop safely. Do not crash, hang, or report unexecuted work as successful. |
| External service boundaries | Simulate disconnection, timeout, expired authentication, error responses, empty results, and user cancellation, then retry. | No unbounded retries or duplicated business operations. Errors are recoverable and usable local features remain available. |
| Audio resource contention | Start application capture while system recording or another voice feature is active. Test capture interruption, exit, and restart. | Report busy resources clearly without forcibly preempting them. After stopping, both system audio and application capture work again. |
Failure and recovery#
| Scenario | Suggested test | Completion criteria |
|---|---|---|
| Initial authorization and denial | Deny a required permission first, then let the user authorize it again. | Explain the impact without repeated prompts. After authorization, provide clear steps to continue. |
| Interruption on either side | Test Bluetooth disconnection, glasses-plugin exit, and phone-page stop separately during runtime. | The other side must not show unconfirmed success or endless progress. Provide recovery or restart. |
| Repeat input and slow response | Click the same button rapidly, then enter more input or navigate back during processing. | Do not create duplicate pages, start duplicate recordings, or accumulate requests. |
| Backgrounding and resources | Lock the screen, switch to another App, return, then stop and restart. | No duplicate listeners. Validate recording and non-recording scenarios against their actual lifecycles. |
| File, recording, and location cancellation | Cancel file selection and stop tasks during capture or location access. Test permission denial and timeout separately. | Stopping releases resources and allows another start. Old replies must not overwrite new tasks. |
| Networks and Empty Results | Make the business service unavailable, delayed, or return empty data. | Provide timeout, cancellation, and empty states. Keep usable local functionality. |
| Languages and Displays | Test target languages, long text, and actual wear conditions. | No missing glyphs or clipped essential text. State and exit instructions are understandable. |
| Audio stream integrity | Consume data slowly to trigger the selected queue strategy, then inspect tail data after a normal stop. | Record dropped frames. Do not treat overflow or interruption as a complete recording. Allow restart after release. |
| File and saved-data boundaries | Read empty and large files, cancel reads, delete a saved fileId's file, then update the application. | Previews are size-limited, missing files can be selected again, cancellation does not hang, and migration/reset has a clear result. |
Additional checks for games and long-running applications#
- Fix the test device, firmware, application version, and duration. Record hangs, crashes, rendering backlogs, and delayed input.
- Measure business-update time and actual input-to-display latency. Record device state, power consumption, and temperature rise using available test methods. Do not invent temperature readings from a plugin without such an API.
- Test continuous input, system suspend/resume, and exit separately. After reducing graphics complexity or refresh frequency, confirm interaction and stop still work.
- Finally, scan and retest the same complete ZIP. Simulator FPS or another debug package's results do not establish this version's physical-device behavior.
Flash cache and transfer regression checks#
- Start after first import and check both component versions and the complete runtime result. Stop and restart the same package; confirm a cache hit with no GMP data retransmission.
- Keep the package unchanged, reboot the glasses, and start again. After updating, verify new content. A changed package digest must not reuse stale cache even if the business version is unchanged.
- Disconnect/reboot during reception, decompression, Flash writing, and commit. Retry must resume from a valid persisted offset or retransmit according to the error type. Never run an incomplete package.
- Install and alternate between several external plugins. Verify least-recently-used eviction and early insufficient-space reporting. If a same-name update is interrupted, the old complete version remains valid.
- Repeatedly start, stop, and switch plugins. Distinguish loaded memory retained on stop from leftovers after unload. Record system free memory and its low-water mark, not only Studio Peak.
- Complete a normal firmware OTA using matching versions, then verify the first necessary plugin retransmission and subsequent cache hits. Also regression-test existing recording, teleprompter, translation, navigation, and lyrics features.
Record reproducible results#
Record ZIP filename, SDK/Studio/App/firmware versions, phone OS, steps, and errors. Retest with the same package and records; do not mix another version's screenshots or steps.