About two weeks ago I again put my SIM card into my Pinephone to see whether I can make it a daily driver device. The last time I tried this was nearly a year ago so I have that benchmark to compare it to as well as some new information now.
The stack:
The highlights:
The details:
Firstly let's talk about cell tower APNs (access point names?).
My Pinephone automatically detected my T-Mobile SIM card and set up the APN
named mobilenet
in my Phosh settings. Apparently T-Mobile also has an APN
named fast.t-mobile.net
and you can use either value for your APN host name.
For T-Mobile there is no username/password needed for their APN, only one of
these two names. The Pine64 wiki
has a bunch of these settings for a lot of other carriers in case you don't use
T-Mobile.
For MMS support, it currently seems that ModemManager can only deal with a
single APN at a time. For T-Mobile this is OK because their 4G data and MMS go
over the same APN, but some carriers use different APNs for MMS and this may
cause problems there. For my Pinephone I set mobilenet
as the APN both for
4G data (in GNOME Settings) as well as for my MMS config (editable in Chatty
with the latest branch, or in ~/.mms/modemmanager/mms config).
Updates: (Dec 15 2021)
Mobian now has mmsd-tng packaged in their normal testing repo, so I could
apt install
it and stop running my compiled-from-source copy. But, their mmsd-tng still seems unable to send MMS, but can only receive it.Chatty v0.5.0 seems "coming soon" and I've pulled the updated code from Purism's repo; Mobian's MMS wiki page says 0.5.0 (mistakenly written as 5.0.0) will be their planned release that integrates well with mmsd-tng. Their current packaged Chatty is the older 0.4.0 without MMS support. When both are fully packaged for Mobian I will probably reinstall the OS to get my hand-compiled copies cleanly out of my system.
The main feature I've been waiting on has been MMS support. It is still a very popular service in the US and I get roped in to group chat threads frequently. However, this has been the slowest developing feature on the Pinephone; I've had this device since May 2020 and MMS support has always been "coming soon" the whole entire time.
I have heard that Manjaro had MMS working out-of-box, however Manjaro doesn't have an installer image capable of setting full disk encryption on my phone. I consider full disk encryption to be crucial in a portable device: envision the case where your phone fell out of your pocket on the train and a random stranger finds it. I would prefer that the root filesystem and SD card are encrypted so that the stranger doesn't immediately gain access to my SSH keys, saved passwords in Firefox, cookies that logged me in to various sites, the password for my email inbox, and so on. To my knowledge so far, only Mobian and postmarketOS have an option for encryption and the latter doesn't run the GNU stack which makes things complicated for me as a developer.
Anyway, the Mobian wiki has a page about MMS and you basically need to compile some stuff yourself to get it working. I decided I had lost patience waiting for this to be fully packaged nicely and that I would see what I could get working from their wiki instructions.
There are two main parts: mmsd-tng
provides a sort of MMS daemon and there is
a newer build of Chatty (the texting app) that understands MMS. For mmsd-tng
,
Mobian has it packaged now on their unstable branch, but I decided to compile
it from source code instead -- I don't want to upgrade my entire Mobian to unstable,
as then I will run into likely problems with Waydroid or other third-party software
that doesn't track unstable; and I wanted to avoid any kind of Frankendebian that
I would wind up with if I were to try and get the mmsd-tng.deb from their unstable
repo to install onto my otherwise testing branch.
Source repo: https://gitlab.com/kop316/mmsd
It was fairly straightforward to compile and install. The build steps will point out any missing dev dependency and it took a little trial-and-error until I got them all.
For Chatty: Mobian already had one installed and I didn't want any risk of conflict for building my own version, so I carefully removed Chatty first before compiling it from source:
# Remove Chatty CAREFULLY without taking out Phosh with it!
dpkg -r --force-depends chatty
Be careful! If you simply did an apt remove chatty
it will try and uninstall
Phosh and a bunch of stuff with it! For some reason Phosh depends on Chatty so
remove it carefully before installing your own.
The end result: Chatty has an updated UI with a paperclip button to attach a picture to my message, and it 'appears' to send the picture, but nothing actually goes out. However, incoming picture messages from others work fine, and if I get into a group MMS chat, that works fine too - I can see the numbers and names of the participants, I can see picture messages they send in the chat, but I can not respond to the chat - my message appears to send, but nobody actually sees it.
For my needs, though, this works okay: so long as I know when I got an MMS and I can see what it was, that's enough for me. It was rough before when MMS was just "not working" or you needed a command-line hacky script to get them, with no notification you even got one.
From further poking, I think the "sending MMS" problem is in mmsd-tng itself and not in Chatty; mmsd-tng contains some test scripts in Python for sending MMS out and I tested those and they fail to deliver MMS too, despite them thinking they got back a confirmed delivery response from the network.
At first I ran into this problem: if my Pinephone is connected to my WiFi network, it was unable to download MMS messages at all, despite having a functional LTE modem connected to 4G.
Apparently the root of the problem is: in the MMS payload there is a URL to the attached image asset (or w/e) but this URL is protected with credentials and the phone must access it over the 4G modem and not over WiFi; but when your WiFi is connected, it will prefer that for its network gateway and be unable to authenticate to get the MMS URL.
The fix: in my ~/.mms/modemmanager/mms config I set ForceCAres=true
to make
it use the C-Ares library for DNS rather than systemd. With this, it was able to
download MMS messages even while I was on WiFi!
The battery life on the Pinephone is just okay and in the couple weeks I've been daily driving my Pinephone I simulated a few common cases to see whether the battery would be a complete deal breaker. For example, I charged it to 100% and then unplugged it and left it overnight as I slept to see how it fared by the morning.
The battery is not great for active screen-on use.
I'll wake up at 9 AM, unplug my Pinephone (full charge), play around on it for one hour, scrolling Reddit or checking my e-mail or whatever: and it will have dropped from 95% charge down to 75% charge in just that one hour of use. My screen brightness was set below the 50% mark (probably closer to 30%) to maximize its battery life and this is about how fast it will drain with active use.
But for how often I actually play on my phones, this isn't actually so bad for me. I work from home and have laptops to play on instead, it's mainly just an hour in the morning and an hour in the evening that I play on my phone and just check it periodically thru the day for any SMS or Telegram chats that came in.
The deep sleep feature on the Pinephone does very well to prolong the battery life while idle. Sometimes I would unplug my Pinephone to charge my Pixel instead, and then forget about the Pinephone for three days, and it will still be hanging in there with 20% battery remaining.
Leaving it just overnight off its charger, it would go from 95% charged and still have maybe 91% in the morning or thereabouts.
I still have my Pixel phone which is now WiFi-only because it can control my Chromecasts and it runs certain Android apps better than the Pinephone does. But, I don't have a whole ton of phone chargers around my house!
If my Pinephone is at 75% or more battery and my Pixel is at 50% or less, I'll opt to plug my Pixel in to charge overnight and not my Pinephone; and the next night, the Pinephone will obviously be needing it more and I'll plug that in and leave my Pixel off the charger.
And after doing this a few days back to back, it works for me!
So despite the relatively poor battery in the Pinephone, it's actually not terrible in practice for my needs and usage patterns for my mobile devices.
There is an issue with alarm clocks when the phone is deep sleeping: basically, only the cell modem will wake the phone and everything else is suspended so normal alarm clock apps (such as GNOME Clocks) will not trigger at the right time.
If you plug your phone in to charge overnight (and you have faith that there won't be a power outage in the morning) it should trigger fine. If you are on battery, though, there is a hacky workaround:
Wake-Mobile is a simple alarm clock app that uses systemd timers to wake the phone from sleep. It's very barebones and its alarm clock noise is annoying without an ability to customize it, but it'll work in a pinch.
If I were staying at a hotel or something, I'd probably use the hotel's alarm clock as a backup just in case.
I wrote about Waydroid recently
and it still works well. On Mobian it seems to be more stable recently than it
had been; not long after I had excitedly written that article, an apt upgrade
broke Waydroid for me and it needed some manual debugging to get it sorted out,
and the comment thread has someone else who struggled to get it working on Mobian.
Apparently people have found that Waydroid "just works" on Manjaro but I can't use Manjaro for the aforementioned lack of full disk encryption. But anyway: for weeks now Waydroid has been stable and reliable for me on Mobian, it hasn't broken on me in some time.
Mobian's wiki has instructions that you should check out if you wanna try this. There are a few little gotchas and caveats to getting it set up.
Waydroid currently has a problem where it interferes with deep sleep on the Pinephone. Right when the phone would want to start suspend, instead the screen lights up and stays lit up, eating your battery; and if you turn the screen off, it will turn back on again next time it tries to suspend.
I had filed an issue on their GitHub about this, but for now a work-around is to stop Waydroid when I'm not using it. I put a .desktop launcher in my ~/.local/share/applications to do this:
[Desktop Entry]
Type=Application
Name=Waydroid Stop
Exec=waydroid session stop
Icon=/usr/lib/waydroid/data/AppIcon.png
The down side is: I'll need to wait the slow 2 minutes next time I launch an Android app so that Waydroid can fully boot up (once Waydroid is warmed up, Android apps launch and function well). However, this works okay enough for my needs; if I'm sitting down for an extended play session with my phone, I'll boot up Waydroid so I can scroll Twitter or whatever, and then I just stop Waydroid when I'm finished so my battery will last the rest of the day.
KDE Connect really makes my experience with Waydroid a lot better. Since Waydroid is container-based, the Android filesystem and clipboard are isolated away from the host system, so transferring files back and forth is a chore.
Install KDE Connect on both Linux and Android and they can see each other right away and pair up; then Android notifications can get synced to my Phosh desktop and I can push and pull files both directions. I think clipboard sharing should work too but I don't know if I tested that.
The last time I tested my Pinephone in January, I was especially concerned with the deep sleep feature and what that would mean for incoming phone calls or text messages. Previously: if the phone was sleeping and an incoming call was placed, the phone's screen would light up within a couple seconds and I would watch the cell indicator connect, and only if it did so quickly enough, would the phone actually ring (I counted 11 seconds one time before the ring). But more often, it was too slow and the calling side would get a voicemail prompt instead.
But this time: I one time had my Pinephone sitting on my desk, unplugged, sleeping, and to my surprise it began ringing and I was able to answer it. Luckily for me, it was an important phone call that I'm glad I didn't miss.
I haven't extensively tested incoming calls otherwise but this one anecdote suggests that reliability has been improved in the last year!
This part is not great.
GNOME Maps and Firefox are able to get a location but the location they get is not very accurate:
Mobian's wiki has a page about location to get into the weeds with this stuff, but what I've determined so far is:
Interestingly, on my laptop running Fedora Linux, Firefox is able to very accurately get my real location despite my laptop only having WiFi; from some research it seems Firefox usually prefers Google Location Services (where they have the whole Android userbase and Streetview cars contributing to their WiFi router database) which is probably how it does this; but the Firefox shipped with Mobian is an especially privacy-hardened one that has Google services ripped out. There may be some things you could install and configure on the Pinephone to improve GPS accuracy by using Google's services, but I'm not sure off hand what those are.
GPS problems aside, between GNOME Maps or various maps sites in Firefox you can at least get access to street maps, search for addresses and such; so if you're lost you could pull over to the side of the road and get yourself sorted out.
I think for a while I will carry my Pixel 3 with me, so in a pinch, I can tether it to my Pinephone and use it for navigation.
Some other blog posts I've written about the daily driver-ability of the Pinephone:
There are 2 comments on this page. Add yours.
I am using the 12/26/21 weekly mobian image and I was able to both send and receive MMS after following your instructions. I did notice that I had to add my APN manually to the list in the settings (the ones filled in automatically for T-Mobile's network did not seem to work - I am on Ting). Thank you for sharing your insights.
Are you going to switch your modem firmware to the open-source version? I am on the fence - I don't want to break my phone but at the same time I'm worried that I'm one bad shutdown away from corrupting the existing modem firmware.
Are you going to switch your modem firmware to the open-source version? I am on the fence - I don't want to break my phone but at the same time I'm worried that I'm one bad shutdown away from corrupting the existing modem firmware.
I'm on the fence as well, and I don't see a compelling enough reason yet to bother with the open source firmware. When I briefly looked into what the steps entailed before, it looked like a bit of tedious effort: the modem SOC seemed to be Android-like and you'd flash firmware with the Android adb tools as though you were rooting a phone, and I always have a little bit of worry when dealing with adb for fear of bricking it and not knowing how to recover it should it go wrong.
I've heard some reports that the default modem occasionally crashes and your 4G data and cell connection drops out, but I've only seen it happen to me once so far and rebooting my phone fixed it. Sometimes I'll see the 4G icon disappear like the modem has gone away, but it sorts itself out within a few seconds, except the one time when it didn't and I just rebooted the phone instead. I heard the open source firmware had fixed the problem but I'm not motivated to try.
I ordered the Pinephone Pro from the first Explorer Edition Jan 11th batch, so eventually I'll have two Pinephones and may be more brave to experiment on the older one. The PP Pro still needs software improvements from my understanding (power management and return from suspend have issues, Bluetooth, cameras not working yet, etc.) so it won't be my immediate daily driver but I'll be following its progress closely.
0.0105s
.