"We are giving users control of app permissions in the M release. Apps can trigger requests for permissions at runtime, in the right context, and users can choose whether to grant the permission. Making permission requests right when they’re needed means users can get up and running in your app faster. Also, users have easy access to manage all their app permissions in settings."
Great, finally Google got it. Hopefully with the old Android 2.3 style fine granular permissions and not the few permission groups of Android 4/5.
EDIT: The permission groups are
Location
Camera
Microphone
Contacts
Phone
SMS
Calendar
Sensor
Currently you can change app permissions once an app is installed, but they gain all the permissions they ask for when installed.
If each app has to be updated by the developer for the changes to take place, it might take a while for this to have any large effect on the ecosystem.
Google isn't releasing more details on it, but with it, Google would be able to understand what you do, when you do it, who your pals are, who you go out to movies with, who you chat with the most, are you looking to quit your job, are you about to break up, are you going through a depression and so on...
They haven't revealed anything about how exactly 'Now on tap' works...but the potential for data collection is enormous. With 'Now on tap' they promise to do 'searches' based on the context (which is derived from the contents in the app that's showing on-screen). So no matter what app you're using, Google will get its hand on the data. It sounds nightmarish and exciting at the same time.
Without any further clarification i have to expect Google now to send the displayed data of my mobile banking app to its servers everytime i hit that "Now on Tap" button, accidentally or not, while its open. I don't like that.
Sounds a lot like the NSA.
In other words, that's cool about Android M, but most people aren't even using L. (40% on K, 9% on L whose preview was the 2014 IO)
Can Google not poach one or two of Apple's negotiators to go to the right meetings at Motorola, Verizon, etc to talk about updates?
I am the lead for an app with >250,000 installs. Over 45% of our usage is coming from Lollipop. The rest is JB & KK. We see <6% ICS for the last 30 days.
I know other major apps that have even better numbers.
Looking at my data, L usage was basically nil in January 2015. There was slow growth from there until April, when we saw an inflection point in the number of Lollipop users. This aligned with the release of several Samsung updates that pushed Lollipop to some of the most popular devices out there.
If you want publicly available numbers, I would rely on Mixpanel[1] not the Android dashboard. And even this understates it, as of writing this comment Mixpanel is not including 5.1 in the Lollipop numbers which is cutting 2-3% off that. [2]
[1] https://mixpanel.com/trends/#report/android_os_adoption [2] https://twitter.com/mixpanel/status/604025242529308672
The narrative about Android fragmentation is really out of touch with what I experience on a daily basis.
About 25% of our users are below ICS even. Yes, one quarter of our users are on Gingerbread.
And then the rest is shared equally between JB, KK and L.
https://developer.android.com/about/dashboards/index.html?ut...
I'm learning Android development by building a basic app that I've always wanted but couldn't find in the play store. I'm targeting SDK 21 and minSDK 19 and was afraid of having a small userbase (based on the dashboard numbers). That means that I can continue to focus on the latest SDK and leverage all the good SDK 21 features :)
So yes you'll have to wait ~2 years for the majority to be on M or higher. Oh well. Does that suck? Yeah. Is it a major, show stopping, "omg google why haven't you devoted 100% resources to fixing this?" issue? No, that's absurd.
And why do you think Apple has negotiators for this? Apple doesn't license iOS to anyone. They've never attempted to solve this problem. Ever. For anything.
Why shouldn't Google be devoting resources to solving this issue ? Being unable to upgrade is a massive security risk and prevents developers from rolling out new and interesting features in their apps.
It is largely a solved problem. You have a core OS/SDK which is upgradeable and some sort of plugin style architecture around it for themes/new features. Sure some OEMs may ignore it and fork the OS but then Google has the leverage of Play Services / Android brand they can use as a stick.
And whether iOS is licensable or not is irrelevant. For their particular phone it is upgradeable without carrier intervention. Why is every Android phone different ?
I don't understand why things like these are necessary in the USA. Why should network operator have control to which version you're running? Most other places you can just get new firmware directly from manufacturer.
Even if it weren't a contractual obligation, I can't imagine, say, the AT&T store loading a phone right now with iOS 7
Depending on how you define "version", 2 versions back is Jelly Bean. 90% of our users are on Jelly Bean or newer.
3 versions back is Ice Cream Sandwich, which in my case includes 99% of our users, and we only dropped Gingerbread support Christmas of 2014.
Will this improve wakelock performance that has been plaguing Android for years?
No, this won't magically fix bugs in apps that lead to poor battery life. If an app opens the camera and forgets to close it, yeah that's gonna murder your battery.
Whenever i have something odd going on with the battery life, some app is sitting right up there with Android system for CPU time (sometimes even above). And you don't hit those kinds of numbers even with heavily used apps like web browsers (and yes, the most frequent offenders are the Facebook slop that i only have because family).
"Unsurprisingly, there are three apps set to ignore battery optimization by default—Google Play Services, the Play Store, and Download Manager."[1]
So, nope. GPS will continue to do whatever they want and poll location every 60s.
[1] http://www.androidpolice.com/2015/05/28/android-m-feature-sp...
(I'm unemployed and don't really want to pay for a 64-bit system. Anybody want to hire me so I can afford a new computer?)
So at least we can make use of some C++ love, even if the frameworks access is limited.
Retrolambda is rather useful to get a subset of J8 features.
"The M Developer Preview includes an updated SDK with tools, system images for testing on the official Android emulator, and system images for testing on Nexus 5, Nexus 6, Nexus 9, and Nexus Player devices."
So, no.
Finally! I had to start developing for Android not too long ago, and I couldn't stand seeing "mandatory" material components for certain usages that weren't supported in the official SDK.
In general the UI components are moving out of the SDK into the support libs or the community at large. RecyclerView & Toolbar are examples of Google untangling the foundation from the look & feel, and letting the community come up with the final implementation of things.
And downloads page: https://developer.android.com/preview/download.html
Does this mean gdb integration with android studio? That would be fantastic! Working with the NDK has been a pretty painful at times, and this change will make a lot of people very happy.
That image... Seriously, when will Google stop doing things like these? Will they ever learn to be attentive?
