Skip to content
Draft
63 changes: 63 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -203,6 +203,37 @@ This mode is ideal for sending messages from a local network.
send --phones '+19162255887,+19162255888' 'Hello, doctors!'
```

6. To enqueue an MMS message using JSON (text + media metadata):

```sh
curl -X POST -u <username>:<password> \
-H "Content-Type: application/json" \
-d '{
"phoneNumbers": ["+19162255887"],
"mmsMessage": {
"text": "Hello with media",
"attachments": [
{
"mimeType": "image/jpeg",
"filename": "photo.jpg",
"data": "<base64-encoded-bytes>"
}
]
}
}' \
http://<device_local_ip>:8080/message
```

7. To enqueue an MMS message using multipart/form-data:

```sh
curl -X POST -u <username>:<password> \
-F "phoneNumbers=+19162255887" \
-F "text=Hello with image" \
-F "file=@/path/to/photo.jpg;type=image/jpeg" \
http://<device_local_ip>:8080/message
```

### Cloud Server

<div align="center">
Expand Down Expand Up @@ -264,6 +295,34 @@ Follow these steps to set up webhooks:
}
```

Incoming MMS webhooks use the `mms:received` event and include media metadata:

```json
{
"event": "mms:received",
"payload": {
"messageId": "mms_123",
"transactionId": "tx_123",
"phoneNumber": "+19162255887",
"attachments": [
{
"id": "part_1",
"mimeType": "image/jpeg",
"filename": "photo.jpg",
"size": 2048,
"width": 800,
"height": 600,
"durationMs": null,
"sha256": "<sha256>",
"downloadUrl": "/media/part_1?expires=<timestamp>&token=<signature>"
}
]
}
}
```

Use the signed `downloadUrl` path with basic auth credentials to fetch stored media.

5. To deregister a webhook, execute a `curl` request using the following pattern:

