Events in room UB4.132

This is a review of the current state of Free and Open Source Software on Mobile devices. Mobile computing continues to be one of the most conspicuous and rapidly evolving software ecosystems ever, and open source software is at the heart of it - from the Linux kernel, the tooling, languages and libraries needed to write apps, through to devices that run a completely open source stack

We will talk about the changes in the way Google releases AOSP code and how that affects developers of custom ROMs and off-the-shelf devices. We will talk about developments in fully Android-free platforms, and we will talk about hardware support, drawing on voices from across the FOSS mobile community.

The presentation will be of interest to those already involved in the FOSS and mobile communities, and also to those who are just interested to get an overview of the landscape.

Android support for RISC-V is advancing rapidly, and this talk delivers an in-depth technical update on the open-source AOSP porting effort. We will walk through the current status of AOSP on RISC-V platforms, including ART/LLVM, Bionic, HAL and vendor-interface development, and compatibility work for emerging RISC-V SoCs. The session will examine the key engineering challenges encountered along the way—such as JIT/AOT differences on RISC-V, graphics-stack porting (Mesa, DRM/KMS, GPU drivers), GSI support, SELinux policy bring-up, vendor_boot and dynamic-partition layout, and end-to-end boot-flow integration. We will also highlight upstream contributions completed so far, the remaining gaps in the AOSP tree, and the milestones required to achieve full device bring-up and CTS/VTS compliance. Attendees will come away with a clear understanding of the progress to date and concrete opportunities for community collaboration to accelerate a fully open, fully native Android ecosystem for RISC-V devices.

The Android Open Source Project (AOSP) is more than just the yearly and now half-yearly releases of the Android platform source code. It consists of 3000+ git repositories, 1500+ repo XML manifests, and 1.8+TB of (compressed) source code data.

In this talk I want to give a detailed tour of the AOSP releases, the code, and everything that can be found in the AOSP repositories: How are the _rXXX releases assembled? And why do the git tags sometimes go backward? Where do I find the source code for my Pixel devices (until 2025)? What are the Build IDs? What are Brillo manifests, and why are they also in the AOSP? How are security patches released? Why is the number of git repos increasing with every release? And why is it decreasing with Android 16? How did the amount of rust and other code evolve over time? What is Project mainline and apex's? And where do I find the source code for these "Google Play system updates"? Where do I find the AAOS (Android Automotive Operating System) code and its releases?

These and other questions I want to answer in my talk.

Building Android is notoriously slow and resource-hungry. Even on high-end hardware, a full AOSP build can take hours, and each release continues to grow by ~10–20%, amplifying compile times and storage pressure. For anyone maintaining custom ROMs, vendor trees, or downstream forks, faster builds are not just nice to have: regulation requiring shipping fixes faster makes build performance a core productivity issue.

Over the years, the Android ecosystem has tried to keep pace with this growing complexity. Solutions like ccache and distributed build systems (goma, reclient), and even experiments with Bazel have all aimed to make builds faster and more scalable. But these tools were designed for other projects and struggle with Android’s unique challenges — lack of sandboxing, incomplete dependency tracking, and heterogeneous toolchains.

This talk explains how the Android build system actually works, why incremental builds so often fall apart, and where the time really goes. We’ll then walk through the major open-source acceleration approaches, their strengths and limitations, and what it takes to run them effectively in your own infrastructure—whether you’re a hobbyist with a homelab or maintaining a large downstream tree.

At IzzyOnDroid, we provide Reproducible Builds (RBs) for Android apps. In this talk, I want to outline:

• what Reproducible Builds are and what are some of their advantages
• how we approach Reproducible Builds in combination with our Android App Repo
• some of the challenges of Reproducible Builds for Android apps
• the most frequent sources/causes of failed RBs we encounter regularly (and how to address them)
• things Android App Developers should be aware of / take care for to give their apps the best chances to succeed with RBs

At the end of the talk, there should hopefully be some time for further questions (Q&A).

Securely signing Android releases, while being a critical process and operation for every AOSP-based project, has been lacking in comprehensive documentation, especially for building a production-grade and enterprise-level signing infrastructure. This talk presents our experience in designing and implementing a Hardware Security Module (HSM)-based signing solution for CalyxOS that ensures transparency and operational practicality while upholding security standards widely endorsed by security experts with limited resources.

