>And 57% of our demographics are on 5.0 or newer, with 19+ covering over 80% of users actually using the app
You must have a very unusual user base! We have 11.6% using 5.0 or newer, and apps in our category (Communications) have average of 16% using 5.0+. Our largest user base is for 4.4, at 49%.
Sometimes, Google releases some really cool new APIs or a new design language, and when that happens there's an opportunity for apps to show up that disregard all the other legacy stuff and are built specifically around those new APIs or with the new design language.
That's how they manage to capture a large percentage of the few users who have the latest version of Android. That's how the app builds a strong brand for the "new stuff", and then can usually maintain that brand as all devices start being replaced by devices that support those APIs.
Other time, they don't improve that much on their app, and someone else comes from behind and makes a better alternative with the new APIs, though.
However, as discussed below, the amount of users in the world with Google Play ≠ active app users. If you collect stats on your app's actual usage, I think you'd find that they are much more up-to-date than the Developer Dashboard stats would have you believe.
There are many useful libraries to get a close-enough Material experience working on the older devices. And I am not talking about the official support library, which should be at least on a par of many MIT licensed Android extensions out in the marketplace.
There's more to the Android APIs than UI stuff, which is the majority of what's covered by workarounds like the Compatibility Library. This is a very real problem with Android development -- "hey look at all this cool stuff we've added and you'll be able to actually make use of in two years!"
Sure we are using them, but for example the design support library is not very satisfactory.
The whole approach of backwards compatibility has not worked out well. Google's alternative approach for the last two years have been the Play Services, which are now a behemoth requiring multidex in your app, when the majority just use the API client libraries from them.
What I generally recommend for mass market apps is to code for the latest or near-latest API level, depending on features that are useful in new API levels, and to simultaneously or soon after back-port a version using the compatibility libraries for older devices. Note that you can target higher API levels than phones in the the current sweet-spot have by testing for API availability (I.e. use forward compatibility, not just back-compatibility). Depending on the shape of the market, this can be a better alternative for some Android versions than using the compatibility libraries.
This puts future development on two, or, for very mature products, on three tracks where you have a code-base for up-to-date devices, and another for somewhat training edge devices, and maybe a third for old devices. Very often new phones have an outsize value to app developers because that's where the new phone customers, who buy apps at a higher rate than people with two-year-old phones.
YMMV. If you don't have tens of thousands of users, you aren't going to do it that way. Or, if you app has no need for the latest features, you won't do it that way.
If you just need some API client libraries then you can compile most modules separately[1] e.g. Ads, Analytics, GCM, etc. This makes Play Services actually usable without multidexing.
Well if you write a hybrid app in polymer you can use material for everybody and share out a copy of your app on the chromeos app store and ios off the same code.
OEMs (and probably carriers) really need to get their stuff together. It really sucks that here we are talking about M when very few devices have seen an L release.
The new UI style and notifications means all the skins have to be revamped. That takes a lot of investment, and the only other benefit users are likely to notice is slightly better battery life. Lollipop has better security, but unfortunately that's still not a big selling point. Hopefully cell phone makers have had enough time to update their skins to look good with (or pave over) Material design, and we'll see more updates for M than we did for L.
Then they would have basically no way to compete with one another other than marketing and specs. Touchwiz and all those other gimmicks really do sell phones. That's just speaking from anecdotal evidence, but I assume big corps have done their homework on this one. Remember that the types of people reading this comment are not your average consumer. We might hate it, we might know it's not as good as stock android... but we're a very small segment of the market (especially for Android). You probably don't see a ton of nutritionists/personal trainers eating at McDonalds, either.
The downside of having an open platform is that OEMs will add crap to differentiate themselves - just look at the weird media bs that comes pre-installed on tons of windows laptops.
I suspect this is temporary. A lot of the big OEMs from just a couple years ago are massively losing money on Android. HTC, Sony, LG, etc all reported signficant losses. I imagine the market will tigheten up with one or two premium OEMs (Moto, Samsung) and some bottom feeders selling super budget phones. When things finally tighten up there will less incentive to make these difficult to maintain Android custom distros and more incentive to get closer to the stock as a way to make updating easier. Google may also put in a full theming engine to help this along. Marshmallow has a basic theme engine form what I've read, so that's a start.
I think Google knows that the status quo with Android is unsustainable and will need to migrate to a more tightly controlled business model. Samsung's flirting with Tizen hasn't paid off and they're more or less stuck with Google dictating policy now. The monthly security updates thing sounds promising as well. Its time Android got serious about security and updates.
I tried both and I was all about going back to iPhone, until I tried Cyanogenmod, which puts (a lot of) the sense back into Android. It uses the Google launcher (without the Google Now page integrated on swipe left), but it removes the insanely annoying design decisions by Samsung, e.g. displaying a confirmation dialog when you increase the sound volume over a certain threshold even with your Phone locked in your pocket and you bombing it on your bike downhill. Or the "cannot use camera" and "sorry, dimming your screen" on 5% battery threshold. I don't know what they are smoking at Samsung, but it's not good.
> displaying a confirmation dialog when you increase the sound volume over a certain threshold
Don't blame Samsung for that, my Nexus 7 did that as well. And in Netflix the dialog appeared behind the active window so you couldn't see it or hit the button.
Critics of Android embraced a meme that Lollipop was Android's Vista, substantiated by users anecdotal claims about poor battery life from a given upgrade, or the changes to notification levels, etc. So you still see the echos of that. I've never seen someone go so over the top to claim that it justified vendor skins, though, so this is a new pinnacle.
Yeah, the ritual of rebooting the device every two days because of the memory leaks and camera crashes were quite an incremental update over stable Kitkat.
Even ignoring the placebo effect, and a contingent of people carrying forth a message between advocating the amazing world of task killers, what in the world would a skin have to do with that? TouchWiz and others are literally layered over stock Android, so if there was a fundamental issue it would have the same issue. The notion that the skins are somehow superior is nonsensical, despite the comical, ignorance-induced downvotes I've predictably received.
Lollipop's first release was a bit of a mess in terms of bugs (it has since gotten a lot better, at least on devices that have kept up with releases, like Nexus devices), but I'd still run a stock 5.0 release as a daily-use phone OS over any Touchwiz release ever.
I can't begin to describe how terrible I find the Touchwiz interface relative to stock.
Yeah, I imagine they figured that as long as they kept pushing out updated OS versions, essentially for free, the OEMs would have an easy way to keep offering updates without having to build any of the underlying "stuff" from scratch.
But I think it ends up more like enterprise IT where OS updates get put off and only done when absolutely necessary. To OEMs who only really care about selling hardware, it's just more testing, deployment, and support cost (not to mention porting their customizations).
I realize I'm not in the majority (outside of tech circles) but I really do like Android and the main criteria for choosing a device are specs, build quality, and likelihood of timely updates. My current phone is a Moto X and it's the first non-Nexus I've had in a while. And I only got that because I broke my Nexus 5 and we were still a way off from a refresh. The Moto seemed like a less extravagant (in terms of price and screen size) version of the Nexus 6. But if Lenovo undoes the good things Google did for Moto, I'll be back to the Nexus line regardless for my next phone. I got rid of the carrier as a middleman by avoiding carrier-branded and subsidized handsets but the OEM still plays a huge part as long as proprietary code is needed to port newer versions of the OS to a given device.
Those stats you're linking are extremely misleading and don't really reflect demographic of actual app users. Pretty much all our apps across the board have higher Lollipop and KitKat usage.
Which makes sense - what you linked is aggregate number of all users on the Play store across the world. Users that actually actively engage in their phones and western markets are noticably more up to date. Ignore newer API versions at your own peril.
I think it's more likely you're seeing a survivor bias. If your app runs well on Lollipop, it's very likely gigantic and slow as molasses on older phones due to the compatibility shim bloat.
> [..] demographic of actual app users [..] Users that actually actively engage in their phones and western markets are noticably more up to date.
Your post seem predicated on assumptions which aren't supported:
- That people with "better engagement" are more profitable to app developers (which might be the reverse of true if you aren't on a freemium modal).
- That non-Westerners don't buy apps at all or that we simply shouldn't care. .
No, no, I did not want to imply any of that. Just that:
- For pretty much any of our apps the actual breakdown of Android versions is nothing like what the Play store shows.
- The amount of new Androids is significantly higher (we actually have an app with 57% 5.x and 80% on 4.4 or newer - Samsung updates have been significant for it) and varies greatly
- The users with newer devices and newer Android versions are usually more engaged, use apps more and also advertise them more which makes for a good network effect.
- We have noticed a major shift to apps with Material design, arrogant Apple marketing aside, there's alot of users on Android that DO care about design, UX and those tend to have rather newish phones.
Depending on your app you should of course also care for people on worse phones. If you're providing a public service app (e.g. showing public transport schedules), you should probably target as low as 2.3 (even though, perhaps actually building 2 APKs for that usecase makes sense). If you're building a modern 3D game, you should probably target API 19+ since users with older devices probably won't be able to run it anyway. But in any case, DO YOUR RESEARCH, because the numbers vary greatly across demographics, app categories and regions.
1. Dashboard stats are global and in general show very different numbers when compared to the users of most modern applications, at least in the western world. It probably overrepresents cheap, old devices from China and India who, in general, don't install or buy as many apps.
2. As bad as Android adoption normally is, in general L adoption has been better or at least on par with that of previous versions. Check the last chart: http://www.bidouille.org/misc/androidcharts Lollipop release date is actually wrong there (makes the chart more optimistic), but by a month only.
I thought I was the jaded dev until I started reading these comments! There's a lot of stuff I hate about Android but, in my opinion, the tools, first and third party libraries, testing support, and design have made really great progress this year alone. Android Studio and the Gradle plugin are really, really coming along (and I'm on Linux!), the Support libraries are filling in a lot more holes than they ever did before (and I have to support Gingerbread!), Robolectric is at 3.0 RC3 and you can finally run it in Android Studio, and Material Design is getting more well defined and seeing more and more saturation into other tech (Polymer hit 1.0!).
> Android Studio and the Gradle plugin are really, really coming along
Too bad Gradle only allows us to use one language (i.e. Groovy) to configure the builds. Because Maven uses generic XML, any language can sit atop it. E.g. Polyglot Maven [1] not only allows us to use Groovy, but also Clojure, Scala, and Ruby to configure its builds.
Build systems have been particularly tumultuous for Android. It was unfun to build an app in Eclipse, then want CI and have to write a lot of boilerplate in Ant. The complete translation of all that Ant code and related CI materials to Gradle / Android Studio took weeks for my team on a large codebase. And, if you're a platform dev, you also have to support nonrecursive Make.
I'm not a big Groovy fan either but I am a big fan of picking something that works. The transition was painful but I'm glad the road ahead looks clear and focused.
If Gradle's configuration API was opened up so other languages besides Groovy were allowed, such as Clojure, Scala, JRuby, and even Jython, Gradle would attract a lot more developers who are put off by Groovy. Even Gradle's website and promotional materials avoids using the word "Groovy", instead saying "Gradle DSL", but that's not enough to win over hardcore Python or Ruby shops.
As for your case and many others already reluctantly using Groovy in Gradle, translating it all from Groovy-Gradle to, say, Ruby-Gradle wouldn't take weeks but hours because only the syntax would need to be translated almost one-to-one, leaving all the Gradle configuration names and sequences unchanged. In fact, because it could be done incrementally, only minutes spread out over several days.
Please Google, how about some real battery improvements this time? I was disappointed to hear that the new "doze" feature is only for completely stationary phones. So sitting in your pocket or the bottom of your purse won't set it off because there's too much motion. I imagine this will be nice for tablets that sit on the kitchen counter all day, but might not affect phone battery life at all.
Apparently, the battery gains from Volta in 5.0 didn't do much and from what I've read many of the popular apps never bothered supporting the new APIs for their own reasons.
On the plus side, hearing about monthly security updates tackles my biggest concern with the platform. The problem is only a handful of the biggest players have signed on for that, and even then these updates need carrier approval for some asinine reason. The smaller OEM's will probably never deliver these updates.
I'm pretty sure that Google cares a lot about battery life, but there's no magic way to save energy, so don't expect too much from optimizations. Apps, not the OS, use most of the energy for CPU, screen and radio time. The new features only limit the apps a bit by disabling or rescheduling background tasks.
Well, I don't think my demands are unrealistic. Compared to my iOS devices, Android does terribly, even with much higher capacity batteries. It would be great if google caught up.
Or OEMs could just put decent batteries in the phones? Huawei has the Mate 2 with a 4000mAh battery. I easily get over a full 24-hour day. I never worry about charging it.
Other OEMs could do this if they wanted. But they choose to slice another mm off thickness, and everyone's happy if they can get through 12 hours without charging.
If Apple has chose to ship a battery capable of lasting 24 hours, everyone would just take it for granted that this is obviously how devices should work.
The Mate 2 is a HUGE 6.1" phone and nearly twice the weight of an iphone. This is not a solution for most of the phone market. I own a N6 and I have huge hands and its a bit much for me. Its uncomfortably huge and heavy. I can't imagine most people being on board with a heavy and huge phone because google can't get its shit together on power savings.
Back when I was carrying my Nexus S around, I would have happily paid $50 more for a model designed to contain a double-sized battery. [0] My hands tell me that the battery is quite a bit less than 25% of the total weight of the device, so the weight cost would also be quite small; no more than ~1.5 additional ounces.
It's not a rule that one has to choose between a relatively small phone with shitty battery life and a phablet with somewhat less shitty battery life. One could have double or triple-sized batteries in the smaller phones!
[0] The problem with all of the aftermarket batteries that I saw was that they required a new back cover that contained no NFC antenna.
Blu makes a 5-something phone with a 5000mAh battery. It's sightly thicker than other phones, but gets several 24-hr days. There must be a compromise. It's not just Google. iPhones and Windows Phone devices also can't get through a day without charging because OEMs stick tiny batteries in, then shove power hungry components on top.
> The Android emulator system images and developer preview system images have been updated for supported Nexus devices (Nexus 5, Nexus 6, Nexus 9 & Nexus Player) to help with your testing.
The Nexus 7 is pointedly absent. Will they even get an OTA update for the final Android M release?
Really big fan of the simplified permissions feature. It's something I've always wanted that Android never had. In addition to the supposed battery usage improvements, I'm looking forward to the new streamlined Android Pay features.
Just learned about this and it seems really great! This is something I always wished for when I was developing for Android and actively using apps. When the most of the apps seemed to require me to give permission to access my personal information, I quit installing and using apps.
"The M Developer Preview introduces a new app permissions model which streamlines the process for users to install and upgrade apps. If an app running on the M Preview supports the new permissions model, the user does not have to grant any permissions when they install or upgrade the app. Instead, the app requests permissions as it needs them, and the system shows a dialog to the user asking for the permission.
If an app supports the new permissions model, it can still be installed and run on devices running older versions of Android, using the old permissions model on those devices."
Why does a stylus need bluetooth? I thought it interacted with the display much like a finger (just more precise). Unless they are using thermal touch sensors?
Android as a platform is toast. With the flagrant security issues, anyone who cares about security will buy an iPhone or BlackBerry. Add to that the blatant Oracle IP infringement and you've got a recipe for a platform with no future.
The smart mobile devs are noping the fuck out of the Android ecosystem.
You're correct... at ~78% of the mobile market share the platform is definitely on its last legs. Better to focus development on the remaining 22%, esp with that 30% Apple market overhead.... ???
Android definitely has hurdles to overcome but it's far from "toast". I really can't conceive where that view would come from?
That's the most misleading & pointless statistic I've ever come across and definitely the most dangerous one if you're a developer. Why? Well, VAST MAJORITY of that marketshare are phones that are so cheaply made that they cannot run even 4.4 let alone 5. Only a tiny portion of these phones are actually capable of running latest apps & games well. So all these people running non-Android (China for example doesn't really run certified Android but various forks of AOSP) are not really your customers.
And don't even get me started on user base... if you read Google Play reviews, you'll notice that people give you 1 star ratings if you decide to charge for an app or decide to have IAPs in your "free" app. So good luck making a living off Android apps. About the only way you can do it, and the most common way for Android devs to make money these days, is to exfiltrate as much personal data as possible and sell it to data brokers. That's why all these "free" apps require so many permissions.
Anyway, I've been an Android dev for 4+ years and recently moved into server-side development but I pity the guys who still try to make a living off Android.
This is entirely true, and it's omitting the worst aspects of the situation relating to revenue and platform momentum.
As someone that has overseen tens (possibly hundreds) of millions of installs driven off the Play Store in my time it pains me to admit that economically speaking Android does not make sense at all today. My impression is many of the HN crowd are in denial about this. Two or three years ago things did look very different.
Reflexively I often like to blame poor stewardship for the situation, but in more sober moments I've come to think that the way Android is distributed and the OHA operated is structurally unsound. The surprising aspect of it is just how successful Apple have been at cultivating an audience composed of the vast proportion of valuable customers, and had they not had such success then the open source Android may have worked out better.
This pisses me off massively because Android makes all sorts of more technically interesting end user apps possible, but with a business hat on if it can't also be made to work on iOS it's not worth doing.
> As someone that has overseen tens (possibly hundreds) of millions of installs driven off the Play Store in my time it pains me to admit that economically speaking Android does not make sense at all today.
> My impression is many of the HN crowd are in denial about this
I'm okay with apps becoming non-profitable commodities, at least for the general user. We have enough fremium games and other junk as-is. Apps should be added-value for another product (control my theromstat, get richer content from a website, etc). The vision of mobile as eating the world never made sense. It has its place and unsurprisingly, the gold rush is ending. You can only make so many Angry Bird clones and flashlight apps.
Apps will eventually be like the web. They won't be profit makers on their own. Its also good to see a lot of the goldrush crowd go away. The app store is just too gamified to the point that finding good stuff in near impossible unless you know the exact name of the app you want.
>I'm okay with apps becoming non-profitable commodities,
You're delusional if you think you will have free AND excellent apps at the same time. It's usually "pick one" situation.
To have great apps you need incentive for developers to make them (which is 99% of the time MONEY). Take the money out of the equation and you have mostly junk.
Yeah. A better objection for 51Cards to have made would have been something along the lines of "Especially with that infinitely recurring $100/year Apple Market membership fee." [0]. :)
[0] Note: I have not checked the price of Apple Market membership fee in quite a while. It might no longer be $100. I am fairly sure that the policy of deactivating your apps in the App Store[1] when you stop paying the fee remains.
[1] This is different from removing software from phones, mind.
I like the fact that it's open source, mostly excluding some third-party binary blobs, but on most phones I can install custom ROMs and kernels, and even fiddle with these binary blobs.
People who bought into Apple's closed garden (with a capitol c) need to rationalise their investment.
Part of that rationalisation is at will dismissing the value of open technology, despite 99% of the internet and 90% of the Apple ecosystem lives atop of it.
Considering how lots of full on FOSS Linux users were lured to the Apple platform for its (at the time) impressive desktop, this has probably caused one of the biggest damages to open source software we have seen in recent time.
Looks like the Windows troll decided to show up. I'd be more worried about the sad state of Windows, its flagrant security issues and it's invasive privacy "features". No wonder the PC market is declining.
Which means that what I learned at I/O 2013 can finally be put to good use!
The sad part is that I decided to skip looking enthusiastically under the hood of M, because I won't be able to use it anyway for quite some time.