Bug: Android app cannot access Windows desktop screen data and says there is no recorded screen when there is

[hugoaap-code]

Summary

The Android Omi app cannot see or use screen data recorded by the Windows desktop app.

When asked about it from the Android app, Omi responds as if there is no recorded screen data, even though the Windows desktop app has recorded it.

Problem

There appears to be a cross-device data visibility or sync problem.

Screen data exists from the Windows desktop app, but when interacting through the Android app, Omi answers that there is no recorded screen.

Expected behavior

If screen data was recorded by the Windows desktop app under the same account/workspace, the Android app should be able to access that data and use it in answers, memories, or context retrieval.

Actual behavior

The Android app behaves as if no screen data exists.

When asked from Android, Omi says there is no recorded screen, even though there is recorded screen data from Windows desktop.

Impact

This breaks cross-device continuity.

Users cannot rely on Android to access or reason over screen data captured on desktop, which makes the shared memory/context model unreliable.

Suggested investigation

• Check whether Windows desktop screen recordings are syncing correctly to the backend
• Check whether the Android app is querying the same data source/account scope as the desktop app
• Check whether screen data is stored but excluded from Android-side retrieval or chat context
• Check for platform-specific filtering that hides desktop screen data from mobile queries

Environment

• Omi Android app
• Omi Windows desktop app
• Same user/account context
• Observed on Monday, July 27, 2026

[tianmind-studio]

I traced this on current main. This is a missing cross-device capability rather than a failing existing sync path:

• Windows writes each captured JPEG to a local file in captureService.ts and stores the timeline in the local rewind_frames SQLite table in db.ts.
• The agent tool contract explicitly says screen-history search requires local Rewind data.
• A repository-wide search for rewind_frames / search_screen_history finds no backend or mobile consumer outside desktop/windows, so Android currently has no route from which it could retrieve this data.

Because screen history can contain highly sensitive pixels and OCR, I would avoid treating this as a routine “upload the missing table” fix. A lower-risk product path would be:

1. Add an explicit opt-in cross-device setting and retention/delete contract.
2. Phase 1: sync only redacted OCR + timestamps/app/device provenance, not raw screenshots, and expose that text to mobile retrieval.
3. Keep raw image sync as a separate decision requiring encryption, access control, quota, and deletion guarantees.
4. Make retrieval report whether results are local-only or synced, so the assistant does not claim no history when the current device simply cannot access it.

The issue is valid, but I recommend tracking it as a product/privacy architecture feature rather than a platform-specific sync regression. I can help implement the first slice once the data contract is agreed.