As a follow-up to my last article where I discussed the merits of using STA versus mVPN for WorxMail, I wanted to write a more general article on the vast topic of battery life. This seems like one of those topics that every vendor probably talks about internally, but no one really publishes anything externally-facing on the topic. So I thought I’d take a stab at this topic from a Citrix perspective, specifically how things like WorxMail, STA, encryption and our new client, Worx Home, affect battery life. Because let’s face it – the battery life of your personal device is precious – and I continually hear folks complain about poor battery life. I realize there are a ton of variables, so we’ll tackle the big Citrix-related stuff that seems to have a significant impact on battery life first…and then we’ll wrap-up the article with some general tweaks, most of them having nothing to do with Citrix at all.
To be clear, the goal of this article is to really set expectations in terms of battery life if you deploy XenMobile. I’d like to answer popular questions like “how does WorxMail compare to native email clients on Android and iOS?”, “how does the STA method compare to mVPN?”, “do features like encryption and notifications have any impact to battery life?”, etc. If we can at least provide some high-level guidance on those topics/questions, then I think our customers will be better served.
I’ve been doing extensive battery life testing ever since we introduced CloudGateway and the Mobile Solution Bundle (now XenMobile Enterprise). I’ve done tests in my home lab, our public-facing Citrix Demo Center, and most importantly, in several real customer environments. I’ve used a variety of devices in my testing, namely a GS3, Nexus 7 and iPad tablets, and iPhone 4’s and 5’s. And lately, I’ve been working with our Product Development team on some more formalized battery analysis/testing. So the results that I’m about to share are rough guidelines and I’m going to generalize results for both iOS and Android – your mileage will absolutely vary and I’m going to express things in terms of percentages, not actual hours or minutes since all devices and batteries are different. And as part of the “baseline” for these tests, in almost all cases (unless otherwise noted), Bluetooth, location services and WiFi were OFF. Only a single mail client was used at any given time and “auto brightness” was enabled.
WorxMail – STA vs. mVPN
The first question I wanted to answer is “How does WorxMail compare to native email clients?”. The answer first depends on how your Exchange ActiveSync (EAS) services are architected and configured. If your EAS services are “exposed” externally, then you really don’t need to use anything like mVPN or STA to access those services. But let’s assume your EAS services are only available internally for security reasons. Then the answer depends on whether you use WorxMail with mVPN or STA. If you haven’t read my other article by now on this topic, it’s a good time to do so. But for WorxMail specifically, we highly recommend using the STA method as opposed to mVPN. After all, this new STA method is specifically designed for WorxMail and WorxMail only (at this time anyway – that may change)! And since I already sort of answered this question and talked about mVPN in my other article, I’m not going to re-hash that here. So the focus will be on the scalability and performance of STA here. With STA configured properly, the “damage” can be as little as 6% in the best case scenario (more on the “best case scenario” in a minute). In the worst case scenario with STA and WorxMail, you can expect about a 19% reduction of battery life. So in most cases, as a general rule, we might want to split the difference and say that WorxMail w/ STA results in ~10% hit on battery life compared to native email clients. And that’s really what we’re seeing in the field…and what I’m seeing personally.
WorxMail – LTE vs. 3G vs. WiFi
This is one of those things that is not Citrix-related, but made probably the second biggest impact in terms of battery life (much to our surprise). As I mentioned earlier, in most of our tests (and all of our initial tests), we simply turned WiFi off and used whatever network was available. But then we started noticing some weird stuff on 3G networks, so we started testing different service providers (Verizon, AT&T, Sprint, etc.) as well as WiFi and non-WiFi connections with WorxMail. We found that WiFi (which is usually a battery drainer in itself) actually yielded the best results in terms of WorxMail battery life – that was the best case scenario I was talking about earlier with only 6% overhead. We’re still doing 3G testing, so the jury is still out there and I will share something when we are finished with the testing. On the other hand, on LTE networks, we saw about a 12% overhead with WorxMail compared to native mail clients using the same network connection.
WorxMail – Encryption and Notifications
Two of the other key features we were “suspicious” about were encryption and notifications. We all like data to be secured at rest, right? And we all like those cool pop-ups and alerts when we have new mail, right? We sure do…but how much do those things cost in terms of battery life? We ran a ton of tests to figure that out…as it turns out using encryption with WorxMail (default by the way) results in about a 4% hit on battery life. And having notifications enabled or turned on results in about a 3% hit on battery life. So if you want those nice features, you’ll have to pay a bit for them. The good news is it’s not going to cost you much. But it’s all about trade-offs whenever we talk about security versus performance or user experience. 😉
Worx Home (and really the XDM Agent)
In case you haven’t heard, we’re starting to roll a few clients into this new thing called “Worx Home”. Which clients you ask? Well, it sort of varies by platform today. On Android, that would be Receiver and the XenMobile MDM Agent. On iOS, that would be Receiver, the XDM Agent and Enroll. Since the overhead of Receiver and Enroll are negligible in terms of battery life (less than 1%), we’re not going to talk about those. But we do need to talk about the performance impact of the XDM Agent. And this is another one of those things that varies by platform – namely because on iOS we have APNS and we’re checking in with Apple every 6 hours (by default – this is configurable actually). And on Android, we aren’t using the APNS equivalent – we have our own notification system and we use “scheduling” policies to enforce things. But in a nutshell, we have an always-on connection on Android if we want to enforce anything. We can configure scheduling policies as I mentioned to either enforce that connection 24×7 or we can relax it and tell it to only keep a connection to the XDM server from 9 am to 5 pm on weekdays, for example. And this obviously affects battery life and makes it much more difficult to predict on the Android side of the house, since every customer has different security and enforcement requirements. The other thing that makes this whole topic tricky is the tremendous variety of MDM settings one can choose to enforce. Some customers might only configure a single deployment package with one MDM policy to block camera usage – another customer might have 50 policies and 20 different packages. But all in all, you should expect somewhere in the 2-5% range depending on what policies you’re enforcing, what platform you’re using and how often you’re checking in. I’ve tried a number of different policies and scheduling variations over the last year after we acquired Zenprise and I can say that I’m somewhere in that range as well – typically 3% overhead in terms of battery life.
I should also mention this is one area where we actually DO have something documented on our public-facing website (for Android anyway)! So if you want to read more about how specific MDM policies affect Android battery life, here is the link to an informative eDocs page. But it pretty much aligns with what we’re seeing in the field and what I just said – expect about a 2-5% hit for the XDM Agent or Worx Home itself.
Other General Battery Life Improvement Tips
These types of tips are all over the Internet, but let me summarize a few of the more common tips and some of the more important ones as they relate to WorxMail, Worx Home and XenMobile battery life:
- If you’re using WorxMail, disable your native mail client and other account sync policies that you don’t need (which is what we did for all our tests)
- Disable services like Bluetooth, WiFi and location services/GPS (or toggle them only when you need them using widgets like I do)
- When you are roaming or out of a solid service area with a good connection, disable your mobile network (3G, LTE, etc.)
- Use the latest versions of WorxMail for Android and iOS – we’ve made significant improvements to the latest Worx apps, even over the last few months
- Keep your Android and iOS firmware updated
- Reduce the brightness of the device to a lower level and keep auto-brightness on. This is always one of the biggest battery life drainers on laptops, phones, etc.
- Keep auto-lock enabled and set to a low value like 1 minute
- Turn off notifications for apps that you don’t use
- Make sure you’re using STA as opposed to mVPN when using WorxMail (if your EAS services are not exposed externally)!
As you can see, your mileage is going to vary based on a number of factors. But I hope this at least provides the Community with some sort of high-level guidance in terms of what to expect with battery life as you deploy XenMobile. To put this in perspective and wrap things up, I used to average about 16 hours of battery life a day with my GS3 and native Android mail client. I have been using the latest versions of Worx Home, WorxMail and Receiver almost every day for the last 6 months and I’m able to routinely get about 13-14 hours. So I am somewhere around the 15% range in terms of overhead to battery life…right where we’re shooting for honestly in my opinion. I have to also note that I’m a Verizon customer and I spend probably half my time on WiFi and the other half of my time on LTE networks. We have minimal MDM policies deployed in the environment I connect to and a pretty relaxed enforcement schedule (8×5). I’m also extremely picky about what runs on my phone in terms of services and processes, so I disable most stuff through the use of widgets and really only enable things like location services and Bluetooth when I absolutely need them. On the other hand, if you’re in a high-security environment with a large number of MDM packages/policies and maybe you’re users aren’t the most savvy in terms of controlling what’s running on their devices at all times, you might expect somewhere in the range of 25% overhead. If you’re experiencing a reduction of battery life by 30% or more, I would almost venture to say you’re using mVPN or something is configured incorrectly.
Hope this helps. Special thanks to Suresh Mathew John and the entire XenMobile Dev team who conducted a lot of the formalized testing. I’m sure this will be a hotly debated topic for many years to come, but feel free to drop me a comment and let me know how you have your specific XM environment configured and what you’re experiencing in terms of battery life. I’m expecting nothing but positive comments. 😉
Nick Rintalan, Lead Architect, Citrix Consulting