```sh
Expand All @@ -275,6 +334,10 @@ For cloud mode the process is similar, simply change the URL to https://api.sms-

*Note*: Webhooks are transmitted directly from the device; therefore, the device must have an outgoing internet connection. As the requests originate from the device, incoming messages remain inaccessible to us.

*Known MMS limitation*: MMS transmission depends on carrier APN/mobile-data configuration and OEM telephony behavior; when delivery fails, API/message states report platform MMS error codes (e.g. invalid APN, network, HTTP, or retry-required).

*Carrier troubleshooting note (Phonero / Norway / Pixel)*: if MMS delivery fails on Pixel devices, ensure mobile data is enabled for the SIM used to send messages, reset APN settings to carrier defaults, reboot the phone, and verify MMS/APN values with Phonero support (Phonero uses Telenor network infrastructure).


<p align="right">(<a href="#readme-top">back to top</a>)</p>

Expand Down
3 changes: 2 additions & 1 deletion app/build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -115,6 +115,7 @@ dependencies {
implementation 'androidx.preference:preference-ktx:1.2.1'

implementation("com.aventrix.jnanoid:jnanoid:2.0.0")
implementation("com.klinkerapps:android-smsmms:5.2.6")
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

klinkerapps android-smsmms library maintenance status 2025

💡 Result:

As of 2025, KlinkerApps’ android-smsmms appears to be effectively unmaintained:

  • No real releases in years: GitHub shows the latest release/tag activity at v5.2.5 (Oct 24, 2019). [1]
  • Latest published artifact is old: Maven lists the newest version 5.2.6 dated Jan 28, 2020. [2]
  • Last code activity is ~5 years old (as of late 2025): Open Hub reports the “most recent commit” was about 5 years ago and describes it as “maintained by nobody.” [3]
  • Community issues still appear, but don’t indicate active maintenance: there are open issues/PRs created in 2024–2025, but that’s user activity, not necessarily maintainer response. [4]
  • Repo mirrors/indices may update without new releases: a Maven repository index shows the android-smsmms/ directory “Last Modified” in Dec 2025, which can reflect repository syncing/metadata updates rather than new library development. [5]

Bottom line: for 2025, plan on no active maintainer support and be prepared to fork/patch if you depend on it.

Sources: [1] [2] [3] [4] [5]


🌐 Web query:

com.klinkerapps android-smsmms version 5.2.6 maven central

💡 Result:

Artifact com.klinkerapps:android-smsmms:5.2.6 is present on Maven Central (packaging: AAR) and is available under: (repo1.maven.org)

https://repo1.maven.org/maven2/com/klinkerapps/android-smsmms/5.2.6/

Gradle:

implementation "com.klinkerapps:android-smsmms:5.2.6"

(MvnRepository also lists 5.2.6 as the “New Version” for this artifact.) (mvnrepository.com)

Citations:


🌐 Web query:

klinkerapps android-smsmms security vulnerabilities CVE

💡 Result:

Are there CVEs specifically for KlinkerApps / Pulse SMS (Android SMS/MMS app)?

I could not find any public CVE entries in NVD that explicitly name Klinker Apps or the Pulse SMS Android package (xyz.klinker.messenger). (That doesn’t prove none exist—only that none appear to be publicly cataloged/attributed that way.)

Relevant Android SMS/MMS CVEs you should be aware of (platform-level, not Klinker-specific)

These are examples of SMS/MMS-stack or messaging-app vulnerabilities that have affected Android or Google’s messaging components:

  • CVE-2025-12080 – Wear OS / Google Messages intent handling could allow silent sending of messages via crafted ACTION_SENDTO intents in certain conditions. (nvd.nist.gov)
  • CVE-2011-0680 – Android “Mms” app draft-cache issue could allow opportunistic disclosure of SMS intended for other recipients (older Android versions). (nvd.nist.gov)
  • CVE-2014-8610 – Android manifest issue (pre-5.0) could allow triggering SMS sending of stored/draft messages via broadcast intent in certain conditions. (nvd.nist.gov)

Pulse SMS “cloud sync” security claim (not a CVE)

Pulse SMS’s support docs state that messages stored on their servers are encrypted using your password and claim they cannot decrypt/read them. (support.pulsesms.app)

If you tell me which specific KlinkerApps app you mean (Pulse SMS vs other Klinker apps) and whether you want CVE-only results or also non-CVE disclosures/advisories, I can narrow the search further.

Citations:


Reconsider dependency on unmaintained com.klinkerapps:android-smsmms:5.2.6.

Version 5.2.6 exists on Maven Central but the library is effectively unmaintained: the last release (v5.2.5) was October 2019, with no code activity for ~5 years and no active maintainer support. While no specific CVEs are publicly cataloged for this library, relying on an unmaintained dependency for core MMS transport is a significant long-term risk—you will need to fork/patch if critical issues emerge. Consider whether a maintained alternative exists or if you can implement MMS support without this library.

🤖 Prompt for AI Agents
In `@app/build.gradle` at line 118, The project depends on an unmaintained library
"com.klinkerapps:android-smsmms:5.2.6" which is risky long-term; review and
either replace it with a maintained alternative or remove/implement MMS support
in-house. Locate the dependency line using the exact artifact string
implementation("com.klinkerapps:android-smsmms:5.2.6") in app/build.gradle,
evaluate maintained libraries or native platform APIs that provide MMS
transport, update the build file to use the chosen alternative (or remove the
dependency and add a TODO/issue reference for implementing MMS), and document
the decision and migration plan in the PR description so reviewers know why the
change was made. Ensure any replacement is compatibility-tested with existing
MMS flows and add a follow-up issue to track backport/patching if we must fork
this library.


implementation("androidx.room:room-ktx:$room_version")
annotationProcessor("androidx.room:room-compiler:$room_version")
Expand All @@ -132,4 +133,4 @@ dependencies {
testImplementation("junit:junit:4.13.2")
androidTestImplementation("androidx.test.ext:junit:1.1.3")
androidTestImplementation("androidx.test.espresso:espresso-core:3.4.0")
}
}
Loading