"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.
"When the user installs or updates the app, the system grants the app all permissions that the app requests that fall under PROTECTION_NORMAL. For example, alarm clock and internet permissions fall under PROTECTION_NORMAL, so they are automatically granted at install time."
Based on the Android 5.1 source, there are a lot of permissions in the "normal" group, which will apparently now be accepted automatically at install time:
Application YourTypicalMobileApplication is asking for access to the Internet
to display advertisements powered by Google AdMob.
[ D̶E̶N̶Y̶ ] [ ALLOW ]
(Do you think we would give you the option to easily cut our income?)
That's what I meant. It covers a good ~95% of all ads. Have any extras register for security exemption. Makes sense to me - in the context of not screwing the user over constantly.
Can't agree more. It always bothers me all apps can access my external storage by default.
But I have to use Android, because it's the most open established mobile ecosystem. Only system that supports the mobile web browser I find tolerable to use for instance (hint - it's not the default browser or Chrome). Only system that allows developers to map executable pages. Only system that allows me to customize user experience as I see fit, and not offer one size fits all. And so on.
>As for Internet, they leave that out of their "improved" Play store permissions as well (and the M groupings seems like a carbon copy).
Why would they do that? On it's own "Internet" may not seem to be an important category, but I am willing to give apps many more permissions if I know that they can't phone home. For tools, the Internet permission is often the deciding factor for me.
A few years ago mobile virtualization was hyped a lot. What came of it? I'd love to be able to run multiple OS instances on same phone. Use one for private communication and others for fun and games (not that I play games, but the point).
Nowhere near the same but android does support multiple accounts - might be worth looking into whether they're sandboxed enough to stop apps looking beyond the account they're installed on.
I'd like to see a modified internet permission that permitted access to only a specific domain. Maybe along with a policy prohibiting or discouraging using the all-internet permission for anything that didn't clearly need it, like say a web browser. Say the Twitter app only has permission to access URLs under twitter.com, and accessing any other URL domain is a separate permission.
I'm not sure if Google would go for it, but I suppose it would encourage devs to use Play services for ads and analytics, since it wouldn't need any extra internet permissions, while using an external service for either would.
Google should silo those into separate categories to generic "internet access". Same with ad access. Sending data to pre-whitelisted, registered and trusted sites that register with Google in advance should be in a different category to "upload to random server in china".
>Isn't there an entry point on the OS/Google Play side that allows the dev to get crash reports?
There is, but there are multiple crash reporting services that provide more features than Google (and just having some competition in that area is pretty great).
In my company, we use Crashlytics on Android & iOS and Bugsense on wp.
Everyone with a pulse has asked themselves that already, and come up blank. All we have are potential conspiracy theories revolving around ad revenue for both Google and app devs.
What I see missing, that Xposed + App Ops gives me is the "Keep Awake"... having revoked this permission from almost all non-Google apps, my battery life is a full 50% longer than other people with my phone report.
Best i can tell, Doze is supposed to cover that automatically. But then Doze will wake the device up if a GCM priority notification comes down the wire. And i expect Facebook and the rest to start spamming those to make sure they get every nanosecond of your life to their servers.
Using the developer preview now there is no difference when installing new apps, so do developers all have to make manual changes in their apps for it to work, or will Google flip a switch at some point?
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.
The app needs to target M in order to access to these granular permission.
An app targeting a lower API level will work in legacy mode where it gets its permissions at install time, like before.
I guess it makes sense in order to give enough time to the devs to update their apps to this new system.
As long as the checking/warning becomes more aggressive in N, I am fine with that choice.
According to the session after the keynote, you'll still be able to at least go back and revoke permissions individually for apps targeting older API levels.
And they will most likely crash if you do, because they are not expecting a SecurityException. I prefer the CyanogenMod way to just give out empty data, if a permission is not given by the user.
What you're calling the "CyanogenMod" way is actually what Google built, it's called AppOps. All CM did was expose it. The actual capability of permission revoking and handing out dummy data instead was all done by Google as part of AppOps and I assume that M is using that same system because it'd be silly not to.
yeah, but that way you can only remove the permission after the installation.
Facebook for example is known to siphon your contact list as soon as the app is installed, so even if you remove the permissions from the fb app, it is already too late.
IMO, the most game changing feature announced today is 'Now on tap'
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.
What scared me about that announcement was that "no changes in the app are necessary" which basically means that google from now on will parse the text that is displayed, regardless of the type of app that is open.
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.
This only works if the developer uses app indexing where Google can search through the content and make it searchable to end users and other endpoints. It doesn't come for free so Google has no access to things like your bank app's screen.
The presenter actually mentioned app indexing on stage at some point so I think it does rely on the developer opting into indexing.
On the other hand, it's not clear to me that the user opts into the indexing, so Google might suddenly silently be getting access to a huge number of user's deep within-app data without them realising it. But that is old news, app indexing has been around for a while.
I think the way to think about it is Google is doing what it does best: search. They use whatever content they can scrape from the screen using the view hierarchy once the user signals intent that they want to search. It's a faster way to do search using context (in this case the screen) to provide the "keywords". The app indexing part is how they are able to show related apps with deep links. They use app indexing of other apps to find relevant results for the query.
App indexing makes sense when you have more stable content inside of an app like a traditional public website. Think Yelp and their 'screen' per place inside of the app. It doesn't make sense to publish the contents of a chat conversation to Google's app index -- that would be a huge privacy leak! It would be the equivalent of GoogleBot indexing my Gmail inbox.
I am curious if this will be a source of friction with app developers. If Google is scraping app data usage for both content and context ostensibly to extend the benefit of that app's data and utility, wouldn't that make it considerably easier for them to clone the app and improve upon it?
I don't think the same engineers that work on products like some new app even have access to the kind of data that would come from that feature, nor does that sort of snooping even occur at google. It's not the NSA
That attitude seems naive. Google took a stab at replacing Wikipedia with Google Knol, Yelp (or was it Foursquare) with Google Places, and that's just two examples that spring to mind. It seems expected that Google would mine its own data for trends and look at how they could use that data to drive new app development or make existing third party apps irrelevant by rolling new features into Google Now, even if that data is mined only "in aggregate".
I would hope this to be correct, but I didn't see Google address it at all. A lack of transparency is a great way to foster FUD and a bad perception of what could be a great piece of tech. I get that they're building the marketing hype first, so hopefully it will be forthcoming.
> 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...
Google is showing off Android M dev previews while devices sold new last fall in major US retailers are still running KitKat with no updates from Google or their providers. They continue to actively create the "fractured" world of Android.
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?
Damn lies and statistics. The Android dashboard numbers are always super pessimistic on upgrade rate.
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]
That's some awesome data, thanks for sharing! I have to imagine geo matters here too. China, Latin America, and Africa have huge Android growth (though even then a huge chunk must be AOSP) but I would guess it's mostly older OS versions coming from the smaller OEMs that are spawning so much of the growth. Who knows if those would ever be updated, but it's less relevant unless you're a pervasive, global app (like FB or Gmail).
The Android Market lets you depreciate old versions of Android now for your apps by leaving up the last compatible apk for them while newer devices get the latest version of your app.
With that, you can either let the old version die slowly as users upgrade devices. I haven't attempted it, but I assume you can still somehow push bugfixes for the older version without newer devices also getting it.
Backporting bug fixes or new features? I wouldn't be going out of my way to try adding new features to 5 year old versions of Android. If a user reports a crash for 2.3, sure, I will fix it. I know I have a fair amount of devices showing as Android 2.3 for one of my apps, but I've noticed most of them seem to be inactive. The app in question is a tool for testers and power users, so I would expect many of them to keep old devices around for fun/hobby, but not really using them actively.
Just something you might want to investigate. You may not have as many actively using 2.3 as you might think. Creating a new branch for active build really isn't that much complexity and then a branch for legacy when the legacy is just maintenance mode only.
We are talking only about people who installed the latest version of the app – so they had to be online, and had updates activated, within of the past few weeks.
I would imagine much more people have the Play Store installed than the 250,000 installs of your application. It seems reasonable then to point to Google's own page for the better count.
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 :)
If you are working on a side project type app my best advice would be min SDK 19 or even 21. The total # of Android users in the world makes even the minority that are on L a large userbase. You will get much further faster not having to deal with backwards compatibility. If your app is aimed at making money, the people with money are generally on the newer versions. Not everyone can get away with it (Facebook will be supporting Gingerbread forever), but don't waste your time on the old versions if you can avoid it.
And by disk space I mean after the user has installed the typical number of apps, photos, music etc. My partner is an example of this. She has to choose between deleting apps and doing OS updates.
Your post was word for word identical to posts made 2 years about KitKat when it was released. Only instead being compared against Gingerbread. And several years before THAT when Gingerbread was released people were saying it about Donut & Eclair.
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 ?
Upgrading the core OS is hard mostly because new android versions rely on certain new kernel features; and the new kernels break backward compatibility with proprietary drivers.
There was a story posted a few weeks back about how a certain (Samsung or LG?) phone had added new members to the middle of a kernel struct, for the benefit of their camera driver. It hamstrung a lot of the community reverse engineering work to port a new kernel to the device.
> 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 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.
So, you'd be fine with your ISP being the gatekeeper for which operating system(s) and version(s) you can run on your computer?
The U.S. system where operators are such gatekeepers for mobile devices is an anomaly. It doesn't need to be so, and it is not so elsewhere.
I don't understand the overall picture of the U.S. telecom industry in the first place. Slow speeds, data caps, bad coverage, high prices and control freak carriers.
Kinda. My Xperia Z didn't update to Kitkat when it was available. I bought it at JB-HIFI and therefore it came with Telstra junk on it. In /system/build.prop there's a setting called Customisation Number. So I used towel root and changed it to a stock number and the system updated to Kitkat and removed the non-uninstallable Telstra junk.
Telstra didn't update because of a battery issue. Which was true... the battery died quickly if you left the GPS on. I didn't use the GPS much so I left it off. (This issue has since been resolved, then telstra enabled the update)
Considering I didn't even have Telstra as a carrier. it was because JB-HIFI is a Telstra reseller that this happened.
It's because the Manufacturer agreed to only update when Telstra updated. It's all through the Sony update software.
a big reason is that you actually need to test whether the newest version works well. Even the jump from 4.4 to 5 has some performance hits. Not to mention when we get beyond vanilla android, custom home screens and stuff are extremely sensitive to base OS changes.
Also, the phone companies themselves need to put out the updates, which isn't happening a lot of the time (or with 6 month+ delays).
Or google could just stop playing nice, they practically own the platform after all. If they would say "either you supply updates for two years or you are not allowed to preinstall google apps on new devices" the issue would be over.
And watch Samsung go Tizen over night, HTC partner up with Microsoft, etc etc etc.
Damn it, Android without Google is already big in China. And lets not forget that Amazon is maintaining what amounts to a fork for their device range.
Google can't really play hardball unless they want to go full Apple.
In essence Android has gotten where it is by being more accommodating to OEMs etc than the competition. Something akin to what MS was doing until they went retard with Windows Mobile 7.
Most new Samsung devices (including all SmartTV and SmartWatch) already use Tizen (based on an evolution of Samsung's Bada). Samsung could switch to Tizen anytime given it features a compatibility layer. People don't buy "Android" devices, they buy by the brand name of the manufacturer e.g. "Samsung".
The situation is so bad that they announce all this new stuff, and I think, that's great and all but who cares. A few thousand people will use this stuff and everyone else is 2-3 versions back. And they don't care, either.
> Battery - We’re making Android devices smarter about managing power through a new feature called Doze. With M, Android uses significant motion detection to learn if a device has been left unattended for a while. In this state, Android will exponentially back off background activity, trading off a little bit of app freshness for longer battery life.
Will this improve wakelock performance that has been plaguing Android for years?
Wakelocks have just been a scapegoat for people to pretend to sound smart when just saying that they want better battery life. They haven't actually been an issue 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.
Yep, you can as easily find battery guzzling apps by looking at CPU time.
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).
I, too, would love to live in a world where it's impossible to write bugs. Things would be so much nicer if Google could just solve the halting problem already.
Sadly it's more likely I'll just get some stupid pony instead.
The OS manages resources. It can temporarily grant (exclusive) control of a resource to an application. It can measure your other resource activity (touchscreen). If not touch screen activity for a long time, or when simply the screen is locked, then why is the camera on?
Sure, it can be a spy app, designed to listen and record! But then the OS can expose a per-app maximum wake setting. Yes, it'd look like a spreadsheet instead of a happy user UI, but that'd be a solution, instead of this "oh we can't do anything" excuse.
> If not touch screen activity for a long time, or when simply the screen is locked, then why is the camera on?
Because the OS shouldn't be making assumptions about applications' interaction models. People tend to write apps that OS creators never dreamed about. There are legitimate reasons for resource usage (camera) to continue without user interaction.From the top of my head, I can imagine writing a baby-monitor app that uses camera to stream video to my phone in the other room using wifi.
The resource-limiting heuristics have to be impossibly good, otherwise it gets in the way of useful apps.
One way of handling this is to have a separate permission - Use camera, which allows an app to use it for a limited time with the user interacting and while in foreground, and a 'Background Camera' permission which your baby-monitor app would request. Perhaps make the permissions dialog for the background permission scarier so developers have an incentive to use the less privileged permission.
This would work nicely for GPS etc - sure, I want to be able to have My Tracks keep GPS on for 3 hours, but I don't need Uber to be able to do that - and their app has a nasty habit of forgetting to turn the GPS off if you leave it at the wrong time.
> If not touch screen activity for a long time, or when simply the screen is locked, then why is the camera on?
Face unlock, dash cams, baby monitors, live-wallpapers-that-make-your-phone-look-transparent, security apps that snap a picture when someone fails to enter the correct unlock code and emails it to you, etc...
But replace camera with GPS and it's the same thing. Or audio. Or motion detectors. Or just really frequent alarms to poll a server (see IRC apps for an example)
The keynote claimed they took two identical Nexuses side by side with Lollipop and M loaded it up with a bunch of common apps. The standby battery time with M was around double.
The update to provide run-time permission prompts pleases me as a user; as a developer, I'm not as excited about it, especially if it doesn't come with narrower categories of permission. I could see it prompting the user to provide permission to do much more than is being done, and without the ability to provide reasoning and context in the dialog.
I assume that the upfront permissions prompted before an install will be simpler and fewer, and the more granular permissions (like microphone or camera access) will be prompted when they are actually requested by the app. Just like iOS.
Don't think so, as their post install UI slide showed pr category switches with categories very similar to those already seen in the "improved" Play app.
I disagree. I don't know that they've got the right balance until I try it, but anything is better than eg Facebook having permission to just about everything and presumably using it whenever some algorithm tells them there might be useful data to grab.
Forcing them to ask every time will either show my concern is wrong (a good thing) or stop them doing it (even better).
Well that goes without saying. I'm just trying to say that applications running on M and later that still target an older SDK will not use the new system.
According to the android session this morning even apps compiled against older SDKs will still have permissions that can be disabled when run in M, so they were encouraging everyone to test apps on M even if they weren't going to release their app built against the M SDK anytime soon.
As best i could tell, on a device running M it would be like this:
M ready app, you get no permissions display up front but asked to approve on API use.
Older app, you get a permissions display up front and can disable API access in Android settings.
On older devices both M ready apps and older apps would behave like today, giving you a list of permissions up front and no way to control them (unless you are running a custom Android or the OEM added the possibility).
The thought of writing Java without IntelliJ makes me want to quick programming. Ironically, Kotlin might be great in a text editor despite being made by Jetbrains.
Do you use Kotlin with Gradle? I like Kotlin a lot, but it feels very slow on my laptop, do you know if there any special optimizations to make it faster?
I haven't shipped anything to production yet but I haven't noticed any build slow downs. I have only really worked through Koans repo to try and learn the paradigms. It can pretty much do anything Ruby, Python, JS, etc can do and it only costs you a 200KB runtime.
You might want to make you have parallel builds and the gradle daemon on for the gradle CLI. Android Studio seems to turn these on for you but if you build from the terminal I think they need to be specified in a gradle.properties file in the project root. You can also increase the amount of memory gradle is allowed to use.
As far as I know Kotlin does almost all of its magic at compile time so I am sure it will slow down builds slightly versus plain Java. From what I have seen so far I am more than willing to pay this price.
Here is a good overview with benchmarks from Square
Right, the runtime speed of Kotlin is very good. But the build times got much slower. An average java build with Gradle takes ~30 seconds on my pretty old laptop, but with Kotlin it is about 1 minute. Daemon and parallel are enabled in global gradle properties. I think running Kotlin compiler as a daemon would help, but I don't see an easy way to do that with Gradle.
I feel like I would take more than 8 extra seconds just writing out and correcting the package names in imports than I would gain by trying to write Java in vim, and I'm saying that as someone who otherwise uses vim/tmux for everything.
I'm liking vim/tmux for Ruby, but for Android Java, so far, the AS plus IdeaVim combo seems nicer than anything I've put together with vim and tmux. Project-wide autocomplete and auto-adding imports plus the debug support is such a time-saver.
I often program Android in Emacs as well. I use the Java Development Environment for Emacs and have been happy with it.
If you add an Android-specific class like TextView in your code, you can easily have Android Studio add the needed import command for it.
With Emacs/JDE, I point my jde-global-classpath to the Android jar, then when I need to add an import line I highlight the class and do a Control-C, Control-V, Control-Z. It is slightly more convoluted than Studio but works well enough, I could probably automate and simplify it more if I needed to. This was the main shortcut I missed when moving from Eclipse/ADT to Android, but doing this got it back for me.
I'm actually considering going back to Eclipse (or dumping IDEs altogether) because my computer is struggling under Android Studio's memory requirements.
(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?)
"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."
> Android Design Support Library - Making Material design apps gets even easier with the new Android Design support library. We have packaged a set a key design components (e.g floating action button, snackbar, navigation view, motion enabled Toolbars) [...]
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.
Nothing is mandatory. Material guidelines are a suggestion and a set of tools to make the baseline app better by default.
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.
Is that a deliberate strategy or a lack of communication between teams at Google to create the SDK level support for components their design team designs?
I don't understand this sentiment, why do you need those components? There's bunch of 3rd party libraries to implement the UI patterns. Do you go annoy Safari/Chrome/Firefox developers that they don't provide you with components for carousels in browsers as well?
I think the comparison between operating systems and browsers is apples (no pun) and oranges. Browsers generally don't implement any specific UI design language, whereas operating systems do.
Android is a system where Google controls most of the baseline UI and does implement much of the Material design language in the SDK- but at least on the launch of 5.0 several components were missing. As you rightly say the community came to the rescue and there are several versions of each component now on github.
Was just wondering if that was on purpose, and the strategy is only to provide base components in the SDK, and only visual designs of a more comprehensive set of UI components - and then let the community implement the missing components outlined in the design guidelines? Not saying that's a bad thing, just curious if it's done on purpose.
> Most notable is a much requested feature from our Android NDK & game developers: code editing and debugging for C/C++ code
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 was probably just a poor attempt by whoever edited the screenshot to de-emphasize the app in the background and highlight the actual permission dialog.
"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.