I would like to propose a modular approach not only to the phone hardware, but to the operating system and the development process as well.
How would this look like:
A basic layer based on FP OpenOS and TWRP.
An additional layer of optional non-open apps like the Google stack. Phones could still be delivered with this layer pre-installed, or users could get a prompt at the first startup that ask them if they want to install Google or not. F-Droid would be the default app manager If the phone does not come with GAPPs preinstalled.
Fairphone marketing would probably benefit from this: “Fairphone - Ethical down to the bit!”
I think this could save costs and make FP OpenOS users in particular happier:
More effective use of development resources than he current two-track approach.
FP OpenOS would not constantly lack behind in fixes and development as in the present situation.
This type of OS could be an easier “entry point” into the world of FOSS software for many people.
OK, but we could still use the same base system instead of developing on two tracks: One with GAPPs preinstalled and TWRP for shipping and an open version without GAPPS that can be installed later. I have used cyanogenmod for years, with and without GAPPs. GAPPs is just a matter of patching another image in the system - bingo. I just don’t get it why it takes the FP dev team so much effort to maintain both the offical and the open version that in the end - to be frank here - some OpenOS users feel like “second class citizens”.
I believe that’s pretty much what is happening. I don’t know why lately Open OS is behind so much, but usually it’s released a few days after the standard OS. Sombody in the FP team just has to tweak the OS a bit so it excludes Google and includes TWRP and root. If they are sick or on holidays then there is no Open OS update until they are back.
I’m with you mostly, but note that flashing a GApps ZIP is an unofficial way to get the Google Mobile Services. We (as Fairphone owners) are not companies, so we are blind about what is the official way to integrate the said GMS to a developing Android system. It could be more complex than that.
I just mean processes are different, and Fairphone is not able to just flash an unofficial ZIP and redistribute that OS.
Do not forget: Android is a Google walled garden, and Fairphone depends on them (for better (sells) and worse (freedom))
I guess the reason is that the stock recovery is part of Android too. No pure Android, no GMS license.
Also, these previous comments of myself on the forum could bring more info to the matter. We can wikify the topic and add list of exclusive differences between the two OSes, maybe?:
I don’t know if there is a “repo for GMS OS”. Android is composed out of >200 git repos (depending on the version), and I assume that the GMS part just takes like 30 or 40 extra repos, but probably not as source code but more in binary form like the FP2 blob archives.
Regarding the “stock recovery” it seems like it’s part of the plain AOSP:
I recommend you to read this post [Edit: Added link to “Why I think Fairphone OS should drop root and pre-install Google Apps” by @ben] and the following (lengthy - you might want to summarize the topic) discussion. It’s a weekend read because it goes quite deep and has a lot of background information. Very interesting are also the posts by Fairphone’s former lead developer @keesj (filter out his posts by clicking this avatar and choosing “8 posts in topic”).
It’s good to keep this in mind always. I can understand well that Fairphone’s priority is to ship security fixes to the highest relative amount of their customers so that as many people as possible benefit from them as soon as possible. Maybe it’s a wrong suggestion, but I’d even go so far as to say that the 5% FPOOS users are more security aware than the 95% and can be “entrusted” with security wholes for a longer time, until they receive the fixes.
@Stefan: Sorry, but I can’t find the posts mentioned by keesj in this Android 6.0/7.0 topic, but of course I would be interested in the technical reasons why basing the regular FP2 systems on FP Open OS should not be feasible.
It’s out of question that the “regular” FP2 system has a larger userbase. However, to me this is not a valid excuse for why the regular FP2 system is not build on top of FP Open OS but the other way round or if they are two separate systems. If this was done right, every time you would build the regular FP2 system you would also be able to build the FP Open OS flavor.
I can’t judge the technical im-/possibilities of this approach, but from my own experience with software aystems from my (large) company I’d guess the main reason is just the history. Probably they started out with FP (GMS) OS to get it ready as soon as possible (to not delay FP2’s market start) and only after that either forked FP Open OS (or ser it up separately). Of course it should be possible to move this to a more favorable model (likw suggested in posts avove), but again this step costs time at first, even if it surely will save time later.