We will walk through our process of defining criteria for secure signing operations and redesigning a signing infrastructure. In particular, we will discuss the trade-offs and our trajectory to technical decisions, including: * Security and operational pros and cons: Why use an HSM; * Our criteria for evaluating HSM solutions: Exemplified with the comparison between YubiHSM 2, Nitrokey HSM, Amazon Cloud HSM, and Entrust nShield in open-source standards, cost-effectiveness, and operational practicality; * PKCS#11 integration challenges: What it is, why it matters for HSM compatibility, and the specific code changes and scripts we made to to support it; * Key ceremony design: The use of Shamir's Secret Sharing (SSS) schema for recovery and additional backup and lessons from the provisioning process; and * Audit logging and cryptographic verification of signing operations.

In addition, this talk invites discussions from participants on experiences in operational security and building trust through transparency and communication. We will focus on how to balance complex Android development needs and overcome challenges with constrained resource and scant systematic documentation. This talk aims to start collaborations on issues such as concurrent multi-device signing, ceremony design, and community-driven criteria across FOSS development teams.

NewPipe is a widely used FOSS Android app that provides privacy-respecting access to YouTube, PeerTube, and other streaming services. It can search, view channels, play videos, listen to playlists, download media, and more.

Developing an application with so many distinct features often involves compromises or feature trade-offs. During the talk, we'll explain how TeamNewPipe takes these decisions together with the community. In recent years the team has been supported by NewPipe e.V., a German association which strives to promote access to libre digital media, even outside of the NewPipe app. This more general spirit dates back to the beginning of NewPipe, when the backend library that scrapes data from services was made independent of the user interface, making the backend ideal for use in other projects.

Usually it's hard to port Android apps to other mobile Linux platforms due to the use of Java and the tight integration with the Android APIs. The user interface libraries required aren't available outside of Android emulation layers and, even if they were, the user interface paradigms would differ greatly. In this talk we'll go on to describe our efforts to port the app to Sailfish OS, a Qt-based mobile Linux platform with a user interface paradigm that differs significantly from Android's. The process took us on a fascinating journey, compiling Java code for a platform without a JVM and integrating it with the Qt (C++, QML, Silica) layers above.

This talk will cover topics relevant to AOSP users, mobile Linux users, the Sailfish OS community, Android developers and Qt developers.

Since August 2025 IzzyOnDroid has been providing app download stats for the IzzyOnDroid repository and since September, Neo Store has included these download stats in the client, with Droid-ify support hopefully releasing before this talk.

This lightning talk will quickly go through: 1. How the download stats system works 2. Which applications already show the stats 3. How to use the stats in your own applications

Relevant links: Download stats dashboard: https://stats.izzyondroid.org/ Neo Store: https://apt.izzysoft.de/fdroid/index/apk/com.machiav3lli.fdroid

iod-stats-builder: https://codeberg.org/IzzyOnDroid/iod-stats-builder/ iod-stats-collector: https://codeberg.org/IzzyOnDroid/iod-stats-collector

The maps application is one of the main usage of the smartphones nowdays. Let's introduce Cardinal, (not) yet another mobile maps application. It intends to definitely offer an alternative to Google Maps.

In this lightning talk, we will introduce what it is, how it differs from other open source maps application (OSMand, Comaps and others), and how we are building it.

Project source code: https://gitlab.e.foundation/e/os/cardinal

There are a lot of code releases from AOSP: there is a major release once per year, Quarterly Platform Releases (QPR) every quarter, plus releases specific to particular segments, such as Automotive, or devices, e.g. the Pixel Fold. On top of this there are regular security fixes.

This short talk will try to make sense of all of these data points, and show how they relate back to the release number, which is the canonical identifier of a release.

Key takeaway: Knowing the way Google identifies releases helps you understand the release cadence and which tag you may want to use when building Android

