Thursday, January 25, 2018

Google's Timeline

I was reading an article on Slashdot yesterday in which the author claimed that Google had lost its innovative edge and was now focused purely on "chasing the consumer". Being Slashdot, most of the commenters agreed. One  particular comment mentioned something I had not heard of before: Google Timeline. You can access it by going to

To my surprise, I found 428 places that I have apparently visited in the past 5 years, all presented in a nice browsable Google map interface.

I take a nice, long motorcycle ride each summer, frequently heading up from Santa Fe, NM to British Colombia or Alaska, and it sure looked like all the places I'd been were on the map. Digging a bit deeper, I began to realize that there was a lot more fine-grained data there. For example, one day in August 2106 my riding partner and I decided to take a float plane ride from the harbor at Victoria, BC.

There was a lot of detailed data preserved and available via Google's map interface: travel time for each link, distances, restaurants stopped at, hotels, and geotagged photos taken along the way.

I suppose we all know that Google collects data from your Android phone, but I was still surprised at how much they had collected, and how cohesive it was. I decided to look around to find if anybody had done a study to determine how much data Google collects from Android phones. Someone had: the people at Quartz had just published a study on this very subject. From the article:

Quartz was able to capture transmissions of Location History information on three phones from different manufacturers, running various recent versions of Android. To accomplish this, we created a portable internet-connected wifi network that could eavesdrop and forward all of the transmissions that the devices connected to it broadcast and received. None of the devices had SIM cards inserted. We walked around urban areas; shopping centers; and into stores, restaurants, and bars. The rig recorded every relevant network request made by the Google Pixel 2, Samsung Galaxy S8, and Moto Z Droid that we were carrying.

  • According to our analysis of the phones’ transmissions, this is just some of the information that gets periodically sent to Google’s servers when Location History is enabled:
  • A list of types of movements that your phone thinks you could be doing, by likelihood. (e.g. walking: 51%, onBicycle: 4%, inRailVehicle: 3%)
  • The barometric pressure
  • Whether or not you’re connected to wifi
  • The MAC address—which is a unique identifier—of the wifi access point you’re connected to
  • The MAC address, signal strength, and frequency of every nearby wifi access point
  • The MAC address, identifier, type, and two measures of signal strength of every nearby Bluetooth beacon
  • The charge level of your phone battery and whether or not your phone is charging
  • The voltage of your battery
  • The GPS coordinates of your phone and the accuracy of those coordinates
  • The GPS elevation and the accuracy of that

That's a lot of data, and I'm guessing that Google hasn't thrown any of it away. As the Quartz article points out, whether or not to allow Google to collect location data from your phone is optional, but as the article also points out, Google makes it sound like Google services such as Maps and Assistant won't be nearly as useful to the user if you don't opt in.

So, let's pause for a moment and consider some of the implications of getting your Google account hack.

No wonder all the bad guys on NCIS use burner phones.

Sunday, January 25, 2015


Back in July, 2013 I put together a couple of fun Raspberry Pi projects:
  1. an NFS and Minidlna server, and
  2. an XBMC home entertainment system component.
Last month I purchased a couple of Odroid-C1 units which looked interesting because for the same $35 as the Pi you got a slightly smaller SBC with approximately 6X the power. 
  • Pi CPU: ARM 700MHz, C1; Quad-core ARM 1.5GHz
  • Pi GPU: 24 GFLOPS, C1: 54 GFLOPS
  • Pi 2 USB 2.0 ports, C1 4 USB 2.0 ports
  • Pi Ethernet: 100MB/s, C1 Ethernet: Gigabit
Both the Pi and the C1 draw approximately 3 - 4 watts when idling.

I wanted to see how the C1s performed as replacements for the Pi units. I was especially looking forward to the greater bandwidth that the C1 gigabit ethernet would provide because I have found that the 100Mbps bandwidth of the Pi was constraining when streaming 1080p Matroska video media; there was not quire enough bandwidth for the media to stream smoothly.

Building the Arm Ubuntu 14.04 LTS system provided by the Odroid developers was a snap. Simply download the image, uncompress it, and 'dd' it to a Class 10 MicroSD card, insert into the slot on the underside of the C1, and boot. The instructions for completing the Ubuntu installation were straight forward.

As I usually do when playing around with an SBC, I installed Tightvncserver for convenient remote access. The Odroid developers did a nice job with their Ubuntu distro; the LXDE window manager that comes installed by default is perfect.

