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.
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.
Camera has worked in the past, they made cosmetic changes
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…
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.
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.
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.
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!
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]
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.
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.
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
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.
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.
