Fairphone 2 “Ethical” Smartphone Gets a Ubuntu Port

Orange Pi Development Boards

Fairphone aims to “create positive social and environmental impact from the beginning to the end of a phone’s life cycle”by designing easy to repair and long lasting phones that can be recycled and reused, and manufactured in good working conditions using conflicts-free materials. Their latest model is the Fairphone 2  5” Android 5.1 smartphone with a Qualcomm Snapdragon 801 processor, but you can now install Ubuntu on the device as UBports Ubuntu community has released a port for the phone.

Let’s go through Fairphone 2 hardware specifications first:

  • SoC- Qualcomm Snapdragon 801 (MSM8974AB) quad core Krait 400 processor @ up to 2.26 GHz with Adreno 330 GPU
  • System Memory – 2 GB LPDDR3
  • Storage – 32GB eMMC flash + micro SD slot with support for SDHC, SDXC, UHS cards
  • Display – 5″ Full HD (1920 x 1080) LCD TFT IPS touchscreen display with Gorilla Glass 3
  • Cellular Connectivity
    • 2x micro SIM (3FF) Dual-SIM, Dual-Standby (DSDS); Not shared with micro SD slot
    • GSM/GPRS/EDGE Quad-band: 850, 900, 1800, 1900 MHz
    • WCDMA Bands 1 (2100 MHz), 2 (1900 MHz), 8 (900 MHz)
    • 3G Max Downlink Speed Cat. 24 – 42.2 Mbps
    • 3G Max Uplink Speed Cat. 6 – 5.76 Mbps (Cat. 7 capable)
    • LTE Bands 3 (1800 MHz), 7 (2600 MHz), 20 (800 MHz)
    • 4G Max Downlink Speed Cat. 4 – 150 Mbps
    • 4G Max Uplink Speed Cat. 4 – 50 Mbps
  • Wireless  Connectivity –  Dual band 802.11 b/g/n/ac WiFi up to 433 Mpbs, Bluetooth 4.0 LE, GPS with A-GPS, Glonass, FM radio
  • Camera – 8MP rear camera with flash, 2MP front-facing camera
  • Audio – Rear facing speaker, 3.5mm headset jack, dual microphones
  • USB – 1x micro USB OTG port
  • Sensors – Ambient Light, Proximity, 3-axis Compass, 3D Accelerometer, 3D Gyroscope
  • Misc – Vibration Motor with Haptics Feedback; Power, Volume & Camera buttons; 3 color LED
  • Expansion – Backside expansion port for external case with USB 2.0 device interface and power input
  • Battery – Removable 2,420 mAh battery
  • Dimensions & Weight – N/A

You’ll also be able to buy spare parts in case you need to repair the phone with the display, camera, battery, core, top and bottom modules sold separately if you need a replacement. Fairphone 2 sells with Android 5.1 exclusively, so if you want to run Ubuntu Touch LTS, you’ll need to install it yourself with Magic Device tool. The installation procedure looks very easy as shown in the video below.

If you are interested you can pre-order a Fairphone 2 for about 524 Euros including 21% VAT.

Via Ubuntu Insights

Support CNX Software - Donate via PayPal or become a Patron on Patreon

19
Leave a Reply

avatar
19 Comment threads
0 Thread replies
2 Followers
 
Most reacted comment
Hottest comment thread
11 Comment authors
Paul GeraedtsBlahcnxsofttkaiserwilly Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Willy
Guest
Willy

Well, it seems from https://github.com/ubports/android_kernel_fairphone_fp2 that they’re using a completely outdated 3.4.0 kernel into which they backport their own fixes 🙁 When will hardware vendors understand that these dangerous practices are putting *all* of their customers at risk of getting their private data stolen and their device being rooted and remotely exploited ? There’s a reason LTS kernel branches exist and a reason why they have a (reasonably) limited lifetime… 3.4 was released almost 5 years ago. In the mean time we’ve had 3.10, 3.14, 4.4 and now 4.9 (just to count the official ones). In 5 years they didn’t manage to rebase their stuff onto a still supported one ? If that’s because of lack of time they’re not serious. If that’s because of a difficulty (eg: blobs), it simply means that the device is dead by design. I can only recommend *not* to touch this thing at all.

Fossxplorer
Guest
Fossxplorer

Price…

Sander
Guest
Sander

Fossxplorer :
Price…

The port is free.

If you mean the phone: it’s 523 Euro. The Fairphone is not meant to be cheap, but to be honest.

Sander
Guest
Sander

Willy :

Well said!

blu
Guest
blu