Installing the NFS server software just took a minute, and installing Minidlna 1.1.4 was simply a matter of downloading the source and building it.

Once that was done, the C1 became a plug 'n play replacement for the Pi NFS/Minidlna server. No muss, no fuss: it simply worked, serving ~8TB of media from a stack of USB external drives.

So far, so good. Now onto the C1 replacement for the Pi XBMC unit. As before, installing the Odroid Ubuntu 14.04 system was quick and easy, and since XBMC (now called "Kodi" for whatever reason) comes installed with the Odroid-C1 distribution, all that was needed to get it running was to set it up to automatically mount the media being served by the file server.

Here's the C1 sitting on top of a gigabit switch in the entertainment system cabinet:

For perspective, the whole cabinet:

As before, it looked like this was going to be a plug 'n play replacement that "just worked". Movies, even 1080p Matroska Blu Ray rips played smoothly.

But then, oops! I started one of my older MPEG-2 movies and it was choppy, almost like one of those stop-motion Claymation movies. I checked the movie on the Pi, and it was perfectly smooth, so I reported the issue on one of the Odroid Forums. That was just a few days ago, and so there has not been any resolution yet announced. I have replaced the C1 with the Pi, and will wait to see if this is a problem that the Odroid developers are able to patch.

So, the C1, while impressive, is not yet perfect, which really isn't very surprising for a brand new innovative SBC. When I get an update from the Odroid devs on the MPEG-2 issue I will pass it along here as a comment to this article.


Wednesday, July 16, 2014

Google Abandonware

About six months ago I noticed that one of the portfolios I was tracking using Google Finance Portfolio suddenly started reporting wrong historical data for nearly all of the equities in the portfolio. I clicked on the "Report a problem" link at the bottom of the page and used the form to send off a detailed description of the problem off to Google.

I never received a reply, of course. I've sort of come to expect that when reporting issues with free Google resources. So, in the mean time I clicked on the link for the Google Finance Blog to see if anybody else had reported the problem.

Oh, oh. Here is the top post, dated two years ago:

Please follow us on the Inside Search blog

Thursday, August 9, 2012 at 9:20 AM

Posted by Karolina Netolicka, Product Manager

Thanks to everyone who has been a loyal reader of the blog over the last five years. After some consideration, we've realized that we're just not generating enough content here to warrant your time, so we won't be posting here any longer.

Instead, we'll start contributing to the Inside Search blog, so tune in there for updates on Google Finance.

Looking through the referenced Inside Search Blog  blog turned up no discussion on the broken Google Finance portfolio tracker, but a more general search turned up plenty of discussions on the topic, such as this one. Bottom line: Google Finance is broken, and unsupported.

More recently, about three weeks ago I went over to the Google Finance Stock Screener using, as always, Google's Chrome Browser on my Linux box, and I found it to broken as well, and fairly recently. I had used it just one month prior.

Digging a little deeper, I realized that their stock screener page itself wasn't really broken; it worked fine when using Firefox. However, the page was not being rendered properly by the Google Chrome browser; elements of the page overlapped each other, making the page unusable.

Here's how the screener page is supposed to look (Firefox):

And here's how it looks in Chrome:

The slider elements overlay the the numeric input boxes on the right making it impossible to set screener selection criteria.

Bottom line: it is probably not a good idea to include Google products in any mission-critical applications, because you simply never know if they will continue to be supported in the future.


Sunday, July 28, 2013

A Second Helping of Pi

In my last article I described how to set up a Raspberry Pi as a network attached storage (NAS) device and UPnP media server. By the time I was done with that project I was so impressed with the power and flexibility of the Pi that I decided to order another unit and set it up to replace my Linux Mint-based home entertainment system computer.

A quick literature search indicated that  the Pi had plenty of power to stream even 1080p HD movies, and that XBMC would be a natural choice for a Pi-based home entertainment system.

One search result returned this page listing three pre-built XBMC Raspberry Pi images. After reading through the clear, well-written installation instructions I chose the Raspbmc image, although I suspect that OpenELEC and XBian are also good XBMC implementations.

For this system I chose a different case than the one I used for the NAS. The Adafruit Industries clear case is really slick, it only took about 5 minutes to peel all the paper off the flat pieces and snap it together with the Pi inside. Here's what the assembled case looks like in my entertainment center, sitting on top of the gig-e switch and snuggled up next to the Roku player:

