Welcome to our first CalyxOS progress report of 2026. January was a busy month for the team: finalizing provisioning ceremony operations and scripts, establishing the new signing infrastructure with our newly onboarded CalyxOS sysadmin, and attending FOSDEM2026. We are grateful for the questions, concerns, and suggestions shared with us from our community, and sincerely apologize for any delayed response and update.

CalyxOS’ new HSM-based signing infrastructure

Throughout January, the CalyxOS team has been focusing on the implementation of the new signing infrastructure to facilitate and streamline our future development. With the completion of the provisioning ceremony, we are now equipped with the new signing toolkit built by us and audited by Trail of Bits. This new signing infrastructure achieved two major goals:

• It resolved the potential bottlenecks and security risks that come with relying on a single person, machine, or HSM to sign every release.
• It reduced the chance of compromise of the signing keys by preventing exporting them in plaintext.

You can read our deep dive into the whole process or watch our talk at FOSDEM2026.

Setting up new release server and Gerrit Code Review

We are now at the final step to resume CalyxOS: stabilizing the release cycle for our 25+ supported devices with the upgraded development infrastructure. To give an example, our release server upgrade has been in the backlog for more than 18 months. After a thorough inspection over the past few months, we came to the conclusion that our Gerrit and release servers should be set up with easier, regular backups to protect the project from server-side incidents. We are now migrating the CalyxOS release server to the organization’s Vultr instance along with the web server that is hosting the CalyxOS website. As a result, at the moment you might encounter downtime or missing objects if you are syncing CalyxOS sources. You can find more information about the organization’s larger infrastructure revamp here.

Dedicated, expanded Systems Administrator support

More good news: we are pleased to have Nat Meysenburg supporting the CalyxOS system admininstration work. Nat joined our team at the beginning of 2026 and has been playing an instrumental role in our infrastructure modernization from server management redesign to code documentation. With Nat as our new member, we are steadily rebuilding the team capacity with a much more refined workflow.

Image created by Jeroen Heijmans

Why are we using a HSM?

Code signing is commonly used to cryptographically verify the origin of software. A typical Android build consists of many individually signed pieces, which requires a significant amount of signing keys. Among these keys, the most important is used for verified boot, which establishes a full chain of trust for all parts of the operating system.

Each key comes in two parts: the certificate and the private key. Developers use the private keys to make the cryptographic signatures, which need to be stored somewhere. This is typically a file on a storage medium. However, if anyone gets a copy of that file they can make valid signatures indefinitely and there is no way to stop them. It is impossible to verify where there are any copies of the key file, where they exist, or who has access to them. That is quite a risk. It also makes giving more than one person access to the keys quite challenging and thus is bad for your bus factor.

To improve the security, you can store keys in special hardware security modules (HSMs) instead of files on a computer. These modules use tamper-resistant storage hardware that makes it extremely hard to extract private keys without authentication. Even though it may be possible for powerful actors, such as nation-state intelligence, to extract key material if they gain physical access to the module, a HSM is still much more secure than storing keys as files on a computer.

A common use-case for HSMs is to simplify and automatize signing of build artifacts in a continuous integration environment (CI). An attacker that compromises the CI machine could make malicious signatures. If you stored your signing key in a file that is extractable in plaintext, you have no choice but to generate new signing keys. But with a HSM, if you detect the breach, you can stop the attacker by preventing their access to the HSM.

Note that for now, CalyxOS has no plans to automate signing in this way. We will start with manual signing on a dedicated and secured machine where the HSM is only connected when needed.

Defining criteria for secure signing operations

By now, it is evident why new keys were needed; generating fresh keys gave us a clean slate with no unknown copies floating around, and allowed us to fully control the redesign and safety of our new signing solution. Next, we defined the criteria for the hardware backing our HSM solutions; you can find the criteria in our November 2025 community update. This set of criteria helped us reach our goals in three categories: security, operational practicality, and transparency. Many solutions, while meeting our security requirements, were not immediately available, financially affordable, auditable, or aligned to our organizational mission to promote and advance open-source tech.

Our process of evaluating options for the secure signing operation involved many discussions and trade-offs until we could make technical decisions. We looked into cloud-based HSMs, such as the Amazon Cloud HSM, enterprise-grade appliances, such as Thales Luna HSMs and Entrust nShield, and more affordable options, such as Nitrokey NetHSM. Also considered were smaller hardware dongles, such as the YubiHSM 2 and the Nitrokey HSM 2.

