androidengineers.Book a session

Context and notification triage

Build context-aware notification triage

article2–3 hours

Start with a synthetic inbox

Create three fictional notifications: a meeting update, a promotional offer and a request to call back. Add explicit fixture controls for headphones connected, device locked and read-aloud enabled. Label these as simulated signals. This lets you debug routing without collecting another application's content.

Use SHOW_IN_APP, READ_ALOUD, ASK_USER and IGNORE. SHOW_IN_APP adds an entry to the lab inbox. IGNORE leaves the source notification alone. Keep dismissing, replying to or modifying other apps' notifications outside V1.

Introduce context with provenance

Each context snapshot needs a capture timestamp, source and availability state. Unknown is not false: unavailable headphone state does not establish that speakers are acceptable. An unlocked device does not establish that speaking aloud is appropriate either. Ask the user to opt into read-aloud behavior and choose acceptable output routes.

For a fictional “Call me when you have a moment,” the model may propose READ_ALOUD. If headphones disconnect while inference is running, the executor should stop that action even though the captured snapshot allowed it. Evaluate policy against current state at execution time.

Snapshot + fictional notification → candidate action
                                         ↓
Current consent + current audio route + fresh request → allow / ask / block

A product-defined freshness limit is part of your policy, not a provider feature. Choose and document it for the demo; evaluate delayed responses to see whether that choice prevents obsolete actions.

Optional real notification access

NotificationListenerService supplies notification callbacks after appropriate user-granted access. Follow its documented service declaration and connection lifecycle. Notification access is separate from ordinary notification posting permission. Account for unsupported devices, access revocation and restricted content rather than assuming every notification is readable.

Before connecting live content, explain what the app reads and what it sends to the backend. Use an app allowlist and transmit only the fields needed for the chosen experiment. Do not send authentication codes, financial messages or private conversations merely because listener access exists. Exclude them before networking, and prefer fictional inputs for public recordings. If reliable exclusion cannot be established, retain the synthetic inbox.

Consent to listener access is not blanket consent to cloud processing. Keep live access and cloud submission separately controllable. Avoid logging raw notification bodies; an inspector should use a redacted summary by default.

Practice and checkpoint

Implement the synthetic inbox with a policy gate. Test read-aloud disabled, headphones disconnected during inference, locked-device restrictions, missing context, stale results and a duplicate event. None should cause unintended speech. Revoke real listener access if you enabled it and confirm new collection stops.

Expected evidence: a table of input, captured context, candidate decision, current policy and actual action. Include one case where Jev recommends an action that the app blocks. Explain why that is correct behavior rather than a failed integration.

YOUR LEARNING JOURNEY

0 of 7 available lessons completed

Progress saved in this browser. No account needed.
Build context-aware notification triage | Jev + Android | Android Engineers