Official Android 6.0 SDK and Final M Preview
android-developers.blogspot.com
android-developers.blogspot.com
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.
Perhaps updating your app to the 5.x standard will actually make those users use it instead of running away to other Material apps ;)
Luckily, Android has a great compatibility library so you can still use many of the new features.
This allows you to use the newer features, but also include fallback layouts for lower SDK versions.
EDIT: Yeah, looks like I was mostly right: minSdkVersion and targetSdVersion. https://developer.android.com/guide/topics/manifest/uses-sdk...
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.
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%.
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.
[1] https://developers.google.com/android/guides/setup#split
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.
Cough, Touchwiz.
On my Note device, I've done everything I can to hide Touchwiz and go back to stock Lollipop because of how much better it is.
To everyone else it was an incremental update.
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.
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.
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 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.
Based on https://developer.android.com/about/dashboards/index.html though, L is behind the pace :(
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.
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. .
- 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.
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.
[edit]
According to Sprint's website[1] 4.4.4 is the latest version.
1: http://support.sprint.com/support/article/Find-and-update-th...
Also, this lag is the reason they won't get rid of the Nexus program. Without it, they would not have a test bed for Android.
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.
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.
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.
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.
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.
https://developer.android.com/preview/behavior-changes.html#...
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.
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.
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.
The Nexus 7 is pointedly absent. Will they even get an OTA update for the final Android M release?
"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."
https://developer.android.com/preview/features/runtime-permi...
Styluses often have interaction mechanisms other than the pointer (e.g., the button on Samsung's "S-Pen".)
But OEMs will wait for 6.1 to let the bugs settle out. After 5.0 and its memory leak bugs etc, i'm wary.
I'd say
ICS → Jellybean = Lollipop → Marshmallow
Refinements, tweaks, and moderate improvements, as opposed to a whole rethinking of design.
Just putting it out there, so when I am right in a year or so time we can refer back to this comment ;-)
I'll write up a separate post later as to why I think it'll be called that.
The smart mobile devs are noping the fuck out of the Android ecosystem.
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.
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.
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.
As a developer, I'm not.
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.
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.
> My impression is many of the HN crowd are in denial about this
Oh, the irony here is great
You realize that Google has the exact same 30% overhead, right?
[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.