After connecting the Pi's HDMI output to an unused HDMI input port on the home entertainment amplifier, the Raspbmc image booted into a full screen frame buffer display with XBMC up and running as shown here.

For performance and simplicity, Raspbmc uses the frame buffer for output, X11 is not part of the distribution.

The only additional step for this system was to install the nsf-common package (sudo apt-get install rpcbind nfs-common) and set up fstab so that I could mount all of my media sources from that shiny new Pi NAS running in my office.  Then it was simply a matter of adding those music and video directories using the XBMC UI, and the installation was done! It literally only took about an hour from start to finish. Here's what the finished system looks like:

As I was playing around with it, feeling impressed at how everything Just Worked with Raspbmc, I discovered that I wasn't actually quite done yet.  I tried to play one of my MPEG-2 encoded movies, and got sound only.  Another quick literature search returned this bit of info:
The Raspberry Pi was designed to be an educational computer. As part of that educational mission, the Raspberry Pi Foundation has gone out of their way to minimize the manufacturing and licensing costs in order to keep the final cost of the device down. Part of their cost cutting measures included not purchasing a pricey blanket license to use the MPEG-2 and VC-1 video codecs. 
This doesn’t mean the Raspberry Pi is not capable of decoding media encoded in MPEG-2 or VC-1, but that by default the codecs cannot run on the Raspberry Pi hardware for want of a proper license. Fortunately the Raspberry Pi Foundation was able to make arrangements to sell individual licenses for each codec very inexpensively.
Inexpensive is right: $3.86 for the MPEG-2 codec license from the Raspberry Pi Store. A couple of hours later the license key arrived in an email, and after appending it to /boot/config.txt and a 40 second reboot, everything now Just Worked.  The viewing and listening experience with XBMC is supurb.

So, in the past week this has quickly turned into a multi-Pi household, and since they consume only 3.5 watts each, these systems will stay up 24X7.  Tonight I'm going to order another one to have just to play around with and see what other projects make sense.


Thursday, July 25, 2013

Closure on Nexus 4 Bugs

Finally, seven months after having been reported to Google, these two Nexus 4 bugs are fixed in Android 4.3:

- Nexus 4 stops responding to ARP requests when screen is off with wifi on
- Nexus 4 loses wifi connection when bluetooth is in use

That's the good news.  The bad news is that during those seven months Google refused to acknowledge that there were software issues with their phone that prevented wifi and bluetooth from properly working. We're not going to rehash all of that again, but those not familiar with the long saga can read about it here:

The Fine Art of Corporate Fibbing

We can at last move on: the phone is working as it should have been.


Monday, July 22, 2013

Delicious Raspberry Pi

I'm sure most folks have heard about the Raspberry Pi by now, and maybe some of you are curious if this $35 ARM-based computer is worth anything more than just a digital toy to play around with.  I know I was, so this last weekend I finally took a day to build one and see what it could do.

It was quite easy to assemble and get up and running. I won't produce another HowTo doc here because there are plenty of good ones already. The ones that I used that are referred to throughout this article. What actually took the longest was putting together the slick little case sold by Built To Spec.  There are lots of folks selling enclosures for the Pi, but I liked the looks of this one. It does require a bit of ambidexterity to assemble, kind of like putting a Chinese puzzle back together, but it is a nice, well-designed case.

In addition to the $35 Model B Pi purchased from Allied Electronics, I bought a $10 8GB SDHC card and a 7-port USB 2.0 powered hub for $25, because my plans for the Pi were to see how well it could perform as a NAS device and media server, and for that I was going to need more than just the two USB ports on the Pi.

I used the Raspbian “Wheezy" distribution downloaded from here and copied it to the SDHC card. I pretty much just followed the instructions in this document to boot and configure the device, and then I installed the Tightvncserver package and did the rest of the installation and configuration with the unit running headless.  The image at the top of this article is the Pi's vnc desktop running on my Linux Mint 15 work machine, click it for a larger image. Btw, here is a nice document that describes how to have the vnc server started at boot time.

Underneath my desk, nearly covered in cat hair are four USB 2.0 drives that I've accumulated over the past few years which have a total combined capacity of about 6 TB.  That's where all my movies, music, and other digital content is stored.  It is these drives that I wanted to disconnect from my main work server and let the Pi handle. I do, btw, have redundant backup elsewhere on higher-capacity USB 3.0 drives.

