Slashdot Mirror

← Back to Stories (view on slashdot.org)

Android M Arrives In Q3: Native Fingerprint Support, Android Pay, 'Doze' Mode

Posted by timothy on from the sleep-beats-death dept.

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.

2 of 83 comments (clear)

  1. No... by robmv · · Score: 4, 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

  2. Can't really complain... want more encryption by mlts · · Score: 4, 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.