TL;DR: /e/OS major Android upgrades currently arrive so late that the next Android generation may already be released. Could Murena reduce this lag through earlier upstream work, parallel development, greater automation and carefully applied AI-assisted engineering, while retaining human review, security requirements and physical-device testing?
Longer version.
Development proposal
I would like to suggest making the reduction of the major Android version lag an explicit development priority for /e/OS.
The issue is not specific to the Fairphone 6. It affects the general /e/OS release process and is particularly important for older supported devices, where a long delay in major Android upgrades can have an even greater impact on the useful lifetime of the device.
Current situation
A recent Fairphone 6 example illustrates the problem clearly.
Android 16 was officially released on 10 June 2025.
Fairphone released Android 16 for the Fairphone 6 on 16 March 2026.
The /e/OS 4.1.1 release based on Android 16 was rolled out in late July 2026, with the official FP6 Android 16 build becoming available around the end of July / beginning of August.
However, Android 17 had already been officially released on 16 June 2026.
So by the time the Fairphone 6 received an official Android 16 based /e/OS version, Android 17 was already the current Android generation.
From a user’s perspective, this means that /e/OS can reach one Android generation only after the next Android generation has already been released.
Information received from support
I previously asked about this delay.
Murena Support told me that it can take approximately one year after the release of a new Android version before the corresponding de-Googled /e/OS version becomes available.
Fairphone Support had earlier told me that approximately 3–4 months after the release of a new Android version could be expected for the de-Googling process.
These were support responses given directly to me, not published service-level commitments.
The significant difference between these estimates raises an important question:
Can the /e/OS major-version migration process be made substantially faster?
This is not simply about removing Google applications.
I understand that producing a new /e/OS major version is much more complicated than just removing Google applications from Android.
The process involves dependencies on upstream Android/AOSP, device-specific support, LineageOS, microG, /e/OS-specific system modifications, privacy features, applications, OTA upgrades, testing and many other components.
Therefore, I am not suggesting that the entire delay is caused only by “de-Googling”.
The question is whether the complete migration pipeline can be reorganized and accelerated.
Could more work begin earlier?
One possible improvement would be to start compatibility work for the next Android generation as early as technically possible.
For example, Android 17 reached Platform Stability in March 2026, several months before the final Android 17 release.
At Platform Stability, the API surface is already locked and developers can perform final compatibility testing.
Even if full source-level /e/OS porting cannot begin until the required AOSP, LineageOS or device-specific sources are available, some work could potentially start earlier, such as:
analysing API and framework changes
checking /e/OS applications for compatibility
identifying components likely to require changes
preparing automated tests
testing microG and system applications
preparing migration documentation
identifying potentially incompatible /e/OS patches
This could reduce the amount of work that has to begin only after the final upstream release.
Could AI-assisted development help?
Modern AI-assisted development tools could potentially reduce the amount of repetitive engineering work required during a major Android version migration.
I am not suggesting that AI should replace developers, code review, security review or physical device testing.
Instead, AI could be used as an engineering acceleration tool.
Possible uses include:
analysing differences between Android / AOSP / LineageOS generations
identifying /e/OS patches affected by upstream changes
assisting with patch porting
assisting with merge conflicts
detecting changed or deprecated APIs
analysing compilation failures
analysing build and runtime logs
suggesting fixes for repetitive compatibility problems
generating or updating regression tests
grouping similar failures across many supported devices
maintaining compatibility matrices
assisting with documentation and migration work
This kind of work is often repetitive and could potentially benefit significantly from modern AI-assisted development.
Privacy-respecting AI
Since privacy and digital sovereignty are core values of /e/OS, it would also be appropriate to investigate privacy-respecting AI development tools.
Where sensitive source code, logs or internal development information are involved, self-hosted or otherwise controlled AI infrastructure could be considered instead of sending development data to external services.
Separate common platform work from device-specific work.
Another possible optimisation would be to separate the common /e/OS platform migration from device-specific validation as much as possible.
A significant part of the work should be common across supported devices:
/e/OS framework changes
microG integration
privacy features
system applications
Settings modifications
default applications
common compatibility fixes
automated regression testing
Could this common platform work be completed earlier while device-specific work proceeds in parallel?
This could be especially important because /e/OS supports many devices. If too much of the release pipeline is sequential, the number of supported devices itself may contribute to delays.
Improve coordination with device vendors and upstream projects
For officially supported devices such as Fairphones, could Murena work more closely with Fairphone and other relevant upstream developers during major Android migrations?
For example:
earlier access to development information or branches where possible
parallel testing before the final device release
early identification of vendor-specific changes
shared compatibility testing
better synchronization between Fairphone, LineageOS and /e/OS release work
The goal would be to avoid unnecessary periods where one stage of the pipeline has to wait completely for another stage to finish.
Publish the migration status
It would also be useful to have a public status page for the next major Android generation.
For example:
Upstream Android analysis
AOSP available
LineageOS base available
/e/OS common platform port
microG integration
Core applications compatible
Automated regression testing
Community device testing
Official device testing
OTA upgrade testing
Ready for release
This would make the process more transparent and would also show where the main bottlenecks actually occur.
A measurable target
Could /e/OS define a measurable target for major Android version migrations?
For example, could the project investigate whether approximately 3–4 months after the necessary upstream platform and device components become available is a realistic target?
If 3–4 months after the original Android release is not technically achievable because important upstream dependencies are not yet available, it would be useful to make this clear and measure the delay from the relevant upstream milestones instead.
The important point is that approximately one year should ideally not become the accepted normal delay if parts of the process can be parallelized or automated.
Why this matters
This is not primarily about receiving cosmetic Android features earlier.
A newer Android base can also provide:
platform security improvements
new privacy and permission mechanisms
better compatibility with newer applications
framework improvements
new hardware support
a longer practical software lifetime for older devices
For a project focused on privacy, sustainability and extending the useful life of smartphones, reducing the major Android version lag seems particularly important.
Main proposal
Could Murena and the /e/OS development team investigate a structured programme to reduce the major Android version lag through:
earlier upstream compatibility work
greater automation
AI-assisted porting and analysis
more extensive automated regression testing
parallel platform and device work
closer coordination with device vendors and upstream projects
and a publicly visible major-version migration status?
It would also be very useful to understand which parts of the current migration process consume the most time and which of those parts could realistically be automated or accelerated.
The goal should not be to compromise reliability or security.
The goal should be to preserve the existing quality requirements while reducing the time between a new Android generation and the corresponding official /e/OS release.
just kidding, sorry.
