Google I/O is here, and the company’s big keynote is still underway. The biggest announcement so far is – as expected – Android M, the next major Android release scheduled for Q3 of this year. Much like how the last few iOS releases played catch-up to major Android features, Android M is really catching up to a number of major, stand-out iOS features – and all of them are very welcome.
The biggest new feature coming to Android M is App Permissions – and it’s exactly what you’re thinking. Instead of applications asking for all possible permissions during installation time, they will now only ask for a permission the first time you use the specific feature of the application that requires it. If you’ve ever used iOS – well, it’s that, essentially. In addition, you can go into the Settings application and revoke an application’s individual permissions, or the other way around – look at which applications have a specific permission.
If you’re familiar with Android, you’ll be aware of the incredibly long and confusing list of possible permissions. Alongside implementing an iOS-like permission system, Android M will also pare down the number of permissions to a much smaller number (I think I saw 8 or 10?), making them clearer and more straightforward. All good so far, and yet another example of how competition between the major platforms makes both of them better – consumers, win.
There’s bad news, though, and it’s this: the new permission system will only work with applications built with the Android M SDK. “Legacy” applications will, sadly, default to the existing permission system. While that in and of itself is disappointing enough, it also means we’ll be using two different permission systems at the same time for at least several months, and possibly years.
Another major new feature in M is a new power state, called Doze, which is basically a deeper form of sleep. Your device will learn your usage patterns, and move to this deep sleep state when it’s not being used. According to Google, tablets will benefit the most from this, doubling their standby time. For phones, which get used more often, this will deliver less benefit.
Android’s intents system is also getting an upgrade, allowing applications to directly link to each other, without throwing up that “open with” dialog. Google Wallet is getting an upgrade and a name change – Android Pay – and now works pretty much exactly like Apple Pay, and it will be available on all Android phones with NFC. In addition, it supports fingerprint readers. Support for these readers will be further integrated and standardised in M.
There’s a lot more in Android M, but these are the biggest features. Google is releasing a developer preview for select Nexus devices today, and the final release will happen somewhere in Q3. This being Android, though, the biggest elephant in the room remained unmentioned: updates. As great as Android M looks, you’ll most likely not be getting it until somewhere next year. Such is life.
I wonder if this will open the doors for the currently non-existing: A bar code reader app which doesn’t require to give away your contacts, gps location, phone id and # and all other non-essential information.
From a different angle:
– Now: Google and all developers are harvesting personal data and building their own data silos
– After M: Developers will have it harder to create and maintain their data silos. Google’s position will therefore be stronger.
This is a feature as much for users as for Google.
A bar code reader that can’t add to your contacts by scanning a QR code, or look up the price and description of an item at the store, seems pretty bare bones and useless to me. The bar code reader app needs access to your contacts (see above example), camera (to read bar codes in the first place), internet connection (to look up bar codes), and phone state (to turn itself off during a call) because without all of that, it can’t do what it’s designed to do. If you’ve done your due diligence, you’ll be able to figure out which bar code app is just doing its job and which one is watching your camera all the time or serving you ads you don’t want to see.
That said, most utility apps go a bit overboard with their permission requests, probably because their app developers see a revenue stream in pushing ads. That’s why the user has to be diligent and seek out apps that don’t require access to everything.
Maybe aping Apple’s permissions model will help on both sides, maybe it won’t. But at least Google is trying.
No, I don’t need a barcode reader to add contacts, or do internet searches. I need one that translates the non human readable code, into human readable information. At which point, I, the human, can decide how to proceed.
https://f-droid.org/repository/browse/?fdid=com.google.zxing.client….
It requires those permissions, but as open source, you can review the source and decide to remove any features you don’t want. At least you can do a better than normal job of making sure it doesn’t contain any spyware.
I beleive it also prompts you to proceed with the results of the scan. Like “This is a contact”, do you want to add it? “This is a URL, do you want to go to http://www.example.com?” its really not bad. But it would be better with the new style permissions.
Correction: You most likely won’t get it till next year, when you buy a new phone.
…but rather Symbian like permissions.
I have mixed feelings about a couple of these features:
1. Permissions. I am 100% in favor of giving the user more control over the permissions; e.g. turning them on/off individually. But I’m not sure I like the idea of fewer, broader permissions. I hope there’s a way for “power users” to get to the granular permissions – I think some of the existing permissions are already too broad.
2. Doze. Again, I like the idea of a “deeper” sleep mode (ignoring that the word “doze” actually refers to a lighter form of sleep). But I don’t like the idea of devices “learning” my usage patterns. I may be in the minority here, but my usage doesn’t always follow discernible patterns, and it’s annoying to have to work around actions I didn’t ask for. I just want the device to do what I ask it to.
(Obviously, the implementation details could make these concerns irrelevant.)
From the slides they are showing off, internally the permissions are still the same old same old Android has had since 1.0.
But the M interface only allow them to by yay-ed or nay-ed on a group by group basis, similar to the “improved” permission groupings readout Play started using.
So it may well be that while the app only asks for access to speakers, hitting ok will grand it access to the whole of the audio group (microphone included).
So 8 people will get Android M this year, 64 people next year… Considering how slow Android releases are adopted.
I have a *ahem* Very Old Nexus 7 2012 (GSM) tablet. If I understand correctly it won’t be supported anymore by M, will it?
You can’t possibly be running an N7 on a stock ROM anyway.
I installed slimkat with f2fs and it made it somewhat usable, but it is still painful.
This is the infamous NAND issue
The problem for me wasn’t storage, it was the upgrade to Lolipop. Downgrading back to stock KitKat (or upgrading to Lolipop-based CM 12.1) results in a usable device still, although it is really only used as a handheld Firefox and baby monitor these days.
So, from the old, all-or-nothing approach, we now have a system that pelts you with questions when you use the app. Goodbye good experience.
Why not being able to deny/allow app permissions before download?
Modern technology doesn’t make sense to me anymore.
Edited 2015-05-28 20:50 UTC
I have CyanogenMod on almost all my Android devices, so CM 13’s schedule (which will probably be ahead of all devices except the Nexus ones) is the most important schedule for me and I’d expect it before the year’s end.
Let’s face it, if your device can’t run CyanogenMod and isn’t a Nexus device either, then it’s worthless 🙂
Now that user can protect their privacy better, developers will earn less money on selling ads and user data. This will mean that developers will have to find other ways to make the apps profitable. One solution would be to make fewer free ad financed apps and charge for the either for the apps or services that can be bought from within the apps.
Does anyone else think these are kinda low hanging fruits compared to the big issues that need to be addressed, like updates and latency? And that these enhanced permissions have more to do with not spooking a user from installing an app than actual security? And that many of these ‘advancements’ just seem to be copied from Apple as opposed to improved upon?
I certainly hope there’s more to M than this.
1
Browser: Mozilla/4.0 (compatible; Synapse)