Category Archives: Android

Samsung’s Microsoft deal and Cyanogen

SamMobile reported last night that Samsung was planning to pre-install a number of Microsoft applications on the Galaxy S6, which is to be announced in a few weeks at Mobile World Congress. I think this is a huge boost for Microsoft’s Android apps and for the services behind them – far bigger than the applications that come pre-installed with Microsoft’s own devices, obviously. To get on Samsung’s flagship device (presumably others will follow) is a huge coup for Microsoft. But it’s also a big deal for Samsung, which has until now been pre-installing ersatz versions of Microsoft apps on its devices for productivity.

But what I really wanted to talk about here was what this says about Microsoft’s broader strategy, and what it might mean for the rumored investment Microsoft is making in Cyanogen. Nokia, of course, forked Android itself using AOSP when it created the Nokia X line of smartphones shortly before the Microsoft acquisition was announced, but it was killed off right after Microsoft took control. So rumors of an investment in yet another Android fork seem funny – was Microsoft hedging its bets on Windows Phone and preparing another Android-based device line?

I think the much more likely explanation is that Cyanogen and Microsoft are planning something rather different, something much more along the lines of that Samsung deal. Cyanogen’s biggest weakness is that it’s missing all the Google apps and services that you sacrifice when you use AOSP. The challenge for any company doing this outside of China has always been what to replace them with. Inside China, it’s simple, because Google’s own services are largely irrelevant and local alternatives are actually better. But outside China, Amazon and others have struggled to provide really compelling replacements. The two companies that have comprehensive sets of services and applications that can replace Google’s today are, of course, Apple and Microsoft. Apple’s are (today) unique to its own products and platforms, but Microsoft is increasingly pursuing a cross-device strategy. Hence its investment in Cyanogen.

I wouldn’t be at all surprised if at least some flavor of Cyanogen devices in future come with Microsoft apps and services where the Google ones would normally be. We won’t see Microsoft launching another Android-based line of devices, but rather an Android-based line of devices that puts Microsoft’s services and apps front and center. That, after all, is the real goal here: getting Microsoft’s services in front of as many customers as possible, integrated into the platform in a way that makes them the default options for key tasks, and which provides benefits across the platform. Windows Phone has been the only platform where that’s been true, but Cyanogen could easily become a second. Quite what Cyanogen’s current customer base would make of that is unclear, but then Cyanogen’s future depends on broadening its appeal way beyond the hackers and tinkerers who flash alternative ROMs on their Android devices, and Microsoft could be a great fit there.

Both these deals – Samsung and Cyanogen – are good for both parties. Samsung and Cyanogen both need compelling apps to set their platforms apart, while Microsoft badly needs the broader exposure it will get from being pre-installed on these devices.

Quick thoughts: Another way to think about Nest

A couple of good blog posts from other analysts this morning triggered a thought in my mind about Nest.

The first of the two blog posts is from my fellow Techpinions contributor Ben Bajarin. I recommend reading the whole thing, but here’s the key thought:

Apple’s customers are higher value customers and their growing installed base means they are amassing one of the largest, if not the largest, installed base of premium customers on the planet. This observation has some striking implications…

He goes on to talk about two of the implications, and I think the insight there in  particular is great. One of them is the impact this has on the competition, among which of course we find Google, which owns the mobile operating system that’s mopping up the vast majority of the non-Apple customers.

Something else I read this morning (a post from Benedict Evans that’s really about something completely different) prompted me to think about this in the context of Google’s Nest acquisition. I’ve been thinking about Nest primarily as Google’s strategic play in the smart home space, and as the hub and vehicle for the rest of what Google will do in the home. And I think that may well be in large part what that Nest acquisition is about.

But thinking about Nest in the context of Ben Bajarin’s piece made me see Nest in a different way. Think about Nest for a minute: its characteristics as a product, the people it’s likely to attract, even the people who work there. This is a very Apple-like product, made by a former Apple executive, and I’ve always said that Nest was a much better fit at Apple than at Google. It’s even sold in Apple stores.

What if Nest is at least in part about capturing those very lucrative and attractive Apple customers without having to convert them to Android? What if what Google is building with Nest is at least in part a concession that Android and phones based on Android aren’t likely to attract these customers, but by playing in a completely different space – the smart home – Google can in fact attract those customers? And once it has them there, perhaps convert them to other aspects of the Google ecosystem, which after all is where Google really makes its money? There’s no particular reason why Google needs to have all its customers on Android anymore – it’s served its function of preventing Microsoft and Apple from dominating the mobile world. And of course, there’s been lots of talk about even Google’s services making more money on iPhones than on Android. What if Google could establish a different beachhead in devices that’s not dependent on first converting people to Android? What’s fascinating about Nest is that it’s about the only recent Google initiative that’s not about reinforcing Android as a platform – Android Wear, Android Auto and Android TV are all about extending Android specifically into new domains rather than simply spreading Google services into new domains.

