Review 1 of 6: Android platform feasibility

Reviewer lens: are the Android assumptions in PRD-original.md and DESIGN-DRAFT.md actually true?

Date: 2026-10-03. Method: primary sources only. That means AOSP main source pulled from android.googlesource.com, developer.android.com, Google help pages, and Google blogs. Where the only evidence was a secondary article or a search-engine summary, the item is marked so.

Legend:

• VERIFIED: a primary source says so.
• CONTRADICTED: a primary source says otherwise.
• UNVERIFIED: no primary evidence was found, so the spike must confirm it.

---

1. Google Messages notification structure (design §C)

Note on 1.3 (Person uri). The Person.setUri javadoc says: "should be specified by the String representation of a ContactsContract.Contacts#CONTENT_LOOKUP_URI … The system will also attempt to resolve mailto: and tel: schema URIs. The path part of these URIs must exist in the contacts database … or the reference will be discarded as invalid." Source: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/core/java/android/app/Person.java

What this means:

• A tel: uri is NOT evidence of a contact. It is merely a number the app supplied.
• Only a content://com.android.contacts/contacts/lookup/... uri implies a contact.
• The "discarded as invalid" step is a system ranking step. It does not strip the extra, so the listener sees whatever Google Messages put there.
• Whether Google Messages sets a uri at all is UNVERIFIED.

Note on 1.8 (lock screen). The listener post path (notifyPostedLocked / isVisibleToListener in NotificationManagerService.java) applies no keyguard or lock-screen-visibility condition. Lock-screen redaction is SystemUI-only. It uses publicVersion and the allow-secure-notifications-on-lockscreen setting, which does not reach listeners. Source: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/services/core/java/com/android/server/notification/NotificationManagerService.java. Exception: an app-level setting inside Google Messages that changes what it posts would apply. That part is UNVERIFIED.

2. Android 15 sensitive-notification (OTP) redaction (design §C, §A rule 1)

VERIFIED, but the design's understanding of it is wrong in three ways.

Sources:

• Behavior page: "Android will stop untrusted apps that implement a NotificationListenerService from reading unredacted content from notifications where an OTP has been detected. Trusted apps such as companion device manager associations are exempt." https://developer.android.com/about/versions/15/behavior-changes-all
• Code: NotificationManagerService.redactStatusBarNotification(), isAppTrustedNotificationListenerService(), and NotificationRecord.java (mSensitiveContent is set only from Adjustment.KEY_SENSITIVE_CONTENT). https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/services/core/java/com/android/server/notification/NotificationRecord.java

Who is exempt (any one of these is enough):

• Holding RECEIVE_SENSITIVE_NOTIFICATIONS, which is signature|role in core AndroidManifest.xml.
• Being platform-signed.
• Appop OP_RECEIVE_SENSITIVE_NOTIFICATIONS == allowed.
• Having a non-revoked CompanionDeviceManager association in the same user.

A sideloaded sidecar is untrusted unless Byron creates a CDM association with a real device or sets the appop over adb. Both are possible hacks. Both are rejected: redaction protects OTPs, which the PRD wants.

What the listener actually receives (redactStatusBarNotification):

• android.title becomes the app label ("Messages"). The sender name or number is gone.
• android.text becomes the localized string "Sensitive notification content hidden" (R.string.redacted_notification_message). Match on structure, not on the English text.
• The notification is cloned with cloneInto(…, heavy=false), which calls lightenPayload(). That removes every Parcelable, Parcelable[] and ArrayList extra, so these are all stripped:
• android.people.list
• android.messages
• android.messages.historic
• android.messagingUser
• the large icon
• MessagingStyle is rebuilt with a single message from an empty-named Person.
• android.subText and android.textLines are removed.
• These survive:
• The contentIntent.
• shortcutId.
• The sbn key, tag, id, channel, and postTime.
• All actions, with blank titles. RemoteInput objects are retained.
• CharSequence extras that aren't rewritten. In particular, android.conversationTitle survives if Google Messages set it, typically for groups.
• getActiveNotifications() returns the redacted form too (line ~5681).

Corrections to the design:

• R2-a. "Redacted OTP" means no sender identity, not just "no text". A redacted post can only be linked to a sender through the shortcutId or notification key seen on an earlier, unredacted post in the same conversation. Detect redaction structurally: title == app label, people list absent, single empty-sender message.
• R2-b. Redaction is device-dependent. The flag is set only by the Notification Assistant: Android System Intelligence on Pixel, possibly Samsung's own or none. On a device whose assistant doesn't emit KEY_SENSITIVE_CONTENT, the sidecar receives raw OTPs. The OTP/financial span-drop before storage (design §G) is therefore mandatory and load-bearing, not a nice-to-have. The spike must test with a real OTP on the Samsung.
• R2-c. Redaction also covers the notification update. If an existing conversation notification gets an OTP appended, the whole notification is redacted for that post, including earlier non-OTP messages in the tail. The dedupe logic must not interpret this as "messages deleted".