We decided to start with a simpler, HSM based, intermediate solution with a quick startup path that would let us soon start signing releases with new keys. That being said, we built in a migration path to a better or final signing solution.

In the end, we decided to start with the YubiHSM 2.

Key wrapping: A secure way to manage keys with limited storage space

It is worth noting that YubiHSM 2 has very limited storage space. It cannot fit all the signing keys required to sign our builds since we use a unique key for each device and different components. This issue is not unique to CalyxOS, it also applies to other projects that need lots of keys, e.g. F-Droid.

Thankfully, there is a solution for this problem called key wrapping. Keys that don’t fit on the HSM can be stored outside, encrypted. When you need to use them, you can import them into the HSM and decrypt them inside. The key that encrypts and decrypts the signing key set, called the wrap key, is always stored securely inside the HSM. This way, signing keys are never available in plaintext outside of the HSM.

Key backup: Why and how?

When using HSMs, there is always a possibility they might break, fail, or get stolen, necessitating a plan to securely backup the keys. The actual signing keys are only available outside of the HSM in encrypted form, so you can back them up in the same way as you back up other files. Still, for the signing keys to be useful, we also need the wrap key, which is only available inside the HSM. Of course, a plaintext backup of the wrap key needs to be avoided, because it re-introduces all the same problems the HSM was supposed to solve.

The best option we found was Shamir’s Secret Sharing (SSS). This sharing algorithm was first developed in 1979. With this technique, we split the wrap key up into several parts, also known as shards. The wrap key could only get reconstructed when a pre-defined number of shards were present. We opted for five shards with a threshold of three shards required to recover the wrap key. Instead of relying on one person to securely back up private keys, we rely on a group of three out of five people to keep each of their shards safe and only ever combine these in a special ceremony.

Key provisioning ceremony

Somehow, the key material needs to get into the HSM. This could be for restoring a wrap key backup as stated above or when generating the initial key material. Unfortunately, the YubiHSM 2 doesn’t have SSS implemented in its firmware and even the official setup utility briefly holds the wrap key in memory, splits it into shards, and imports it back into the HSM. So for both cases, we need a secure ceremony that tries to ensure that key material can not leak in any way.

As you can see in our last community update, we spent quite some time in designing, testing, reviewing, and preparing for the key provisioning ceremony. And the whole key ceremony package was audited by Trail of Bits. You can find their audit report.

The ceremony taught a few practical lessons. To prevent a targeted attack from compromising the machine used in the provisioning ceremony, we bought a compatible device from a randomly selected store immediately beforehand. To establish a trusted and secure environment, we used an epheremal live OS with a good security track record: TailsOS. Using TailsOS on a random out-of-the-box machine came with its own constraints; we needed to use a DVD as our initial data medium for ceremony scripts and TailsOS files. Prior to creating the bootable TailsOS flash drive, we also needed to verify the integrity of the live medium on Windows, the out-of-the-box operating system. Our specific solution was to create a reproducible .iso file and burn that onto a DVD. Then, in Windows, we used powershell commands, which ware also used in the Juicebox HSM Key Ceremony, to compute the SHA256 hash of the entire drive. The operator confirmed the hash by reading it aloud in front of all ceremony participants for everyone to verify the hash of our .iso file:

4b1f31960c64fe0bf5bb7087f8d06923cce611a795f510f028fe3811b4c25847

If you are interested, you can reproduce this hash on your own computer following our instructions.

After verifying the DVD and the files stored on it, we created a live Tails drive with a flash drive we (also) bought randomly. To ensure security, we made sure to keep the ceremony computer offline throughout the entire procedure, from the initial Windows Setup Wizard to the running of the ceremony scripts on TailsOS.

The next step was rather quick and smooth as we booted into the Tails drive to run the audited scripts from the DVD to set up two HSMs, one for operation and the other for backup. We did a physical factory reset for both the YubiHSM 2 devices and turned on auditing (you can find more about this in the following paragraphs). The script then created three authentication keys: one for the signing operator, one for the admin, and one for the auditor.

The wrap key was then created in the HSM, split into shards, and imported into both HSMs. The shards and the authentication keys were encrypted to pre-defined public keys using age.

