# 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](https://gitee.com/as_pixar/glass3sdkdemo/blob/main/glass3sdkphonedemo/app/src/main/java/com/rokid/phone/notification/NotificationActivity.kt)
- [MessageNotificationListenerService.kt](https://gitee.com/as_pixar/glass3sdkdemo/blob/main/glass3sdkphonedemo/app/src/main/java/com/rokid/phone/notification/service/MessageNotificationListenerService.kt)
- [MessageReceiveActivity.kt (glass)](https://gitee.com/as_pixar/glass3sdkdemo/blob/main/glassdemo/app/src/main/java/com/rokid/glass/MessageReceiveActivity.kt)

## 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.  