Installing the NFS server was straight forward, basically as described here.  Getting the NFS server running consists pretty much of just  sudo apt-get update; sudo apt-get install nfs-kernel- server nfs-common rpcbind , and then setting up the configuration files (/etc/fstab, /etc/exports).

At this point I was ready to test the Pi as a NAS.  I was pleasantly surprised that it could effortlessly serve up big, fairly high bandwidth Matroska 1080p movies across my home network to the Linux-based home entertainment system without a hitch.  So far, so good.

The final bit that I was interested in was installing some kind of media server package so that all my movies and music could be accessible from some of the Android devices laying about the house. The package I chose for this was MiniDLNA, and there is a decent document on installing it on the Pi here. MiniDLNA will scan all folders you specify in its config file for video, audio, and picture files. It will then make these available to any UPnP devices such as televisions, games consoles, and Android devices running a UPnP client like the MediaHouse UPnP / DLNA Browser.

When you first start minidlna on the Pi it searches through all the directories that you specified in the config file and indexes all the audio, video, and digital image files that it finds and builds that information into a MYSQL database.  In my case there were about 8,500 movie and audio files that have collected over the years, and it took about 1 1/2 hours for minidlna to index all of that. However, once it was done I could access the media from the Android devices running the MediaHouse UPnP browser.

Bottom line, I am very impressed with the Pi. It is amazing how much work you can do with the Broadcom 700MHz ARM1176JZFS processor with FPU and Videocore 4 GPU, and just 512 MB of ram.


Update 7/23/2013: The cat discovered the 6 TB foot warmer.

Tuesday, April 9, 2013

The Fine Art of Corporate Fibbing

Word has it that the good folks at Google's Device Support hotline (1-855-836-3987) are still telling people who call in to complain about the wifi and bluetooth issues with their Nexus 4 phones one of two little white whoppers:

  • (Imagine a voice on the telephone expressing the deepest of surprise) "Really? There are no reports of any wifi problems like that for the Nexus 4. Would you like to exchange your phone for a new one?" Or,
  • (Imagine a voice on the telephone expressing the deepest of regret) "Oh, we are so sorry.  If that happened to me I'd be very concerned too! But tragically, that was intended functionality of the phone. We designed it so that you could not use wifi and bluetooth at the same time.
In the mean time, a developer over at XDA has provided a kernel that includes a new beta release of the Nexus 4 Qualcomm Prima wifi driver code that completely fixes the first bug, above, that Google has never heard of. I'm running the latest nightly CyanogenMod 10.1 release with this kernel, and it completely fixes this problem (that Google has never heard about).

Also, as I write this the CyanogenMod developers are integrating the new Qualcomm Prima driver code into their nightly builds, so that this bug (which Google has never heard about) will soon be fixed there as well.

Regarding the intended functionality bug that prevents the N4 from being able to run wifi and bluetooth at the same time [note that this only happens when you are connected to a wifi access point running at 2.4 GHz; if your wifi access is running at 5 GHz you do not experience this bug] there has not been even a whisper that anyone is looking at this.

What I find amazing is that Google has been given a free pass on these little corporate fibs. Nobody has called them on it.  I guess I'm still naive after all these years; I confess to have been completely fooled, snookered, suckered, taken in hook, line, and sinker regarding Google's corporate motto. 

“War is peace. 
Freedom is slavery. 
Ignorance is strength.” 
― George Orwell, 1984

"Lying is not Evil."
― Google, 2013


Sunday, March 24, 2013

Steve's Upcoming Counseling Session

We just set the following email to the Google Device Support Team:


Hi, Google Device Support Team.

It's  been a while since we spoke, but I recently discovered that someone in your organization has been (I hope inadvertently) disseminating inaccurate information about this Nexus 4 bug, and I thought you'd want to know about it right away.  

Here's the deal: you see, we all know that the Nexus 4 was not designed on purpose to prevent wifi and bluetooth from being used at the same time.  We all know that it is a bug.  Well, all of us except for Steve, apparently. Here, read for yourselves:  

Now, we all have the utmost confidence that someone in your organization will immediately take Steve aside for a private little counselling session about the inappropriateness of, shall we say, bending the truth regarding this particular flaw in the Nexus 4 product.

Thanks for your prompt attention to this matter.




