Skip to content

Local development checks

Confirm that you built the current source. Do not mistake old output behavior for new code.

Checks before and after building#

  1. Save all source and check the project directory used by the command.
  2. Run ./build.py at the complete toolkit root (py build.py on Windows) to handle both sides automatically. Add glass or web when changing only one side.
  3. Wait for the entire command to exit successfully. A generated GMP with a failed source-dependency snapshot is not a complete build.
  4. Check output paths and timestamps. Keep matching .gmp, .review.json, and .review-source.enc files together.
  5. Refresh workspace examples in Studio, or re-import the latest separately imported files. Check both selections and wait for repackaging.

Your own headers and resources#

  • External headers must be discoverable by GCC and within the declared source-collection boundary. --include-dir and --source-root address these requirements respectively.
  • Do not depend on developer-machine absolute paths, uncommitted assets, or local web servers outside the package.
  • Preserve vendor, images, and protocol files when copying Web examples. MMPKG entry must point inside the package.

Make one observable change at a time#

For example, change Breakout's paddle width from 80 to 100 or edit Hello Web's display text. Rebuild, refresh, scan, and verify the actual change instead of only the QR pattern or filename.

Where to find logs after a failure#

  1. For build failures, save the first actual terminal error and context, working directory, and command. A final “Build failed” line usually does not identify the cause.
  2. Open “Runtime Logs” in Studio and compare “Web logs” and “Glasses simulator logs” for requests and results from the same operation.
  3. Double-click “Log directory (double-click)” to open the persisted logs. In the complete toolkit, this is usually Studio/logs. If installation or environment configuration differs, use the directory opened by the button.
  4. For App failures, record the message, time, and application version. Test Apps with diagnostics enabled can open and export “Plugin diagnostic logs”. Otherwise contact test support; not every release exposes this entry.