Good. We need more actual linuxes on mobiles.

peter
Guest
peter

@Sander

Thats right, but the relatively high price has much more to do with low order numbers. If such a device would be build in millions, it would be way cheaper.

peter
Guest
peter

Willy :
Well, it seems from https://github.com/ubports/android_kernel_fairphone_fp2 that they’re using a completely outdated 3.4.0 kernel into which they backport their own fixes When will hardware vendors understand that these dangerous practices are putting *all* of their customers at risk of getting their private data stolen and their device being rooted and remotely exploited ? There’s a reason LTS kernel branches exist and a reason why they have a (reasonably) limited lifetime… 3.4 was released almost 5 years ago. In the mean time we’ve had 3.10, 3.14, 4.4 and now 4.9 (just to count the official ones). In 5 years they didn’t manage to rebase their stuff onto a still supported one ? If that’s because of lack of time they’re not serious. If that’s because of a difficulty (eg: blobs), it simply means that the device is dead by design. I can only recommend *not* to touch this thing at all.

I agree that is would be nice to have options for phones, like we have on desktops. These ‘old’ kernels are still regularly patched by Google. Sadly, such phones and also such ports depend on Android kernels, because without closed drivers and firmware, you can’t do anything else. There is no really open hardware around to build a phone. And you also cannot expect that such a very small firm like ‘fairphone’ or their community members will deliver, what you want.

If you want a really open hardware phone, you would need to wait, f.i. for the Neo900. Or may be the ZeroPhone (based on the RPi Zero). But you will see that such phones will not sell in hundred thousands…

Linuxium
Guest

Old out-dated EOL unsupported kernel? Greg K-H has just the solution for you: http://lkml.iu.edu/hypermail/linux/kernel/1702.1/00296.html

willy
Guest
willy

@peter
I’m not asking for mainline-only kernels, I’m well placed to know that we all have our patches and I’m perfectly fine with this. What I’m saying is that any vendor kernel should be based on top of a *maintained* stable tree on top of which they apply their own patches. Their closed-source drivers need to be adapted to recent kernels, and if the chip makers don’t do it, simply don’t use these chips. As long as consumers will continue eat such crap, there will be no incentive for hardware makers to take bugfixes and security seriously.

The claim that Google&co backport fixes is a joke. First because they skip 99% of them that they don’t consider critical enough to warrant a backport. Second because without public review of the backports, it’s impossible to get all of them done correctly and not to miss any. There’s a reason we force ourselves to go through the annoying review process for each kernel, there’s no single time where it doesn’t allow us to detect a problem before the kernel is released. That’s absolutely mandatory nowadays.

willy
Guest
willy

@Linuxium
Ian, I’m well aware of this email. And you can bet that if Greg had to issue another 3.18 after it was dead, it must precisely be because of such people not properly doing their rebasing job but maybe at least considering updating within the same branch. 3.4 was already supposed to be EOLed by end of 2016 and Li postponed its death for a few months. But by the time these phones arrive in the first customers’ hands there will be no more 3.4 fix at all, ever. And anyway the kernel in it doesn’t even use Li’s tree so who knows anything about the quality and completeness of their backports ? It’s really sad that vendors repeat the same mistakes all the time.

willy
Guest
willy

So for those still doubting, I made the exercise of applying the missing patches from 3.4.113 on top of this kernel… No less that 5687 commits applied without any human intervention, indicating they were never backported there. Others failed due to conflicts with other changes and sometimes because they were already applied. Among the missing patches, 119 are fixes for the ARM subsystem, 302 for the core kernel, 254 for the network, 583 for filesystems, 56 for crypto and security stuff, 2788 for drivers. For sure not all of them are relevant to this device. But a number of them definitely are generic.

Oh and for those wondering, the famous “Dirty cow” exploit (cve-2016-5195) was not even fixed so at least you’ll trivially root your phone, just like any intruder… Pathetic. At least now you know what to hope from such devices running outdated kernels. DON’T EVER BUY THEM!

tkaiser
Guest
tkaiser

@willy
Thanks for taking the efforts. We (Armbian team) made the same experiences when dealing with ‘legacy kernels’ for a couple of dev boards, eg. patching HW manufacturer’s ‘port and forget’ kernel version always up to latest LTS version (currently dealing with 3.4, 3.10, 3.14, 4.4 and otherwise latest and greatest mainline kernel mostly on Allwinner devices). On most of these Android kernels ‘Dirty COW’ and friends are also not fixed and this most probably applies to the whole ‘Internet of shitty things’ running with vendor kernels too. Unfortunately users don’t pay (much) attention.

