Android M Arrives In Q3: Native Fingerprint Support, Android Pay, 'Doze' Mode 83
MojoKid writes with yet more news from the ongoing Google IO conference: Google I/O kicked off this afternoon and the first topic of discussion was of course Google's next generation mobile operating system. For those that were hoping for a huge UI overhaul or a ton of whiz-bang features, this is not the Android release for you. Instead, Android M is more of a maintenance released focused mainly on squashing bugs and improving stability/performance across the board. Even though Android M is about making Android a more stable platform, there are a few features that have been improved upon or introduced for this release: App Permissions, Chrome Custom Tabs for apps, App Links (instead of asking you which app to choose when clicking a link, Android M's new Intent System can allow apps to verify that they are rightfully in possession of a link), NFC-based Android Pay, standardized fingerprint scanning support, and a new "doze" mode that supposedly offers 2X longer battery life when idle.
Re: (Score:1)
I prefer iOS with its text based restart.
Re:Fuck Dice.com!! (Score:4, Informative)
Is that Dice? Little Registry Cleaner [sourceforge.net] now installs a ton of crap by default. Look at the latest reviews. You can still get a clean install by reading each of the dialog boxes but the point is it comes bundled with crap in the first place.
Re:Fuck Dice.com!! (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Laugh (Score:2)
"these aren't the droids you're looking for"
Re: (Score:2)
I know, right? A boneheaded miss on a slam dunk reference.
useless without updates (Score:5, Insightful)
The most common Android version in the wild is still.. Jelly Bean.
Android has dropped the ball on OS updates. Apple didn't do it perfect, but they are much better and mostly you can update devices to at least one or two more versions before it beomes obsolete.
Google needs to up their game around OS updates or it doesn't matter what they put in it, if nobody is running it.
Re: (Score:2)
Among the changes are bug fixes and improved battery life, which are immediately useful to anyone who installs M, regardless of how many others don't.
Google's Useless About Updates (Score:3)
Well, thank you very much, telling me that I'd get better battery life if I installed the new Android version. As far as I can tell (at least with all previous Android versions), Google's instructions for installing the new software are "What? You don't have one of these three Google-brand phones? Then wait for your carrier!".
That's bad enough for my phone (which has a carrier, and Samsung's a reasonably major brand, though my previous HTC phone never got upgraded), but my tablet's Wifi-only, so there's n
Re:Google's Useless About Updates (Score:4, Informative)
Google Play works fine with cyanogen.
Re: (Score:1)
Google Play works fine with cyanogen.
Assuming you mean CyanogenMod and not Cyanogen, Inc.: they have yet to release a stable (or even a snapshot) build of Android 5 or 5.1. I like CM, but I'm hesitant to sign on to CM12.1 when the forum threads for nightlies are bug report after bug report.
Re: (Score:2)
You'd have access to the Play store, also could use the Amazon market, as well as FDroid, the free focused app resource--I have all three on my Cyanogenmod wifi-only tablet.
Re: (Score:2)
I thought from what I read that because there's so much customization by each manufacturer for each model that updates or whole version upgrades (i.e. Ice Cream Sandwich to Jelly Bean or Jelly Bean to Kitkat) have to come from the manufacturer? That you can't just install a generic version from Google and have all features work?
Re: (Score:2)
Re: (Score:2)
I'm just repeating what I read, I can't find that specific article but this one provides similar details: http://www.howtogeek.com/12927... [howtogeek.com] so in actuality it is true.
Re: (Score:2)
It's called differentiation. Manufacturers want to make their phones unique, distinct and more desirable on the shelves. So if you're deciding between two phones with otherwise identical specs (same processor, RAM, flash), you'd look to their customizations as the differentiating factor. Because there's only so much a manufacturer can do - processor c
Re: (Score:1)
I would blame the manufacturers and carriers about as much as Google themselves for this update mess we have ourselves in. The Droid Turbo was supposed to get the latest OS a while back but Verizon and Motorola keep delaying the update.
Re: (Score:2)
Verizon finally updated my Ellipsis 7 to KitKat after a while - but now, I have lost the ability to save files to my 32GB SD card. I was told that for this device, KitKat only supports up to 16GB. But it took a while to upgrade. They had the same issues qualifying Windows 8.1 for Microsoft, and now, Verizon no longer offers the Lumia Ikon.
In the above case, doesn't Motorola == Google itself? If Google has certified an OS, why wouldn't it be available on every Google device that meets the hardware requ
Re:useless without updates (Score:4, Informative)
The most common version is now KitKat with 39.8%. Jelly Bean is second with 39.2% and Lollipop has just under 10%.
https://developer.android.com/... [android.com]
Keep in mind that a lot of Android users have low incomes and/or live in countries where an over the air OS update would be a significant cost to the average person. We might think that a smartphone is useless without at least a 1GB per month data plan, but hundreds of millions of users in the developing world think otherwise.
Re: (Score:1)
Re: (Score:3)
True, but if you're not visiting the Play Store you're probably either not using your phone for anything that would benefit from an OS update, or you're using Cyanogen or some other custom build.
If you look at the distribution of people who actually download your app from Google Play it will be even more skewed towards newer versions of Android, because people download a lot more apps in the days and weeks after they buy a new phone.
I have an app that currently sees about 20% Lollipop and 45% KitKat in new
Re: (Score:2)
I don't see it being a big deal though since the general rule of thumb of developing on Android is you choose
No... (Score:5, Interesting)
No, they grouped them in categories that are granted or revoked at the same time (group => non granular). What they made is make those group be revocable by the user and be able to request them at use time instead of at install time
M arrives (Score:2)
Re: (Score:2)
but is it Bernard, Judi, or Ralph?
Presumably you're deliberately excluding Robert. [wikipedia.org]
Large change with app permissions (Score:5, Insightful)
They talk about how it's a stability release, but if you are going to compile your application with the newer dev tools you are going to have to do some work adapting to the iOS style permission model.
I'm really glad to see Android adopted this model, the previous model made no sense from any standpoint - it was worse for the users, and worse for security. Now that Android will ask for permission when you actually want to use some protected resource, they can make a way more informed choice if they should allow it or not - and on the fly decide an app can access some things and not others (say allowing Contacts but not location).
It's just a shame the older style permission model will be supported for some time to come, as it greatly eases the ability of spyware to operate on Android.
Re:Large change with app permissions (Score:5, Informative)
Older applications not targeting M, will show permissions at install time and be granted by default, but the user will be able to revoke them, the platform will just give empty data or fail. From the preview documentation [android.com]
Note: On devices running the M Developer Preview, a user can turn off permissions for any app (including legacy apps) from the app's Settings screen. If a user turns off permissions for a legacy app, the system silently disables the appropriate functionality. When the app attempts to perform an operation that requires that permission, the operation will not necessarily cause an exception. Instead, it might return an empty data set, signal an error, or otherwise exhibit unexpected behavior. For example, if you query a calendar without permission, the method returns an empty data set.
If you are worried that old applications can use the permissions immediately after installation, before you have time to disable the permissions, take into account that applications are installed on a stopped state, there is no programmatic way for it to auto start itself. Start on boot may work but it is not precisely immediately. So I think the best action is to go to those old applications just after install and remove every permission you don't want to grant before starting it.
Re:Large change with app permissions (Score:5, Informative)
Re: (Score:3)
Will it run on Nexus 4? (Score:2)
The preview doesn't say it will run on Nexus 4, hopefully the final version will run because it's powerful hardware, 2GB RAM and Quadcore. Forced obsolescence of good hardware is annoying and hope Google is not bad as other OEMs.
Re: (Score:2)
google isn't an oem
Re: (Score:2)
Will the make a nexus 4 or 5 since a 6 is to fsking big to be useful and costs 2x as much.
wat? (Score:5, Informative)
"For those that were hoping for a huge UI overhaul..."
Yeah, because we haven't had one of those in a whole year. [wikipedia.org]
Re: (Score:1)
A year ago? That's practically prehistoric for the "UX designers" of the world.
Re: (Score:2)
Some people may not want a new UI every year, some are unhappy with which UI was left when the music stopped.
App Permissions ring hollow (Score:5, Informative)
The App Permissions seem to be missing the crucial ability to deny internet access to an app. There are apps where network data connectivity is the problem. Similarly, I wonder if Google will have this permission setting capability on its internal applications. I know that I have a rather tightly worn tin foil hat when it comes to Google and the information they get, but the Xprivacy 'deny' list on my phone is a mile long, and that's with most of their apps frozen or forcibly pulled out, I find that Google's data access on the platform demands a tight leash, leading the 'privacy' and 'permissions' charge to ring of hypocrisy - "we'll make sure that only we have your location" doesn't mean much to me :/
Re: (Score:2)
Uh, are you aware that Google owns AdMob, the main mobile ad provider?
They would probably not want to make it easy for users to block ads by turning on and off internet access on a per app basis.
Re: (Score:2)
The App Permissions seem to be missing the crucial ability to deny internet access to an app. There are apps where network data connectivity is the problem. Similarly, I wonder if Google will have this permission setting capability on its internal applications. I know that I have a rather tightly worn tin foil hat when it comes to Google and the information they get, but the Xprivacy 'deny' list on my phone is a mile long, and that's with most of their apps frozen or forcibly pulled out, I find that Google's data access on the platform demands a tight leash, leading the 'privacy' and 'permissions' charge to ring of hypocrisy - "we'll make sure that only we have your location" doesn't mean much to me :/
The ability to block internet access would effectively block ads. On the plus side, there are plenty of firewall apps in the Play store (though they do require you to have a rooted device).
Can't really complain... want more encryption (Score:5, Interesting)
Lots of evolutionary fixes. The privacy stuff is better than nothing... but still all of nothing with legacy apps. The fingerprint standardization is good, because it allows an app that keeps keys to have an easy way to validate that the user is authorized.
Mobile payment - works with credit cards, as opposed to ACH debits, so thumbs up there. This means there is some way of rolling back fraudulent charges should something happen. With ACH based mechanisms, once the crook sucks the money out, there is little or nothing one can do.
Of course, there is one thing missing -- a standardized way to encrypt data on SD cards. Yes, /data is protected, but each device maker has their own way of securing SD card data. What is needed is protection similar to Blackberries in the past:
1: Offer compatibility with vfat and exFAT filesystems, by using loopback encryption (EncFS), as well as adding UNIX permissions via UMSDOSFS to keep apps separated. UMSDOSFS hasn't been used in ages... but is ideal for enforcing basic UNIX permissions while allowing for MS-DOS based filesystems to be used underneath.
2: Encrypt the entire SD card's partitions entirely similar to how /data is encrypted. This is the ideal choice, but it keeps the card from being able to be popped out and used with other devices.
Re: (Score:2)
The goal is to have something that isn't limited to a device. This lessens the amount of code that is locked to one make, or even worse, one model. It also reduces the chance of security issues, since one company's EncFS implementation may be brain dead, while another's is quite up to par with security.
Same with device encryption. If each maker did its own thing with regards to encrypting /data, it would be difficult to make a ROM for that platform that would be up to par with security. At best, a facto
'Doze mode...? (Score:2)
I've clearly been on Slashdot for far too long. I read 'Doze Mode in the title and thought, 'Goddammit, if you're going to talk about Windows Mode, just fucking call it "Windows"!'
And then I realised that it actually is 'Doze Mode'. Because 'Naptime' was taken, I guess.
Re: (Score:2)
Which is quite a coincidence, because my new Windows phone is actually quite good at not draining the battery when I'm not doing anything. The other day I was still at 95% battery by the end of the day because I was too busy to use my phone. My old Android phone on the other hand would easily go through 25-50% of it's battery in a day, even if I didn't use it for much. Most of the time I would plug it in at the office because if I didn't, it would be below 20% by the end of the day.
How about Undo? (Score:1)
Apps on the SD card (Score:2)
Following Microsoft's Every Other Version pattern (Score:2)
Lollipop is to Android what Windows Vista was to Windows: Nice looking, but slow and buggy. It lags a lot, sometimes to the point of entirely freezing up. If they speed it up and clean it up, I'll be very happy.
Re: (Score:1)
My sons Moto G disagrees with you, every bit as fast as my Nexus 5. Perhaps you had a dirty flash?
Can't wait ohwait (Score:2)
oh, yeah... Verizon.
Re: (Score:2)
We'll be lucky to see the first device running Android "M" on Verizon by Q2 next year.
Nexus 6 launched on November 3, 2014 as the first Lollipop device. Seven months later in May 2015, my Note 4 is updated to 5.0.1.