3. Restricted settings and sideload install path (design §C last bullet)

Note on 3.2 (ECM). The ECM service isPackageEcmGuarded() (https://android.googlesource.com/platform/packages/modules/Permission/+/refs/heads/main/service/java/com/android/ecm/EnhancedConfirmationService.java) makes these settings protected:

• OPSTR_ACCESS_NOTIFICATIONS
• BIND_ACCESSIBILITY_SERVICE
• SYSTEM_ALERT_WINDOW
• GET_USAGE_STATS
• the SMS permissions
• ROLE_SMS
• device admin

A package is always guarded if its packageSource is PACKAGE_SOURCE_LOCAL_FILE or PACKAGE_SOURCE_DOWNLOADED_FILE, i.e. a browser or file-manager install. Allow-listed installers and preinstalled installers are trusted.

Note on 3.3 (adb install). An adb install has packageSource UNSPECIFIED. The outcome then depends on getInstallingPackageName(), which is null or com.android.shell, and on the trustPackagesInstalledViaNonAllowlistedInstallers flag. The code doesn't settle it. Spike action: install the probe with adb install from the Mac, then check whether the Notification Access toggle is greyed out.

Note on 3.5 (Play Protect). Play Protect "enhanced fraud protection" automatically blocks installation of apps from "web browsers, messaging apps, or file managers" that declare RECEIVE_SMS, READ_SMS, NOTIFICATION_LISTENER or ACCESSIBILITY. It is active "in select markets", and the US is not stated. https://developers.google.com/android/play-protect/warning-dev-guidance. Never distribute the APK by browser download or by messaging it to the phone. Use adb.

Note on 3.6 (developer verification). Certified devices begin requiring developer-verified apps on 2026-09-30 in BR, ID, SG and TH, and globally in 2027. There are limited-distribution (hobbyist, ≤20 devices) accounts and a power-user "advanced flow". https://developer.android.com/developer-verification. Whether adb installs are exempt is not stated on that page. Plan for a limited-distribution account before 2027 if Byron wants this to keep working on a certified phone.

4. Firing Google Messages' contentIntent from our activity (design §D "Open conversation")

VERIFIED feasible, with a required opt-in.

https://developer.android.com/guide/components/activities/background-starts

• Sender side (Android 14+ / targetSdk 34+). We must pass ActivityOptions.makeBasic().setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE) to PendingIntent.send(...). Without it, the launch "might be blocked".
• Creator side. A creator targeting SDK 35+ no longer donates its privileges by default. The launch is ALLOWED if at least one of creator or sender delegates and currently satisfies a BAL exception. Our visible activity plus ALLOW_IF_VISIBLE is sufficient, so Google Messages need not opt in. (An earlier tool summary claimed both are needed. The verbatim text says "at least one".)
• Android 17 (API 37). IntentSender.sendIntent() requires sender opt-in. This is the same API we already use, so no change.
• Lifetime caveats.
• The PendingIntent held in our process dies with our process.
• It becomes useless if Google Messages cancels or replaces it on update, or if Google Messages is force-stopped. On Android 15 a stopped app's PendingIntents are all cancelled (same Android 15 behavior page as §2).
• Design change D5: after a restart, re-acquire it from getActiveNotifications() in onListenerConnected(). If it's gone, fall back to smsto:.
• Per the cancelNotification javadoc, if we fire a FLAG_AUTO_CANCEL contentIntent we should also call cancelNotification(key) to mimic the shade. NotificationListenerService.java: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/core/java/android/service/notification/NotificationListenerService.java

5. "Ask who this is" via ACTION_SENDTO smsto: (design §D)

6. Interruption control: cancel, snooze, importance (design §E)

Note on 6.1 (cancel and snooze).

• The javadoc frames all of these as user-initiated ("after the user dismisses…").
• Snoozed notifications re-post to everyone, including us, when the duration expires. So "snooze Likely scam" is temporary unless we re-snooze. That is a loop the user cannot see in Google Messages.
• The Play Protect guidance lists "Apps that hide or prevent notifications from other apps without a user's prior consent" as a disallowed use: https://developers.google.com/android/play-protect/warning-dev-guidance.

Note on 6.2 (importance). updateNotificationChannel(pkg, user, channel) exists on the listener, but it requires "an associated device [CDM] or be the notification assistant" (NotificationListenerService.java javadoc). BIND_NOTIFICATION_ASSISTANT_SERVICE is signature.

• Replacing the system assistant via adb shell cmd notification allow_assistant is theoretically possible. It is rejected: it would displace Android System Intelligence, and that assistant is the very component that marks OTPs sensitive (§2).