(BTW, we don't think this is a picture of Steve, but it could be.)

Saturday, March 23, 2013


"It's a hardware bug, we can't fix it. If it were a software bug, we could, in theory, fix it, and we therefore would not be calling it a feature. Instead of calling it a bug.  Which is what it really is. But it would be inconvenient for us to be calling it that."

From one of the Google Nexus 4 product forums regarding the bad wifi/bluetooth interaction on the Neuxs 4:

The Google rep I talked to said this was intended functionality of the device and there is nothing to be done:
Hi James,

Thank you for contacting Google Play Support. I understand you're having trouble with your wi fi and Bluetooth. If I were experiencing this issue I would be concerned as well. I assure you I have the information for this issue.

As we discussed, this is built in functionality of the device. You cannot use both wi fi and Bluetooth at the same time.

Thanks again for your patience and understanding.If you have any further questions or concerns, please feel free to reply to this email directly. Also, you can visit our help center at: 


The Google Play Support Team

Of *course* this is "built in functionality. Of *course* Google  designed the phone so that you could not use wifi and bluetooth at the same time.

Oh, and by the way, telling little white lies is a little bit evil.


Sunday, March 17, 2013

Key Lime Pie and the Nexus 4

Since the last post, we've tried a CyanogenMod derivative ROM on the Nexus 4:  Paranoid Android 3+.

PA 3+ is a decent ROM, it feels solid and fast. However, it, like CM 10.1, is based on Android 4.2.2, and like CM 10.1 it has the same two irritating bugs as Google's own 4.2.2 Nexus 4 factory image which Google refuses to fix, for whatever reason.

Those two bugs of course are:

We suspect that Google hasn't fixed these because they simply are unable to fix them, along with all of the other wifi and bluetooth issues in 4.2.2. The best we Nexus 4 owners can hope for is that when Google releases Android 5 Key Lime Pie in May, these well-known problems with the N4 will have been fixed.

But don't hold your breath.  It has been 179 days since the wifi and bluetooth problems with the Nexus 4 were first reported to Google: not exactly confidence-inspiring.


Saturday, March 9, 2013


We've gone down the path of CyanogenMod for the Nexus 4.  The Android development community has an apparent average age of about 14, and all the arrogance and haughty superior attitude of, say, your typical Los Alamos National Laboratory staff member in the mid-80's, but at least they know how to bang out code. It's kind of refreshing actually after the ponderous interactions with "Fuck you, we're Google".

The two primary outstanding N4 bugs that we've been tracking, and seeing zero progress from Google are
  1. Nexus 4 stops responding to ARP requests when screen is off with wifi on, and
  2. Bluetooth kills wifi on the Nexus 4.
We've reported both of these on the CyanogenMod Jira bug tracking site. Let's see if the CM folks can make better progress on them than Google.  Actually, if they do *anything* they'll be making better progress than Google, so the bar really isn't set all that high.

We've been favorably impressed with CM 10.1 M2 experimental release, as well as the recent nightly builds, so we're holding out some hope that a more agile, more energized bunch than the Google behemoth can finally get these issues fixed.


Saturday, February 23, 2013

96 Days, and Counting

Yep, 96 days since the Nexus 4 narcolepsy wifi bug was first reported here, and again later here.

However, after using up nearly a whole box of digital bandaids, like this one, which required rooting the phone, and this one, which was necessary to fully goad the still groggy N4 into reliably responding to push notifications when on wifi, well, the phone sort of works on wifi as you would have expected.

All this being necessary because Google just can't muster up the wherewithal to push out a fix for the buggy Qualcomm wifi driver.

However, if you dare to attempt to use wifi and bluetooth at the same time, say, to make a Skype call while using a bluetooth headset, boom: bluetooth kills the wifi radio.  Every time.  Usually locking up the phone in the process.

Other than that, the Nexus 4 is a great phone.  I guess.


Monday, February 18, 2013

A Report Card on the Google Nexus 4 Phone

The new Nexus 4 phone from Google went on sale mid-November last year. It is made by LG and sold by Google, and is presently running, of course, the latest Android - 4.2.2 Jellybean.

We received the first of what eventually became a series of four Nexus 4's on December 13 last year. We figured some of you readers might be interested an actual user's experience with the phone, as compared to the often rather breathless "Oohs, and Aahs," that a few of the professional reviewers have been publishing about the N4. You might also want to take note of who pays for advertisement on some of those reviewer sites, btw. Just sayin'.

So, after having had three months to fully explore the phone, we thought we'd give Google a report card on the Nexus 4. We divided the report card into the following categories:

  1. E-commerce purchasing experience,
  2. customer support, and
  3. product quality.

E-commerce Experience, Grade: D-

These days we have big-time professional E-commerce retailers like and around against which to compare Google for an online buying experience. As it turns out, Google fell flat on its face. When the phone first went up for sale on November 12, Google's servers crashed within minutes, and stayed down for most of the day. The phone apparently sold out within minutes, but potential buyers didn't know this until later that day because the servers could not handle the load of people trying to buy the phone.

Then, on December 17 when a fresh batch of phones became available for sale again, the same thing happened again! If I were Google, I'd be real embarrassed about that. Google: take a lesson from Amazon on how to host a scalable E-commerce infrastructure. We were torn between D- and F+, but eventually decided to give points for at least trying.

Customer Support, Grade: F

Here's were it gets a bit ugly. It seems like there were a few known issues with the Nexus 4 and with the Android 4.2.1 distribution that came with the phone. It also seems that the Google Nexus 4 developers were fully aware of these issues at the time the phone went up for sale. Or became so immediately after it went up for sale because that's when people started complaining.  

So, this is why we ended up calling Google's Device Customer Support number (1-855-836-3987) about an hour after receiving that first phone. The first thing we did after unpacking it and letting it connect to the home office wifi was to do an update from Android 4.2 to 4.2.1. Next, we paired it with a  Plantronics bluetooth headset, fired up Skype, and attempted to make a Skype VoIP call. 

Oops. Immediately, the phone's wifi died, and the wifi icon disappeared. And the phone locked up, requiring a hard reset. Wifi seemed to work fine. Unless you tried to use bluetooth. Bluetooth killed wifi, every time.

So we called Google's Device Support number, and were told, "There are no known problems with the Nexus 4, it sounds like a hardware problem; we'll be happy to replace if for you."

So we replaced it.

And the replacement phone had the same problem.

Then, we noticed that when we blanked the screen, the phone would disconnect itself from its wifi connection and would no longer respond to push notifications. This in spite of having the "Keep Wifi On" set to "always". When we'd turn the screen back on the wifi icon would be grey and then turn blue again after the phone reconnected to my wifi access point.

Another call to Google's Device Support Team. Was again told "No, there are no known issues with the Nexus 4." We let them send another replacement.

In the meantime, we searched the Google code forums where the Google developers hang out, and found several bug report threads devoted to the specific bluetooth wifi-killing issue and the wifi suspend issue, both dating back to November 20, 2012.

Clearly, Google had known about both of these problems for quite some time. 

By now we were curious to see if the Google Device Support team would tell us yet one more time "There are no known problems with the Nexus 4." So we called them. And they did.

We decided to have them send a third replacement. Because by now, one of the Google developers had identified the cause the wifi screenblank dropout behavior - a buggy Qualcomm wifi driver. Plus, a number of other wifi bugs had been identified in Android 4.2.1 which the Google Android developers promised to have fixed in 4.2.2. We figured we'd install the 4.2.2 update to see if they fixed the Nexus 4 problems.  

The problem is, 4.2.2 didn't come out in a very timely fashion. So on day 15, the last day for returning the phone to the vendor, we called to RMA our third Nexus 4.  

And then 4.2.2 came out. So we ordered a fourth Nexus 4. We are nothing if not tenacious.

And guess what? The same buggy Qualcomm wifi driver was in 4.2.2, and bluetooth still kills wifi. And other customers are now complaining the the Google Device Support Team is still telling them that there are no known problems with the Nexus 4.

So, we took our fourth Nexus 4, rooted it and installed the latest Cyanogenmod image, recovery-clockwork-touch-, and then installed this patch to the Qualcomm driver init file. The patch helps, but does not totally fix the wifi screen blank suspend problem. Bluetooth still kills wifi though.

I always wanted to root a phone anyway.  

The grade for customer support therefore is a big, fat F. Either for being dishonest, or for being completely incompetent. Whichever.

Product Quality, Grade: C

The HSPA+ 4G data service is nice, seems to work as it should with T-Mobile. We usually get download speeds of 3 - 7 Mbps and uploads of 0.7 - 3 Mbps in Santa Fe, NM were there is decent T-Mobile 4G coverage.

The camera is nice.

Battery life is on the short side, maybe 6 - 8 hours if the phone is used sparingly.

The wifi and bluetooth components are a shambles.


Google does not know how to do retail. The online buying experience was a disaster.  Google's customer support is either completely dishonest, or hopelessly incompetent. The Google code forums provide very little feedback to the thousands of bug reports about the Nexus 4. 

When bug reports are made via the Google code forums, progress can be measured by glacial standards. Relative eons pass with no feedback, and little progress. Bug reports about critical features of the Nexus 4 went for weeks before even being acknowledged, and once acknowledged, estimates of time to fix were never given.

Google effectively does not have a working customer support system.

The Nexus 4 looks great on paper. The reality is somewhat different, and at the rate Google is progressing (actually, we can't even tell if they are progressing) someone else will come out with a newer, better working product. 

Our advice: wait for that.


Thursday, February 14, 2013

Opportunity Knocks


We see that potential competition is beginning to snap to the fact that an opportunity has opened up in the Android unlocked GSM cell phone market.

Blood is in the water.

The Google has exposed weakness.

Time to pounce?

Sony is considering the possibility.  As are a number of those quick turn-around knock-off cell phone manufacturers from (shh...) China, and oh, Korea.

Heck, they'd be idiots not to have noticed that Google has not even attempted to respond to the thousands of complaints which have surfaced about major flaws in their flagship offering, the Nexus 4.

Cripes!  A business opportunity.

Google sold a phone -- with under-powered Ecommerce servers, no less -- for which they *oopsie doodle*, appear unable to fix critical flaws. The OS and device drivers for that flagship device are broken! What!? Only part of the phone works!?  Which parts?  Well not the WiFi and bluetooth parts, that's for sure. Maybe the HSPA+ parts work, and apparently that's good enough for Google. But see, that leads to the next part just below.

Here it is, this is where opportunity knocks. First, note that the behemoth is paralyzed. Their support infrastructure is a shambles. Big parts of their phone are broken, and Google has demonstrated that they are incapable of addressing those issues. The Google Device Support toll-free hot line staff are still telling people who call in to complain about the phone that the Nexus 4 has no known problems, for fuck's sake.

Now, if we may suggest, is the time to pounce. Snatch that low-end GSM unlocked cell phone market away from The Google before they own it. Lock in to a working, maintainable version of Android, build the phone, and sell it!

Classic Darwinism in action.

All evidence suggests that at the rate Google is progressing towards fixing the now known critical flaws in the Nexus 4 - three months now with no appreciable progress -- an agile competitor could have a functionally equivalent competing working product on the market comfortably before Google has even publicly acknowledged that they have a problem. Which, of course, they have not done yet, because that would be bad for business.

Go for it.  Competition benefits all of us.  Except the ones who can't keep up.

One word of advice, though, to any of those out there considering this opportunity: don't make up little fibs to your customer base, in case problems arise.  They don't like that. It could get ugly if you did. Tell it like it is instead.  That will work.




After a particularly, um, direct post on the blog here, we immediately see a bunch of stealthy proxy vpn-masked visits from Mountain View, Palo Alto, San Jose, and other communities geographically near the Immense Google Mother Ship.

For example:

Page Views:
Entry Page Time:
14 Feb 2013 17:42:18
Visit Length:
2 mins 47 secs
Chrome 24.0
*Total Visits:
San Jose, California, United States
IP Address:
Proxypacket Vpn ( [Label IP Address]
Referring URL:
(No referring link)
Entry Page:
Exit Page:

Or this black pajama-clad visitor:

Page Views:
Entry Page Time:
14 Feb 2013 17:25:40
Facebook Bot
*Total Visits:
Palo Alto, California, United States
IP Address:
Facebook ( [Label IP Address]
Referring URL:
(No referring link)
Visit Page:

Cookies OFF! Sneak mode ON! BROWSE!

I've got a sneaking suspicion that even you Googleons are (slowly, massively, and with much inertia) beginning to notice the perception that


you have some room for improvement 

you could stand to improve a bit

No, actually, you do pretty much suck

at bringing a product to market.

You're welcome.

No, actually, you're not.  My Nexus 4 is still broken.

And along the way we've noticed that

1) Google's Ecommerce sales infrastructure sucks
2) Google's QA sucks
3) Google's support sucks
4) Google's product feedback channels are non-existent
5) Google is slow to respond to trouble reports 

