Over 150 Technical Sessions, Livestreamed
The show kicks off at 10AM PDT on Wednesday, May 17 with the Google
Keynote, an opportunity to hear about the latest product and platform
innovations from Google, helping connect you to billions of users around the
world. After that, we'll be diving into all of the ways developers can take
advantage of this newness in a Developer Keynote at 1PM PDT. From there, the 14
tracks at Google I/O kickoff, with over 150 technical sessions livestreamed
(i.e. all of them!) at google.com/io.

We've just published more talks on the I/O website, so
you can start planning your custom schedule ahead of the conference (shhh! we've
got a few more sessions up our sleeve, so don't forget to check back directly
after the Developer Keynote).

You can also take advantage of Codelabs - self-paced tutorials on a number of
technical topics to get you up and running with a Google product or feature.
These Codelabs will be available both to those who are joining us in person at
Shoreline, and online for those of you tuning in from around the world. More
details will be available on the schedule soon.

Joining in person?
We received a lot of great feedback from attendees last year, and have been
working hard since then to make sure this is the best Google I/O, yet. To help
make it easier to attend your favorite talks and minimize lines, you'll be able
to reserve seats across sessions before I/O starts. But don't worry, we're
saving a few seats in each session that will be available on a first-come,
first-served basis onsite. We've also increased the size of each of the tents
this year, giving you more opportunities to see all of your favorite talks
in-person.

Finally, we've doubled the number of Office Hours available, since you told us
that being able to connect directly with Googlers to get your questions answered
was extremely valuable. On top of that, all of the sandbox demo areas will be
inside climate-controlled structures, making it easier to avoid the elements
(but don't forget to bring your layers – Shoreline Amphitheatre is still an
outdoor venue, after all).

See you in 3 weeks!
We're looking forward to seeing you in just a few weeks. We've got a few more
updates to share before then; be sure to check out the Google I/O website for
more details, or follow the conversation using the #io17 hashtag.

When we first announced the Google Assistant, we talked about helping users get
things done no matter what device they're using. We started with Google Allo,
Google Home and Pixel phones, and expanded the Assistant ecosystem to include
Android Wear and Android phones running Marshmallow and Nougat over the last few
months. We also announced that Android Auto and Android TV will get support
soon.

Today, we're taking another step towards building out that ecosystem by
introducing the developer preview of the Google Assistant SDK. With
this SDK you can now start building your own hardware prototypes that include
the Google Assistant, like a self-built robot or a voice-enabled smart mirror.
This allows you to interact with the Google Assistant from any platform.

The Google Assistant SDK includes a gRPC API,
a Python open source client that handles authentication and access to the API,
samples and documentation. The SDK allows you to capture a spoken query, for
example "what's on my calendar", pass that up to the Google Assistant service
and receive an audio response. And while it's ideal for prototyping on Raspberry Pi devices, it also adds
support for many other platforms.

To get started, visit the Google Assistant SDK website for developers,
download the SDK, and start building. In addition, Wayne Piekarski from our Developer
Relations team has a video introducing the Google Assistant SDK, below.

And for some more inspiration, try our samples or check out an example
implementation by Deeplocal, an innovation studio out of Pittsburgh that took
the Google Assistant SDK for a spin and built a fun mocktails mixer. You can
even build one for yourself: go
here to learn more and read their documentation
on Github. Or check out the video below on how they built their demo from
scratch.

This is a developer preview and we have a number of features in development
including hotword support, companion app integration and more. If you're
interested in building a commercial product with the Google Assistant, we
encourage you to reach out and contact us.
We've created a new developer community on Google+ at g.co/assistantsdkdev for developers to
keep up to date and discuss ideas. There is also a stackoverflow
tag [google-assistant-sdk] for questions, and a mailing
list to keep up to date on SDK news. We look forward to seeing what you
create with the Google Assistant SDK!

In this scenario, field masks serve a different, but similar purpose—they still
filter, but function more like bitmasks by controlling which API fields to
update. The following video walks through several examples of update field mask
usage with both the Google Sheets and Slides APIs. Check it out.

In the sample JSON payload below, note the request to set the cells’ bold attribute to true (per the cell directive below), then notice that the field mask (fields) practically mirrors the request:

Now, you might think, "is that redundant?" Above, we highlighted that it takes
two parts: 1) the request provides the data for the desired changes, and 2) the
field mask states what should be updated, such as the
userEnteredFormat/textFormat/bold attribute for all the cells in
the first row. To more clearly illustrate this, let's add something else to the
mask like italics so that it has both bold and italic fields:

"fields": "userEnteredFormat/textFormat(bold,italic)"