Android signing with PKCS#11

All tools involved in Android signing support PKCS#11, an OASIS standard, C interface to let software communicate with a HSM and also referred to as Cryptoki. It is a common choice when replacing signing keys in files with an HSM. However, we couldn’t find out-of-the-box PKCS#11 solutions for signing Android builds. As far as we know, we were the first Android ROM building a complete PKCS#11 Android signing solution and documenting it. It was possible that bigger OEMs had been taking this route to sign their builds with HSMs. Or at least we hope so.

Android’s entire signing process is quite complex. It is not only about signing lots of apps, but apps inside partitions that get unpacked, repacked after all contents have been signed, and finally signed themselves.

There are three different tools used throughout the signing process: apksigner, signapk and OpenSSL. All of them need to get hooked up to use our HSM but each is used in their unique ways and troubleshooting tool-specific bugs takes time.

For example, apksigner was using a PKCS#11 module, but it didn’t close sessions, which caused a denial of service because of the limited number of open sessions allowed and the long timeout. To add to this, we found signapk quite buggy and not usable with strictly PKCS#11-compliant solutions. So we had to switch to using apksigner instead. It remained unclear to us why Google would use two different tools here when one could simply do the job.

Other changes we made included performance improvements. For instance, apksigner would load the entire key store at each start. If the keys were on the HSM, this would take a long time. Since we used apksigner a lot, we added a batch mode to it.

We also disabled V1 signatures for our apps. V1 signatures require a lot of HSM operations (one for each file in the APK). Plus, it is not needed in recent Android versions.

The next steps for us include continuing the code cleanup, revising the changes with better, more sustainable logic, and further improving signing performance by using a signing cache (so that signing the same component will use the same HSM and key only once).

All of our source code for the above is free and open-sourced. We invite all custom ROM development teams who are curious about signing with HSMs to contact us and collaborate. You can find links to them at the bottom of this post.

Auditing

Keeping the signing keys safe with a multiparty backup approach was important but we wanted to go further. Being auditable at all times was another important goal for us to improve our signing design; specifically addressing the issue where whoever performed the actual signing with the HSM would still hold significant power. While they could not extract the signing keys themselves, they could sign arbitrary things with those keys, such as a malicious app. With a valid signature, an imposter app can replace the real app installed on a victims’ device.

With this in mind, we aimed to audit all signing operations, which led us to the discovery of more limitations of the YubiHSM 2. Similar to the limited key storage, the space for saving the audit log is equally limited. If you don’t want to lose logs you need to regularly fetch logs from the HSM. Since we enabled a force-log mode, a full log would cause a denial of service. This was where some of our own toolings came in; we intercepted every signing command and ensured that logs would get flushed to a file on disk. The audit logs were then pushed to an append-only git repository where CI would automatically verify the hash chain of signing log.

Even with these logs, there were still room for improvement: the audit log on the HSM wasn’t cryptographically signed and we needed extra steps to verify the log in the git repo against the one in the signing artifacts. Since the log contained sparse information, we would need to manually retain all signed artifacts to properly investigate a potential incident. Despite the improvements we are planning, this has got us a head start in reviving CalyxOS.

This project came to fruition with the support of many open-source tools. We would like to thank the tool developers, our security auditors, and everyone who has contributed to this work along our journey. The talk was presented by aysha and Torsten Grote on the CalyxOS team with a special thanks to t-m-w.

If you are curious about our work and want more details, you can check out our PKCS#11 documentation and provisioning documentation on this topic. All of our signing-related scripts can be found here.

Here’s a list of patches we had to make to AOSP:

• Add PKCS#11 signing support
• Add argument to keep temporary files
• Don’t add quotes around signing_args
• Use apksigner for most APK and APEX signing
• Add option to use a signing command interceptor
• Add support for a signing command interceptor
• Add alignment override option like signapk
• Log out of SunPKCS11 on exit
• Add batch mode to reuse loaded keystore

If you have more questions, feel free to get in touch with us.

Following last month’s update, the CalyxOS team is entering the final stage for the new signing plan and policy. In addition, we are working on bringing CalyxOS supported devices up to Android 16 QPR2 and building the team capacity with new hires. Here is a detailed rundown of our work:

Signing finalization and audit

