On small screens, scroll tables sideways to read every column. With a keyboard, focus the table and use the arrow keys.
Identify the build
Begin with the exact hardware model and configuration, firmware version, SDK package version, application version and operating system used in the evaluation. Include accessories and a phone or network service where they affect the workflow. If a version is unknown, record it as unknown and ask for identification before treating a result as reproducible.
Request the package contents, release notes, known limitations, licence, minimal setup steps and support route. Keep a copy of the agreed evaluation conditions. A working vendor demonstration shows a result on its own setup; it does not establish that an equivalent interface is documented, licensed and available in the package your team receives.
For each capability, record one of four evidence states: demonstrated on an identified build; available through the delivered documented interface; planned but not delivered; or not yet established. Do not silently turn a roadmap item into a contractual dependency.
Map required interfaces
Translate the application into operations before comparing feature lists. The eight rows below are buyer requirements and evidence requests. They do not state that every SmartXY platform supports the listed interfaces.
| Interface | What the buyer needs | Evidence to request |
|---|---|---|
| Audio recording | Access to required microphone data, format, channels and recording controls. | Documented input path; a captured file or buffer from the evaluation app; permission and interruption behavior. |
| Still photography | A trigger, image result and the metadata needed by the application. | Supported call or event, sample output, timestamp meaning, transfer method and failure reporting. |
| Real-time streaming | Continuous frames or audio with the required destination, transport and lifecycle controls. | Released interface and build; receiver example; measured workload conditions; reconnection and stop behavior. A recorded video or demonstration alone is insufficient. |
| Device events | Button, touch, connection, status or other task-relevant event notifications. | Event definitions, ordering, subscription example and behavior when the app or connection restarts. |
| OTA and recovery | An agreed update route, ownership, failure handling and supported versions. | Update procedure, package-verification process, interrupted-update recovery plan and responsibility for release approval. |
| Network and connection | The required Wi-Fi, Bluetooth or phone-mediated path and authentication model. | Supported path on the selected build; setup steps; disconnect/reconnect cases; service and phone dependencies. |
| Data export | Files or records in a usable format, with access controls and the required completeness. | Export sample, format definition, timestamps, transfer verification, retention/deletion behavior and error handling. |
| Device and output controls | Required camera, audio, display or device-state commands without assuming all outputs exist. | Documented command surface, parameter limits, acknowledgement, permissions and behavior for unsupported commands. |
Add a project column to your internal worksheet for the owner, evidence link, result and gap. Mark “not applicable” when the platform has no relevant hardware; for example, a camera requirement cannot be satisfied by a camera-free display product without changing the system scope.
Test capture and delivery
Exercise an entire task: start the operation, collect the required data, transfer it to the intended application or endpoint, confirm it is usable, and stop or release resources. Record where each step occurs. File capture, file transfer, preview, continuous streaming and third-party broadcasting are different paths with different evidence needs.
Use the intended receiver, payload and permissions in the evaluation. Check whether an application can identify incomplete data, distinguish a timeout from an empty result, and relate data to the correct task. A successful connection is not proof of complete delivery, and an isolated camera specification does not establish OCR performance for your images.
C100 is a scope example, not a template for all platforms: Android applications can run on the glasses, while direct Wi-Fi and BLE through a phone application are distinct connectivity paths. Connected cloud or private services perform model inference. Verify the actual path required by your application and its available interfaces on the supplied build. Do not infer a released camera-stream API from a demonstration; check its current release status on the C100 page and in the delivered package.
Check failure and recovery
Define repeatable failure cases alongside the normal workflow: a lost connection, a restarted phone application, an unavailable endpoint, insufficient storage, revoked permission or a low-battery stop. Use only the cases relevant and safe for the evaluation configuration. Agree disruptive or firmware-recovery tests with the responsible technical team before running them.
Record what the user sees, which data is retained, whether the application knows the task failed, and how it returns to a usable state. Repeat a request only when its retry behavior is understood; a duplicated capture or upload can be as problematic as a missing result. Ask what logs can be collected without exposing customer data or credentials.
Separate issues in the device interface, your application and the connected service. A concise support report contains the build identifiers, minimal reproduction steps, expected result, actual result and permitted diagnostic evidence. It should not include unrelated personal data, customer recordings or secrets.
Review licensing and maintenance
SDK access, a companion application, firmware modification and source-code rights are separate deliverables. Check allowed evaluation and commercial use, redistribution, third-party components and any restrictions on transfer to another engineering partner. Ask who maintains compatibility when an operating system, device build or remote service changes.
For C100, the unchanged standard Android SDK and Demo are available free for customer evaluation and self-development. The existing policy treats SDK modifications, feature changes and special requirements as paid development, with NRE starting at USD 3,000, payable before modification work begins; the final fee depends on agreed scope. That is a development-service fee, not a hardware price. No iOS SDK or Demo is provided, including for paid requests. Use the independent free standard-package request without a paid project brief.
Before placing a dependency in your delivery plan, agree supported versions, how releases are communicated, defect ownership, support boundaries and the procedure for a required change. Do not assume an SDK licence includes full firmware or application source.
Record gaps before quoting changes
Summarize the evaluation as requirements, evidence and gaps. A useful gap statement is specific: which operation is missing, which build was tested, what your application requires, and the evidence that would close the gap. “Improve AI” or “enable live video” is too broad to define a change request.
- Already delivered: identify the documented interface and the successful application-level check.
- Configuration question: identify a dependency or setting that still needs confirmation.
- New development: specify the requested change, owner, test and intended supported versions.
- Outside scope: record unavailable hardware, excluded platforms or services that need a different architecture.
Use these findings to compare standard access, customer-owned development and supplier modification work. The result should be an agreed scope with acceptance conditions, not a promise inferred from a feature list. Continue with the ODM manufacturing guide when the gap changes hardware, certification, production or support responsibilities.
Questions buyers ask
Does a working demo prove that an SDK interface is available?
No. Identify the build and distinguish demonstration behavior from a documented, delivered and licensed interface that your application can use.
Does SDK access include source code?
Not automatically. SDK binaries, samples, phone applications, firmware changes and source licences are separate deliverables that must be identified in the agreed scope.
Can a recorded video demonstrate a live-streaming API?
It demonstrates recording or playback on that setup. Continuous stream access needs its own released interface, transport, receiver workflow and recovery evidence.
Must I fund a custom project to request the standard C100 Android SDK?
No. The unchanged standard Android SDK and Demo have a separate free request route. Changes are paid development under the current C100 policy; no iOS SDK or Demo is offered.
Sources and scope
This is SmartXY's buyer-planning guidance. Platform statements refer to the linked public pages and their stated conditions; they are not independent test certification. Requirements, proposed tests and blank templates are not completed project evidence. Configuration-specific facts and current package availability must be confirmed for the project.
Define your next evaluation
Share the intended task, preferred platform and the decisions your team needs evidence to make. Product access, engineering work, pricing and delivery remain subject to the agreed configuration and commercial scope.