I’ve no idea if this was actually part of the thinking behind the acquisition of Nest – most likely, like other acquisitions, it wasn’t about a single strategic objective but rather several. But it would certainly be an interesting response to the emerging reality that Apple has captured the vast majority of the most valuable customers within its ecosystem, and trying to win them back through phones seems to be a losing strategy.

The big downside to this, of course, is that Google has very deliberately kept Nest somewhat at arm’s length from the rest of the company (a point Benedict raised in his post). But this strategy only works if Google continues to build links between the two, as it’s already begun to do with Google Now integration. With Tony Fadell now overseeing Glass as well, there’s obviously even more linkage between Google proper and the Nest team, and it’s another sign that Fadell might be asked to oversee more Google devices and pursue the same strategy.

Motorola’s lessons for Samsung

I’ve been testing three of Motorola’s new devices for the last several days: the new Moto X and Moto G smartphones, and the Moto 360 smartwatch. I don’t do traditional reviews – there are plenty of sites out there that do those well – but I thought I’d share some of my thoughts about these devices, briefly, but also about what they can teach us more broadly, and tech Samsung specifically.

Moto X

Last year’s version of the Moto X was already a very good device in a number of ways, and this year’s version fixes several problems: the price/performance ratio feels a lot better, the materials and build make for a more premium experience, and the camera is a lot more competitive. I’ve been using the Moto X as my main phone for the last few days, and I’ve really enjoyed it. The camera still isn’t as good as the iPhone camera, or arguably the Galaxy S5 camera, especially in low light. And the digital shutter mechanism still frustrates me by taking pictures when I’m trying to change the focus point. But it’s an awful lot better, and I’ve taken some nice pictures with it, including this one:

IMG_20140914_162715In short, the Moto X is much better on the things it was bad at. But it’s also got even better at the things its predecessor was good at – namely the little software customizations that added significantly to the stock Android experience without taking it over, adding huge numbers of visual customizations and tweaks, or overloading the device with gimmicks and widgets. What Motorola has done really well in these devices is creating in its software elements that significantly add value to Android without feeling like they’re trying to replace it. They’re done in such a way that they feel like they are – or should be – part of the core OS, both visually and in terms of their functionality and integration into the OS itself. Unless you’ve used stock Android, it would be hard to see where Android itself ends and Motorola’s enhancements to it begin.

In many respects, this is just the sort of thing Samsung should have been working on over the last few years, to set its handsets apart against the flood of other Android phones. Instead, it’s focused on gimmicks – features that are eye-catching and make for good demos, but that don’t really make life easier or improve upon the core Android experience. If Google were keeping Motorola, I would say these features should slowly work their way back into the core Android experience as Motorola invents new ones. Under Lenovo, I wonder to what extent these innovations will continue and to what extent Lenovo will embrace them at a corporate level and build them into its other devices too. If it’s smart, it will realize what it’s getting here and fully embrace it.  Continue reading

The three problems with Android Wear

I’ve been using an Android Wear device – the Samsung Galaxy Live – since I picked it up at I/O last week. I’ve tried a number of other smartwatches before now, and it’s interesting to see the differences. As it’s currently constituted, I see three flaws with Google Wear, two of which seem to be pretty fundamental, and one of which should be fixed soon:

Cards are a bad UI for small screens

Cards make a ton of sense on smartphones and tablets and on the web, where they provide useful visual separation between discrete chunks of information, and they work well on Twitter.com, in Google Now on smartphones, and elsewhere. But on a space-constrained screen they really don’t work because they’re a terribly inefficient use of screen real estate. There are several different layers of information in Android Wear, as shown in this triptych:Android Wear triptych 560px

The first screen is what you see before you interact with a card – the card stays in the bottom half, and takes up just a third of the screen. The amount of information presented is extremely limited. If I then interact with the card, I get the middle screen, which is slightly richer but still takes up only half the pixels on the display. If I then swipe, I get even more information as shown on the right. But the card still only takes up half the screen. Compare this with the Galaxy Gear 2, which (though not a paragon of great UI) uses the whole screen to display notifications. This is a minor annoyance with the weather card from Google Now, but it’s really annoying when a notification comes in about a new email, and just a tiny amount of the email shows by default – I almost always have to tap on the small card to make it big enough to have a real sense of what it’s about. The “glanceability” factor just isn’t there.

