Implement limited, opt-in/perms-protected local API to read, mark read and delete messages, send messages, and notify changes. NO internet access requested/required.

Start by reading the app's existing message-action and Settings code, then assess the proposed bound AIDL service and runtime permission; the issue names app/build.gradle.kts as the AIDL build entry point. The change is done when opt-in, permission-protected access covers the requested SMS/MMS actions and change notifications without adding networking to FM; the API boundary and security model need design first.

Checklist

• I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the request will be dismissed otherwise.
• This issue contains only one feature request.
• I have read and understood the contribution guidelines.

Feature description

An opt-in API in Fossify Messages ("FM") that lets a separate, user-approved app on the same phone do the following through FM:

- read conversations and messages
- send messages to new recipients and to groups
- mark messages read
- delete messages
- be notified of new, sent, read and deleted messages

while FM STAYS the default SMS app.

Access to the API should be off by default.

FM Settings should toggle it on/off, and list which apps can use it. Anything done through the API should work exactly like doing it in FM itself (blocked numbers, recycle bin, notifications, etc.).

Intended use: a separate app on the phone connects to my desktop over local Wi-Fi ONLY. No Google, no cloud relay, no account. FM still sends/receives everything over the phone's SIM, same as now.

Scope: SMS and MMS only. No RCS.

Why do you want this feature?

I want to read/send/manage my phone's SMS from my Linux desktop.
For user workflow here, phone-only SMS, without desktop integration is a non-starter.

Two primary, current ways to use SMS on a Linux desktop (KDE, in my case) through the phone are:

(1) Google Messages: an Electron app on the desktop wrapping Google Messages for Web. The phone has to run Google Messages.

It works, BUT it needs Google services and a Google account.

(2) KDE Connect: KDE Connect with PhoneLink on the desktop, and KDE Connect on the phone. It's Google-free, and can read/notify/send via FM (or any SMS app) on the phone.

BUT the desktop can't delete messages on the phone; deletions stay on the desktop. Afaict, KDE Connect has no packet type for deleting a message or conversation.

It's also been buggy as heck in my use.

The other options listed in #665 (tijder/SmsMatrix, beeper/android-sms, benkuly/matrix-sms-bridge, RebekkaMa/android-sms-gateway-server) all need a Matrix homeserver or some other self-hosted server in the middle.
Automatic backup (#1, suggested in #112 by @Aga-C) produces a one-way copy; it can't send, mark read or delete messages on the phone.

A separate app CAN'T fix this on its own. FM doesn't currently give other apps a way to read or send messages or to see changes. So a standalone app would either have to:

- replace FM as the default SMS app

or

- read the system message store directly, which can't mark messages read or delete them. It'd also bypass FM's blocked numbers and recycle bin.

With THIS requested API, a companion app on the phone can relay all of it to the desktop. Delete on the desktop, it's deleted on the phone, and vice versa.

I.e., the functional split is:

FM API (on the phone, no network access):
- everything in FEATURE DESCRIPTION above, off by default

Standalone companion app (on the phone, installed separately):
- all networking: discovery and the local connection to the desktop
- desktop pairing (approve/revoke)
- encryption
- relays desktop requests to the FM API, and FM's change notifications to the desktop
- syncs a desktop that was offline

Additional information

Related issues, all closed:

• #112 "Auto sync between devices."
  https://github.com/FossifyOrg/Messages/issues/112
  (closed by @Aga-C)

• #113 "Permit external access."
  https://github.com/FossifyOrg/Messages/issues/113
  (closed by @Aga-C)

• #665 "Web based Messaging"
  https://github.com/FossifyOrg/Messages/issues/665
  (closed by @naveensingh)

• Discussion 502 "Desktop browser messaging"
  https://github.com/orgs/FossifyOrg/discussions/502
  (@naveensingh said no, because it needs internet access)

THIS request adds NO internet access to FM.

It's JUST the API, and Settings control.

It adds no new library dependencies.

ALL networking stays in a separate app. User explicitly opts in to it. It remains completely separate from FM.

No separate "connected" flavor needed. There's no network code in the API, so it ships in every FM flavor.

FM's "part" would be just the local API and one Settings switch; the desktop integration itself lives entirely in the separate apps.

My initial thoughts on a stack I'd use:

FM API:
- a bound AIDL service (Android Binder IPC)
- protected by a new FM runtime permission (e.g., org.fossify.messages.permission.COMPANION_ACCESS)
(maybe, content provider + broadcasts, instead?)
- needs buildFeatures { aidl = true } in app/build.gradle.kts (AIDL is off by default since AGP 8.0)
- a "Companion app access" switch in Settings, off by default
- reuses FM's existing code for each action

Standalone Android companion app:
- Kotlin, Gradle, Jetpack Compose/Room
- NO Google Play services or Firebase
- F-Droid install compatible
- mDNS discovery and QR-code pairing
- encrypted, mutual auth for local connection to desktop

Likely candidate stack for Desktop app:
- packaged as a Flatpak
- frontend, GTK4
- backend, Rust
- connection: rustls + tokio-tungstenite
- D-Bus (Avahi discovery, notifications): zbus
- cache: rusqlite + SQLCipher
- key storage: oo7