Notification sync

Purpose

Show how the phone acquires Notification Listener privileges, narrows mirrored apps, and forwards payloads downstream; and how the glasses consume them.

Entry points

Phone:

• NotificationActivity
• MessageNotificationListenerService

Glass consumer:

• MessageReceiveActivity inside glassdemo

Platforms

• Phone + Glass

Main files

• NotificationActivity.kt
• MessageNotificationListenerService.kt
• MessageReceiveActivity.kt (glass)

Flow

1. User opens the notification settings surface.
2. Guard logic checks whether listener access is granted.
3. If not, deep-link to the OS listener approval screen.
4. Enumerate installed apps and let the user opt into mirroring.
5. Listener service receives StatusBarNotification objects and filters per policy.
6. Glass logs or renders the forwarded payload.

FAQ

Capturing vs rendering

Both are touched, but the stress test is capture + policy on the phone; the glass side is minimal on purpose.

Why permission setup often “fails”

Listener access is not a standard runtime dialog — you must enable the specific listener component and any app-level gates stored in prefs.

Caveats

• UI toggles differentiate global vs lock-screen-only policies.
• When listener access lapses, the sheet auto-routes users back to approve it again.