DuraSpeed silently blocks incoming SMS/MMS delivery for sideloaded default-SMS apps

Technical Support
1

Posting this for the mudita team (@urszula ) and the community in case anyone else has struggled with this issue.

I wanted to report a bug I’ve confirmed and reproduced on my Kompakt, which I believe may affect other users who sideload a replacement texting app — a workaround I know a number of Kompakt owners use, based on other forum threads which describe similar symptoms.

The symptom: when using a sideloaded app set as the default SMS handler, some incoming texts — both plain SMS and MMS — never arrive at all. No placeholder, no notification, nothing. This happens specifically after the phone has sat idle for a while (overnight, for example), and the messages aren’t merely delayed — they’re lost entirely. I’ve seen this with two different sideloaded SMS apps (InkMessage previously, and currently kotozute), so it doesn’t appear to be specific to either app’s code.

I confirmed the exact mechanism with an overnight adb logcat capture, timed against a text my wife sent at a known moment. At that exact timestamp, the log shows:

  1. The telephony stack and Android’s own SMS provider successfully receiving and storing the message:
    Mms/Provider/Sms: insertInner succeed content://sms/raw/1

  2. Immediately followed by system_server (PID 1126) explicitly blocking the sideloaded app from being started to receive it:
    DuraSpeed( 1126): onBeforeStartProcessForStaticReceiver, packageName = com.wanderwildwood.kotozute, suppressPolicy = 2a20, suppressPkgList = [… com.whatsapp, dev.imranr.obtainium, com.aurora.store, com.wanderwildwood.kotozute, app.inkos …], isSkip = true
    BroadcastQueue( 1126): processNextBroadcastLocked, suppress to start process of staticReceiver for package:com.wanderwildwood.kotozute

So the message does arrive and gets stored in Android’s own database, but DuraSpeed — which appears to be built into system_server itself rather than a separate app — actively prevents the OS from starting the sideloaded app’s process to deliver it. The message is then simply gone.

A few things worth flagging about why this is hard for a user to fix on their own:

  • Settings > Apps > [app] > App info has no Battery or background-usage option at all for sideloaded apps on this OS, unlike stock Android, so there’s nothing to toggle there.
  • The “Duraspeed” entry findable via Developer Options > App info search does not control this — disabling it there has no effect on the behavior above.
  • The real controls appear to be three system properties (persist.vendor.duraspeed.app.on, persist.vendor.duraspeed.lowmemory.enable, persist.vendor.duraspeed.support), all currently set to 1 on my device. Attempting to change the first via a non-root adb shell fails outright: “Failed to set property … Permission denied,” and dmesg is similarly locked (klogctl: Permission denied), so there’s no way to inspect or override this further without root access.

Given app.inkos (InkMessage’s package) sits in that same suppress list alongside WhatsApp and other common sideloaded apps, this looks like a deliberate, systemic restriction rather than anything specific to one app — and since it silently drops real incoming messages, it affects core phone functionality for anyone who doesn’t use the stock SMS app.

A few questions:

  • Is this suppression of incoming-message delivery for sideloaded default-SMS apps known/intended behavior?
  • Is there a supported way, without rooting, for a user to exempt a specific app — particularly one set as the default SMS handler — from DuraSpeed’s suppression list?
  • Would this be something Mudita would consider addressing in a future firmware update, given that it results in silently missed text messages?

Happy to share the full overnight log capture if it would help your team investigate further.

Thanks,

Wahlo

4 Likes
2

Are you on 1.5, 1.6, 1.61?

(hoping that makes a difference, I’m not getting texts either on 1.5 [QUIK]…)

1 Like
3

I am and was on 1.6 when doing these tests. I am about to update, but nothing I’ve seen in the update list seems to suggest this particular issue would be any different.

1 Like
4

So just to confirm the following toggles have no effect:

image.jpeg
image.jpeg480×800 33.9 KB

image.jpeg
image.jpeg480×800 19.7 KB

image.jpeg
image.jpeg480×800 10.7 KB

image.jpeg
image.jpeg480×800 53.7 KB

Neither toggling an exemption for a particular app nor switching off the toggle at the top fixes the issue?

1 Like
5

Correct. Months ago, I had switched off the toggle at the top. Interestingly, once I did so, these toggles vanished - seemingly unable to be returned to again.

1 Like
6

I’ve talked to our team about this & they asked if it’s possible for you to send logs to our tech support, so they can see what’s happening behind the scenes for this to occur. Generally, in standard Android, when a user selects an app as their Default SMS App, Android grants it special high-priority privileges so it can immediately wake up and intercept incoming texts (SMS_DELIVER broadcasts).
However, DuraSpeed operates outside standard Android rules. Unless an app is explicitly whitelisted at the system level (as the built-in Mudita Messages app is), DuraSpeed intercepts the wake-up signal and prevents the replacement app from launching in the background. As a result, the phone receives the text over the network, but the app never wakes up to save or display it.
• Is DuraSpeed supposed to restrict default apps?
No, not by design. From an OS and user-experience perspective, selecting an app as the default SMS handler should automatically exempt it from background restrictions. In MediaTek’s default BSP configuration, however, DuraSpeed is often unaware of Android’s default role changes unless the OEM configures/links them.

Please reach out to [email protected] and when you send the logs, our team asked that you redact any personal phone numbers or message metadata before sharing.