Google recently upgraded Gmail for Android so that it now not only works with Gmail but also with POP/IMAP and Exchange. Last night I configured Gmail on my Nexus 9 to work with an Exchange server that enforces a security policy requiring device encryption. I didn't expect the encryption policy to be an issue because the Nexus 9 is encrypted by default, as shipped from the factory. Gmail, or the Exchange server, didn't believe the tablet was encrypted and therefore it refused to synchronize.

When I tap Settings, Security, the Encryption section is as shown below, indicating that the tablet is Encrypted. Clearly there was a disagreement between Exchange and Android on the tablet.

After searching via Google, I found others who have had the same problem. The key piece of information is posted in this issue thread on Google's Android forum.

If you have configured devices running versions of Android earlier than Android 5.0 (Lollipop) to be encrypted, and you have a Nexus 9, you should notice a difference in how the Nexus 9 boots up versus those devices. In prior versions you had to enter your device PIN or password once during the initial startup and then the device boots a second time to decrypt and startup. After the device boots, you have to enter that PIN or password a second time in order to access the device.

The default boot up process of the Nexus 9, with encryption enabled as indicated in the screen shot above, does not have the initial PIN or password prompt. Instead, it starts up just like any other, non-encrypted Android device, although you will have to enter the PIN or password in order to unlock it. Apparently, the Exchange policy that confirms whether the device is encrypted is checking to see whether that startup PIN or password is assigned, but it doesn't provide this specific information.

The encryption policy requirement causes Gmail to force you down the path of encrypting the device, in other words, it acts as if it thinks the device is not encrypted. If the battery has at least an 80% charge, and is plugged into power, you can elect to encrypt the tablet. The encryption process will reboot the device, determine that it is encrypted, and leave you at the screen lock, and you will keep cycling though this process.

To make Exchange, and presumably any other application or process that requires it, recognize that the device is encrypted you need to configure Android to require a PIN or password at device startup. Tap Settings, Security, Screen lock, then enter your PIN or Password. Tap the option you prefer on the screen lock screen, in my case Password, to display the page below and select the option Require Password (or PIN) To Start Device and tap continue. You will be prompted to enter either a Password or PIN and specify how notifications display on the screen lock page.

After configuring my Nexus 9 to require a password at device startup, Gmail and Exchange recognized that the tablet was encrypted and data synchronization began. Assuming that the Nexus 9 is in fact encrypted by default as the settings indicate, Android should be reporting that a device startup Password or PIN is required rather than acting as if the tablet is not encrypted. As it exists right now, the user is sent down an infinite loop of executing the process for encrypting an already encrypted device and returning back to the Gmail Exchange account settings to encounter the Encryption Security policy requirement over and over.

01/07/15; 03:18:04 PM

I got a Moto 360 for Christmas, and while I am happy with the watch's functionality, I've been struggling to manage battery life.

Unlike Android smartphones, Android Wear does not include what I consider to be robust battery monitoring tools. You can use the Android Wear app to see a graph of battery life, with a prediction on how long the watch will last before the battery drains, but it doesn't provide specific information on what is consuming battery life.

Wear Battery Stats provides a little more detail, but it is not as good as the GSam Battery Monitor app I use on my Moto X. The one important piece of information that Wear Battery Stats does provide is the percent of battery consumed per hour, which is the best indication of how well the device is using power.

Initially, the Moto 360 consumed more than 10% of battery per hour, which is not good at all and results in much less than 12 hours of overall battery life. Twelve hours is the minimum amount of total battery life one can live with, truth is you really need about 14 to 18 hours to get one through a full day from waking up to going to bed. I can live with recharging the watch every night as I sleep.

I should mention that I have the very latest version of Android Wear on the Moto 360, it was pushed to the watch right after I initially set it up.

Several posts I found on the Internet suggested that there is a break-in time during which the battery monitoring syncs with the actual battery life, and this seemed to coincide with my experience. I have also found that watch faces, particularly ones that display information like the temperature and steps, can consume a lot of power. Facer is a popular app for downloading free watch faces and changing them on the watch, but I have found it consumes too much power just by being on my phone and watch. Watchmaker appears to have a much less hit on battery life.

Over several days I managed to get the hourly battery drain down to around 5%, but after my first commute to work today battery during the one hour commute was drained 25%. What was I doing?

During my commute I use Pocket Casts to play podcasts on my smartphone. When I checked Android Wear, it indicated that Bluetooth was the highest power consumer. Best that I can tell, it seems that because playing Pocket Casts causes media controls to appear on the watch, doing so drained the battery at an alarming rate.

I found that there is no way to disable media controls on Android Wear. I posted on Google's product support forum of my experience and theory that media controls was causing the problem, but others responded saying they have no problems using media controls.

Next, I went to Motorola's forums and found a thread started by others who found that after they installed the latest version of Android Wear, version 5.0.1, on their Moto 360, they had worse battery life than prior to the upgrade. (I note that prior to an update released on September, the almost everyone was experiencing poor battery life, but the September update seems to fix that problem.) Some reported on this thread that Bluetooth appears to be the highest consumer, which aligns to my experience this morning.

I followed instructions posted on the thread to uninstall Android Wear and Moto Connect, do a factory reset of the watch, then go through the first start setup process, which according to others, restored battery life to what it was before the 5.0.1 update was installed. I know I didn't do a factory rest after the update installed on my watch, so I am hopeful this resolves the problem.

Unfortunately, I am not home right now so I cannot recharge the watch to observe whether the reset that I have performed has resulted in better battery life. If it continues to discharge at the previous rate the watch will be dead by the time I commute back home later this afternoon. I hope that the factory reset provides the fix to the problem.

What I am finding is that battery life is a huge issue with Android Wear. If one spends more than $200 on a device they don't want to limit how it is used just to get the battery to last a full day. A smart watch needs to provide full functionality or it ceases being "smart" and not worth the cost. Certainly, features that cannot be disabled, like media controls, must not be huge battery drainers. If the media controls continue to be a problem the only solution I can think of is to not use my smartphone for listening to podcasts, which totally unacceptable. A smartwatch should not decrease my smartphone's functionality, particularly given the fact that it is really a smartphone accessory.

01/05/15; 11:56:39 AM

Last built: Wed, Feb 17, 2016 at 3:26 PM

By Frank McPherson, Monday, January 5, 2015 at 11:56 AM.