Should Fairphone prioritize on fixing Lollipop Bugs or upgrading to Marshmallow?

Sadly, that’s the way it currently is.

The ideal solution (in my point of view) would be:

chipset manufacturers (in case of the FP2: Qualcomm):

  • upstream all drivers to the mainline Linux kernel
  • (if needed: provide binary blobs e.g. firmware)
  • use a standardised way of booting the devices (e.g. EFI)

A build of just AOSP should be able to at least boot.

manufacturers (in this case Fairphone):

  • use AOSP as the base for everything
  • don’t make a mess inside the source code
    Don’t modify it!
    Use overlays.
  • provide device-specific configuration (e.g. a device tree - for the FP2 this - and it is unofficial)
  • provide vendor-specific configuration (e.g. a vendor tree - for the FP2 this - and it is unofficial)

A build of pure AOSP combined with the device configuration should be able to completely work on the phone.
A build of pure AOSP combined with the device and the vendor configuration should be exactly the same as the software the phone was shipped with (minus Google Apps, of course).

Users should be able to:

  • download AOSP
  • add the device tree (and optionally the vendor tree if they like)
  • build
  • run it on their phones

This has many positive aspects:

  • Users are free to choose whether they want to use the vendor specific branding.
  • Users are free to inspect the software (and more).
  • Porting new versions of Android (or even completely different Linux-based operating systems) will be much easier.

There is an additional aspect that I would consider positive, but the (chipset) manufacturers might disagree:
The users have full control over their devices (including future updates).

A few notes:

  • I haven’t tested the GitHub repositories I’ve mentioned.
  • “provide” means: Provide to the customer - or to everyone.

Why would anyone do that?

And why isn’t this integrated into upstream?

Because of the release model chosen by Google (i.e. closed development with public releases).

  • Google ends a new Android version → Throw the code through the window to the public
  • Qualcomm catches that code (fork) and improve performance and stability for their chipsets → AOSP-CAF source code
  • Google keeps working on minor releases of Android and Qualcomm try to catch with them

I read somewhere that when Google starts to work on a new Android version, they usually work on top of the CAF codebase, successfully integrating the fork into upstream. I don’t know if this is true.

This brings two different codebases at the same time: one that is more feature rich but not so neat, AOSP, and one that is more performant but behind, AOSP-CAF.


So, as i understood, none of the known bugs of the
FairphoneOS 1.10.1/ Fairphone Open 16.12 Buglist
is solved with the new Update?

Can somebody explain me, why?

Or am i wrong?

1 Like

That is what I meant, too. Camera fixes, Icon fixes, great!
I hope, they fixed at least the clock reset bug in the open OS.


Because of this, presumably (this was regarding encryption and TWRP):

@Johannes, like me, is not working at Fairphone, but this is what we hear from HQ.

1 Like

Camera has worked in the past, they made cosmetic changes :slight_smile:
I don’t understand, who tell the Fairphone Developers what should be done first.
Its very creative to make icons better looking and make some camera enhancements, but what is with the bugs?
Who and (probably more importand) when they will be fixed?
In the beginning i had some hope, Fairphone will do things better than the other big companies, who don’t give a f*ck about their customers and community.
But what i see now is the opposite of my hopes… :frowning:

Fairphone has a nice idea, nice Hardware but with a high Prise tag and lot of software bugs.
And the funniest thing is - Fairphone don’t promise to solve this bugs. They act so, as the bugs are not there.

1 Like

The more time spent of fixing bugs in Android 5 takes time away from the Devs getting Android 6 completed, tested and out to the beta testers (and ultimately the release). Bugs that are non-critical are unlikely to be fixed in the short term due to the Dev of Marshmallow, which is nearing testing as I understand it.


This is ok, but in this case all i want is an official statement:

Dear FP2 User: We will not fix the critical bugs in the Android 5.1 because we want to move to Android 6.0. All this bugs will be fixed in Android 6.0


Because of this, presumably (this was regarding encryption and TWRP):

I can’t understand this your comment, @Stefan
What has encription and TWRP to do with the actual buglist?

1 Like

I have no “official” guarantee on this, but we should be talking a matter of the next few months. Beta testers will be getting the update first - once it’s with the beta testers then we know things are moving forwards and Fairphone should be able to give you a better indication.