Our team has reached a final draft for the new HSM-based signing process. This includes a detailed plan for the initial key ceremony, provisioning scripts, and the verification methodology of each element in the process. Based on the criteria we laid out before and our requirements for signing CalyxOS builds and apps at the frequency of every one to three months, our goal for this new signing design is ensure that all key material will have a secure backup so that no single person can hold access to our signing keys. The main key we will be generating during a provisioning ceremony will be split into shards using Shamir’s Secret Sharing. Each shard is only ever stored encrypted and kept safe by a designated team member. Together with security auditors we selected a library for this job and wrote our own simple Go executable with it, which could create reproducible builds and was already audited.

All the provisioning tools, key ceremony operational plan, and auditing mechanism are being packaged for a final security audit.

Once this package for key signing provisioning passes the audit from our security consultant, we will perform the key ceremony and deploy the new signing mechanism for CalyxOS. We anticipate this to happen in the next few weeks and will keep you updated on audit progress.

Android 16 QPR1 and QPR2

We are pleased to share that we have booted Android 16 QPR1 on all modern devices on our supported device list and are testing full CalyxOS functionality while also porting it to the rest of the our supported devices. What’s more, we have started analysis of the newly published QPR2 and are building out our QPR2 sync plan and timeline for all supported devices.

In the meantime, we are setting out to migrate our CalyxOS Gerrit Code Review instance to a new and faster server as part of the Calyx Institute’s data infrastructure overhaul. The success of the Gerrit migration will stabilize and facilitate our QPR2 bringup.

Building capacity for the CalyxOS team, continued

Last month, Lucas, a long-time CalyxOS contributor, joined the team as the Community Coordinator. You might have been familiar with Lucas on our various community channels, including Matrix room and CalyxOS subreddit. We will keep improving our community communications with the tremendous help from Lucas. To start, we will try to make sure we respond to all questions and concerns. If you have any comments or suggestions, please do not hesitate to ping us on our channels.

The position of CalyxOS Android Board Support Packages (BSP) Engineer has been closed and we have entered the interview stage. We will soon have a few more openings on our job board. Stay tuned!

Meet the CalyxOS team at FOSDEM 2026

If you plan to attend FOSDEM 2026 and are interested in knowing more about our effort in HSM signing upgrade, we will present our methodologies and lessons at the FOSS on Mobile devroom. Looking forward to seeing you there!

As promised, today the CalyxOS team is sharing an update on our progress to improve the project and increase transparency.

Throughout the past few weeks, the team has been focusing on improving the security of our critical infrastructure and tackling long lasting challenges. In addition, we are revising our communication strategy toward a combination between providing thorough updates and building capacity for direct engagement in our community channels. Understandably, the decrease of the team voice and public actions have raised questions and concerns around the capacity of the project. We would like to respond to concerns people have raised by confirming that CalyxOS hasn’t been compromised and the organization is directing significant resources to get it back on track. We deeply appreciate all the people who have been sharing their concerns with us. And we will try our best to address their questions in this report.

Redesigning the CalyxOS signing process

We are finalizing the design of a Hardware Security Module (HSM) signing solution for CalyxOS. A HSM is a dedicated physical hardware device that generates and stores cryptographic keys in a tamper-resistant environment; the keys never leave the HSM, which puts a guardrail against key extraction and compromise. We decided to move to a HSM because signing keys are a critical part of the chain of trust: they are what verifies to your device that an update actually comes from CalyxOS and hasn’t been tampered with.

Our criteria for the CalyxOS signing solution were that it should be: available, affordable, secure, expandable, auditable, redundant, easy to access, and aligned to the mission of the Calyx Institute. These requirements were what led us to choose the HSM solution among available options. Specifically, we selected the YubiHSM2 based on our current urgent development requirements and resources as an interim solution while we evaluate and build out a long-term solution. To keep our solutions consistent with a seamless transition in the future, we are ensuring that our keys are transferable both operationally and technically, and that CalyxOS users will not need to reflash their devices beyond the initial installation.

Our work has also included integrating AOSP’s documented signing process with PKCS #11, the public-key cryptography standard for communicating with HSMs and cryptographic devices. To make that happen, we are building an interface layer between the two that does not yet exist in the standard AOSP tools or within the FOSS community.