OpenHarmony offers a compelling FOSS alternative to the mobile OS duopoly, but porting it to real phones presents unique technical challenges. This talk shares practical insights from bringing Oniro, an Eclipse Foundation project focused on making this technology usable beyond its original ecosystem, to mobile devices. We'll cover the complete porting workflow: QEMU-based x86_64 emulation for rapid development cycles, kernel adaptation strategies for diverse chipsets, and our LibHybris integration to bridge OpenHarmony's musl libc with proprietary Android binary drivers, unlocking GPU, and peripheral support on existing hardware. Beyond the technical stack, we'll discuss developer experience improvements that lower contribution barriers: VS Code-based tooling, and early app ecosystem expansion through React Native and cross-platform framework support. Whether you're interested in AOSP alternatives, mainline device enablement, or building truly open mobile platforms, this talk demonstrates a practical approach to accelerating FOSS mobile adoption today.

I maintain the Collabora Office mobile apps: office software for mobile devices based on LibreOffice. I've been at FOSDEM twice before, and each time I've had people approach me and ask if the apps could run on mobile Linux.

Each time, I've had to tell them "not yet". This year, I finally have a mobile Linux device running Collabora Office. It's not perfect yet, but it works, and it can give a glimpse into a future where a mobile-optimised Collabora Office is available outside of the mainstream Android/iOS mobile duopoly.

I'll give you an overview of how we got here, how I'm doing this, and what's still left to do before we can get my demo on your mobile Linux device.

Let's review what has happened in the lands of upstream kernel development on Fairphone devices in recent times. Where are we now in 2026? Where are the major pain points now? Can you use postmarketOS on a Fairphone as daily driver yet? Let's find out!

After last year's FOSDEM we set "Improve the reliability of postmarketOS!" as main goal for 2025. This lightning talk covers what shiny puzzle pieces we have built throughout last year and the exciting future that awaits us now that we can flip the box on the table and assemble all of them to a nice picture reliable operating system! 🧩

Phones running Linux became reality in last few years, and they do have cameras. Every notebook and most computers do have cameras, too, and there's a lot of effort to get good support for them concentrated around libcamera project. Unfortunately phones have different hardware than computers (dumb vs. USB cameras) and use cases are very different.

Pavel will explain challenges presented by phone hardware, explain what is needed to take good photos with phone such as Librem 5 or OnePlus 6, and explain additional challenges with video recording. He'll also talk about his work in this area, Clicks Machine and Millicam and improvements to Megapixels, Millipixels and Libcamera projects.

To understand how we can replace Google push notifications (FCM) with something open source and decentralized, we need to understand how they work and why they are needed in the first place. This talk explains the mechanics of push notifications and why, despite their potentially bad reputation, they are a more elegant solution than having every app maintain its own persistent server connection.

While open-source tools like microG can remove proprietary Google software from your Android phone, the actual notifications are still sent via Google's servers (Firebase Cloud Messaging).

UnifiedPush is a framework that allows push notifications to be delivered in a decentralized manner or through self-hosted servers. Numerous open-source Android apps already support UnifiedPush, including Tusky, Ltt.rs, Fedilab, DAVx⁵, Fennec, Element, and many more.

The presentation ends with a short demo on how to use UnifiedPush on Android.

Phosh is not just a popular user interface, but also a project that aims to propel Mobile Linux forward contributing mobile-specific bits where necessary. With yet another round around the sun it's time to share what we've been up to since our last status update

So far, almost all mobile phones capable of functioning with close-to-mainline Linux kernels (with the exception of special phones such as the PinePhone) are based on Qualcomm SoCs. Unisoc is an alternative SoC manufacturer from China that is often overlooked due to its focus on the low-end segment and lack of upstream kernel support for important features.

In 2024, Jolla released the C2 community phone as a new reference device for Sailfish OS, based on the low-end Reeder S19 Max Pro S from Turkey. This phone uses the Unisoc UMS9230 (Tiger T606 / T7200) SoC. A bit more than a year has passed since the phone was first released and the official port still uses libhybris. Meanwhile, I have been working on an unofficial mainline Linux port and am daily-driving it now. Some things are still not working, but there has been a lot of progress since the last FOSDEM.

This talk is going to explore the challenges involved in porting mainline Linux to a new SoC platform, the features I have implemented so far, and the opportunities this creates for Sailfish OS and other mobile Linux projects such as postmarketOS.

Linux kernel fork: https://codeberg.org/ums9230-mainline/linux \ Sailfish OS port: https://forum.sailfishos.org/t/mainline-linux-kernel-for-the-jolla-c2/21382 \ postmarketOS port: https://wiki.postmarketos.org/wiki/Jolla_C2_(jolla-c2)

