Author Archives: Google Devs

Using field masks with update requests to Google APIs

Originally posted on the G Suite Developers Blog
Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

We recently demonstrated how to use field masks to limit the amount of data that comes back via response payloads from read (GET) calls to Google APIs. Today, we'll focus on a different use case for field masks: update requests.

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:

"repeatCell": {
"range": {
"endRowIndex": 1
"cell": {
"userEnteredFormat": {
"textFormat": {
"bold": true
"fields": "userEnteredFormat/textFormat/bold",

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 the first post 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!

Expand your color palette with new tools for Material Design

Posted By: Rachel Been, Creative Lead, Material Design

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.

Test accessibility

Check if text is accessible on different-colored backgrounds, as measured using the Web Content Accessibility Guidelines legibility standards.

Preview your UI in color

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

Santa Tracker, open-sourced and delivered

Posted by Sam Thorogood, Developer Programs Engineer

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.

To get started, you can check out the code on GitHub at google/santa-tracker-weband google/santa-tracker-android. Both Web and Android versions include detailed build instructions.

On the Web

If you'd like to read about how the elves build Santa Tracker as an offline Progressive Web App, check out our Case Study on Google Developers. To download the source, head over to GitHub. Here are some highlights of the release-
  • 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 housein 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 great video content 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.

On Android

In 2016, Santa went on a diet, and reduced his APK download size by over 10mb—while adding four new games and a visual refresh. To learn more about our work, check out the in-depth analysis on Android Developers—or to try it yourself, head over to GitHub. Here are some highlights of this year's app-
  • 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.

Ho Ho Ho!

We hope you enjoy exploring Santa Tracker and its source code, and it inspires you to leverage the same approaches to make your own magical experiences!

Using field masks with Google APIs for partial response

Originally posted on the G Suite Developers Blog by Wesley Chun, Developer Advocate, G Suite

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):
     addresses = GMAIL.users().settings().sendAs().list(

Whether you’re using a Client Library (as our Python call) or using HTTP directly with GET, this is the payload you get back from the API:
"sendAs": [{
"sendAsEmail": string,
"displayName": string,
"replyToAddress": string,
"signature": string,
"isPrimary": boolean,
"isDefault": boolean,
"treatAsAlias": boolean,
"smtpMsa": {
"host": string,
"port": integer,
"username": string,
"password": string,
"securityMode": string
"verificationStatus": string
}, ...]

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 API without 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):
     addresses = GMAIL.users().settings().sendAs().list(
userId='me', fields='sendAs(sendAsEmail,isPrimary)'
Field masks filter our unnecessary data from Google API call responses.

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.

Noto Serif CJK is here!

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.
Traditional Chinese
Supports BIG5, and Traditional Chinese glyphs are compliant to glyph standard of Taiwan Ministry of Education (教育部國字標準字體).
Supports all of the kanji in  JIS X 0208, JIS X 0213, and JIS X 0212 to include all kanji in Adobe-Japan1-6.
The best font for typesetting classic Korean documents in Hangul and Hanja such as Humninjeongeum manuscript, a UNESCO World Heritage.
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 hiragkana 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!

    Noto Serif CJK font download:
    Noto Serif CJK on GitHub:
    Adobe's landing page for this release:
    Source Han Serif on GitHub:

    Updates to end user consent for 3rd-party apps and Single Sign-on providers

    Originally Posted on G Suite Developers Blog
    Posted by Rodrigo Paiva, Product Manager & Nicholas Watson, Software Engineer, Identity, and Wesley Chun, Developer Advocate, G Suite

    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 hdhint, 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.

    Introducing the Mobile Sites certification, for web developers

    Posted by Chris Hohorst, Head of Mobile Sites Transformation

    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.

    1 Google Analytics data, U.S., Q1 2016 from Find Out How You Stack Up to Industry Benchmarks for Mobile Page Speed

    A new issue tracker for G Suite developers

    Originally Posted on the G Suite Developers Blog
    Posted by Ryan Roth, Developer Programs Engineer & Wesley Chun, Developer Advocate, G Suite

    You may have read recently that the Google Cloud Platform team upgraded to Issue Tracker, the same system that Google uses internally. This allows for improved collaboration between all of us and all of you. Issues you file will have better exposure internally, and you get improved transparency in terms of seeing the issues we're actively working on. Starting today, G Suite developers will also have a new issue tracker to which we've already migrated existing issues from previous systems.

    Whether it's a bug that you've found, or if you wish to submit a favorite feature request, the new issue tracker is here for you. Heads up, you need to be logged in with your Google credentials to view or update issues in the tracker.

    The new issue tracker for G Suite developers.

    Each G Suite API and developer tool has its own "component" number that you can search. For your convenience, below is the entire list. You may browse for issues relevant to the Google APIs that you're using, or click on the convenience links to report an issue or request a new/missing feature:
    To get started, take a look at the documentation pages, as well as the FAQ. For more details, be sure to check out the Google Cloud Platform announcement, too. We look forward to working more closely with all of you soon!

    Game developers rejoice—new tools for developing on Actions on Google

    By Sunil Vemuri, Product Manager for Actions on Google

    Since we launchedthe Actions on Google platform last year, we've seen a lot of creative actions for use cases ranging from meditation to insurance. But one of the areas where we're especially excited is gaming. Games like Akinator to SongPop demonstrate that developers can create new and engaging experiences for users. To bring more great games online, we're adding new tools to Actions on Google to make it easier than ever for you to build games for the Google Assistant.

    First, we're releasing a brand new sound effect library. These effects can make your games more engaging, help you create a more fun persona for your action, and hopefully put smiles on your users' faces. From airplanes, slide whistles, and bowlingto cats purring and thunder, you're going to find hundreds of options that will add some pizzazz to your Action.

    Second, for those of you who feel nostalgic about interactive text adventures, we just published a handy guide on how to bring these games to life with the Google Assistant. With many old favorites being open source or in the public domain, you are now able to re-introduce these classics to Google Assistant users on Google Home.

    Finally, for those of you who are looking to build new types of games, we've recently expanded the list of tool and consulting companies that have integrated their development solutions with Actions on Google. New collaborators like Pullstring, Converse.AI, Solstice and XAPP Media are now also able to help turn your vision into reality.

    We can't wait to see how you use our sound library and for the new and classic games you'll bring to Google Assistant users on Google Home! Make sure you join our Google+ community to discuss Actions on Google with other developers.

    A New Home for Google Open Source

    Originally on Google Open Source Blog
    Posted by Will Norris, Open Source Programs Office

    Free and open source software has been part of our technical and organizational foundation since Google's early beginnings. From servers running the Linux kernel to an internal culture of being able to patch any other team's code, open source is part of everything we do. In return, we've released millions of lines of open source code, run programs like Google Summer of Code and Google Code-in, and sponsor open source projects and communities through organizations like Software Freedom Conservancy, the Apache Software Foundation, and many others.

    Today, we're launching, a new website for Google Open Source that ties together all of our initiatives with information on how we use, release, and support open source.

    This new site showcases the breadth and depth of our love for open source. It will contain the expected things: our programs, organizations we support, and a comprehensive list of open source projects we've released. But it also contains something unexpected: a look under the hood at how we "do" open source.

    Helping you find interesting open source

    One of the tenets of our philosophy towards releasing open source code is that "more is better." We don't know which projects will find an audience, so we help teams release code whenever possible. As a result, we have released thousands of projects under open source licenses ranging from larger products like TensorFlow, Go, and Kubernetes to smaller projects such as Light My Piano, Neuroglancerand Some are fully supported while others are experimental or just for fun. With so many projects spread across 100 GitHub organizations and our self-hosted Git service, it can be difficult to see the scope and scale of our open source footprint.

    To provide a more complete picture, we are launching a directory of our open source projects which we will expand over time. For many of these projects we are also adding information about how they are used inside Google. In the future, we hope to add more information about project lifecycle and maturity.

    How we do open source

    Open source is about more than just code; it's also about community and process. Participating in open source projects and communities as a large corporation comes with its own unique set of challenges. In 2014, we helped form the TODO Group, which provides a forum to collaborate and share best practices among companies that are deeply committed to open source. Inspired by many discussions we've had over the years, today we are publishing our internal documentation for how we do open source at Google.

    These docs explain the process we follow for releasing new open source projects, submitting patches to others' projects, and how we manage the open source code that we bring into the company and use ourselves. But in addition to the how, it outlines why we do things the way we do, such as why we only use code under certain licenses or why we require contributor license agreements for all patches we receive.

    Our policies and procedures are informed by many years of experience and lessons we've learned along the way. We know that our particular approach to open source might not be right for everyone—there's more than one way to do open source—and so these docs should not be read as a "how-to" guide. Similar to how it can be valuable to read another engineer's source code to see how they solved a problem, we hope that others find value in seeing how we approach and think about open source at Google.

    To hear a little more about the backstory of the new Google Open Source site, we invite you to listen to the latest episode from our friends at The Changelog. We hope you enjoy exploring the new site!