Do you know of a smartphone/tablet vendor really upstreaming device support patches to solve this issue? Or at least choosing any more recent LTS kernel branch and supporting them? I just ask since I’m not using Android and was pretty surprised looking at a friend’s phone some months back running kernel 2.6… so expectations are already at an absolute minimum…

peter
Guest
peter

@willy
I understand… Too few people care about this. I do not have a ‘smart’-phone, because I decided to wait for a GNU/Linux-phone.

blu
Guest
blu

I’m as much for kernel version hygiene as the next guy, but let’s get realistic here: how many SoCs can you think off the top of your head that have steady kernel support *and* steady GPU stack support? Because you know, that’s what it takes for a functional mobile. In practice the GPU stack vendor pins a kernel version, and from there on it’s on the good will of the SoC vendor to backport kernel patches for as long as possible. But SoC vendors are traditionally in fire-and-forget mode – they always are, as they have little incentive for a different MO. So unless you have a sizable community to back up a SoC in the long run, what small end-product vendors like fairphone do is inevitable. Either that or we don’t have such products, at all, and we all stick with ios devices, since apple are the sole timely-updates vendor on earth.

Willy
Guest
Willy

@blu
Hardware support has nothing to do here with using an unpatched 3.4 kernel. There are two issues :

– using and end-of-life kernel branch : this is indeed often dictated by the SoC vendor’s BSP, but can sometimes be solved by better communication between the SoC vendors and the stable maintainers. We still have too many LTS kernels but by joining efforts on less branches we can ensure having longer support on certain branches if that helps shipping still supported kernels. For example, 3.4 is dead in 2 months but it was still acceptable to sell 3.4-based devices 3 years ago.

– using unpatched LTS kernels : this is solely the device vendor’s fault and responsibility and there is zero excuse for this. It only took me 86 minutes to apply 4.5 years of patches to their kernel and I did nothing except a shell “for” loop. Can’t they spend 19 minutes per year to backport necessary fixes ? The problem is that as long as vendors will not do *this* part which is their responsibility, there will be no effort from SoC vendors to pick supported LTS branches since it’s useless… More importantly the fact that they don’t backport fixes comes from their total incompetence on the kernel, which explains why certain devices crash all the time, hang, experience
FS corruption or such bugs. So a long-unpatched kernel on a device simply indicates a lot of problems to expect using this device with no hope for a future fix.

Note that if debian picks kernel 4.9 and Ben maintains it for 5-6 years, we have a chance to start to see SoC vendors adopt it and ship it while still under support. But that will not stop irresponsible product vendors from shipping unpatched versions.

@tkaiser: unfortunately I don’t use android either. I’ve recently seen 3.10.73 on another stable maintainer’s phone. We both felt sad and helpless in front of this, thinking that tens of millions of people have mobile backdoors in their pocket that vendors know to be vulnerable and exploited.

@cnxsoft: indeed if you’re running 3.10.49, you’re missing ~2852 fixes. I’m fine with people who upgrade once a year or so on average with very old kernels, with the occasional quick upgrade when a critical fix is issued, the extended LTS kernels are maintained for such people who can rarely upgrade (typically servers). But 3.10.49 is 2.5 years old and is affected by many painful bugs.

We’re seeing with Android and some Linux ports for SBCs the same situation we’ve known with windows 95 20 years ago where it was almost impossible to find a non-infected one. It’s about time to act to make this stop.

blu
Guest
blu

@cnxsoft
I haven’t been following win10 closely enough, so I cannot really comment on them. But even if we assume they reached apple level of delivery one day – that would not really change the picture much, would it?

@Willy
I concur with your remark about end-product vendors having certain fault in the grand scheme. We should expect them to make the best of the LTS they’re given, and sometimes (more often than not) they don’t even do that. Luckily there are counter-examples as well – BQ launched with 3.10.93 last year. But it needs emphasizing how virtually impossible it is for the vendors to leave their LTS bracket, and that has everything to do with hw support (read: essentially android GPU stacks).

Blah
Guest
Blah

@Willy – please provide a short tutorial on how someone would patch the 3.4 kernel, on their phone

Paul Geraedts
Guest
Paul Geraedts

@Willy
What if Fairphone defines upstream as Google? If they follow the monthly Google security updates closely, I would say they act well defined. Maybe not optimal from a security point of view, but well defined. I value well defined.
My personal struggle is to see why -apparently- Google is not following upstream closely when it comes to the kernel. Could you please help me understand this better? Thank you in advance.