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

@moderators EDIT: Moved from here as this was getting off-topic.

I am not in favour of Fairphone development going the typical route: Leave the old with bugs behind and work on the shiny new. IT “history” has shown too often that at the end you are sitting there with an old buggy version AND a new shiny one full of edges and quirks to be sorted out.
As much as I am looking forward to Android 6, I am using my phone for business and that means reliability has priority over “new and shiny”. From a business / reliability point of view it is just unacceptable how serious bugs like the “clock bug” and the battery drain are getting neglected for months! I understand if there is a lack of resources, but at least in my business I try to get the pending jobs done instead of starting new ones in such a situation.
Please Fairphone devs use the same strategy that is used for the hardware: Upgrade and fix the existing so that it can live longer instead of “planned obsolescence” in the OS.


I think you are comparing apples and oranges here. Working on an Android Upgrade for FP2 will benefit all FP2 users. There are no FP2s with weaker hardware that can’t handle Android 6.
Upgrading to Marshmallow will probably fix some bugs in one go, maybe even faster than fixing them one by one on Lollipop. But you can also be assured that the dev team are no dummies and they know that some bugs are related to firmware and drivers and as you can see with the random reboots they do still have people assigned to fixing things on Lollipop.


I agree in principle, but not if that means waiting more months to have problems fixed that where brought to the awareness of the dev-team over half a year ago. I would understand if there is an official statement that certain things cannot be fixed in the current version because of incompatibilities, but I have very little understanding for getting no clear answers and it then becoming more and more obvious that the main dev activity is going into the future.

… and will introduce very likely new, at the moment unforseeable bugs, that require attention.


I can’t see any reason for such an assumption. And if you are right, they should fix the still exsisting big 5.1-issues for 5.1 and also for Marshmallow. We all have made and are making our experiences with the Fairphone 5.1 OS and I remember very well how it started last year.
I don’t want to have that again, but there will be some more or less severe issues with the update, I am sure! And for that situation I prefer it very much to be able to go back to a really stable 5.1-OS, in case it is needed.


I don’t think so. When the FP2 was released there had not been any final prototypes and it was shipped to the customers first and only then to the support and software team. So they heard about all the issues from customers before they could test and fix them. With the upgrade to Marshmallow there will certainly be an extensive beta test with - I’m very certain - many many voluntary testers.
If there are any severe issues they will be found during beta testing and fixed before the final release, even if that means the release will be postponed for months - like it’s the case with the FP1 atm.

Well, the clock-bug is pretty obvious and must have slipped through. The same thing can (and very likely will) happen again. It’s just in the nature of beta testing that some things just don’t show up: For example the majority of beta testers might live in cities, so the product does not get enough rigorous testing under weak signal conditions etc. Nobody to blame here, but starting with a new version always has risks.
It is known in aviation that planes that grow older and have passed several maintenance cycles are safer than new ones, because problems got fixed and systems improved.
This is why I would appreciate a conservative approach that ensures that there is always a stable and ideally bug-free version available.


I’d like to bring another aspect of the story to your attention: Imagine a person, who needs a new phone and kind of is into ecological buying, but then that person learns that the Fairphone runs old software that was released in late 2014. Google stopped releasing security updates for Jelly Bean after 2,5 years. They could do the same for Lollipop, which would mean that in May 2017 there would be no security updates any more.

Fairphone is completely at the mercy of Google here and they always have to fear that older Android versions are cut off by Google without prior notice. There is no Long Term Support version like with other popular software products (e.g. Ubuntu).

A second aspect I’d like to mention is the perspective of the smartphone industry in general. Fairphone started out to change the system and has made some impact and earned respect from mobile operators. What will the industry say, if Fairphone can’t keep up with the fast pace? Nice little project, but they can’t even update their OS to a newer version.

Since Fairphone themselves ruled out newly engineered phones every other year, they have to provide “new” phones by other means, for example with software updates.


Do you really think, the clock reset bug will be fixed automatically with Marshmallow? I don’t.
And that is one of the most annoying known bugs. And fixing this must have a higher priority.


I think Fairphone should not upgrade to Android 6 only because of the security updates. I prefer an stable Android 5.1 over an unstable Andropid 6.0

Fixing security holes is very good, but only IF the Software base is stable. I can’t say i will be happy with my shiny new Android 6.0 on my FP, which fixed a lot of security holes, but in the same time being unstable with basic functions like sensors, power management etc.

So i would prefer to concentrate all resources to fixing bugs and made the software base stable.
I read also another Forums about other Android Phones like OnePlus or Xiaomi Devices.
Ok, they have much more resources than Fairphone, but they Forum is not flooded with users, who has Problems with the basic things.

Software bugs need to be solved first, give the user an stable system. Afterwards they can fix bugs, make updates, anything they want.

I was very enthusiastic about Fairphone 2 at the beginning. But my patience has also limits.
I will wait till Juni 2017. (It will be exact one year, since i got FP2)

If all the bugs, which make my FP2 experience bad will be solved - i would move on with the FP2,
If not - i will sell it and left the community.

I try to do for the community as much as i can, i support it, i"m active on forum, i do bug testing, write manuals, help other users, try to find workarounds and solutions.
But i am also a customer. I bought a product, which i can’t use because of the software bugs.
What do you think, how long i should wait, until the bugs will solved?
How long i should wait, when nobody answer on my requests?

I hope Fairphone will hear on their community members and change something.


They are probably porting Marshmallow from scratch, not basing it on Lollipop. AFAIK, there’s no other way to do it. Custom ROMs teams rework (git rebase? Hard) their features on top of the new codebase. That’s one of the reasons Android is so fragmented and quickly obsolete; their upgrade model is broken by design.

Anyway, having a fully working base leads to clear answers when reimplementing things in the new codebase. It’s simpler to port, basically. I really hope the Fairphone team has learned from the experience and will build Marshmallow well. It will be hard for me (and others, sure) to keep supporting the product (not the proyect of ethical electronics, obviously).


The ideal way would be to not modify AOSP, but to use the device and vendor trees instead. (StackOverflow and AOSP)

If there’s really a need to modify the core of Android, you could use git rebase.

(But none of this is in the hands of Fairphone. I guess they receive the whole mess from their suppliers and not from AOSP.)

1 Like

Time for the neat HTC infographic!!! :smiley: :smiley: :smiley: :rocket:


Oh, I forgot about that. True, that was something I observed while porting CyanogenMod and trying to make a universal device config. They don’t use overlays at all, but modify the source tree directly.

BTW, they work from the AOSP-CAF base, not pure AOSP.

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