Pixel C Keyboard Pairing Problem – Solved.

I own a Google Pixel C Tablet, which I did order with its recommended, accompanying Bluetooth Keyboard. I’ve been using it with a lot of fun for months now. But yesterday evening, the problem finally happened to me, which I had been contemplating, which was, that I had spent such a long series of hours using them, into the night, that the keyboard actually went dead. I mean, the batteries of the KB could not live as long as my session would have, and pressing keyboard keys eventually had no more effect on the tablet, as the pressed keystrokes were no longer being received. So what I did was to close the tablet over the keyboard in the recommended way, to plug the two in to have them charge, and to leave them that way overnight.

Next morning, I wanted to find that not only the tablet charge was back at 100%, but that I could just step in and start using the keyboard again. But what I found, was that the tablet – with its battery at 100% – was still unresponsive to the keyboard. So my first conclusion was, that the state of the Bluetooth Pairing, was somehow corrupted on the software-level, between the tablet and the keyboard. So I followed ‘The usual, basic steps, to re-pair the two':

  1. Separate the tablet from the keyboard. The on-screen keyboard will become available.
  2. On the tablet, go into Settings -> Bluetooth, tell it to Forget all Bluetooth Pairings, and turn Bluetooth Off.
  3. Re-Attach the tablet to the keyboard, and watch the tablet ask me to turn Bluetooth On. Do so.
  4. Wait for the Tablet to show me the PIN-number, which I am to type into the keyboard, to make them pair.

The next problem was, that Step (4) above wouldn’t happen. So my next thought was, that one of two things could finally be wrong with my keyboard:

  • The charging system / KB battery could genuinely be defective (Unlikely, as they are virtually still new, and were working before).
  • The logical corruption in the Bluetooth Pairing State, between the tablet and keyboard, could be more-deeply corrupted than I thought, from the broken-off session the previous night, maybe even at the Firmware Level.

So now I proceeded with ‘A more-robust procedure, which amounts to resetting the keyboard, as there does not exist a more-proper, explicit way to reset that keyboard':

  1. Separate the tablet from the keyboard.
  2. On the tablet, go into Settings -> Bluetooth, and tell it to Forget all Pairings / and turn Bluetooth Off.
  3. Soft Boot the tablet.
  4. After the orderly reboot has finished, Go To Step (3) in the more-basic procedure above.

And what I found next, was that after I had allowed the tablet to turn Bluetooth back On, it did in fact greet me with the 6-digit PIN-number, and after I typed that into the keyboard, and after I had hit Enter on the KB, the keyboard worked fine again.


Now, there exist people who claim, that they tried all the steps above, numerous times without success, but that “Suddenly, the keyboard started working again.” To the best of my understanding, what must really have been happening to those people, is that they did try all the above steps, but ‘Maybe not in the correct sequence?’


(Edit : )

Even when there is no malfunction taking place, I never try to reboot my tablet, with the BT Keyboard connected.

My best guess for what goes wrong with this KB, would be that it keeps its local store of information, with its encryption key, as a volatile (RAM) chip, with no backup power-supply. It lacks a non-volatile chip to store that. Hence, when the battery goes fully flat, its encryption key is corrupted, and depending on the extent to which encryption is hardware-based these days, it can also leave a trace in the firmware of the tablet itself, that the tablet was paired with it. Hence the reboot needed.


Pixel C Crash Yesterday Night

Yesterday evening, my new Pixel C Tablet did something for the first time, which was ominous. Its screen just went dark, and then started to display the logo, which it displays during a restart. It followed through with a successful restart.

Some people mistakenly think that this behavior is a reboot. If we were to call it that, then this behavior would need to be called a Hard Boot – as opposed to a Soft Boot, which happens when the user shuts the tablet down from the software-side, in telling it to reboot. In fact, a Hard Boot would be happening when the user uses the power-button to force a Hard Boot, and would have an explanation in that.

In reality, what the tablet did was a spontaneous reset. This type of event is also a File System Event, as the File System was never unmounted. Hence, the tablet also needed to repair its file system when it booted anew.

But, there are certain safety-factors built into how any serious O/S works, and built into how any file system works. So in most cases, the repair to the file system succeeds.

The fact that this has happened to a brand-new tablet, causes me to question how (un)stable it might really be. I’ve only had this tablet for a few short months now.

One of the features of how this happens, which is even less reassuring, is that after the reset, there is nothing displayed in the user interface, which betrays the fact that the reset happened. What this means is that in theory, this could be happening every night as I sleep, even while the tablet is charging, because by the next morning, there would be nothing displayed, to betray the fact that it has happened.

It just happens to have taken place once now, while I was sitting in front of it.


(Edit : )

I should add, that this tablet is running the May 5 patch of Android 7.1.2 .


Latest Android Patch / Norton Mobile Version, Introduce a Bug.

My Pixel C tablet is running Android 7.1.2, and overall I am happy with it. One interesting difference that exists between this stock Android implementation, and the Samsung implementations I am used to, is that this implementation has no disable feature, to look on the servers for the latest security patch. And frankly, I like my devices to be up-to-date.

This means that I have already installed the May 5 patch, with its latest security enhancements.

But this patch seems to have introduced one bug I am aware of. When I go into ‘Settings -> Security -> Device Administrators’ , and when I try to enable ‘Norton Mobile Security’ as a Device Administrator, then I get the message that the Settings app has crashed – each time. Yet luckily, in general, I can still change app permissions – just not Device Administrator Status.

The Device Administrator Status allows one app selected by the user – or several apps if he so chooses – to take over control of the mobile device. It needs to be unset, before the app in question can be deactivated. But apps can sometimes refuse to let users unset this Status Bit, in order to protect the Device Administrator capabilities of the app.

It tends to get used by anti-theft software, so that the anti-theft can remotely wipe, or just track the whereabouts of the device, without a person who may have stolen it, being able to deactivate this feature. So there do exist scenarios in which we’d want this capability.

I happen to have another anti-theft app on the same tablet, which has Device Administrator Status set, so I am not fearful that I would have no recourse, if the device was stolen.

But it would actually be nice to have two anti-theft systems in place, by adding this capability for Norton Mobile Security.

Now, instead of just thinking that the crash is a bug, I could guess that it might be another app, with this bit set, that is interfering in my (user) ability to Set Device Administrator instead, for the app I chose. But more according to my real musings, if another app had set that, the result should just be a message-box telling me that the settings change has been refused… The result should still not be, a crashed Settings App. And so it would seem to make more sense to me, that this is just a bug, introduced by the latest Security Patch. I am hoping that this bug will be gone, by the time the June 5 patch is out.


(Edit 05/18/2017 : )

Actually, it now seems that this bug could be with Norton Mobile Security, and not with Android itself.

The reason I am saying this, is the fact that I can assign Administrator Privileges to another app without problems. The app in question needs to display an additional screen, once we have checked it off, and from that screen, the privilege can be granted.

Norton Mobile Security could contain some programming error, that hinders it from displaying that additional screen correctly, and that causes the Settings App to crash instead.