Official Android 6.0 SDK and Final M Preview(android-developers.blogspot.com)
android-developers.blogspot.com
Official Android 6.0 SDK and Final M Preview
http://android-developers.blogspot.com/2015/08/m-developer-preview-3-final-sdk.html
12 コメント
And 57% of our demographics are on 5.0 or newer, with 19+ covering over 80% of users actually using the app.
Perhaps updating your app to the 5.x standard will actually make those users use it instead of running away to other Material apps ;)
Perhaps updating your app to the 5.x standard will actually make those users use it instead of running away to other Material apps ;)
>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%.
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%.
Not quite catching your point - if you set your min sdk to android 5.0, you will remove 43% of your users. That's kind of the problem.
Luckily, Android has a great compatibility library so you can still use many of the new features.
Luckily, Android has a great compatibility library so you can still use many of the new features.
Correct me if I'm wrong, but I thought you can have a minsdk version and a recommendedsdk version.
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...
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...
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.
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.
For me its less than 7%. Here are my numbers for last month excluding china: https://www.dropbox.com/s/q9yj8k4cac8xaqb/Screenshot%202015-...
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!"
Why aren't you using the compatibility libraries?
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.
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.
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.
[1] https://developers.google.com/android/guides/setup#split
[1] https://developers.google.com/android/guides/setup#split
The Support Library is very UI-focused. There's a lot of stuff added to the Android API that never gets backported.
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.
Or they could, you know, just ship stock Android and make everyone happier by not shoving awful carrier skins down everyones throat nobody even likes.
Cough, Touchwiz.
Cough, Touchwiz.
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.
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 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.
If people didn't mind Touchwiz, Samsung wouldn't sell nearly as many phones as they do. Not that they like it, but they clearly don't mind it.
Lollipop is bad enough that Touchwiz, on devices like the Note 4, is a massive improvement over stock Android.
That's the first time I've ever seen that claimed. In what way does Touchwiz improve on Lollipop?
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.
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.
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.
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.
To everyone else it was an incremental update.
To everyone else it was an incremental update.
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.
This is more of a comparison of Lollipop vs. Lollipop + TouchWiz rather than Lollipop vs. 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.
Speaking as an Android user/developer:
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.
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.
A good rule of thumb is that 25% of Android devices will have the OS within 1 year of release and 50% within 2 years of release.
Based on https://developer.android.com/about/dashboards/index.html though, L is behind the pace :(
Based on https://developer.android.com/about/dashboards/index.html though, L is behind the pace :(
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.
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. .
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.
- 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.
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.
Android L was released on October 15th so it could still make it to 25%. Also note that 5.0 was pretty buggy so that didn't help...
I have a less than 2 year old flagship phone (Moto X) with no L release yet, so this doesn't surprise me.
Both the 1st and 2nd gen MotoX are on 5.1.
And how do I update? I went to System Update and it says "Your device's software is up to date."
[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...
[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...
I think the release lag for OEMs is far longer than Google thought it would be.
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.
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.
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.
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.
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.
[1] https://github.com/takari/polyglot-maven
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.
[1] https://github.com/takari/polyglot-maven
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.
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.
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.
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.
"App standby" in Android M also works for non-stationary phones. It disables services and background data for apps that you don't use for some time.
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.
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.
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.
Google did. It's called Doze.
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.
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.
That's a brute force way of trying to solve the issue and one I am not big on.
Sure, but A: it works, today, B: it works well, with no compat issues.
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.
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?
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."
https://developer.android.com/preview/features/runtime-permi...
"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...
Really hoping 6.0 and the new Nexus phones have pen support so I can get over my disappointment that the Galaxy Note 5 won't be released in Europe.
Android M gets native Bluetooth stylus support so it should be supported.
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?
> Why does a stylus need bluetooth? I thought it interacted with the display much like a finger (just more precise).
Styluses often have interaction mechanisms other than the pointer (e.g., the button on Samsung's "S-Pen".)
Styluses often have interaction mechanisms other than the pointer (e.g., the button on Samsung's "S-Pen".)
Most stylus' have at least one additional button (on a Surface Pro, there's 3).
I predict that only Nexus devices will get 6.0 initially, just like 4.0 and (to a lesser degree 5.0) before that.
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.
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 don't know. Marshmallow feels a lot more iterative than KitKat → Lollipop did.
I'd say
ICS → Jellybean = Lollipop → Marshmallow
Refinements, tweaks, and moderate improvements, as opposed to a whole rethinking of design.
I'd say
ICS → Jellybean = Lollipop → Marshmallow
Refinements, tweaks, and moderate improvements, as opposed to a whole rethinking of design.
Oh please. Android 5.0 introduced a new runtime that was the cause of a lot of the issues. These have been ironed out in 5.1.
Pretty sure that was exactly his point; major issues until the point one release so why wouldn't they wait?
I think that next version of Android will be called Oreo.
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.
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.
Slightly OT: Does anybody have an ETA of Java 8 in Android?
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.
The smart mobile devs are noping the fuck out of the Android ecosystem.
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.
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.
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?
Android definitely has hurdles to overcome but it's far from "toast". I really can't conceive where that view would come from?
>at ~78% of the mobile market share
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.
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. 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
Oh, the irony here is great
> My impression is many of the HN crowd are in denial about this
Oh, the irony here is great
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.
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.
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.
"I'm okay with apps becoming non-profitable commodities"
As a developer, I'm not.
As a developer, I'm not.
"Better to focus development on the remaining 22%, esp with that 30% Apple market overhead.... ???"
You realize that Google has the exact same 30% overhead, right?
You realize that Google has the exact same 30% overhead, right?
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.
[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.
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.