Right now, we are finalizing the detailed provisioning plan for the signing process under the guidance and testing from our independent, third-party security consultants.

Once the new signing infrastructure and procedure is in place, documentation and code will be shared as a FOSS project as part of our commitment to open source, transparency, and community collaboration.

Adapting to the new norm of AOSP releases

Google has made serious changes to AOSP development in the last few months; monthly security patches are often empty and public git tags for developers, which make it easy to identify patches, are no longer available. As the changes unfold gradually, the challenge of keeping a regular and timely development cycle with all these AOSP changes remains significant as the custom ROM community has spoken about extensively.

Despite these challenges, we have made the decision to — in our best effort — further extend our device support for moto g32, g42, g52, Pixel 5, 4a 5G, and Pixel 5a 5G when CalyxOS resumes update releases. That means people with these devices can install the Android 16 version of CalyxOS when it becomes available. We are still gauging whether we can ship QPR1 to these extended release devices, pending the release of the QPR1 source; QPR2 is even less certain as we assess the work involved. Once we have builds ready with a thorough evaluation of the case, we will publish a confirmed new EOL date for devices for which we provide extended support.

In the interim, we have also reached out to our peer custom ROM developers and several device manufacturers to align strategies to sustainably access and publish OS security patches. We hope that this collective effort of the global FOSS community will stop the trend of closing source for AOSP and other open-source projects.

Building capacity for the CalyxOS team

In reality, Calyx has been a small team running a lot of projects, not least of all CalyxOS. We are stretched thin right now and our priority has been getting CalyxOS back up and running ASAP. As we are drafting this report, we are also working diligently to expand development capacity and optimize team structure. We have brought Lucas—a long-time CalyxOS community facilitator—to the team as our new Calyx Community Coordinator, a role that has never existed in the organization before. In addition, we are in active recruitment for the CalyxOS Android Board Support Packages (BSP) Engineer position and a new Android Platform Software Developer. Keep an eye on our job board and please help spread the word!

Dear CalyxOS community members,

We would like to share an update on how to reach the CalyxOS team given the recent traffic insights and our internal temporary shortage of staffing. As we work hard to get the project back on track, including its community channels, we are increasingly concerned with the rapidly growing spam messages in the Telegram channel. Historically, this community channel, like every other CalyxOS community channel, has been fully administrated and moderated by volunteers and the moderator bot that was set up to bridge between the CalyxOS Matrix and Telegram channels. And the CalyxOS team tried our best to make sure they are governed under the CalyxOS Code of Conduct and Community Pledge.

As we are transitioning the project, we also aim to refine our community support to make the best use of small team’s capacity at the moment. To further clarify, here is a rundown of how you can seek help or support from the CalyxOS team on our community channels:

• To seek a quick answer to a technical question, the best way is to reach us in our Matrix room. You can tag @calyx_institute:matrix.org to ensure a response.
• To report bug or send feature / functionality request, please start a new issue on the Calyx GitLab. Regular triage and review will restart in mid-October.
• To follow the latest CalyxOS updates, you can check the CalyxOS X and Mastodon accounts.
• We will also continue to sync all CalyxOS updates to the CalyxOS subreddit and answer questions when we have the time.

Going forward, we will withdraw our support from the Telegram channel to make sure our main channel is fully supported. However, the Telegram channel will continue to run as a entirely community-led space, however, our team is unable to moderate nor delegate moderator privilege in those groups at this time. We thank all the admins and superusers on Telegram who have been voluntarily facilitating a democratic space for CalyxOS with our deepest gratitude.

Please stay tuned for our next community periodical progress report which will be coming within the next week!

What’s included

As mentioned in our letter to the CalyxOS community, this project has been on a hiatus for the last two months. However, we are concerned with the many existing CalyxOS users who may have not been made aware of this important change. To reach as many active CalyxOS users as we can, our team decided collectively to push one last OTA update to inform all people currently running CalyxOS about the hiatus and its impact.

Therefore, rather than a typical monthly update, this OTA update alerts people through a system notification that their current version of CalyxOS will no longer receive updates from our team and a link to our community letter. Once the project comes out of the hiatus, you will be alerted with an additional notification, and reinstalling CalyxOS will be required to receive updates going forward.

