Continous security and bug fix process

Hi Fairphone team,

this is more a general question than any form of bug report or trouble. Recently, there have been a couple of incidents with security flaws in Android. Such incidents occur in any software-ecosystem. However, in the Android ecosystem the update rate is low. Fox example, most bugs in Linux operating systems (kernel or application layer) are normally fixed in days. And in the same time update are available to the end user. In the time between release and fix, users get informed by their vendor or distributor. With Android this is totally different. And that is a sad thing, because Android is not that different to other Linux distributions.

Therefore, it should be possible to establish a continuous integration service which rebuilds and tests Android every time a new fix come in. When it works it is automatically offered to the end user. From personal experience, I know that this sounds like a lot of work when the present development of the OS is not based on such technologies, but (a) if you switch you will profit from it due to better a workflow in the software development, and (b) after setting it up, you will see that it sounded more complicate in the beginning than it really is. As a bonus the software, which is nowadays equally important than the hardware, can be used for a longer period resulting in more sustainability. And in the end that is what it all is about with Fairphone, isn’t it?

Kind regards
Reiner

3 Likes

This is true. But the real 'vendor" of FP OS should be considered MediaTek. While Linux is a modular OS where you can install and remove almost any part, vital parts of Android are modified by MediaTek, distributed as binary blobs and cannot be patched by FP team. So your approach can only work for the parts of OS that can be modified by FP.

That said, it still should be possible for FP to distribute small patches more than once or twice a year.

This is a community led forum. If you want to make sure that someone from the Fairphone Team reads this, you must contact them directly through support.

I’ve assumed that the company employees are also reading the forum and, therefore, everyone can see their reply to the message, but just in case they did not read my post, I will send them a letter (also called email). :wink:

Thanks anyway
Reiner

2 Likes

Are you suggesting pushing nightly builds to end users? Sounds like a bad idea to me.
Also consider the current update installation process. It takes 10 to 15 minutes and requires a few manual actions. Not something I’d like to do daily or even weekly.
Android’s rough update process is something that I doubt FairPhone or even MediaTek can fix. It’s up to Google to make Android updatable in similar fashion to Windows updates (small patches, quick to download/install and silently installable)

No, as far as i understand he is suggesting continous builds, you do not have to update every day, but if you know a bugfix for a small annoyance has been fixed for example, you can try right away. This way, regular builds are well better tested, in addition to knowing you always have a buildable, working systen in case fast responses are required (in case of security updates for example).

Well, in that case, FairPhone also better hurry up and release the FairPhone OS source code. No, not the MTK proprietary bits but FP’s kernel and app code. The current KwameCorp github dump is severely outdated and incomplete.

1 Like

That might have been a little misleading. I would suggest building it on a nightly basis, if and only if changes to the code base have been made. And with providing to the user. I would not push Updates to the user every day, but give him or her the option to check the newest version. Maybe this can also be done on a package level, so that not the complete OS must be transferred. Pushing to users is only necessary when security fixes were made and must be published.

Correct. Both OS and all extensions should be available via a git repository. Like most phone companies Fairphone did not fully realize that they are also an software distributor, like Canonical, RedHat, SUSE etc. and, therefore, they should learn from them how to handle software.