Other than that, you're doing a great job, keep up the good work!


(BTW: When we say you are "slow" to respond to trouble reports, we mean slow as in "Glaciers progress down the mountain slowly", and not: "That little old lady with the cane sure is slow crossing the street.")

Very Little Surprise Here

As I write this, my Nexus 4 is downloading the 4.2.2 OTA update. But I already know from reading this Google code bug forum as well as several other technical forums this morning, the promised delivery of a less buggy Qualcomm wifi driver did not occur with this release.

Imagine my surprise. Another turd sandwich. WiFi on the Nexus 4 still effectively turns itself off when the screen is blanked.

Ok, it's a few minutes later now, and 4.2.2 is installed. In the interest of completeness, I decided to test to see if the very first bug I encountered with the Nexus 4 last December still exists. This is the bug that if your phone is connected to WiFi and you place a call while using a bluetooth headset, bluetooth kills the phone's WiFi as soon as the call initiates.

You're still batting 1,000, Google.

So now I need to decide if I'm going to send this, my 4th Google Nexus 4 back (see the story about the previous three here, if you're interested), or hang on to it out of morbid fascination to see if Google ever does manage to fix it.


Tuesday, February 5, 2013

Us Department of Commerce

Hmm.  You've got to wonder whether this visitor was taking a professional interest in potentially Evil E-Commerce, or if the person was just researching a potential new Nexus 4 phone.

