What You Already Proved
Your browser experiment already demonstrated an important flow:
Do not throw this work away. Treat it as the behavioural reference for the mobile experiments.
Two Transport Families
BLE Smart Glasses
The supplied Glasses SDK sample is an Android-native BLE project.
Available reference capabilities include:
The two supplied BLE SDK packages use the same Android AAR/sample and should be treated as one SDK reference rather than two independent platforms.
USB / UVC Smart Glasses
The supplied Camera SDK is a separate Android USB-camera route.
Its sample demonstrates:
This is a different transport, but the final application should produce the same type of Capture Event.
The Architecture to Explore
The transport may change. The application meaning should not.
A Common Capture Event
Do not let Android BLE, Android USB and iOS each invent a completely different data model.
A simple research object could look like:
{
"event_type": "glasses.photo.capture",
"transport": "ble | usb",
"device_id": "device identifier",
"captured_at": "timestamp",
"capture_intent": "human initiated",
"image_status": "local | uploaded",
"upload_status": "pending | success | failed",
"ai_status": "not_requested | processing | complete | failed"
}
Device identity is not automatically person identity. Do not add personal identity unless a real use case and authorization require it.
Priority 1 · Android BLE MVP
Use the Mac M4 as the development workstation and the available Android phone as the first physical test device.
Start from the supplied Android BLE sample rather than rewriting the vendor SDK.
Success condition:
Do not start with background services, account systems, full media synchronization or production UI.
Priority 2 · Android USB / UVC MVP
Treat USB as a second Capture Adapter. Do not merge the USB libraries into the BLE project on day one.
The experiment is successful when BLE and USB can both create the same logical Capture Event.
iOS · Do Not Port the Android AAR
The supplied SDKs are Android projects. There is no iOS framework, Swift SDK or Objective-C SDK in the provided packages.
Therefore the iOS task is initially a protocol research task, not a direct Android port.
iOS BLE research path
Some vendor BLE details may be hidden inside the Android AAR. If the required protocol cannot be recovered, record that dependency instead of guessing.
iOS USB
Treat iOS USB support as a feasibility study until an iOS-compatible vendor interface or clearly supported USB class is confirmed. The Android UVC AAR libraries cannot simply be imported into Xcode.
One Mobile App Should Not Hold the AI Secret
Do not embed production OpenAI / GPT credentials inside the Android or iOS application.
The mobile app should primarily own: device access, user action, capture, local presentation and evidence.
The Runtime should primarily own: AI credentials, external AI calls, logging and controlled data routes.
Evidence Boundary
A failed iOS connection with a clear protocol blocker is a valid research result.
Suggested Research Package
MOBILE_GLASSES/ │ ├── 01_BROWSER_BASELINE/ ├── 02_ANDROID_BLE/ ├── 03_ANDROID_USB/ ├── 04_IOS_BLE/ ├── 05_IOS_USB_FEASIBILITY/ ├── 06_CAPTURE_EVENT/ ├── 07_API_BRIDGE/ ├── 08_EVIDENCE/ └── 09_HANDOFF/
Do not mix experimental code and known-good code without labels.
Your First Research Question
Do not ask:
“Can I build an Android and iPhone glasses app?”
Ask:
“Can the same intentional glasses photo become the same Capture Event whether it arrives through Browser BLE, Android BLE, Android USB or eventually iOS?”
That question keeps the project about Reality and interoperability, not only about platforms.
Minimum Handoff
What transport did I test? What device did I use? What SDK / protocol did I use? What worked? What failed? What image/event did I capture? How was it uploaded? Did AI return a result? What evidence proves this? What remains vendor-dependent? What should the next builder test?