The cards UI, with its limited use of the screen space, and the rest given over to a background that really adds nothing, is just not a good fit for such a small screen. It’s a great example of the problem with applying a single design language, essentially without modifications, to multiple form factors. It’s a problem that Microsoft has struggled with too in the form of Windows 8, and one that Apple so far seems to have managed to avoid in providing useful integration between iOS and OS X without taking things too far.

Google Now is still too much just in case and not enough just in time

Continue reading

A review of early Android Auto and Apple CarPlay support

Apple announced on Tuesday that it had added several new auto manufacturers to its list of partners for its CarPlay automotive platform. Given Google’s official launch of Android Auto last week, we now have two major platforms looking to do very similar things in the car: namely, extending certain smartphone functions to the in-car display. I thought it would be useful to have a quick look at how the two platforms are shaping up in terms of their support from major automobile manufacturers.

Here’s a summary of support by the major manufacturing groups 1. A full list by brand follows at the bottom of the post.

Android Auto and CarPlay support by major manufacturing groupWhat’s striking is that there is no clear pattern between the two sets of companies. Both companies have just under 30 total brands supporting their platform, and there’s no clear separation between luxury and non-luxury brands, as one might expect given the the market segments iOS and Android skew towards. Yes, Ferrari and BMW are CarPlay-only for now, but Maserati, Acura and Infiniti are currently only supporting Android Auto. There are major groups that appear to lean one way or the other – the VW group, for example, appears to favor Android Auto, but its Audi brand is on both platforms, while Peugeot Citroen is CarPlay only.

There are quite a number of sub-brands which are not on either list yet – particularly where a manufacturer has a core mid-market brand with high-end and low-end sub-brands: GM’s Chevrolet is committed to both platforms, but there’s no mention of Buick, Cadillac or GMC. Similarly, Toyota is on CarPlay, but there’s no specific mention of Lexus or Scion at the high end or low end. It’s likely that these companies will experiment with either platform or both in one or two mainstream models and then extend them to others as demand warrants. The main other marques missing are high-end luxury brands such as Porsche, Lamborghini and Bugatti.

The other glaring omission, though, is Tesla, tiny in terms of overall manufacturing share but a very tech-centric brand and one which likely shares a great deal with the target market for CarPlay and Android Auto. Tesla, of course, already incorporates a large, smart screen in its cars, and as such doesn’t have the same need to buy in something better from Apple or Google. But to the extent that users will want their own smartphones, rather than an independent car-based system, to drive their entertainment, navigation and communication experience in the car, Tesla may still want to find ways to work with Apple and Google to enhance its infotainment solution. The challenge will be that both Android Auto and CarPlay are designed to essentially take over the UI, something that makes much more sense on a traditional small car screen than on Tesla’s 17-inch display. It’s likely that it will want to build something more customized than what we’ve seen from either platform so far.

Perhaps the most cheering element of the support both platforms have received from major manufacturers is that so many of them seem to be planning to support both, even in the relatively short term. Given that the biggest objection from many users to the whole concept of a Google- or Apple-powered in-car system is that they don’t want to have to choose their car purchasing options limited by their choice of smartphone, this is a welcome trend. The best outcome for consumers would be in-car systems that either come with both platforms pre-loaded, or with the ability to activate either at any time. It seems that Volvo, Honda and Hyundai may be moving in this direction already, which again should be a cause for celebration. This will have to be part of a broader shift towards more upgradable in-car systems, which will drive demand for in-car connectivity and create opportunities for other players such as wireless carriers.

The key thing here, though, is that we’re very early in the development of this new market. Both platforms currently rely on wired connections between the phone and the car to a degree that most customers won’t be happy with. Bluetooth and potentially WiFi connectivity seem logical next steps for improving the experience. But for the most part, all we’ve seen today are concepts and some very early commitments to include Android Auto and CarPlay in some models. It will likely be a couple of years before we see broad support for these platforms in a large number of models, and the list of manufacturers supporting each will likely grow significantly between now and then.

Here’s the full listing of support by brand: Continue reading

Notes:

  1. This is a surprisingly complex exercise, given the sometimes intricate relationships between the various marques and their owners – e.g. I’ve listed Porsche as part of the VW group, but technically the Porsche company is an owner of the VW group

What we learned at I/O about Google’s app revenue

With both Apple and Google’s developer events behind us now, we have some useful new numbers to play with, specifically on the amount both companies have disbursed to developers. In today’s Google I/O keynote, Google announced that it had paid developers $5 billion over the past year, and that this was 2.5 times what it had paid developers in the previous twelve-month period. This gives us some really good numbers to start plotting overall Google Play developer payments for the first time. The Wall Street Journal also reported today that Google is now retaining almost all of its 30% cut, as does Apple, rather than giving the majority to carriers as it once did. This, in turn, allows us to calculate Google’s revenues from Google Play as well.