Page Views:
Entry Page Time:
5 Feb 2013 17:12:30
Visit Length:
34 seconds
Firefox 18.0
*Total Visits:
Montgomery Village, Maryland, United States
IP Address:
U.s. Dept. Of Commerce ( [Label IP Address]
Referring URL:
Entry Page:
Exit Page:

Fourth Time's The Charm


I just ordered another Google Nexus 4.  LG is gearing up to produce a new batch, for which the estimated shipping date of 2 - 3 weeks matches the now-estimated release date of Android4.2.2, which is purported to contain a less-buggy Qualcomm wifi driver, and patches to the buggy 4.2.1 wifi and bluetooth code. Plus, it wouldn't surprise me if LG hasn't tweaked a manufacturing issue or two that I believe existed in their first production run.

Hey, what have I got to lose, aside from the $13 that Google charges to ship it to me?  Google pays the return shipping if the phone is broken.  At the very least I get some more writing material.  For those counting, this will be the fourth N4 that Google will have shipped me.  Maybe it won't be the fourth one I ship back.

Of course, I will have done this four times, so I guess I'm really going to be $52 out of pocket for the privilege of beta testing Google's fine product.


What Is Evil?

Well, we have the answer to the question of when the WiFi and bluetooth problems with the Nexus 4 (and 7, and 10) Google devices will be fixed.  And we didn't get the answer from Google, we got it from the Android Police, who tell us that Android 4.2.2 will be released February/March.

4.2.2 is a bug fix release, in which they will reportedly fix things, oh, like WiFi and bluetooth on Nexus devices.

Which sort of brings up the question: is it evil of Google to sell product which they know is defective, and to do so for months without telling us?  And then to sort of, unannounced-like slip out a software release that silently fixes things?

Google's definition of what is evil appears to be somewhat flexible.


Monday, February 4, 2013

Massive, Indifferent, Brooding Silence

Google is exercising their right to remain aloof to all of the complaints about their lackluster Nexus 4 (and 7, and 10) support.

I see them browsing this site regularly, though.  So we know that they know what we know.

Oh, look!  There's one now!

Page Views:
Entry Page Time:
4 Feb 2013 09:46:57
Google Webmaster Tools
*Total Visits:
Toronto, Ontario, Canada
IP Address:
Google ( [Label IP Address]
Referring URL:
(No referring link)
Visit Page:

Everybody say "Eh!" to our Google colleagues up in Canada.

Oops, here's another, a bit closer to home:

Page Views:
Entry Page Time:
4 Feb 2013 10:48:21
Visit Length:
27 seconds
Chrome 24.0
*Total Visits:
Mountain View, California, United States
IP Address:
Google ( [Label IP Address]
Referring URL:
(No referring link)
Entry Page:
Exit Page:

As a completely unrelated side note, I rode my motorcycle through Mountain View last summer.

So now that we all know that they know what we know about the buggy Nexus 4 (and 7, and 10), perhaps we should all just sit back, relax, and let Google brood further about when they might, or might not, get around to fixing their broken Android infrastructure.

But don't forget, they have the