Just to bump this - could anyone in the Mudita team provide some very basic instructions on installing Lineage GSI on Mudita? I know it’s possible (as I’ve done it before) but the process is a bit convoluted and it would be a testament to the ethos company to allow users to own their device and install other operating systems on it.
Would a response from the Mudita team be possible?
Lineage is fantastic for security-focused people. Do they have a version for the MK? That would solve my security concerns with their OS and vague outline of how they’ll do security updates.
@jayloofah I responded in another thread. I saw the question there as well:
How would it compromise MuditaOS? Lineage is its own OS. If you’re flashing Lineage, then you’re no longer running MuditaOS so there’d be nothing to compromise.
@bone_naga here’s what I meant by compromising MuditaOS K in a broader, technical and functional sense, it’s not about damaging the OS itself, but the entire software integrity and design architecture it depends on.
MuditaOS runs on a locked bootloader that ensures only signed, verified system images can run on the device.
Additionally, Mudita OS K is also designed for specific hardware configurations (E Ink display, custom power management, Offline+ switch, etc.).
Flashing Lineage could overwrite partitions and functions critical for those hardware interactions.
This is just my speculation because I am not familiar with LineageOS.
So it only affects security if you go through all of that and then return to MuditaOS.
It would be better if Mudita just built their next OS off of Lineage so it would have all the security features, which Mudita doesn’t seem to be that transparent about right now. Then they could add in the hardware specific stuff for e-ink and such.
Meanwhile, the US is heavily stepping up electronic surveillance and are already targeting people based on what they say online. Security and digital privacy are rapidly becoming “must haves” instead of “nice to haves.”
@anon7028788 That’s such a wonderful message to read & thanks for sharing your experience! We’re really glad to hear that returning to the Kompakt has been such a positive and mindful choice for you. It sounds like you’ve found the perfect balance between functionality and focus, using it exactly as it was intended, as a tool that supports real life, not distracts from it.
Enjoy those moments on the soccer field with your kids, and we’re so happy to have you on the Mudita Forum again!
That sounds promising, but would be nice to get some more details for what it actually means.
The silence around security is deafening.
I’ve decided that I’ll wait until the next 1.4 update and see if there’re new patches or even just clarification for the security model, before potentially selling my Kompakt. And by security model I mean concrete information about how new security patches are/will be backported/implemented to AOSP 12. I’d love to use Kompakt but I’m afraid I don’t have any use for it if security remains questionable. Not expecting GrapheneOS-level hardening or anything like that, but just some basic security so I can trust the device with my and my loved ones’ personal data. All we know about Kompakt security updates until now is that the update 1.2 brought some minor UI tweaks.
I think that this will really need to be spoken about in an upcoming update. Security concerns are not a small deal. Especially if this is an important and bespoken feature of a device from mudita.
Sorry for spamming this thread, but just as an update, we now have a good (scary) litmus test: a critical vulnerability that’s been patched in AOSP 13 and above.
The most severe of these issues is a critical security vulnerability in the System component that could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.
https://source.android.com/docs/security/bulletin/2025-11-01
And yet still no response. It’s obvious they don’t take security seriously. The device lacks even basic security options that normally come included on Android.
Hi everyone, I’d like to expand on the information we shared earlier on the Forum to help clarify the current security situation with Mudita Kompakt. This post is meant to explain how we handle security updates today and what happens now that Google has ended support for AOSP 12.
Mudita OS K and Kompakt itself are minimalist products, designed that way on purpose. Kompakt started from AOSP 12, but we changed it a lot.
So at this point, Mudita OS K is its own system, based on AOSP 12, but not a “stock Android 12” build anymore. Some attack paths that exist on regular Android phones simply do not exist here, because the features or apps are missing.
Google has now stopped publishing security patch backports for Android 12. The last Android 12 fixes were part of the March 2025 security bulletin.
That means:
Applying every single patch from Android 13–16 to an Android 12 tree, no matter what, would be risky and almost unrealistic. Instead, we review Android Security Bulletin and pick what matters.
We focus on critical issues. Lower‑risk problems are still monitored but take lower priority.
We want to be clear here:
A few points that also matter for security:
We do not ship Google Play Services or Google Play Store. Some vulnerabilities from the bulletins and from Google’s own bulletins simply do not apply, because that code is missing.
On the other hand, we also do not get protections like Google Play Protect out of the box. So we put extra care into the system side and keep the default app set small.
Because Kompakt now allows sideloading, some risk depends on which apps you choose to install. The OS gives each app its own sandbox and permission system, but no system can fully protect a user from a malicious app they install themselves. Third-party apps can bring in their own bugs or malware.
Thank you for engaging with us and for caring so deeply about doing security the “right” way on a minimalist device. Please keep your Kompakt updated and install apps only from sources you trust.
Thank you for shedding more light on this issue @michalstasiuk. Now I’m a bit more reassured that you’re thinking about this stuff at Mudita. However, I can’t say that I’m fully convinced yet.
I’m not a developer so I have more of an “outside-in” kind of view, but I’d like to think I’ve gotten some understanding of these things over the past years. While GMS, apps and drivers considerable in terms of security, there’s still the core system itself that requires maintenance. I have a degoogled ROM (based on LineageOS) on my other phone, and even though they don’t have GMS, they still keep shipping security patches that come with AOSP.
Could you tell more about how you’ve applied this process during this year and the beginnings of Kompakt: have you ended up doing anything on Mudita OS K? Apparently something has been done:
What was your assessment of this vulnerability and will you patch it in the upcoming update?
The word security does not appear in the 1.4.0 release notes…
This entire post just again makes me question how seriously Mudita is taking security.
Some attack paths that exist on regular Android phones simply do not exist here, because the features or apps are missing.
This is exactly one of the concerns I raised previously in a discussion about security (I don’t recall if it was this thread or a different one but it doesn’t really matter). If you only apply patches based on the device out of the box, you’re leaving anyone with sideloaded apps (which is a lot of people including people who care about security/digital privacy) potentially vulnerable since you might decide “that app isn’t pre-installed so we don’t care about that vulnerability.”
Google has now stopped publishing security patch backports for Android 12. The last Android 12 fixes were part of the March 2025 security bulletin.
That means:
- There will be no new official Android 12 patches from Google.
- Any long-term support for a device on an Android 12 base must come from the system vendor (in this case: us), by backporting fixes from newer Android versions.
This issue is well known but it begs the question: why did you insist on using a version that was going to be end of life before the phone was even released?
Applying every single patch from Android 13–16 to an Android 12 tree, no matter what, would be risky and almost unrealistic.
So again why are you using AOSP 12 when there are newer versions that are still receiving support? This feels like you’re saying it’s unrealistic to walk around while neglecting to mention that you shot yourself in the foot. You chose to use an EOL version of AOSP. You chose not to make your code open source, which could allow the community to find and help fix issues (or continue support beyond the dismally short 3 year plan).
We focus on critical issues.
How focused are you on these issues at all? The 1.4.0 update doesn’t even mention any security patches. The phone itself lacks basic security features that have long been part of Android such as whole device encryption, custom DNS, even the standard VPN settings were made inaccessible to the user (I can sideload a VPN app but there are VPN settings baked into Android that I should be able to access).
Don’t get me wrong, I know you can’t do it all. I know you have to prioritize your fixes. My main thoughts/concerns are this:
Thank you for the response and I imagine Mudita, given the limited development resources, is attempting to port over security patches in a way that’s possible for them.
However, it still remains true that, like many older Android devices that have lost support from the manufacturer, there exists a vibrant community that supports these devices by porting the latest generic Android system images to the device (via Lineage or other flavors).
For advanced users who are legitimately concerned and for owners of the Mudita Kompakt, it would be great to get some certainty around the ability for us to own our devices and be able to install generic Android builds past version 12.
Guys, it might be a dumb question but hear me out.
I work with Linux servers sometimes. Every now and then when an appliance has to be updated, the update tends to come along with underlying Ubuntu update to another LTS release.
Shouldn’t it be possible to upgrade AOSP one day?
Well, I think it is a dumb question. Smartphones do jump up between Android releases from time to time.
I don’t think it’s a dumb question. I work with Linux all the time so I know what you mean with how Ubuntu does its LTS updates. To your point, yes the AOSP version could be upgraded if Mudita chose to go that route and provide the update. Since they haven’t indicated any interest in doing so, individual users would probably have to flash the files to do an upgrade themselves, which means someone would have to craft that update file, which would be easier to do if Mudita would make their OS and drivers open source.
Just wanted to say that the Mudita Kompakt did seem like the perfect choice for me, but same as @bone_naga I’ve been disappointed by mudita’s response.
Security is a big issue for me so seeing that the kompakt runs a old android version which is no longer supported doesn’t fill me with hope that such a small team will be able to deal with all of the security vulnerabilities that have cropped up .
I really hope that Mudita changes its stance on this issue if they did I would almost definitely buy the kompakt, but for now it looks like I need to look for something else.