Note on 6.4 (rebind).

• The system binds the listener and rebinds it after a crash.
• requestRebind(ComponentName) is documented "after a previous call to requestUnbind". It is commonly used as a recovery poke, but it only works if access is still granted.
• If the user force-stops the app (Android 15 stopped state), we stay unbound until the app is launched.
• onListenerDisconnected() must set a persisted "disconnected since" timestamp so the UI can show "N messages may have been missed".
• Recovery: a periodic WorkManager job checks connection state and calls requestRebind.

7. Spam-filed messages and Google Messages' own protection

Note on 7.1 (spam-filed messages). The primary source only says "When Google Messages suspects a potential scam text, it will automatically move the message into your spam folder or warn you." (https://security.googleblog.com/2024/10/5-new-protections-on-google-messages.html). The "no notification for spam-folder messages" wording came from a search summary, not a primary page.

The implications are the same either way:

• The sidecar mostly sees messages Google Messages chose not to auto-spam. It will under-observe the worst scams and over-observe the ambiguous middle.
• That is fine for the product's niche. It is bad for any accuracy metric computed on "what we saw".

Note on 7.2 (Scam Detection). It is on by default as part of Spam Protection. It only applies to conversations with non-contacts. It runs in English in the US, UK and Canada, and covers SMS, MMS and RCS. https://blog.google/security/new-ai-powered-scam-detection-features/

The design claims "No single-message filter sees this" about trajectory. That is CONTRADICTED in spirit: Google already does conversation-level detection. The differentiator must be explainability + the personal context ledger + "unknown ≠ malicious" verdicts, not trajectory detection per se.

Spike action: check whether Google Messages' scam warning shows up as a notification change, e.g. an updated text or extra.

8. Work profile and Private Space

Note on 8.1 (work profile). The DevicePolicyManager.setPermittedCrossProfileNotificationListeners javadoc says "By default all packages are permitted … When zero or more packages have been added, notification listeners installed on the primary user that are not in the list … won't receive events for managed profile notifications." https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/core/java/android/app/admin/DevicePolicyManager.java

So the sidecar will receive work-profile notifications unless the employer's DPC restricts it. That is a data-minimization and possibly employer-policy problem.

• Design change D7: drop any sbn.user != Process.myUserHandle() by default.
• Filtering by package name alone is insufficient, because a work-profile Google Messages has the same package name.

9. Play Store policy (only if ever published)

VERIFIED with limits.

• I found no Notification-Listener-specific Permissions Declaration Form, so I won't claim one exists. The "Permissions and APIs that Access Sensitive Information" page (https://support.google.com/googleplay/android-developer/answer/16558241) does not mention it.
• What does apply:
• User Data policy: access must be necessary for core functionality, with prominent disclosure and consent plus a privacy policy. https://support.google.com/googleplay/android-developer/answer/10144311 and https://support.google.com/googleplay/android-developer/answer/11150561
• Data safety section declarations.
• Play Protect's guidance names acceptable NLS uses (wearable relay, focus aggregation, alternate UIs). It names unacceptable ones: reading content without explicit consent, and hiding other apps' notifications without consent. https://developers.google.com/android/play-protect/warning-dev-guidance
• A "message scam triage" use case is defensible but not on the list. The "Quiet unknowns" snooze feature is the riskiest from a policy standpoint.
• A no-INTERNET manifest is a strong review asset.

---

Design changes required

• D1. Redaction model. Replace the "completeness < 40 → Cannot assess (redacted OTP)" rule with an explicit REDACTED_BY_OS state.
• It has no sender and no text.
• Link it to a conversation via shortcutId or the notification key from a prior unredacted post.
• Detect it structurally, not with the English string.
• Never store it.
• D2. OTP scrubbing is mandatory on every device. OS redaction depends on the Notification Assistant and may not happen on Samsung. Run the detectors before any persistence or logging, the probe APK included.
• D3. Sender key. Use HMAC(normalized number) when a number is present. Otherwise use HMAC over a stable substitute, in this order:

1. contact lookup key from Person.uri
2. Person.key
3. shortcutId
4. title

Record which one was used. identity_confidence must treat "title is a name" as weak evidence of being a contact, not proof. That is UNVERIFIED until the spike: Google Messages may show caller-ID or business names for non-contacts.

• D4. "In contacts" signal. Treat only a contacts lookup URI as contact evidence. A tel: uri means "number known", nothing more. Offer optional READ_CONTACTS (PhoneLookup) as an explicit opt-in upgrade, and keep the no-contacts mode working.
• D5. Open conversation.
• PendingIntent.send() with MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE from a resumed activity.
• Re-fetch it via getActiveNotifications() after reconnect.
• Catch CanceledException and fall back to smsto:.
• Do not persist PendingIntents. That is impossible anyway.
• D6. Compose draft.
• Put both EXTRA_TEXT and sms_body.
• Prefer Google Messages explicitly if it resolves.
• Hide the action when there is no dialable number.
• Spike: verify that the body is prefilled and not sent.
• D7. Scope.
• Default filter types are conversations|alerting.
• Package allow-list in code.
• Drop other-user (work-profile) notifications.
• Onboarding copy must say the OS grants access to all notifications and that we discard non-Messages ones without reading them.
• D8. Block/report. There is no documented intent into Google Messages' block/report UI, so the draft's "deep-link the user to Google Messages' block/report" is unsupported. The realistic path is:
• open the conversation (D5) and tell the user which menu to use, or
• use TelecomManager.createManageBlockedNumbersIntent() for the system blocked-numbers screen. Spike whether Samsung honors it.
• D9. "Quiet unknowns". Ship it as experimental and off by default, and say these things plainly:
• Snooze is temporary, and re-snoozing is a hidden loop.
• If the sidecar dies, the user gets silent messages (already noted in the design).
• Alerting cannot be prevented, only replaced. Muting the Google Messages channel is the only lever, and the user must do it by hand in Settings. We cannot change another app's channel (§6.2).
• D10. Missed-window accounting. Persist the disconnect, Lockdown, and force-stop gaps, and show "may have missed messages between X and Y". Feed this into analysis_completeness at the session level.
• D11. Install path.
• Install by adb install only. Never by browser or messenger (Play Protect auto-block plus ECM).
• Document "Allow restricted settings" as a fallback.
• Register a limited-distribution developer account before global verification enforcement (2027).
• D12. Reposition the differentiator. Google Messages already does on-device conversational Scam Detection for non-contacts. Lead with explanations, the context ledger, and "unknown ≠ malicious", not trajectory detection.
• D13. No-INTERNET guarantee needs a CI check on the merged manifest. AndroidX, ML Kit and Play Services libraries can merge in INTERNET. Whether ML Kit GenAI / Gemini Nano works without INTERNET in our manifest is UNVERIFIED. It goes through AICore, but model download or feature checks may need Play Services. Spike before promising it.

What cannot be done without being the default SMS app

The same list applies to anything without READ_SMS, which the PRD forbids anyway.

1. Read message history or the full thread. You get only the MessagingStyle tail Google Messages chose to post. That excludes outbound history beyond that tail, and messages read on another device or the web before a notification was posted.
2. See messages that never notify. That covers spam-filed messages (likely), conversations the user muted or archived, messages arriving while Google Messages notifications are off, messages during Lockdown, and messages during our own downtime (unrecoverable afterwards).
3. Act before alerting. You cannot suppress, delay or re-rank Google Messages' sound or vibration before it fires. You can only snooze or cancel after the fact, or ask the user to mute the channel.
4. Block or unblock numbers programmatically. BlockedNumberContract: "Only the system, the default SMS application, and the default phone app … and carrier apps can read, and write to the blockednumber provider." https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/core/java/android/provider/BlockedNumberContract.java
5. Report spam to Google or the carrier, delete, or archive. All of these must be done by the user inside Google Messages.
6. Get attachments, RCS metadata, verified-business badges, read or delivery state, or canonical thread IDs.
7. Get the OTP / sensitive content of notifications the OS redacts. Being the default SMS app would give you the raw SMS, which is exactly what we don't want.

Caveat that strengthens the sidecar choice: even a default SMS app gets no RCS. There is no public RCS API for third-party SMS apps, so becoming default would cost Byron RCS chats entirely. Notification listening is therefore not a stopgap. It is the only way to observe RCS content at all.

Spike checklist additions (beyond PRD §6.2)

• Dump the extras keys/types only for each case below. For each one, record: Person uri scheme, whether a number is present, whether android.messages includes our own replies, shortcutId, actions count, channel id, tag/id, category.
• 1:1 SMS from a contact
• 1:1 SMS from a non-contact
• RCS
• group
• short code
• business (RBM)
• Google-Messages-flagged scam
• Send a real OTP SMS on Pixel and on Samsung, and record whether a redacted form arrived (§2).
• adb-install the probe, then check whether the Notification Access toggle is restricted (§3.3).
• Fire a stored contentIntent from a foreground activity, on the latest Android version available, with ALLOW_IF_VISIBLE.
• ACTION_SENDTO with EXTRA_TEXT vs sms_body. Check that the body is prefilled, the user still taps send, and which app opens.
• Force-stop, reboot, Samsung "sleep" the app, and Lockdown, then measure the gaps.
• Work profile: confirm that its notifications arrive and are dropped.

← Back to the proposal