GNOME OS is GNOME's development, testing and QA operating system. It builds the in-development versions of the GNOME desktop and core applications. It is also a modern image-based Linux system.

In this talk, I'm going to present recent efforts to run GNOME OS on phones. Right now, the FairPhone 5 and the OnePlus 6 are supported, but ideally we could support any phone that is supported by the mainline Linux kernel.

I will briefly present the different tools and projects that make this possible, and what we're hoping to achieve from this initiative: better testing for the GNOME applications, and more ways to do FOSS on Mobile.

"Okay, this Linux on Phones thing ... but it has no apps, right?" It has apps - Sailfish OS and Ubuntu Touch have dedicated app stores, and the newer projects also have many well working apps.

This talk is a refresher on my 2024 FOSDEM talk, with a focus on what changed - a call to action.

It has been two years since the initial mainline Linux support for the Snapdragon 8 Gen 3 (SM8650) was posted on the very day of its marketing announcement and used to present the Qualcomm platforms mainline state in this very conference on an SM8650 HDK development board. What started as basic boot support with display has evolved into a fully-featured upstream ecosystem, but the road was far from smooth.

In this session, we will explore the technical evolution of SM8650 support, moving beyond the "it boots" milestone to a fully usable system. We will dissect the challenges of enabling complex subsystems—from the Hexagon DSPs and Adreno 750 GPU to the intricate power domains that modern SoCs demand to properly support runtime power management and suspend-to-ram state.

We will also address the often-overlooked bootloader story, showcasing the current state of upstream U-Boot on this platform and how it interacts with the standard EFI boot flow.

The Talk Will Feature a Technical Post-Mortem about the whole upstreaming process and a live demonstration running mainline Linux on actual Snapdragon 8 Gen 3 powered device running the mainline kernel with code changes—proving that upstream support is no longer just for development boards.

There are lots of carving tools out there, but surprisingly there's no open-source one for carving JSON objects. Reporters United, a network of investigative reporters in Greece, wrote json-carver as part of our investigation into the Telemessage leaks. json-carver is a FOSS tool written in Rust, that can recover JSON objects from any binary stream, even partially-corrupted ones.

We'll discuss the role of this tool in our investigation, compare its accuracy and speed against strings(1), and show how to use this tool in any of your future investigations.

Bugbane is an open-source Android application that simplifies consensual forensics by building on Amnesty TechLab's Mobile Verification Toolkit (MVT). Bugbane makes MVT's capabilities accessible to everyone through a user-friendly interface, allowing users to self-test in just a few minutes without needing a second device. It also enables periodic data acquisitions, supporting the analysis of past acquisitions with updated IoCs in an "acquire-now, detect-later" workflow. Bugbane reliably extracts and decodes key artifacts like installed apps, backups, and system logs, and allows users users to export AndroidQF-compatible age-encrypted archives.

The goal is to expand access and usage, helping users and supporting organizations work more efficiently, and reaching a broader audience, including less-technical individuals and communities currently outside civil-society support. In the longer term, Bugbane aims to strengthen the collection of open threat intelligence that can be shared with researchers, analysts, and civil-society organizations.

• https://github.com/osservatorionessuno/bugbane
• https://osservatorionessuno.org/blog/2025/09/bugbane-simplifying-consensual-android-forensics/

In this talk, we will introduce PUMA (Programmable Utility for Mobile Automation), an open-source Python tool developed by the Netherlands Forensic Institute. PUMA streamlines mobile app automation by allowing users to define high-level actions—like sending messages or searching in apps—without manual UI scripting. PUMA is designed for ease-of-use and reproducibility, making it ideal for testing, research, and workflow automation. We’ll explore PUMA’s architecture, key features, and practical applications, from forensic purposes like generating reference datasets, educational purposes like how to validate your application, to personal use cases like automating repetitive tasks. Whether you’re a developer, tester, or automation enthusiast, discover how PUMA can save time, reduce errors, and unlock new possibilities in mobile automation. https://github.com/NetherlandsForensicInstitute/puma