1 Like

The more time spent in doing icon changes and camera stuff takes time away.
@explit you are absolutely right!
Are the moderators here so much more patient than we are? Please don’t feel attacked!

1 Like

In case nothing changed in the past half year, then possibly no one:

[quote=“douwe, post:12, topic:20050”]
The software team is on a steady path releasing timely updates and fixing bugs at a good pace at the moment. It seems they work better then expected without a manager and are really good at managing themselves. Therefor the need for this position [software team manager] has declined and we also now removed it from our website. [/quote]


No feeling of attacked here, but understanding that FP have priorities which are beyond are own is where I think we need to be looking…

FP is pushing for more partners to sell via (i.e. operators), and for that some of these smaller insignificant things need to be resolved.

There are competing priorities, and while the Community priorities are one thing, FP is having to balance that against other challenges


I agree. I don’t care about Icons. But crashes during phone calls should not exist. Not if you use a device which should be made for calls!
Since I taped the battery the phone crashes less but still about one to two every day. Sometimes randomly sometimes during calls. thats anoing.

1 Like

Nothing, I just wanted to explain what @Johannes was talking about. The first part of the quote, however, is true for any minor bugs.

Ok, to be honest, I have my phases of being impatient. But we have to remind ourselves that people out there are suffering and that won’t change with fixed bugs. If they rather use their (wo)manpower for impact in the supply chain than for software development, I completely understand.

1 Like

I have a feeling, that they need to push an Update every month to show, that Fairphone is “better” than the other Android Smartphone Vendors, who don’t push updates very often. Public Android Security fixes is a good idea, but the critical bugs need to be solved. When the software is buggy - security updates would not bring a value in the “better FP2 experience”

So again FP2-devs: Please fix the bugs, switch to Android 6.0, do something - but communicate with the community. So like the things a running now - its not ok. Changing icons and polishing the camera software is a bad idea, when the bug list is full…


The problem is: When they don’t fix the bugs now - they won’t have anything to sell over the operators.
I can imagine, one customer would buy FP2 with contract from an operator. He comes home, put his SIM-Card in, start the phone, run software update and try to call somebody. And than he see, the phone rebooting during the calls, battery is sucked out in 8h (in idle) and so on…

What would this customer do, what do you think?
He would give it back and get another phone from the provider.
And provider would not buy FP2s any more because of this problems.

So selling a product with bugs is a very risky terrain. I don’t want to know how many customers send their FP2 back in the first 14 days after they were annoyed from the bugs

1 Like

This sounds absolutely reasonable at first, but did you ever think that not every developer has the same skills? Sometimes it’s a much better use of your time to do what you have the right skills for then to help with the most important issues.
My guess is that the camera tweaks are a preparation for the new camera module which sounds to me like a different area of competence then porting or bug-fixing.

Hard to say: I never had big issues with the clock reset bug and for a while now I don’t experience it at all anymore. I also never experienced the battery drain bug nor random reboots. If I had any severe bugs who knows how patient I’d be? (Well, I think I do. ;))

I think I can speak for all @moderators if I say: We love heated discussions that get by without insults. :slight_smile:


Basically I understand your concerns and also agree with you, that I also think bug fixing should be prioritized over tweaking gadgets like the camera.

But I also think that there’s no need to exaggerate. In my opinion there are no critical bugs open at the moment. I know you are very dedicated to the proximity sensor issue, and you have my sympathy. But I also think that this bug basically only affects very few users with certain third party software. SFOS is not an official port (unfortunately!), so I can see why this bug does not receive much priority. And on FPOS it only affects a few users that run certain apps which utilizes the sensor. After all, the officially supported OSs run just fine.
Then of course the annoying clock bug, which has frustrated me several times, as I am frequently in areas without a signal, not even to mention WIFI. Yet, FPOOS has a small user base, and most people in urban areas will not often be affected by it either.

I could continue this list, but I think the point here is: Yes, there are open bugs that we would love to see fixed. In the end though I think we also shouldn’t exaggerate, as most of these bugs affect very few users, while for the vast majority of users there are no critical bugs in the OS, but the FP2 runs stable and reliably.