However, while both elements are in the field mask, we've only provided the
update data for bold. There's no data for italic setting specified
in the request body. In this case, italics for all cells will be reset, meaning
if the cells were originally italicized, those italics will be removed after
this API request completes. And vice versa, if the cells were not italicized to
begin with, they'll stay that way. This feature gives developers the ability to
undo or reset any prior settings on affected range of cells. Check out the video
for more examples and tips for using field masks for update requests.

To learn more about using field masks for partial response in API payloads, check out this video and
thefirstpost in
this two-part series. For one of the most comprehensive write-ups on both (read
and update) use cases, see the
guide in the Google Slides API documentation. Happy field-masking!

The Material Design Guidelines are a
living documentation of visual, interactive, and motion design guidance across
platforms and devices.

Beyond
guidance, Material Design is a also system that supports and strengthens
communication and productivity with new tools and inspiration. With today's
update, Material is introducing a new way to learn about color. The new color tool helps you create, share, and
apply color palettes to a sample UI and through components in codepen. The tool
also supports accessibility by evaluating the legibility of text for any color
combination. Specific features include:

Create color schemes

Create color schemes that include darker and lighter variations of your primary
and secondary colors.

Preview the look of your color scheme across a range of Material Design Components, with
editable HTML, CSS, or JavaScript in Codepen.

With these new tools to dabble with color schemes, you'll be able to give you
users a richer experience, so we can't wait to see what you come up with. To get
the latest news and engage with us directly, please follow us on our new Twitter
account (@materialdesign) and
visit https://material.io/.

Santa Tracker is a holiday tradition here at Google. Every year, you can
celebrate the season with games, holiday experiences and educational content
throughout December: not to mention watching Santa deliver presents on 24th.

Today, we're continuing the season of giving by delivering the updated
open-source versions of both the Web and Android versions that ran in December
2016. These are large, real-world apps that show off the latest and greatest
from Google—using APIs and frameworks like Firebase and Polymer.

This year, Santa's elves added even more engaging, fun and educational
experiences to Santa Tracker: all while making Santa and his reindeer leaner
than ever before—across both Web and Android.

On the Web, we built a reliable, offline-capable PWA-ified version of Santa
Tracker that saved bandwidth and worked in environments with poor connectivity.
For Android, we worked hard to save every precious byte by closely examining our
visual assets and other libraries.

Santa is a Progressive Web App, sporting a responsive design for mobile,
desktop and tablet, supporting Add to Home Screen and offline.

Rather than saving the entire site offline (about 100mb, including
resources needed for different browsers), Santa's Service
Worker only saves the scenes you've visited at least once—icing over houses
that aren't available offline.

Santa Tracker used Polymer 1.7+, packing code into reusable components.
Every house
in Santa's Village is a custom element, only loaded when needed, minimizing the
startup cost of Santa Tracker.

The Web Share API allowed users on mobile to quickly and natively showcase
their creativity—it's a modern API for interfacing with a platform's native
share intent, replacing the sea of share buttons normally presented to users.

Santa sported a new and improved Chromecast experience that scaled well
across all Cast devices—from the original Chromecast device through to the
high-end Chromecast Ultra and supported TVs.

Users were delighted by showing some greatvideocontent from around
Santa's Village, especially during Santa's long travel legs.

The Android client also used this Chromecast experience, so Android users
joined the fun watching Santa deliver presents on the 24th on their big screen
TVs.

Present Quest, a new AR game where players are encouraged to explore their
real-world environment to collect presents and level up!

Santa is smaller and faster than ever before. The download size is down 10mb
from the previous release, despite including multiple new games, Santa works
better on memory-constrained devices, and various sources of jank have been
found and removed.

The app is built using split APKs - one per architecture (armv5, armv7, and
x86), reducing download size. Each APK supports phones, tablets, Android TVs and
provide custom watch faces on Android Wear.

When you write applications using Google APIs (not just G Suite ones, but most Google APIs including YouTube or Google Cloud Platform APIs), it's important to be mindful of the data that’s returned in the response payloads from API calls. If you're not, your apps are likely getting back much more data than they need which can affect the performance of your apps whether on mobile or a server backend.

That's why most Google APIs allow you to only filter the data you need from response payloads with field masks. To get you comfortable with field masks, we’ve put together a video to demonstrate their use with various Google APIs:
With field masks, you can specify exactly what fields an API should return in its response payload by providing a fields or part parameter in your calls. And once the API knows what you want, it will likely spend less time assembling your response too. Here’s an example Python call to fetch your sender addresses using the Gmail API (if GMAIL is your service endpoint):

Whether you’re using a Client Library (as our Python call) or using HTTP directly with GET https://www.googleapis.com/gmail/v1/users/userId/settings/sendAs, this is the payload you get back from the API:

The sendAs array gives you everything you need to know about each of your sender addresses. Did you know you can change a user’s email signature using the Gmail APIwithout all of the data from above? You only need one field, or at most two: sendAsEmail and perhaps the isPrimary flag. By specifying a field mask with just those names from the sendAs attribute, you can cut out all those unneeded fields. Check it out here in Python with the field mask bolded for emphasis (versus the sample code above that doesn’t filter):

In part two of this video series (coming soon), we’ll show you a different use case for field masks...for update API calls. We’ll also provide some usage tips and demonstrate how field masks can be used in both read and update calls, how both types of calls are discrete, and how in some cases, you may use both as part of a single API call. Stay tuned!

To learn more about using field masks for partial response in API payloads, check out this section of the Client Library docs. For one of the most comprehensive write-ups on both (read and update) use cases, see the guide in the Google Slides API documentation.

Posted by Xiangye Xiao and Jungshik Shin, Internationalization Engineering team

Today, in collaboration with Adobe, we are responding to the call for Serif! We
are pleased to announce Noto Serif CJK, the long-awaited companion to Noto
Sans CJK released in 2014. Like Noto Sans CJK, Noto Serif CJK supports
Simplified Chinese, Traditional Chinese, Japanese, and Korean, all in one font.

A serif-style CJK font goes by many names: Song (宋体) in Mainland China,
Ming (明體) in Hong Kong, Macao and Taiwan, Minchō (明朝) in
Japan, and Myeongjo (명조) or Batang (바탕) in Korea. The names
and writing styles originated during the Song and Ming dynasties in China, when
China's wood-block printing technique became popular. Characters were carved
along the grain of the wood block. Horizontal strokes were easy to carve and
vertical strokes were difficult; this resulted in thinner horizontal strokes and
wider vertical ones. In addition, subtle triangular ornaments were added to the
end of horizontal strokes to simulate Chinese Kai (楷体) calligraphy. This style
continues today and has become a popular typeface style.

Serif fonts, which are considered more traditional with calligraphic aesthetics,
are often used for long paragraphs of text such as body text of web pages or
ebooks. Sans-serif fonts are often used for user interfaces of websites/apps and
headings because of their simplicity and modern feeling.

Design of '永' ('eternity') in Noto Serif and Sans CJK. This ideograph is famous for having the most important elements of calligraphic strokes. It is often used to evaluate calligraphy or typeface design.

The Noto Serif CJK package offers the same features as Noto Sans CJK:

It has comprehensive character coverage for the four languages. This
includes the full coverage of CJK Ideographs with variation support for four
regions, Kangxi radicals, Japanese Kana, Korean Hangul and other CJK symbols and
letters in the Unicode Basic Multilingual Plane of Unicode. It also provides a
limited coverage of CJK Ideographs in Plane 2 of Unicode, as necessary to
support standards from China and Japan.

Simplified Chinese

Supports GB 18030 and China’s latest standard Table of General Chinese Characters (通用规范汉字表) published in 2013.

Supports over 1.5 million archaic Hangul syllables and 11,172 modern syllables as well as all CJK ideographs in KS X 1001 and KS X 1002

Noto Serif CJK’s support of character and glyph set standards for the four languages

It respects diversity of regional writing conventions for the same
character. The example below shows the four glyphs of '述' (describe) in four
languages that have subtle differences.

From left to right are glyphs of '述' in S. Chinese, T. Chinese, Japanese and Korean. This character means "describe".

It is offered in seven weights: ExtraLight, Light, Regular, Medium,
SemiBold, Bold, and Black. Noto Serif CJK supports 43,027 encoded characters and
includes 65,535 glyphs (the maximum number of glyphs that can be included in a
single font). The seven weights, when put together, have almost a half-million
glyphs. The weights are compatible with Google's Material Design standard fonts, Roboto, Noto Sans and Noto Serif
(Latin-Greek-Cyrillic fonts in the Noto family).

Seven weights of Noto Serif CJK

It supports vertical text layout and is compliant with the Unicode vertical text layout
standard. The shape, orientation, and position of particular characters
(e.g., brackets and kana letters) are changed when the writing direction of
the text is vertical.

The sheer size of this project also required regional expertise! Glyph design
would not have been possible without leading East Asian type foundries Changzhou
SinoType Technology, Iwata
Corporation, and Sandoll Communications.

Noto Serif CJK is open source under the SIL Open
Font License, Version 1.1. We invite individual users to install and use
these fonts in their favorite authoring apps; developers to bundle these fonts
with your apps, and OEMs to embed them into their devices. The fonts are free
for everyone to use!