Fox-IT's Dissect has a huge collection of features and parsers, but what does it take to maintain those and, more importantly, make them easily usable and accessibly to analysts? Wondered how we made recursive hypervisor analysis a hell of a lot easier? Or why it's so ridiculously easy to build custom tools on top of Dissect? Join us as we take you on a tour of some of the features of Dissect, as well as the challenges that come with maintaining it.

Activists and whistleblowers often handle sensitive documents that can incriminate both the exposed parties and themselves for acquiring or distributing the material. To move forward with their revelations, they must ensure they leave no identifiable trail. Enter Dangerzone, an open-source tool that sanitizes suspicious documents and removes incriminating metadata in the process.

This talk covers metadata removal: concrete examples of how metadata has been used to de-anonymize authors and distributors, the limitations of current tools, and the challenges posed by adversaries who can apply advanced watermarking and tracing techniques to documents.

The absence of forensics data can be just as dangerous as the presence of malicious activity. While traditional digital forensics focuses on artefacts located on storage devices, containerized environments like Kubernetes introduce new challenges for collection of digital evidence from compromised applications, where malware now routinely leaves no traces. In this talk, we are going to explore how to collect, preserve, and analyse forensic snapshots with transparent checkpointing methods while maintaining a chain of custody to investigate security incidents. We will also discuss techniques for automation in real-world scenarios and best practices for capturing and analysing malicious activity in compromised containers.

Someone on the internet told me I was wrong. Or, well, that my code was wrong. And a totally normal response to that is to spend over a month reverse engineering proprietary kernels and kernel modules.

How did we get here? Well, once upon a time I was fed up with all the bugs in vmfs-tools and vmfs6-tools, so I wrote my own VMFS implementation. Except that I took a lot of shortcuts, and in doing so I inherited some of the same bugs! Fast forward to 2025, and those bugs are finally catching up to me.

Join me as I go over the excruciating process of gathering decade old ESX(i) installation media, hunting for debug symbols, and trying to piece together how VMFS actually works. Oh, and fix that bug, of course.

Software reverse engineering is a very useful tool in digital forensics. Not only can it tells us a lot about the inner workings of the software of interest, it can also lead us to quirks and even vulnerabilities not even available in the source (e.g. compiler quirks). With enough effort it even turns proprietary implementations into open-source, what's not to like?

Of course, with a technique this powerful, there will always be downsides. Reverse engineering large binaries can be a monumental task. Where a few kB's of storage seem tiny, a few kB's of code can be huge if you have to reverse it all. A secondary problem to this, is that all this work is quite hard to reuse in the future. Binary code can differ, even with the same source, purely based on compiler options. SRE tools change, making your scripts obsolete. Decompilers change, making your signatures obsolete and so on.

We present an open-source machine learning model, server and Ghidra plugin for creating function signatures from aarch64 assembly. These function signatures can be stored and compared to a database of known functions to easily reuse all the blood, sweat and tears you put into reversing that library that has since been updated twice.

All code is of course open source and available at https://github.com/NetherlandsForensicInstitute/asmtransformers

After working on a 12+ week project looking at how to express in the varied UI's of three package repositories (npm, pypi and RubyGems) we can now see more clearly what developers, across skill and knowledge levels, use in package repository pages to make a decision on the security of an OSS located on a registry. These decisions are critical for better understanding trust, value, social proof and the knowledge of secure practices across developers and helps answer the question: how much do developers know about the security of their software supply chain?

This talk will cover: 1. The essential user research findings from the project, 2. How user research informed the UI style guide design build 3. What gaps and opportunities are here to continue design in the SBOM, Attestations and securing software repositories topics.

https://github.com/ossf/wg-securing-software-repos/tree/main/docs/attestations-style-guide

We spend enormous amounts of time and money auditing code for security holes. Whole industries are built around it. But for all that effort, we rarely look at the part of the system that is actually clicking the buttons and interpreting the warnings. The person with Dorito dust on their fingers and a coffee ring permanently branded on their desk, someone just trying to get things done in a tool that may or may not be helping them make safe decisions. A surprising number of real-world security failures happen not because the code is flawed, but because the interface leaves too much room for dangerous misunderstandings.

