Tag Archives: rant

My old Galaxy Nexus died so I had to get a new phone. I would have loved to have replaced it with a new Nexus 5, but it’s a work phone, and work is paying for it, and work has a contract with Verizon Wireless. So my options for a phone with a relatively stock version of Android were pretty limited—really just the Moto X. But I’ve had enough of the power-hungry AMOLED display of the Galaxy Nexus, and didn’t want to deal with that again in a Moto X, so I picked the HTC One (M8), knowing people on xda-developers have already ported the stock Google Play Edition (GPE) build of Android to it.

When I got the phone, the first thing I did was install the so-called “DigitalHigh” GPE build from xda-developers, but what I found was anything other than a stock Android experience. There were so many tweaks, options, customizations, and glaring security issues (chmod 755 everything!) that it just put me off. Really, the whole xda-developers community puts me off. And since this is a blog, let me go on a little rant:

xda-developers, probably the largest Android modification community, is a place full of advertisements and would-be hackers who call themselves “developers” just because they can compile the Linux kernel and put it up on a slow, ad-ridden file host. No one uses their real names, no one hosts their own files, no one releases source code for their work, and no one documents what they do. And that’s to say nothing about the users, who bring the community down in other ways, but for whom I feel, because I know I would hate to be stuck with the bloatware and skins the carriers and manufacturers collude to lock onto Android phones.

Clearly I don’t think xda-developers is a very pleasant place. The problem is some people on there actually do really good, really interesting work. So it’s an inescapable, conflicting, sometimes great, but usually frustrating source of information for Android.

That frustration led me to port the Google Play Edition build of Android to my new HTC One (M8) for Verizon myself, hopefully demonstrating the way I think Android modification should be done in the process. Some points:

All of the modification is done in an automated way. I chose my favorite automation tool, Puppet, for the job, but shell scripts or Makefiles would work just the same. The point is to download, modify, and build everything required in a hands-off manner. Automation has the added benefit of doubling as a sort of documentation.

Everything is hosted by me without ads, or is otherwise freely accessible—no file hosts.

All modification is done with a light hand, only changing what absolutely must be changed. (Though I do make a concession to enable root access and the flashlight, but even that is done in a clean and transparent way that can be trivially disabled.)

I’m not going to pretend that this is novel, or innovative, or that it took some huge effort—it’s just modifying some configuration files. If you want to give credit somewhere, look at CyanogenMod. They’re doing Android right. They build from source and have a working version for the M8. Sadly, they’ll always be playing catch-up to Google. Still, I have a lot of respect for that team of (real) developers, and I based a number of modifications to the GPE build on their code, so thank you!

Sorry this post was more ranty than usual, but as you can see, I have strong opinions on this subject. If you made it this far, here is the result of my automation:

I leave this file here as a convenience to those who know exactly what to do with it and who are capable of using and understanding my automation tools, but simply don’t want to. If that is not you, then you probably shouldn’t be modifying your phone.

I’m looking forward to seeing how well this works when Android 5.0 drops.

UPDATE #1

Android 5.0 (“Lollipop”) has arrived and with a few small tweaks to my automation tools, I am pleased to provide a flashable image for the Verizon M8:

Compared to the 4.4.4 release, this build deviates even less from the official upstream image. In fact, the only modifications to what Google and HTC distribute are:

Add the Verizon device ID to the Device Tree image for booting.

Enable CDMA with two line changes in build.prop.

Set an override flag on boot to allow screen casting to work—a feature that is more prominent in Android 5.0.

Compare that to the “DigitalHigh” release on XDA which disables important security mechanisms (SELinux, ADB security, file permissions), changes a whole lot of things that don’t need to be—and shouldn’t be—changed (like the I/O scheduler, data roaming, animation speeds, and various WiFi settings), and continues to deviate further as time passes, with inclusions like the HTC Sense camera. At this point, “DigitalHigh” can hardly be called the Google Play Edition, and many of the changes are downright harmful. I would strongly urge you not to use it.

With my automation tools, you can see exactly what modifications are required for Verizon support, and you can run it yourself so you know you’re getting a build that is as close as possible to the way Google intended it to be.

UPDATE #2

Android 5.1 was released for the GPE M8 a couple of days ago, and I already have a build of it ready for Verizon M8 devices.

Judging by the state of the Verizon M8 XDA forum, I believe I’m the first to have 5.1 on a Verizon M8. Another score for automation!

UPDATE #3

As some of you have noticed, some new OTAs have been pushed out for the Google Play Edition HTC M8. I’ve been on vacation so I haven’t had a chance until yesterday to look into them, but now I’ve been able to tweak my automation code to get these updates working on the Verizon M8. The nice thing about these changes is that I can now use the publicly available incremental updates directly from Google rather than having to rely on the community to produce dumps of their updated devices. Anyway, here are the updates, to be applied in succession on top of the LMY47O.H4 build from above: