I've been slogging my way through the videos, and I have to say, no one thing is showstopping. It's all incremental, and mostly in a good way. Highlights, at least from my perspective:

Google Photos: They've split out G+'s Photos (formerly Picasaweb) and rolled in some very interesting new features.

- Infinite free image backups (max 16MP stills or 1080p video)

- crazy cool machine learning to automatically cluster images without any need for tagging

- very easy to share with your friends, even if they're not on G+

Networking

- Apps can say "hey, I can handle any URL of the form http://www.yeahwhatever.com" (think: Twitter for tweets, NYTimes for news articles, etc.). To avoid random hijackings, your phone will download a magic file from the web server in question which has a hash of the app signing key. Clever.

- Full Internet privileges are now a *standard* privilege for any app. This is a serious problem if your WiFi is behind a firewall and you've got softer security on the inside. We're talking about data exfiltration from internal web servers, etc.


Performance / battery saving

- As always, "this time it's way better". Better compilation. Better power management. One thing that jumped out at me is that if your app hasn't been run by a user in a long while, Android will quietly disallow it to run in the background.

- There's a lot of attention to dealing with low-memory devices and low-bandwidth countries. Offline maps. Web sites compressed through proxies. And on and on. Notably absent from this discussion, any hint of how much bandwidth is blown on advertising. (More complaining about this below.)


Login / authentication / security

- There's full support for fingerprint recognition and also an API that basically just says "reauthenticate the user". There's a more general "smart lock" infrastructure that's part of the war on usernames/passwords. This is a good thing.

- Project Vault: There's a nifty microSD card, running its own OS with its own radio even, that can help with authentication. Somehow.

- They're abandoning the current ask-for-everything-up-front permission model for something closer to how iOS does it, allowing an app to make a permission request any time it wants, but now apps have to deal with users who say "no". Legacy apps don't need to make these requests, but users can go in and revoke permissions. This is not the same as what CyanogenMod's PrivacyGuard does, where it just lies to the app. "You want contacts? Here you go. Oh look, there are zero contacts." Nope, you try to read the contacts and it will just grenade on you.


Advertising

- My biggest gripe to Google, which I aired on my blog and to many Google people privately, is that advertisements are this monstrous thing that need to be treated as a first-class citizen in the Android world. Ads need to run as separate entities, with their own permissions, etc. But no! Instead, AdMob is now folding in quite a large number of different third-party ad providers (via syndication) and will load their content. Combine this with the everybody-gets-full-Internet-access thing, and I think they're crazy.


Miscellaneous

- USB-C support -- now your phone can charge somebody else's phone, among other configurable options.

- "Adopting" an SD card -- basically puts a real filesystem on it and merges it in with the regular filesystem somehow.

- The Roboto font, and all the tooling used to create it, is now completely open source

- A cloud service that, somehow, runs your Android app on a bunch of different virtual phones and sends you back crashlogs and screenshots.

- More widget support for all the snazzy Material design, and backward compatibility libraries to let new code run on ancient Android versions, all the way back to Android 2.1. Wow.

- The Play Store has some new tools to help devs experiments on their users (the example they use is trying out four different icons to see which users install more often). Also they're doing some sort of categorization and customization of search results. If this works, it will make all the Android Wear devs, who didn't manage to get "featured" much happier, since right now it's damn near impossible to otherwise find these apps.

- A new spin of Android Pay (nee Google Wallet)


Crazy far out, man

- They've doubled down on the Cardboard VR thing. Now they're planning to distribute content via Youtube, and they've rigged up a ring of 16 GoPros that can capture stereoscoping VR video.

- They've got this crazy tiny radar-on-a-chip that can be used to measure various gestures from your hands. They then crammed it into a wristwatch-ish thing and now you've got all these controls without ever needing to touch it.

- They're working with textile manufacturers to put conducting threads in common textiles. Think touchpads-in-your-clothes.


Notable for their absence

- No new hardware. No new phones, tablets, TVs, cars, watches, etc.

-

I'll have to look for it again, but I thought I saw that for legacy apps when permissions are turned off, the phone will serve up an empty dataset vs just simply grenading the request and letting the app choke. In any case, good to see the main Android platform move to the newer model, and I hope most apps follow quickly.

I watched most of yesterdays keynote, still need to catch up on anything in todays keynote. Props to Google for putting forward a more inclusive group of presenters. Along with toning down the snarky comments about other platforms and focusing more on their own products again.

A few words of caution to anyone on a Mac or iOS device and the new Google Photos. The Mac importer only knows how to handle iPhoto, not the new Apple Photos. Since Photos leaves the migrated iPhoto library around, Google's app may see it and upload stale photos. I couldn't find a way to force it to look at Photos, but it seemed to pick up the images if I set it to simply handle my entire Pictures folder.

On iOS, Google Photos will not function without being granted access to the system photos library. When photos are deleted inside Google Photos, it also tries to delete them from the system library. With iCloud Photo Library on, this would delete the photos on any device (recovery from the trash is possible). Due to the mix of these two issues, my testing environment ended up with duplicated photos, and then when cleaning up, risked causing issues on the Apple Photos side.

You know that apps will deal with users who say no by refusing to work until they say yes. Lying to the app was always the correct answer.

Hadn't really thought about that, as the only time I've seen such a situation on iOS has been when it's very obvious. Like a navigation app needing location access.

Google is also now doing app reviews, so ideally any misbehaving apps that block until permission is granted are caught well before an end user download.

Mmm.. "Legacy apps don't need to make these requests,".. sounds like the "asking" is voluntary rather than enforced by the system. Not really secure.

Oh, Lovely. Thank goodness for DroidWall.

From watching the videos, I think:

. Permissions are still enforced outside of the user process. When a new-school app requests a permission, the system pops up the dialog. Or it fast-fails if the user already said "deny and don't ask me again".

. They said that they rejected the false / fake answer solution as used in CyanogenMod. They instead are trying to get app authors explicitly engaged in their users' experiences. Best practice is to make a permission request at the moment it's needed, eg, if the user hit an audio recording button, it's reasonable to use that moment to ask for microphone access. This approach is good human factors. It's going to be annoying to advertisers.

. Legacy apps get the same install-time dialog as today, and users can subsequently revoke permissions through the system settings.

. My biggest sadness is the complete lack of any discussion of permission bloat from advertising libraries. If there's anything going on with the security ugly of ads, they're not yet willing to discuss it in public.

I had pretty much the same conclusions, Dan. Nothing shocking overall, but everything together left a good impression. It was certainly a long way from skydivers landing on the convention center with Google Glass on their faces, and that's probably a good thing. This was definitely more focused on developers, and I guess we'll see product announcements in the fall.

I'm excited about that USB C port, though. I hope the next Nexus device uses it, although I worry that we're too far in the product cycle for that to happen...

So far as I know, there are exactly two shipping devices in the world that have USB-C: the new MacBook and the new Chromebook. I don't know the availability of parts and whatnot, but clearly this is the future of all things, it's just a matter of when. It never would have occurred to me that the business about "who powers whom" over a bidirectional cable like this is sufficiently confusing as to require user dialogs, but it all makes sense.

Edit: I forgot to mention the oddball Nokia N1 tablet and, just announced today, a new Asus tablet.

Minor digression: I was pondering the new MacBook as a replacement for my four-year-old MacBook Air (13"), but I initially rejected it due to the total absence of useful USB-C accessories. If/when the HydraDock comes out, that might be the thing that tips my hand. You can replace all the dumb dongles in your bag with one big dongle, not unlike the very original and much beloved Sony 505G. The same people are also working on a USB-C car charger and other such goodies. Of course, in a year or two they'll be overwhelmed by the generic Chinese brands, and you can rest assured that every damn one of them will get something important wrong. (Sigh.)

Google has all the new permission API documentation up now. Here's the money paragraph (emphasis mine):

So, that's at least promising.

What I like: They're encouraging apps to use external services rather than requesting permissions themselves. The canonical example is that, if you need to take a picture, you just send an IPC to the camera app, which will do it for you, no permissions required, versus talking to the camera directly, which requires permissions.

Also, they've created eight "macro" permissions. Example: "SMS" covers reading old messages and sending new ones. That's less precise, but it's also more user-comprehensible. I think that's a good tradeoff to make.

I'm still unhappy about every app having full Internet access by default. I went digging to see what else is on by default. Unfortunately, they haven't yet posted the relevant source code, although I suppose I could extract it from the M Developer Preview. That's a project for another day. For reference, here's where all the permissions are defined. The relevant blob is this:

The magic word is "dangerous". So long as that's there, then the app is required to request the permission before it will work. If that field instead says "normal", then the permission is automatically granted. According to Github, the latest commit to this particular file was in March 2015, so that means the decision to give full Internet to every app was made later than that.

I don't see how that is a "good" thing for privacy. It appears to just merely remove the ability to forbid, say, a GPS app from spying on me at night with the camera.

Here's the choice. Say you've got an app that wants to take a picture, like Twitter or Facebook or something.

Choice 1: It asks for camera permissions, and can take a picture at any time, whether or not you want it.

Choice 2: it sends an IPC request to the Camera app (using the Android Intent system, so it's more like "hey, is there somebody out there who can take a picture for me?"). The camera app now takes over, and gives the user a take-a-picture button. If the user presses it, then that's the one and only picture that the app gets back. Otherwise nothing.

A whole lot of use cases that can be satisfied by choice 2 are typically dealt with by choice 1. Choice 2 would seem preferable, since you're not giving your app a general-purpose permission, but rather a wrapper that keeps the user in the loop, in a way that the user won't necessarily even notice the difference.

Okay, the "press the button" part saves the camera here.

But really, this sounds like it is removing all of the nice stuff that I get from Privacy Guard today, and replacing it with .. nothing. True?

In many respects, aside from the Internet permissions thing, Android M does exactly what CM PrivacyGuard does. The difference is that PrivacyGuard tries to operate transparently to the app while Android M is more invasive.