Extended Voice Actions:
The discussion about how applications work with the new voice interaction service may be a little misleading. As with Now on Tap, applications here don't directly interact with Google; rather they go through a platform API (https://developer.android.com/reference/android/app/VoiceInteractor.html for those who care) which interacts with the back-end speech recognition service. So I wouldn't describe this as developers plugging in to the Google App -- they are using the platform API, which has a back-end plugged in to it (by default via the Google App) that does the recognition.
This is very much how Now on Tap is integrated into the platform, as described in the previous section. In fact, it isn't very much like, it is it! Now on Tap and the new voice interaction are all part of the currently enabled VoiceInteractionService, which is what you are selecting when you select which assistant you want. (This is also why voice actions can now use the context of what you are currently looking at to help with the recognition, because it is also the assistant so it that can do that.)
So, it wouldn't make sense for this to move to a Google Play Services API, because it is a very well-defined platform API. This also isn't really the first time this pattern has appeared: it is basically how input methods work, where platform APIs arbitrate interaction between the application and the current back-end input method. More closely, speech-to-text and the old simple speech recognizer are both pluggable components, which applications interact with through a (simple) platform API to whatever back-end implementation the user has selected.
On the topic of organization of "permissions," while I would agree there is some further cleanup that can happen in the UI, in many cases things are deliberately not simple runtime permissions. For example, the new "Draw over apps" and "Modify system settings" controls actually correspond to existing permissions, which we explicitly didn't want to turn into simple runtime permissions. We want to discourage apps from using them unless they have a really good reason, and they don't have anything to do directly with specific personal data access so are really hard to explain to users.
You'll note there is a warning dialog that appears when enabling an app's access to one of these, giving more information about what is happening. This is also a pattern followed by other existing dangerous access controls like accessibility services and usage access.
Speaking of accessibility, if anything we'd like to see that made less easy for apps to get to. This feature really is intended for accessibility services, and you should be skeptical about any other kind of app asking for access to it -- it gives that app almost complete control over your device and the ability to see everything you do on it!
Also fwiw, the new runtime permissions implementation makes use of app ops for applying permissions restrictions to pre-M applications. You can basically see this as the long desired UI for app ops, and app ops' basic behavior remains the same where turning off access means the app simply sees no data (no location, zero contacts, etc). We never create fake data.
Abuse of high priority messages have a special difference from other things like notifications: they must go through Google servers, so Google can monitor and modify what is being sent to devices. If apps abuse these for other things besides their intended use, we will be able to stop that abuse without touching any software on the device. (Also "abuse" here is much less subjective than for notifications, where there is a large gray area of things some users care about and some don't. For high priority messages, if it isn't something that is time critical to go to the user immediately, it is not appropriate.)
Chrome Custom Tabs:
This isn't really tying an app to Chrome. It is defining an extended API with the browser than an app can use to get the behavior. The standard implementation used by apps should work with any browser as long as it supports the API, regardless of what the default browser is. So Firefox and others should be able to implement the same API as Chrome and get the same behavior from the same apps.
When it comes to notifications, you want to strike the perfect balance between standing out and not being spammy. It’s easy enough to stand out if you improve the look of your notification, use informative text, and offer actions to your users. (As explained in this super helpful DevByte https://goo.gl/1UrHMU.)
But when it comes to ranking, your options are fairly limited. Most developers understand that they can set the notification priority (http://goo.gl/Mzemrt), and so they’ll just claim everything as MAX. But not every notification deserves to be high-priority. And honoring that will actually help you build user trust. Use the guidelines below to help you reach your users when you need to, without being that annoying spammy app. High and Max priorities will get a “Heads-up” notification, so make sure these are truly important enough to interrupt the user, since that’s what you’ll be doing.
You can also specify the notification’s category (http://goo.gl/wJBSpJ). Android provides several category options that help the system give deference to things like calendar events, which the user probably cares a lot about. So when you specify a value here, you are only helping yourself. Because while categories won’t directly affect your notification’s ranking, they will influence decisions like whether to trigger when the device is in Do Not Disturb mode.
Finally, you can list the people involved (http://goo.gl/F8RafP). Because when you provide information about who the message is coming from, for example, the system can see that that user is actually a starred contact, and your notification just became more interesting to the user. Possibly even interesting enough to also break through the Do Not Disturb mode. For more information on this new option, check out this protip from (https://goo.gl/0xUZK4).
To learn more about notification priority and categories, check the design guidelines (http://goo.gl/uYcrfH). And to see how to add this metadata to your own notifications, check the documentation (http://goo.gl/M9Q8Wz). But above all else, just continue to #BuildBetterApps .
- IFTTTAndroid Engineer, 2015 - present
- Eric CochranAndroid Developer, 2012 - present
- thredUpAndroid Engineer, 2014 - 2014
- Horizon Chase - World Tour
- Kingdom Rush
- Ticket to Ride
- Hitman GO
- Fit Cat
- Monument Valley
- Georgia Institute of TechnologyComputer Science, 2011 - 2014
Food Delivery by Caviar - Android Apps on Google Play
Step up your food delivery game. With Caviar you can get fresh, hot meals from the best restaurants in your cityâ€”brought right to your doo
Lobsterpicker - Aplicaciones de Android en Google Play
Lobsterpicker is a library for android material design made to support apps and developers if a color should be choosen by a user. The libra
Android Market - Aplicaciones Android en Google Play
Optimizado para el tablet y para Android 3.0 (Honeycomb), ahora Android Market agiliza y facilita la búsqueda de widgets, juegos y aplicacio
Portal - WiFi file transfers – Aplikacje Android w Google Play
Getting pictures, videos, and other files from your computer onto your phone should be quick and painless. Portal helps by making it as easy
Google Spotlight Stories – Aplicaţii Android pe Google Play
Immerse yourself in a world of storytelling made just for mobile. Engineers and critically-acclaimed filmmakers are bringing stories to life