At Google, we're mindful of keeping our users' data and account information
secure. So whether you're writing an app that requires access
to user data or helping your users change
their passwords, we'll keep you up-to-date on policy changes, and now today,
when it comes to consent and 3rd-party applications. Starting April 5,
2017, if you're an application developer or a 3rd-party Single Sign-On
(SSO) provider, your G Suite users may encounter a redirect when they
authenticate with your identity service to make it clear to users which account
they're authenticating as well as the permissions they're granting to
applications.

These changes will occur on these platforms:

Google and 3rd-party applications on iOS

Mobile browsers on iOS and Android

Web browsers (Chrome, Firefox and other modern browsers)

Note that Android applications that use the standard authentication libraries
are already prompting users to select appropriate account information, so
they're not impacted by these changes.

More visibility with new permission requests for your
application

It's important that your users are presented with account information and
credential consent, and apps should make this process easy and clear. One new
change that you may now see is that only non-standard permission requests will
be presented in the secondary consent screen in your application.

Currently when an application requests permissions, all of them are displayed
together. However, users should have greater visibility into permissions being
requested beyond the standard "email address" and "profile" consent. By clicking
to select their account, a user consents to these core permissions,. The
secondary consent screen will appear only if additional permissions are
requested by the application.

Only non-standard permissions will be presented in the secondary consent screen that the user must approve.

Along with these changes, your application name will be more visible to users,
and they can click-through to get your contact information. We
recommend application developers use a public-facing email address so that users
can quickly contact you for support or assistance. For more details, check
out this developer guide.

If your application may also be used by G Suite customers that employ a
3rd-party Single Sign-On (SSO) service, we recommend that you utilize the
hd
and/or login_hint parameters, if applicable. Even with the changes to
the 3rd-party SSO auth flow, these parameters will be respected if provided. You
can review the OpenID
Connect page in the documentation for more information.

An application that uses the hd parameter to specify
the domain name automatically

Changes coming for 3rd-party SSO redirection

G Suite users may also notice redirection when signing into 3rd-party SSO
providers. If no accounts are signed in, the user must confirm the account after
signing in to the 3rd-party SSO provider to ensure that they're signed in with
the correct G Suite account:

The end user who has just signed in with one Google account should select
that account as confirmation.

As mentioned, by clicking to the select their account, a user is opting into
"email address" and "profile" consent. Once the user consents to any additional
non-standard permissions that may be requested, they will be redirected back to
your application.

If the user is already signed in to one or more accounts that match the hd
hint, the Account Chooser will display all of the accounts and require the user
to select the appropriate G Suite account before being redirected to the
3rd-party SSO provider then back to your application:

A user who is signed into several Google accounts will be required to choose
the appropriate account.

See updates starting April 2017

These changes will help your users understand their permissions more clearly
across all platforms, whether they're using Google or a 3rd-party SSO provider
for authentication. We've started to roll out the new interstitial page on iOS
devices, and changes for browsers will begin to roll out starting April
5, 2017.

Mobile now accounts for over half of all web traffic1, making performance on
small screens more important than ever.

Despite this increase, a recent study by Google found that the average time it
takes to load a mobile landing page is 22 seconds. When you consider that 53% of
mobile site visitors will leave a site if it takes more than three seconds to
load, it's clear why conversion rates are consistently lower on mobile than
desktop.

Website visitors now expect their mobile experience to be as flawless as
desktop, and the majority of online businesses are failing to deliver.

With this in mind, we're introducing the new Google Mobile Sites certification.
Passing the Mobile Sites exam signals that you have a demonstrated ability to
build and optimize high-quality sites, and allows you to promote yourself as a
Google accredited mobile site developer.

Through codifying best practice in mobile site development, we hope to improve
the general standard of mobile design and speed, and make it easier to find the
best talent.

What the exam covers

To pass the exam, you'll need to show proficiency across mobile site design,
mobile UX best practice, mobile site speed optimization, and advanced web
technologies. We've put together a study
guide that covers everything you'll need to know.

What are the benefits?
We know that a lot of web developers are doing great work on mobile sites - this
certification is a way of promoting them to a wider audience. Being certified
means being recognized by Google as an expert in mobile site optimization, which
will make you more accessible and attractive to potential clients looking for a
good match for those services.

The certification will display on your Partners profile, helping you stand out
to businesses looking for mobile site development, and can also be shared across
social media.

How to sign up

Check out our study
guide to get started. Then, to take the exam, please click on the Mobile Sites
certification link and log in to your Google Partners account. If you're not
signed up yet, you can create a Partners user profile by registering here.

The exam is open to all web developers globally in English and, once completed,
the certification will remain valid for 12 months.