Mar 20 2015

CyanogenMod com.android.phone crashing – an unlikely APN fix for the NullPointerException in the telephony stack

Currently, I have a T-Mobile branded Samsung Galaxy S4 (SGH-M919) and until this past weekend I was running CyanogenMod 11 (the M9 snapshot) on it. I was having one minor problem with it, and that was that all-too-often the artist and track information from my music stream would not be sent via Bluetooth. I hadn’t updated because if the majority of things are running smoothly, why test fate? Anyway, a few days ago I took the plunge and updated to the M12 snapshot via the CM Updater.

Almost immediately I ran into a big problem. Every so often (seemingly randomly), I would get the alert that “Unfortunately, com.android.phone” had stopped. Worse yet, when that happened, I would lose mobile connectivity on any voice call. If I was in a voice call, the connection would drop. If I wasn’t in a call, I would be unable to receive or dial out for some time. Clearly, this was a huge problem since… well… one of the primary foci of a mobile is to make and receive voice calls.

Thinking that it was a problem with flashing the new ROM from CM Updater, I tried manually flashing the M12 snapshot. When that didn’t work, I tried a bunch of other things as well:

Unfortunately, all of these things got me nowhere. The problem was still occurring, and I couldn’t figure out what was happening. At first I was thinking that there was a hardware problem, but the Java stack trace indicated otherwise:

[CRASH] com.android.phone threw java.lang.NullPointerException
at android.telephony.SmsMessage.getTimestampMillis(SmsMesssage.java:607)

After all of those troubleshooting steps, though, CyanogenMod 12 revealed something to me that I hadn’t seen in the stack trace before:

com.android.mms.service

Noticing the MMS portion of that error made me think to check the APN settings for the device. What I found is that there were some slight problems. Below is what the settings were “out of the box” in CyanogenMod for the jfltetmo/jflte (which is the Samsung Galaxy S4):

Name: T-Mobile US LTE
APN: fast.t-mobile.com
Proxy: Not set
Port: Not set
Username: none
Password: **** (yes, four asterisks)
Server: * (yes, just as asterisk)
MMSC: http://mms.msg.eng.t-mobile.com/mms/wapenc
MMS Proxy: Not set
MMS Port: Not set
MMC: 310
MNC: 260
Authentication type: Not set
APN type: default,supl,mms
APN protocol: IPv4
APN roaming protocol: IPv4
Bearer: Unspecified
MVNO type: None

HOWEVER, they should be (the changes that I had to make are in red; you may need to change others to match the ones below):

Name: T-Mobile US LTE
APN: fast.t-mobile.com
Proxy: Not set
Port: Not set
Username: none
Password: Not set
Server: Not set
MMSC: http://mms.msg.eng.t-mobile.com/mms/wapenc
MMS Proxy: Not set
MMS Port: 80
MMC: 310
MNC: 260
Authentication type: Not set
APN type: default,supl,mms
APN protocol: IPv4
APN roaming protocol: IPv4
Bearer: Unspecified
MVNO type: None

After making those changes and setting them in the APN, voilà! No more message about com.android.phone crashing with reference to com.android.mms.service.

If you are experiencing the same problem, I hope that you see this post before going through WAY too may troubleshooting steps whilst overlooking the smaller, more likely problems. Let us not forget Ockham’s Razor—given equal circumstances, the simplest solution tends to be the correct one.

Cheers,
Zach

Jan 14 2015

Fortune cookie wisdom part VI

It’s been a long time since I’ve posted a new set of “Fortune cookie wisdom,” but I think that I have five good ones here. Before reading them, if you’d like to check out the previous posts in the series, you can with the links below:

Now that you’ve wasted a good amount of time reading those previous posts (hey, it’s better than watching more cat videos on YouTube, right?), here are the new ones:

  • Generosity and perfection are your everlasting goals.
  • We must always have old memories and young hopes.
  • Discontent is the first step in the progress of a man or a nation.
  • An important word of advice may come from a child.
  • Someone is looking up to you. Don’t let that person down.

I think that the third one is especially true in these times. With many political, social, economic, and societal decisions being made without full support of the people, it is necessary for individuals to express discontent before any change can begin. The fourth one is incredibly important to remember. We all too often forget that children can show us different ways of looking at otherwise maladroit or stale situations. They can enlighten us and open our eyes to perspectives that we may not have considered with our “adult” worldviews. I’m reminded of the recent Why advertisement from Charles Schwab:

It also ties nicely to the final one that I posted today. We need to remember to always act with integrity because there is always someone looking up to us, and modelling his or her behaviours after our own.

Good stuff, but like the previous post, I think that there was less of an emphasis on the funnier side of the fortune cookies. Hopefully I’ll get some new funny ones soon.

Cheers,
Zach

Jan 06 2015

Slock 1.2 background colour

In a previous post, I discussed the method for changing the background colour for slock 1.1. Now that slock 1.2 is out, and is in the Portage tree in Gentoo, the ‘savedconfig’ USE flag is a little different than it used to be. In 1.1, the ‘savedconfig’ USE flag would essentially copy the config.mk file to /etc/portage/savedconfig/x11-misc/slock-$version. Now, in slock 1.2, there is still a config file in that location, but it is not just a copy of the config.mk file. Rather, one will see the following two-line file:

# cat /etc/portage/savedconfig/x11-misc/slock-1.2
#define COLOR1 "black"
#define COLOR2 "#005577"

As indicated in the file, you can use either a name for a generic colour (like “black”) or the hex representation for the colour of your choice (see The Color Picker for an easy way to find the hex code for your colours).

There are two things to keep in mind when editing this file:

  • The initial hash (#) is NOT indicating a comment, and MUST remain. If you remove it, slock 1.2 will fail to compile
  • The COLOR1 variable is for the default colour of the background, whilst the COLOR2 variable is for the background colour once one starts typing on a slocked screen

Hope that this information helps for those people using slock (especially within Gentoo Linux).

Cheers,
Zach