Drawing on our work at Ura with security-critical and open source projects, this talk explores how the user experience itself can introduce or amplify security risks and why these issues often slip through traditional code-focused reviews. We will look at memorable examples of user-driven failures, outline common UX surfaces where security risks emerge, and show why auditing the human side of the system is just as critical as auditing the code.

What does safety look like in the age of Grok, misinformation, doxxing, and technology company founders imposing their own views of safety, surveillance, and ethics on their platforms? As a former trust and safety employee of the Wikimedia Foundation, and online gender based violence expert with over a decade of experience, this talk will cover new design patterns, best practices, and product tooling to help achieve safety, security and foster trust for all types of communities online, but especially marginalized and vulnerable ones. This talk will reference ongoing research on Designing for Safety, a current project of the speaker's, and builds on notable work in the Trust and Safety field from research by Pen America, NDI, the Web Foundation, the Integrity Institute and others. Parts of the talk will focus on how open source design can be a part of the solution space for creating safety, and how transparency, security and privacy should be leveraged for safety online. This talk will also reference actionable design insights, UX, UI, new types of product design, and design related policy that could be implemented all for safety.

Gephi Lite is a web-based open-source network visualization tool built by a three-person engineering team. After two years of development, we had a functional application—and a nagging feeling that our interface wasn't working for users. The problem: we lacked the skills to diagnose what was wrong, let alone fix it. So we brought in Arthur Desaintjan, a design intern, to help us figure it out.

In this talk, we'll share how we approached design at a pivotal moment in our project's life—first by stepping back to clarify what Gephi Lite should really be, then by running user interviews that revealed just how far our assumptions were from reality. We'll walk through the specific findings that surprised us, the design decisions that followed, and what small open-source teams can learn from our experience about investing in design when you don't have designers.

Resources

• The project's website
• The web application
• Arthur's blog post about this journey

Design systems evolved the process by which UI graphics are made, full with automation and deep integration. However, Open Source communities were left out of this bandwagon as most of the applications providing these capabilities were for pay or very limited for users.

Fortunately, a new wave of design system applications, led by PenPot, has made an appearance with a bold strategy and Open Source at its core. As such, KDE Plasma saw an opportunity to build something unique to develop the Plasma desktop faster and with higher fidelity to user experience standards.

This is the talk about the journey and current state of implementation at the KDE Plasma Deskop. In this talk we discuss graphics, colors, typography, graphical components and much more. How the journey took us from a limited application for pay to a fully Open Source system.

Open source thrives on contributions from developers, testers, and community builders, but design often gets left behind. With far fewer dedicated designers in FOSS than in the commercial tech world, usability issues go unaddressed, and end users feel the friction. The good news: you don’t need a design degree or a new job title to make a difference. In this talk, I’ll show how any contributor can use simple, practical design methods to identify and solve UX issues in their favorite open source projects. I’ll try to break down “design” into simple steps anyone can try, noticing where people get stuck, asking the right questions, sketching ideas on paper, and trying them out with friends or community members. No special skills or software needed: just curiosity and a willingness to make things easier for others. If you’ve ever thought, “I see the problem, but I’m not a designer” - this talk will give you the mindset and tools to step up and become one.

Understanding your users should be an important step of software development. In recent years, many end-user facing FLOSS communities integrated at least some aspects of design into their development. Unfortunately, most developer-centric projects still haven't started to even think about it.

This talk concludes two years of user research in Forgejo, a Git-backed software forge and collaboration platform. Forgejo can be self-hosted or used on a public instance like Codeberg.org to create software together, from sharing and reviewing code to tracking user problems, doing project management and doing design work.

Key points include:

• Surprise: False assumptions we made about our users.
• Challenge: Understanding complex and technical use cases.
• Bad-practices: Why "Feature Requests" and the common workflow to create software might actually be a terrible idea.
• Some ideas: Scaling user research beyond the team of one.

The talk considers usage of eye trackers to track usability issues in FLOSS. The use of consumer-grade hardware eye trackers is considered for cases when there is an SDK for Linux available, and when there is not. A webcam-based software eye tracking approach is considered as well and compared with hardware eye tracking using illustrative examples. Visualization of short-term and long-term eye tracking data series is explained with sample code for Graphviz and GNU Octave. Examples of eye tracking heatmaps and their usage scenarios are discussed, as well as using mouse heatmaps as supplementary data.