Application basics
Define the app identity, runtime entry point, capability declarations, pairing and build artifacts before moving on to the relevant development guide.
Application basics#
An application consists of runtime components, resources, identity, and protocols. GMP and MMPKG each use their own manifest and entry point. Studio packages the current selection into one ZIP.
| What to define | Glasses C project | Phone Web project |
|---|---|---|
| Application identity and version | id, name, numeric version, and abi_version in the manifest. | id, name, and string version in the manifest, plus the Bridge and permission formats. |
| Runtime entry point | Exported gm_plugin_entry and descriptor lifecycle callbacks. | manifest.entry points to HTML inside the package. After loading the SDK, the page first completes gm.ready(). |
| Capabilities and authorization | Host capability bits, function pointers, table size, and ABI checks. | manifest.permissions object list, user authorization, and runtime.getCapabilities(). |
| Pairing | Declare pairing protocols and their versions. | deviceRequirements specifies the required GMP, version, and protocol requirements. |
| Build outputs | GMP and its matching build attachments. | MMPKG with complete static pages and resources. |
Your first glasses C plugin: understand these constraints#
The glasses Host loads and calls the GMP. For your first plugin, keep the entry point and cleanup logic from My Glass or an official example. Start by changing UI text and one button behavior, then add functionality gradually. Give these constraints to your AI coding assistant as well.
| Your task | Current SDK approach |
|---|---|
| Set the program entry point | Export gm_plugin_entry, check the Host ABI, table size, capability bits, and function pointers, then fill in the lifecycle callbacks. Do not allocate memory or create UI in the entry point. You do not need main(). |
| Create and update UI | Create UI in on_start and update it in callbacks such as on_event / on_loop. The display root is not yet available in on_load. Use the public LVGL function table; do not link directly to the firmware's LVGL library. |
| Allocate memory and handle strings | Use host->alloc / host->free for dynamic memory. For services such as memcpy and snprintf, obtain and check the extension table with gm_plugin_libc_get(), then call libc->memcpy / libc->snprintf. Do not assume ordinary C library calls will link successfully. |
| Keep ticking or waiting for input | Advance incrementally through on_loop, events, and state variables. Callbacks run serially on the display task: do not sleep, busy-wait, or create infinite loops. Do not use private firmware FreeRTOS APIs directly. |
| Save messages and state | Borrowed event data is valid only during the current callback. Copy it into memory you manage if you need it later. Global variables are lost when the plugin unloads. Persistent configuration can be managed by the companion phone Web page. |
| Stopping and releasing resources | Clean up in on_stop / on_unload according to each resource's lifecycle stage, including partially created resources after startup failure. Do not delete the Host-provided root object; clean up only the children you created. Return from the callback promptly after calling app_exit. |