In addition, Moto and Fairphone devices will receive a patch to fix the issue related to the anti-rollback protection (ARB) feature we discovered earlier. We hope this can provide a temporary solution to people who are seeking to run CalyxOS on these devices before they can establish a long-term plan. Note that since there will be no more updates to the existing version of CalyxOS installed on your device, future releases from the manufacturer to increment the ARB index are likely to cause the same issue mentioned above.

We understand that some people will continue running CalyxOS until our next release, so alongside this notification, we have included the latest open source security updates for Android 15 (although this is not a full CalyxOS security update). This OTA update, however, is not related to our Android 16 port or the AOSP QPR1 update. We are closely monitoring the AOSP QPR1 release and working hard on bringing up Android 16 with all feature updates and security patches along with our current need to overhaul the project.

Rollout

Changelog

• CalyxOS 6.10.10 / 6.10.20
• Android 15
• August 2025 Security update (2025-08-01) with platform patches only.
• Critical notice that maintenance of all current installations have been paused.

Update: December 17 2025

CalyxOS progress report - ceremony preparation, QPR ports, and FOSDEM

Update: November 10 2025

CalyxOS progress report — signing, team capacity, and more

Update: September 30 2025

An update on how to reach the CalyxOS team

Update: August 27 2025

We are concerned that some users may have not seen the important message in this letter about CalyxOS’ current hiatus. Therefore, we are rolling out one last OTA update to devices currently running CalyxOS to reach as many active users as we can. You can read our post for more details about this update.

Update: August 5 2025

We appreciate your valid concerns and questions around the security and safety of CalyxOS.

First, we want to assure you that we have no reason to believe the security of CalyxOS and its signing keys have been compromised.

As you know, we announced a recent leadership transition. When senior personnel have access to signing keys and leave a team, it is security best practice to update signing keys and conduct audits. So in accordance with that, we are using this transition period to update our security protocols, including updating the signing keys and taking other steps to further protect our users.

In the past, security audits have been conducted for parts of CalyxOS, such as the Seedvault project, but not for the entire project. As more and more people across the globe started using this tool, we intend to conduct a broader security audit and publish the reports for the public to review.

As mentioned in our community letter below, we estimate that this audit and the implementation of new security protocols and signing keys will take four to six months, but we will endeavor to complete this process as soon as possible. However, for the time being, current CalyxOS users will not be able to receive further security software updates until our new security protocols are in place.

Without security updates, we can only be honest that this does not guarantee the level of security we strive for, especially when global threats to privacy and human rights are at a critical moment. That is why in the meantime we have posted the recommendation that people who are running CalyxOS should uninstall the OS and follow our community channels for updates, including when the latest version of CalyxOS becomes available again.

In case you wish to migrate to another custom ROM in the meantime, we’ve now published updated guides on how to back up and restore your device using Seedvault and how to restore your device to stock.

We also understand that many community members have expressed interest in having an installation option/images for CalyxOS available again. Due to the overwhelming feedback from our community, we’ve decided to make the images publicly available once more. Please be aware that this decision is not a recommendation to migrate to CalyxOS now.

Please note that, just as current users will not receive further software updates without reinstalling CalyxOS when future updates are released, any device installing CalyxOS in the near future will also need to reinstall it. We want to ensure that all users are well informed before deciding to install CalyxOS at this time.

Again, we are very sorry for this development and we thank you for giving us—the project and more importantly the team—tremendous trust and support. We are doing our very best on our end, and are committed to keeping CalyxOS secure and this decision is a result of that commitment.

Dear CalyxOS community members,

The last few months have been especially challenging for us as we have experienced some changes within our teams and in the Android free and open-source (FOSS) development community.

Nicholas Merrill, president and founder of Calyx Institute, has left the organization to pursue other projects.

Nick has championed privacy and data security over the last 25 years, and we thank Nick for his decades-long leadership, guidance, and contributions.

Chirayu Desai, the CalyxOS Tech Lead, has addressed his departure from the CalyxOS project and the organization in a personal note to the public.

We also want to express gratitude to Chirayu for his enthusiasm and incredibly hard work on CalyxOS.

Nick and Chirayu have been a part of the CalyxOS project and its global community for many years. Without a doubt, there is a gap to fill following their departure.  Following their departure, there will be a period of transition as we move forward. During that time, Calyx Institute’s Interim Executive Director, Ellen McDermott, will continue to lead the organization’s important work while the CalyxOS team will focus on bridging the gap and recentering our efforts.

