Simulator testing
Validate UI and logic first, then real Bluetooth, sensors, and firmware behavior through the phone.
Operate within desktop Studio#
- Import the toolkit root and select the built glasses plugin. If Web is included, select the phone plugin too and verify pairing.
- Watch the 600 × 350 virtual screen and check glasses logs for startup failures.
- Trigger the primary and navigation buttons individually. For IMU plugins, also test head-gesture input.
- Click Web page buttons and check that Web logs, GMP logs, and screen results correspond.
- Switch to another plugin and back, then repeat run/stop. Check for leftover UI and duplicate messages.
What to check in the simulator#
- GMP loading, correct Host API use, and basic memory/runtime errors.
- Web SDK handshake, message protocols, event handling, layout, and language changes.
- Packaging state matches the final selected components, and the QR code appears after packaging finishes.
What requires device testing#
- Actual brightness, optical appearance, Bluetooth interruptions, and transfer duration.
- Raw IMU and head-gesture behavior while wearing the glasses, plus the actual audio input path.
- Native phone permissions, screen lock/backgrounding, glasses firmware versions, and memory limits.
What ROM, RAM and Peak mean#
| Display | Definition |
|---|---|
| ROM | GMP Flash code/read-only segment size, not ZIP size or total Flash-partition use. |
| RAM (data + heap) | Static RAM (including BSS/GOT/pointer tables) plus current plugin heap-request bytes tracked by the simulator. |
| Peak | Static RAM plus peak tracked heap since this load. data is already included; do not add it again. |
Reference files in the toolkit#
- Studio/README.md
- GlassSDK/docs/CAPABILITY_MATRIX.md