Google is catching up quickly in payments to developers

First, a comparison of quarterly developer payments on both platforms. I’ve filled in the blanks with a nice smooth curve on the Google Play numbers, and although my fairly accurate estimates on the iOS side are pretty lumpy too I’ve smoothed that curve as well to make them easier to compare. (The reality is developer payments go up and down because app spending goes up and down as new devices ship and are sold in large numbers around major launches and the holiday period, for example.)

So here’s a chart comparing developer payments from the two companies since the inception of their respective paid app stores:

Google and Apple developer payments Continue reading

Updated Android version charts

Back in December I posted some thoughts on Google’s regularly updated Android developer dashboard, which provides data on the adoption of various flavors of Android as well as screen sizes and densities in use by devices hitting the Google Play store. As we now have several more months’ data to look at, I thought I’d update the charts from that post and revisit some of the trends I saw in evidence back then to see if they still hold.

Android versions in use

Here’s the overview of adoption rates for recent versions of Android, grouped by dessert name: Recent Android versions in use

Let’s test some of the observations I made last time around:

Major versions (i.e. those grouped together by dessert name) tend to take about 12-18 months from launch to hit their peak, usually at around 60-70% of the base

Continue reading

Calculating Microsoft’s Windows Phone revenue

I was going through Microsoft’s 10-Q for the quarter ended December 2013 when I discovered that, for the first time as far as I can tell, there’s enough information in the discussion of the results to derive a figure for its Windows Phone bucket for the quarter. In fact, there’s enough information to derive the number for three other quarters as well. Armed with this information, it may be possible to have a pretty good attempt to estimate revenues for other quarters and therefore the run-rate for this business. Let me walk through those numbers first. The key sentence in the 10-Q is this:

Windows Phone revenue increased $340 million or 50%, reflecting higher sales of Windows Phone licenses and an increase in mobile phone patent licensing revenue.

There are two things to note here:

  • First, the company gives both a percentage and a number for the first time (it’s previously only ever given numbers without percentages), which are enough to calculate last year’s and this year’s number. If $340 million is 50% of the number for Q4 calendar 2012, then the number for that quarter was $680 million, and the number for Q4 calendar 2013 is $1.02 billion 1.
  • Secondly, Microsoft makes clear (as it has in previous quarters) that what it describes as Windows Phone revenue actually includes its patent licensing revenue too, e.g. from Android devices. So this isn’t just license fees from Windows Phone OEMs, but that’s one chunk of it and patent licensing makes up for the rest.

A couple of paragraphs down we get this additional information for the six months ended December 2013, i.e. the third and fourth calendar quarters combined:

Windows Phone revenue increased $440 million or 46%

With the information previously given, we can now deduce revenue figures for two additional quarters with reasonable accuracy: $277 million for calendar Q3 2012, and $377 million for calendar Q3 2013. In the 10-Q for calendar Q3 2013 Microsoft said that Windows Phone revenue increased by $102 million, which more or less matches up with the $100 million difference in my numbers, suggesting we’re on the right track here. Digging back through other previous filings, there are quite a few instances where Microsoft gave a growth figure for Windows Phone in dollar terms, which helps get a sense of overall growth rates and allows us to fill in some gaps in between these numbers. I’ve had to play around with the numbers quite a bit here, but at this point my numbers fit exactly with the growth numbers provided, so I feel pretty good about them. Here are my estimates for the last ten quarters: Continue reading

Notes:

  1. When using percentages to make these calculations, your results might be a couple of million dollars off, but they’ll be very close.

Thoughts on Google’s Android version charts

Google regularly updates the data it provides to developers on Android versions in use, screen sizes and screen densities, and I’ve been diving into this data today for a report I’m working on. In the next few days, Google will update the data again and there will no doubt be the usual flurry of blog posts and news items about Android fragmentation. But I wanted to share some thoughts that occurred to me as I looked through this data that go beyond the usual rhetoric. Some of these are original, some of them likely aren’t.

Firstly, a fairly predictable pattern has emerged in the adoption of the versions of Android, as follows (and as illustrated by the chart below) 1:

Android Major Version Distribution Continue reading

Notes:

  1. It’s worth noting that the methodology Google uses for all these numbers changed in April 2013, and now reflects only devices actively using the Google Play store, and not all devices as previously. From what I can tell, it hasn’t made an enormous difference, but has slightly increased the representation of newer versions while decreasing or eliminating the representation of older versions.