Our commitment to our mission has not changed: defending digital privacy, advancing connectivity, and striving for a future where everyone has access to the resources and tools they need to remain securely connected. CalyxOS is an integral part of our work and stands at the center of the FOSS digital ecosystem we aspire to create. It is our responsibility to protect the privacy of current and future users of our technologies.

To ensure operational consistency during this transition and adhere to security best practices, our team is working to improve transparency and security through better design, communications, and infrastructure. Our ongoing priorities include:

• Upgrading the tech infrastructure supporting CalyxOS development
• Stabilizing update release cycles for our 25+ supported devices
• Revising and updating our usage and development documentation, wiki, and user guides

To fulfill our community pledge and foster collaboration, information sharing, and inclusivity, we are engaging with our peers, partners, and security experts to ensure the delivery and integrity of all changes made during this process. After conducting a thorough inspection of the work required for successful completion of the above priorities, we have determined that it may take up to four to six months for us to provide the level of security maintenance we aim to deliver.

We will be switching to new signing keys along with the overhaul of the signing and verification process. As a result, current CalyxOS users will not be able to receive further security software updates until this process is in place.

Given the potential risk posed by the pause of maintenance and development, it’s logical that we stop providing options to install CalyxOS for now. This was an incredibly hard decision to make, and we understand that this decision may cause significant difficulties for our users. For those wishing to remain on CalyxOS until our next release, note that you will not have the latest security patches on your device as released from the Android Open Source Project and from any proprietary sources provided by device manufacturers. We sincerely apologize for the hassle brought to you by this change, and we understand if you need to uninstall CalyxOS and migrate to another privacy-protecting Android distribution in the meantime. If you wish to continue using CalyxOS in the future, please follow our updates to reinstall CalyxOS when it becomes available again.

We are committed to supporting you through this process. To assist any migration, we will publish, by August 6, instructions to back up and restore your phone to a stock or custom Android distribution with Seedvault.

Starting with this announcement, we will be reporting our progress regularly through our community channels, and we welcome your insights if you would like to contribute to this effort.

We thank you for your continued trust and look forward to further collaborations with people who have, are, and will be using and contributing to CalyxOS and various FOSS projects.

Yours sincerely,
The Calyx team

As we shared in our previous announcement, the biggest change Google made with the release of Android 16 to AOSP was to not release the Pixel device configuration sources (device trees) and its driver binaries. Because Google has been leading the development of AOSP, this move not only means that Google’s internal development progress will further impact the timelines of custom Android distributions (ROMs), but also indicates that what has previously been open to the entire free and open-source software (FOSS) community is slowly and gradually being closed.

What it means to CalyxOS future plans

For developing CalyxOS (and other peer custom Android ROMs) on a variety of devices, there are three key elements to ensure coherent and consistent maintenance: device kernels, device trees, and the proprietary binaries used for different components of the system. In the past, releases of Android versions usually included Pixel device trees in AOSP or otherwise made them available for download. This allowed custom Android ROM developers to easily identify the configurations Google made in new Android versions and customize them accordingly. Starting with the Android 16 release, FOSS custom ROM developers will need to build and maintain their own device trees for Pixels, which takes a lot of guesswork and reverse engineering. Comparing code changes and finding ways around proprietary codes will be a major burden in all future updates.

However, this impact is somewhat limited on CalyxOS. A key factor in our resilience is that CalyxOS has been supporting devices from a diverse range of phone makers besides the Google Pixels — such as Motorolas, Fairphones, and SHIFTphones — which helps us adapt to device-specific development processes and code availabilities. Furthermore, our testing has been focusing on replicating real world experience seamlessly in our development process and we will continue this effort.

With this trend, we are also anticipating more changes in Android 16 QPR1 or QPR2 that could potentially impact kernels — there could be features that existing device kernels are not compatible with and will require significant work to continue to support past each of these AOSP updates.

The trend of Google’s gradual privatization of Android OS development, albeit challenging to all custom ROM developers, has drawn attention to the importance and efficiency of tools, methodologies and processes in each stage of the development, signing and release, especially when it is happening across 20+ devices on a regular cadence, and respects the significance of quick security updates. This most recent change has prompted a close look into our current workflow. Concurrently, we are conducting a series of serious internal reprioritizations, including development (cleaning device trees, automating the extracting and matching stock properties and policies), release (preparing to make it easier for future updates), and key signing (reinforcing and ensuring key integrity, resilience, audibility, and a secure chain of trust). As a result, our users will see a hiatus in our usual schedule with respect to security and general updates. We sincerely apologize for the impact this hiatus has on users of CalyxOS, but we believe this overhaul is vital to ensuring we can put our best efforts into protecting the privacy and digital security of people who trust us by using and contributing to CalyxOS.

What people should know with devices we currently support

Pixels

Modern Pixels

We have made significant progress bringing up Android 16 on all currently supported modern Pixels with GS201/GS101 chips (Pixel 6 and later models). We are cleaning up the Pixel device trees to make them easier to mantain and update in the future. Support is planned to continue despite the changes introduced by Google in Android 16. Update dates in the near future will be delayed as we adjust and improve our processes to build a sustainable and secure pipeline.

Extended support Pixels

Pixel devices in our extended support category will be evaluated after mainline Android 16 work is done. We will share more details once we complete the assessment of the possible kernel backport work required in the near future and feature compatibility.

Motorola, Fairphone

We are currently focused on completing our Android 16 port to Pixel devices. Support timeline will be reviewed afterwards with updates to follow per model.

Looking ahead

Our next step is to consolidate the schedule for ensuing updates and share it publicly, as is expected from our community. This will include adjusting timelines for Android 16 and security updates in the near future, between now and QPR1. If you are using CalyxOS with a device mentioned above, please stay tuned on our website for the update schedule. If you are looking to start using CalyxOS today, we recommend that you kindly wait for our next update. You can reach us in our community channels for any specific questions about CalyxOS, Android 16 and our plan. We will strive to release timely updates on our progress and plan as we have them, to our website.

As part of our broader mission, the Calyx Institute and CalyxOS team is committed to providing privacy-respecting tools and resources, centering on CalyxOS, that are accessible and usable by people, even as the Android landscape continues to change.

Google has released Android 16 to AOSP, but this year’s release is different in a significant way: none of the usual source code for Pixel phones has been made available. This impacts not only CalyxOS, but the entire custom Android ecosystem.

Here’s what we know so far.

Android’s release model today

• Google continues to build on the trunk-stable / quarterly platform release (QPR) model, which has evolved since Android 12.
• Instead of one big annual release, Android now rolls out larger and larger updates every quarter (QPRs), with features, UI changes, and improvements landing throughout the year.
• This model improves consistency but increases complexity—especially for downstream projects like CalyxOS. We’ve already started porting our changes to AOSP 16, but this cycle presents new challenges.

Why Android 16 is different

Android 16 was released to AOSP yesterday but with a one big difference than typical releases:

• Google did not publish any device-specific source code for supported, modern Pixel devices.
• In previous years, Google released full device trees alongside new Android versions. This allowed developers to build and boot AOSP on Pixel hardware relatively easily.
• With Android 16, only the platform/framework code has been released. The device trees are missing, at least for now.

This means AOSP 16 cannot currently be built or run on any recent Pixel device easily just using official source. It’s unclear whether this is a delay or a policy change. Either way, it seriously disrupts custom ROM development and our porting efforts.

CalyxOS Device Support Status

Pixel 6 - 9a

• Without official source code, these devices are currently unsupported for AOSP 16 builds.
• Pixel devices were widely supported in the custom ROM space due to their open-source friendliness (until now).
• We’ll need to approach them like other non-AOSP supported devices: with the GPL Linux kernel sources and updates to Android 15 device trees, which takes time and ongoing effort.

Fairphones, Motorolas

• We’ll look into the status of Android 16 on these devices after we’re done with porting CalyxOS changes in general to AOSP 16
• We’ll post an update per device once we know more.

Pixel 5 series

• We’ll look into the status of Android 16 at the end, and see what we can do, wrt extending support.

References

• Building AOSP for Pixel Devices (Android 15 Guide)
• AOSP Source code

Rollout

Changelog

• CalyxOS 6.8.20 / 6.8.21
• Android 15
• June 2025 Security update (2025-06-01)
• Chromium: 137.0.7151.72

moto g32

• Revert recent brightness changes causing low brightness

Note