Google Developers Blog

From Code to Community: Why developers call DevFest home

2019-09-20T11:00:00.000-07:00

Ricardo Costeira is a Software Engineer from Coimbra, Portugal. For the first time last year, he attended DevFest, the largest developer community-led movement hosted by Google Developer Groups across the world. To celebrate DevFest 2019, we want to share with you Ricardo’s story and how he went from writing code to finding community.

Ricardo (left) and a fellow GDG Lead plan DevFest Coimbra.

1. How did you first hear about DevFest? What inspired you to join?

In 2018, after living in Coimbra for 3 years, I didn't have any friends outside of work that were software developers. I longed to fill my life with more people that understood my passion and decided it was time to make a change. So I took to social media to see how I could connect with more like minded thinkers. Eventually, DevFest showed up on my feed. Out of nowhere, I saw this crazy event in Coimbra packed with bold leaders, energizing speakers, and profoundly creative exercises. I never expected that being with a community would get me so excited. I got a ticket on the spot.

2. Can you tell us about your first experience at DevFest?

It was exhilarating - out of this world. When I first walked in, everyone talked to me as if we had known each other for years. Big smiles, loud laughs, and deep kindness were all around me. As someone who is relatively shy and a loner by nature, I was stunned when I felt myself saying, "I belong here, I'm home." That very same night, I looked up the next event I could attend. Since then, I have attended 2 other events, signed up for 6 more, and have become a GDG Lead. In other words, I’m hooked.

So how did this all change me? To be honest, DevFest brought forward a shift in my personality. I now want to be part of a community - that is a new feeling in my life.

“As someone who is relatively shy and a loner by nature, I was stunned when I felt myself saying, "I belong here, I'm home."

3. What from DevFest 2018 are you looking forward to seeing again this year?

The booths. DevFest Coimbra has booths where you can talk with different companies. It’s exciting to learn about all the opportunities to grow so close to home. In my case, it was thrilling to see just how quickly Portugal is scaling and how so many companies come to DevFest eager to talk with the best talent. Forming these relationships is what can make the difference when finding the right opportunity for you.

4. Leading up to DevFest 2019, what are you most excited for?

Lighting a spark in new attendees. I recently joined the organizational staff and I’m excited to give new attendees that feeling I had when I first walked into DevFest. I’ve found such meaning in working with my fellow GDG Leads to bring together attendees in a sense of shared awe.

5. Any advice for those attending DevFest 2019?

Just say hi. You will be surprised with how far it will take you. DevFest is not only about the talks or workshops, it’s also about the people. This community knows the extrovert and understands the introvert, and warmly welcomes both. That is to say, no matter who you are or how you code, there is a place for you here.

“DevFest is not only about the talks or workshops, it’s also about the people.”

Want to find a DevFest event near you? Check out devfest.withgoogle.com to join our community, meet other developers and learn about Cloud, Android, Flutter, Machine Learning and more.

#DevFest #Community

Get smart about preparing your app for OAuth verification

2019-09-18T11:00:00.000-07:00

Posted by Nafis Zebarjadi, Product Manager and Adam Dawes, Senior Product Manager

Project Strobe was started to help users have control over their data while giving developers more explicit rules of the road to ensure everyone is confident that their data is secure. One result of this effort has been to expand our app verification program to cover more apps and more types of data access. It is important to understand how the process works so that you can optimally build your app and streamline the verification process. Here we walk you through the process of preparing your app for OAuth verification.

Getting prepared for verification

The first thing you should do is confirm whether your app needs verification. App verification is only required if you want to launch your app widely to consumer or enterprise users and the app requests sensitive or restricted scopes. Apps that use non-sensitive scopes, are under development, or are built just for your own G Suite users are not required to go through verification. If the app is just for users within your own organization, choose the ‘Internal’ application type to restrict the app to use within your own organization and skip verification.

Once you initiate app verification, it is not easy to make updates to your app's Google API configuration. If you make any changes while in the process, you will need to start over again, so it’s critical that you get your app ready before initiating verification to avoid delays.

Determining if your app is using sensitive or restricted scopes

The first thing you need to do is look at your code on each platform to determine which OAuth scopes (Google APIs) your service needs. Be sure to do this on every client; we often see that apps will request different scopes on different platforms, and then initiate app verification on a subset of scopes than your clients actually use. Often, you can find the scopes by searching your code for the string “www.googleapis.com/auth”. Not all legacy scopes contain that string so you may also want to find the code related to the Google API library you’re using (on the specific platform) to see what scopes are being requested, or look at our directory of scopes.

Once you have identified all of the scopes that your apps use, you can check to see whether they are sensitive or restricted by going to the Cloud Console (APIs & Services -> Credentials -> OAuth consent screen -> Scopes for Google APIs) and pressing the ‘Add scope’ button. This will bring up the following window:

If the scope has a lock icon, it means that the scope is either sensitive or restricted and that you’ll need to go through app verification before you can widely launch to Google users.

[Note that the tool only lists scopes for APIs that you’ve enabled for your project. If you don’t see a scope listed, you’ll first need to enable the corresponding API for your project from the API Library. The fact that you’re not seeing the scope used in your code may mean that you have clients set up in different projects.]

Setting up the right project structure

Apps are reviewed and approved at the project level so you’ll want to make sure that you’ve configured your clients properly before starting app verification. If you have multiple projects, each one will have to independently go through app verification.

When to add multiple clients to a project: You may have multiple clients for your app to support different platforms like Android, Web and iOS. Ideally, all of these clients should be in the same project because it will smooth out the cross-client consent experience. When clients are in the same project, users only need to provide consent to one of the clients. Other clients can automatically get tokens without forcing the user to go through the consent flow for the same requested scopes again. The user is agreeing to share data with your service regardless of which platform they happen to be using and your service terms should be the same across platforms.

When to separate clients into separate projects: Your company may also have multiple apps that you publish to users. You may or may not want to host the clients related to your different apps in the same project. Generally, if the different apps use the same login system, have the same privacy policy and users recognize the brand of the publisher of all the apps, then it makes sense to have all the clients in the same project. For example, if PersonalFinance Corp has accounting, budgeting and tax apps that all share the same login, privacy policy and users recognize the PersonalFinance Corp brand, then it is best to structure those all in the same project. However, if CoolGames publisher has lots of titles that have different login systems and different privacy policies, or users are more familiar with the individual game titles than the CoolGames brand, then you should use separate projects.

Reorganizing projects: It is not possible to move or reorganize clients once they are created. If you want to make changes, you can either choose to create new clients in a centralized project or get each app verified independently. If you create new clients in a centralized project, you’ll update your apps to use the new client and abandon the old clients. The issue you may encounter with this approach is that your app may have to obtain user consent all over again (if the user hasn’t also consented to your other client). Alternately, you can leave your clients in separate projects; however, each project will have to go through app verification independently and users will have to consent to each of your clients individually.

Setting up test vs production projects: For many developers, it is also helpful to have a parallel test project to your production project. This allows you to easily change scopes or other app properties and test behavior without having to go through app verification.

Configuring your project

If your app does need to be verified, you’ll want to make sure the information about your project is up-to-date to avoid delay.

Project Owners

As we roll out changes across our API ecosystem, it is important to make sure your projects have up-to-date contact information. We often need to send notifications about changes, and have had developers miss important updates because of incorrect contact information which has resulted in their app being unexpectedly disabled. One way to help ensure your team gets notifications is to create a Google Group that aliases to a stable group within your company (and be sure to configure the group to receive emails from non-members). Another option is to create an Organizational Resource in the Cloud Console so that your client assets can be centrally administered and recovered when owners leave the company. It’s also very good practice to ensure the owners of the Android/iOS/Web clients are also owners or editors of the project. Domain verification is also required for every app, so you will also want to add your DNS administrator to the project so that person can easily go through the process.

To update project owners, use Cloud IAM in the Cloud Console (Cloud Console -> IAM and admin -> IAM).

Branding Info and Domain Verification

Branding info includes your app’s name and logo. It is critical that these are accurate because users use these to decide whether they know and trust your app. In the verification process, we will validate that you own the brand and logo and that it matches the information on your web site. If you make changes, your previously approved branding will continue to be shown until the new information can be verified.

You will also need to verify the domain associated with your brand. This is true even if you only have Android/iOS versions of your app because you must have a website to publicly host your privacy policy. You start the domain verification process by linking your domain to your project in the Cloud Console (APIs & Services -> Domain verification). You’ll then need to go to the Search Console to prove that you own and control the domain.

Domain verification is a key security feature for your web clients. If you have web clients in your project, each of those must have their Authorized Redirect URIs or Authorized JavaScript Origins match an already verified domain. This enables us to guarantee that OAuth tokens are only returned to your application.

Scopes

Since you’ve already identified the scopes that your app uses, you should now check to see if you can change scopes to minimize your data access. Our API User Data Policy requires that you only request information that your app needs and that you’re clear to the user about how you will use it. It’s inappropriate to gain access to Google user data for alternate purposes such as advertising and market research.

In particular, you’ll want to try to avoid the use of restricted scopes. The verification process for restricted scopes can take several weeks longer than sensitive scopes. It also requires significant documentation and may involve a third-party security assessment that you must pay for. Currently, only specific Gmail scopes are restricted, but we have announced that most Drive scopes are also becoming restricted in early 2020.

If your app does need to access a restricted scope, consider architecting your app such that the Google user data is only ever stored client-side on the user’s device (like a contact manager app). Storing data in the cloud or on your own servers will require you to obtain a third-party security assessment (at your expense), and could also result in significant work to resolve any security issues found during the assessment.

Once you’ve decided on the scopes your app will need, make sure that they are registered with your project and reflected in your app’s code. We’ve seen many cases where a developer’s code calls a different set of scopes than those that have been registered in the Cloud Console. If your app does this, your users will see an unverified app error. Many developers request troubleshooting help because their users are unexpectedly seeing these errors even though their app was approved. Inevitably, it is because their code does not match what was verified. Similarly, if you need to add new scopes to your application, you’ll need to get those scopes approved before you launch the functionality into your production app (a test client is going to be essential here).

While you’re thinking about scopes, you should also consider how and when you are asking your users for consent. The best practice is to not request scopes at sign-in, but to use incremental authorization to allow a user to access a particular feature when they want it. This is a great way to build trust because the user interacts in a particular feature, can see the benefit of the feature, and understands why granting a particular permission will make the feature more useful.

Privacy Policy

Our goal in verifying apps is to ensure that any data users choose to share with third-parties is well-managed and meets users’ expectations about how it will be used. Your privacy policy is your public contract to your users and a critical proof to us that users’ expectations will be met.

You must include a link to your privacy policy on your website. If the domain where you host that policy isn’t verified, we won’t verify your app. If your app is purely mobile, with no server-side component, you will still need a privacy policy, but it may be very simple and describe that your app only stores data on a user’s device.

Google can not provide guidance on your privacy policy, but if your app requests restricted scopes, we will scrutinize your policy to understand how you plan to use that data and ensure that it conforms to our requirements. Make sure you understand the Limited Use requirements, and consult with your legal counsel to ensure that your privacy policy is consistent with the requirements. To ensure clarity in how your app handles email content, we also recommend adding the following statement to your application’s home page: “App’s use of information received from Gmail APIs will adhere to Google's Limited Use Requirements.” This is needed when your privacy policy is not specific in how email content is used.

Submitting your app for verification

Once you have your project(s) configured with all the appropriate information, you can submit your app for verification. We have three different types of app verification depending on the scopes you request, each taking a different amount of time to complete. If you start your verification with one set of scopes and later decide you need different scopes, you usually need to finish your existing verification before you can start the process again. This could cause frustration and lengthen your overall verification process.

Brand Verification (2-3 days)

Brand Verification is our simplest process and validates that your brand name and logo belong to you. It is an optional step if your app is requesting non-sensitive scopes like Google Sign-In and typically takes just 2 to 3 business days. If your app doesn’t go through brand verification, users will only see your domain name listed on the consent page.

Sensitive Scope Verification (3-5 days)

Starting in June 2019, we greatly expanded the classification of sensitive scopes and started requiring more extensive verification for new apps that are accessing those scopes. Existing apps that are already accessing sensitive scopes need to go through this verification process in the latter half of 2019.

Sensitive scope verification involves brand and domain validation, checking that the privacy policy is prominently available from your application home page. We also review your app and privacy policy against our API Services: User Data Policy and check for deceptive practices. The privacy policy must disclose the manner in which your application accesses, uses, stores, or shares Google user data. Your use of Google user data must be limited to the practices disclosed in your published privacy policy.

A YouTube or accessible Drive video will also be required to understand how users will experience your request for scopes, showing specifically how they’ll benefit from granting you access. The identity of your app needs to be clear from the video (including the app’s client ID), and you’ll need to highlight the value proposition you communicate to the user before requesting the scopes.

Until verification is completed, users will see an unverified app page when your app requests a scope requiring verification. Up to 100 users may choose to grant access while your app is unverified. After that, users will be blocked from granting access to your app until verification is complete.

Sensitive scope verification usually takes 3 to 5 business days if there aren’t any issues with your app.

Restricted Scope Verification (4-6 weeks)

Restricted scope verification is a much more involved process. In addition to going through all the steps for a sensitive scope verification, your app will also have a much more rigorous privacy policy review to ensure that your use of Google user data conforms to our Limited Use requirements. Only permitted application types will be considered for access to restricted scopes. Finally, if your app stores data on a server, you will need to pass an annual security assessment.

We do error validation before allowing you to click the ‘Submit for Verification’ button. Here are some common reasons why the button is not clickable:

No verified domain
Privacy policy URL, authorized redirect URIs or origins for your client do not match an authorized domain
No new scopes added to the project that require verification

When you submit your app for verification, you will need to provide a written explanation for why your app needs the requested scopes. This explanation should include the nature of the feature and how the user will benefit from using it. It’s also best to include a link to your YouTube video in the original submission to save some back and forth with the review team.

You’ll also be asked again what email should receive questions and notifications about the verification process. Make sure you provide an address that you pay attention to and can receive emails from outside your domain. Questions will go to the person who initiated verification (not necessarily project owners) and the contact email address provided in the verification form. We’ve seen many requests delayed because the developer hasn’t responded to questions from the verification team.

Responding to verification questions

Apps with sensitive and restricted scopes often need to answer questions from the verification team. If you believe it has taken a long time to get a response from the verification team, you should search your inbox for messages from ‘api-oauth-dev-verification-reply’ to ensure that you haven’t missed anything.

By following these guidelines for submitting your app for verification, you can greatly streamline the process of getting your app approved and released to the Google user community. If you have any follow-up questions, be sure to scan the OAuth API Verification FAQ.

ARCore updates to Augmented Faces and Cloud Anchors enable new shared cross-platform experiences

2019-09-12T09:00:00.000-07:00

Posted by Christina Tong, Product Manager, Augmented Reality

Two years ago, we launched ARCore, our developer platform for building augmented reality (AR) experiences. Since then, we’ve seen developers create thousands of AR apps across Android and iOS that transform the way people play, shop, learn and create together. To enable even more shared cross-platform AR experiences, we’re announcing new updates to ARCore’s Augmented Faces and Cloud Anchors APIs.

Augmented Faces on iOS

Earlier this year, we announced our Augmented Faces API, which offers a high-quality, 468-point 3D mesh that lets users attach fun effects to their faces — all without a depth sensor on their smartphone. With the addition of iOS support rolling out today, developers can now create effects for more than a billion users. We’ve also made the creation process easier for both iOS and Android developers with a new face effects template.

Improvements to Cloud Anchors

Last year, we introduced the Cloud Anchors API, which lets developers create shared AR experiences across Android and iOS. Cloud Anchors let devices create a 3D feature map from visual data onto which anchors can be placed. The anchors are hosted in the cloud so multiple people can use them to enable shared real world experiences. Cloud Anchors power a wide variety of cross-platform apps, like Just a Line, PHAROS AR and Spacecraft AR.

In our latest ARCore update, we’ve made some improvements to the Cloud Anchors API that make hosting and resolving anchors more efficient and robust. This is due to improved anchor creation and visual processing in the cloud. Now, when creating an anchor, more angles across larger areas in the scene can be captured for a more robust 3D feature map. Once the map is created, the visual data used to create the map is deleted and only anchor IDs are shared with other devices to be resolved. Moreover, multiple anchors in the scene can now be resolved simultaneously, reducing the time needed to start a shared AR experience.

These updates to Cloud Anchors are available for developers today.

Persistent Cloud Anchors and Call for Collaborators

As we look to the future, we’re taking steps to expand the scale and timeline of shared AR experiences with persistent Cloud Anchors. We see this as enabling a “save button” for AR, so that digital information overlaid on top of the real world can be experienced at anytime.

Imagine working together on a redesign of your home throughout the year, leaving AR notes for your friends around an amusement park, or hiding AR objects at specific places around the world to be discovered by others.

Persistent Cloud Anchors are powering Mark AR, a social app being developed by Sybo and iDreamSky that lets people create, discover, and share their AR art with friends and followers in real-world locations. With persistent Cloud Anchors, users can continuously return back to their pieces as they create and collaborate over time.

Mark AR is an app that lets people create and discover AR art in real-world locations.

Reliably anchoring AR content for every use case—regardless of surface, distance, and time—pushes the limits of computation and computer vision because the real world is diverse and always changing. By enabling a “save button” for AR, we’re taking an important step toward bridging the digital and physical worlds to expand the ways AR can be useful in our day-to-day lives.

We’re currently looking for more developers to help us explore and test persistent Cloud Anchors in real world apps at scale, before making the feature broadly available. If you’re interested in early access, you can apply here.

Flutter news from GDD China: uniting Flutter on web and mobile, and introducing Flutter 1.9

2019-09-10T07:00:00.000-07:00

Posted by Chris Sells, PM for the Flutter developer experience

This week is a big one for Flutter! Today, at Google Developer Days, our flagship conference for Chinese developers, we used the keynote to announce our latest stable release: Flutter 1.9. This release is our biggest update yet with more than 1,500 PRs from more than 100 contributors. The new features and updates span a wide range, from support for macOS Catalina and iOS 13 to improved tooling support, as well as new Dart language features and new Material widgets.

At the keynote, we also announced a major milestone for Flutter’s web support, with the successful integration of Flutter’s web support into the main Flutter repository, allowing developers to write for mobile, desktop and web with the same codebase. And we showcased Tencent, one of the largest worldwide internet brands, who are using Flutter in a growing number of their mobile apps.

Let’s take a deeper look at this week’s news, starting with what’s new in Flutter 1.9.

Supporting macOS Catalina and iOS 13

As Apple prepares to release Catalina, the latest version of macOS, we’ve worked hard to make sure that Flutter is ready for you to upgrade. We’ve updated the end-to-end tooling experience to ensure it works well on Catalina and with Xcode 11. This includes adding support for the new Xcode build system, enabling 64-bit support throughout the toolchain, and simplifying platform dependencies.

With iOS 13 on the way, we’ve also been working to ensure your Flutter apps look great on the latest iPhone release. Flutter 1.9 includes an implementation of the iOS 13 draggable toolbar, with both long-press and drag-from-right, and supports vibration feedback. Work on iOS dark mode is also well underway with a number of pull requests already merged.

Finally, in the latest development builds, you can now turn on experimental support for Bitcode, which is Apple’s platform-independent intermediate representation of a compiled program. Submitting your app as Bitcode allows Apple to optimize your binary in the future without resubmission, and opens the door to Flutter potentially supporting platforms like watchOS and tvOS that require Bitcode for app submission.

New Material widgets

The Material components and features also get an upgrade in Flutter 1.9. Material is one of the world’s leading open-source design systems, providing a comprehensive, flexible set of building blocks for implementing interactive user experiences across many platforms.

In this release, we provide several new widgets including ToggleButtons (left) and ColorFiltered (right).

The ToggleButtons widget bundles a row of ToggleButton widgets together, often composed of a set of Icon and Text widgets, to form a set of buttons with fully customizable look and behavior. Do you want single selection or multi-select? Do you want to require at least one selection or allow none? Do you want square or rounded edges, thick or thin borders, icons or text, etc? You can see some of these options above on the left and see how they’re implemented in the ToggleButtons sample.

As shown in the image above on the right, the ColorFiltered widget allows you to recolor a tree of child widgets just like you can recolor an image using one of several different algorithms (some of which are shown in the example screenshot above). This has many uses, for example, handling color blindness accessibility issues for your users. To see this in action, check out the ColorFiltered sample.

Worldwide language support

We’ve also added support for 24 new languages, from Afrikaans to Zulu.

Dart 2.5 release

The end-to-end developer experience depends not just on the features of Flutter but also on the underlying language itself. As part of the Flutter 1.9 release, we are also releasing Dart 2.5. Dart 2.5 includes a pre-release of Foreign Function Interface (FFI) support, providing native extensions so Dart can call directly into code written in C. It also introduces machine learning-powered code completions for the IDE. You can learn about both of these and more in the Dart 2.5 announcement.

Toolchain improvements

With this release, new projects default to Swift instead of Objective-C and Kotlin instead of Java for iOS and Android projects respectively. Since many packages are written with Swift, making it the default language removes manual work for adding those packages to an app created with the default options. Swift 5 is ABI stable, and thanks to app thinning work Apple has done in recent releases, the Swift dynamic libraries no longer need to be included in the distribution package for iOS 12.2 or greater, reducing the size of Swift applications compared to previous releases.

And as Kotlin is now the default language for new projects in Android Studio, it seems natural to make the language switch for Android also. These options are now the default for both the flutter CLI tool and the IntelliJ/Android Studio and VS Code plugins for Flutter, but you can always switch back to Objective-C or Java if you prefer.

Additionally, we’ve been working to improve Flutter’s error messages by making them more readable, more concise and more actionable.

The Flutter User Experience team has led the charge on this project; you can read the details in a separate blog post covering the work on structured error display. We’ve just started to apply these new patterns, and you can expect more error messages to take advantage of this work in coming releases.

Flutter on the web

And finally, we are very happy to announce that the flutter_web repository is deprecated now that web support has been merged into the main flutter repository! What this means is that if you have the latest builds of Flutter from the master or dev channel, you can target the web with the latest experimental version of Flutter by running flutter run -d chrome.

When you create a project, Flutter now creates a web runner via a minimal web/index.html file that bootstraps your web-compiled Flutter code. With that file in place, you can use the Flutter CLI tool or the IDE plugins to edit and run Flutter apps on the web.

Above is a screenshot of VS Code with web support enabled for Flutter. Notice the web/index.html file, along with the dropdown list allowing you to choose Chrome as your target development device. Support for web output with Flutter is still at an early phase, but this release represents a major step forward towards enabling production support for web development with Flutter.

At the end of July, we announced an early adopter program designed to get a group of select Flutter applications deployed to production on the web over the next six to twelve months. We received over 1,000 submissions to the program. Unfortunately, we don’t have the capacity to support everyone who applied to join the program, but now web support is merged into the Flutter framework, we’re excited that everyone can now experiment with this capability.

Some community experiments have already showcased Flutter’s web output:

Flutter Widget Livebook (left) is built with Flutter for web and shows Flutter widgets running live in your browser. Panache (right) is a tool for creating themes for Flutter which you can then download and drop directly into your code.

Please give this updated experimental support for Flutter on the web a try and let us know if you have any feedback.

Community

We’re thrilled to see continuing fast growth and adoption of for Flutter. Here at Google, hundreds of developers are working on more than twenty projects using Flutter, including some that are released and many that are still in development. At GDD China this week, we highlighted how Tencent, one of the largest internet brands, is using Flutter pervasively for a wide variety of projects:

Switching gears to something just for fun, if you have Google Assistant on your phone or one of the Google Nest Hub devices, try saying “OK Google. Talk to Flutter Widget Quiz.” We loved seeing this community-powered quiz that tests your knowledge of Flutter.

Conclusion

We love the support we’ve received from the developer community, whether in the form of blogs and articles, published apps or issues and code contributions. For more details on upgrading to Flutter 1.9, including details on how to fix any breaking changes that you might experience as you migrate your code, check out the detailed Flutter 1.9 release notes.

There’s a ton for you to try with this release, from trying out the new dart:ffi or ML-based code completion features to experimenting with Flutter for web; from the new support for Catalina and iOS 13 and new ToggleButtons and ColorFilter widgets to testing yourself on your Flutter widget knowledge.

Now that you’ve got Flutter 1.9 in your hands, we’re excited to see what you will build with it!

Enabling developers and organizations to use differential privacy

2019-09-05T03:00:00.000-07:00

Posted by Miguel Guevara, Product Manager, Privacy and Data Protection Office

Whether you're a city planner, a small business owner, or a software developer, gaining useful insights from data can help make services work better and answer important questions. But, without strong privacy protections, you risk losing the trust of your citizens, customers, and users.

Differentially-private data analysis is a principled approach that enables organizations to learn from the majority of their data while simultaneously ensuring that those results do not allow any individual's data to be distinguished or re-identified. This type of analysis can be implemented in a wide variety of ways and for many different purposes. For example, if you are a health researcher, you may want to compare the average amount of time patients remain admitted across various hospitals in order to determine if there are differences in care. Differential privacy is a high-assurance, analytic means of ensuring that use cases like this are addressed in a privacy-preserving manner.

Today, we’re rolling out the open-source version of the differential privacy library that helps power some of Google’s core products. To make the library easy for developers to use, we’re focusing on features that can be particularly difficult to execute from scratch, like automatically calculating bounds on user contributions. It is now freely available to any organization or developer that wants to use it.

A deeper look at the technology

Our open source library was designed to meet the needs of developers. In addition to being freely accessible, we wanted it to be easy to deploy and useful.

Here are some of the key features of the library:

Statistical functions: Most common data science operations are supported by this release. Developers can compute counts, sums, averages, medians, and percentiles using our library.
Rigorous testing: Getting differential privacy right is challenging. Besides an extensive test suite, we’ve included an extensible ‘Stochastic Differential Privacy Model Checker library’ to help prevent mistakes.
Ready to use: The real utility of an open-source release is in answering the question “Can I use this?” That’s why we’ve included a PostgreSQL extension along with common recipes to get you started. We’ve described the details of our approach in a technical paper that we’ve just released today.
Modular: We designed the library so that it can be extended to include other functionalities such as additional mechanisms, aggregation functions, or privacy budget management.

Investing in new privacy technologies

We have driven the research and development of practical, differentially-private techniques since we released RAPPOR to help improve Chrome in 2014, and continue to spearhead their real-world application.

We’ve used differentially private methods to create helpful features in our products, like how busy a business is over the course of a day or how popular a particular restaurant’s dish is in Google Maps, and improve Google Fi.

This year, we’ve announced several open-source, privacy technologies—Tensorflow Privacy, Tensorflow Federated, Private Join and Compute—and today’s launch adds to this growing list. We're excited to make this library broadly available and hope developers will consider leveraging it as they build out their comprehensive data privacy strategies. From medicine, to government, to business, and beyond, it’s our hope that these open-source tools will help produce insights that benefit everyone.

Acknowledgements

Software Engineers: Alain Forget, Bryant Gipson, Celia Zhang, Damien Desfontaines, Daniel Simmons-Marengo, Ian Pudney, Jin Fu, Michael Daub, Priyanka Sehgal, Royce Wilson, William Lam

Developer Student Clubs: A Walk That Changed Healthcare

2019-08-21T11:00:00.000-07:00

Posted by Erica Hanson, Program Manager

ARUA, UGANDA - Samuel Mugisha is a 23 year old university student with a laugh that echoes off every wall and a mind determined to make change. Recently he heard from a healthcare worker that many children at a local clinic were missing vaccinations, so he decided to take a walk. He toured his community, neighbor to neighbor, and asked one simple question: “Can I see your vaccination card?”

In response he was given dirt stained, wrinkled, torn pieces of paper, holding life or death information - all written in scribble.

He squinted, held the cards to the light, rubbed them on his pant leg, but for no use. They were impossible to read. As Samuel put it, “They were broken.”

From the few cards he could read, Samuel noted children who had missed several vaccinations - they were unknowingly playing the odds, waiting to see if disease would find them.

“Looking through the cards, you could tell these kids had missed several vaccinations.”

Without hesitation, Samuel got right to work, determined to fix the healthcare system with technology.

He first brought together his closest friends from Developer Student Clubs (DSC), a program supporting students impacting their communities through tech. He asked them: “Why can’t technology solve our problem?”

This newly formed team, including Samuel, Joshwa Benkya and Norman Acidri, came up with a twofold plan:

Create a mobile app to replace the broken cards, so healthcare workers can clearly track which vaccines their young patients have received.
Create a notification to alert healthcare workers when a child is due for a new vaccination.

The idea came together right as Developer Student Clubs launched its first Solution Challenge, an open call for all members to submit projects they recently imagined. These young developers had to give it a shot. They created a model, filled out an application, and pitched the idea. After waiting a month, they heard back - their team won the competition! Their idea was selected from a pool of 170 applicants across India, Africa, and Indonesia. In other words, everything was about to change.

In a country where talent can go unnoticed and problems often go unsolved, this new team had pushed through the odds. Developer Student Clubs is a platform for these types of bold thinkers. Students who view the issues of their region not simply as obstacles to overcome, but chances to mend their home, build a better life for themselves, and transform the experiences of their people.

The goal of the Solution Challenge, and all other DSC programs, is to educate young developers early and equip them with the right skills to make an impact in their community.

In this case, office space in Uganda was expensive and hard to find. Samuel’s team previously had few chances to all work under the same roof. After winning the challenge, Developer Student Clubs helped them find a physical space of their own to come together and collaborate - a simple tool, but one that led to a turning point. As Samuel described it,

“Developer Student Clubs helped us not be alone and apart from each other while trying to solve this problem. They gave us the space to come together and learn. We could all be in the same room, thinking together.”

With this new space to work, DSC then brought some of Africa’s best Google Developer Group Leads directly to the young developers. In these meetings, the students were given high-level insights on how to best leverage Android, Firebase, and Presto to propel their product forward. As Samuel put it:

“If we wanted to learn something, they gave us the best expert.”

As a result, the team realized that with the scarcity of internet in Uganda, Firebase was the perfect technology to build with - allowing healthcare workers to use the app offline but “check in” and receive updates when they were able to find internet.

Although the app has made impressive strides since winning the competition, this young team knows they can make it even better. They want to improve its usability by implementing more visuals and are working to create a version for parents, so families can track the status of their child’s vaccination on their own.

While there is plenty of work ahead, with these gifted students and Developer Student Clubs taking each step forward together, any challenge seems solvable.

What has the team been up to recently? From August 5th-9th they attended the Startup Africa Roadtrip, an intensive training week on how best to refine a startup business model.

The Speed Benefit of AMP Prerendering

2019-08-14T10:00:00.000-07:00

Posted By Eric Steinlauf, Software Engineer, Google

Today we want to walk through some updated analysis on the benefit that prerendering can provide on load times. AMP is designed to reduce page load time, and one of the most important ways Google Search reduces page load time is through privacy-preserving-prerendering AMP documents before a link is clicked.

First Viewport Ready

The AMP framework has been designed to understand the layout of all page content and the loading status of all resources, so it can determine the time when all "above the fold" content has loaded. It also knows when the document is prerendered and when it is displayed. Thus, the AMP framework can compute the time from click until the above the fold content is displayed. AMP measures page load speed with a custom metric called First Viewport Ready (FVR). This is defined as the point in time "when non-ad resources above the fold fired their load event measured from the time the user clicks (So takes pre-rendering into account)". If an AMP document is fully prerendered this metric will be 0. If prerendering was not complete at the time of click or if the document was not prerendered at all, then the metric will be greater than 0.

Google Search prerenders some AMP documents and not others so we are able to see the impact that prerendering has on FVR. The chart below shows percentiles for FVR with and without prerendering. FVR is 0 when the AMP framework successfully completes prerendering before the document is displayed.

First Contentful Paint

First Contentful Paint (FCP) is a page load speed metric that is measured by the browser. It is available for all documents, not just AMP documents. FCP is the point in time when the first bit of content from the DOM is rendered. A high value for FCP indicates that a page is definitely slow, but a low value for FCP does not necessarily mean that a page loads quickly since the first bit may not be important content. This is useful, but since AMP has a better understanding of what content is visible, FVR gives a better understanding of when content becomes visible.

FCP is not aware of prerendering so AMP computes a prerender sensitive derivative metric, Prerender-adjusted First Contentful Paint (PFCP), that subtracts out the time before click. When not prerendered, PFCP = FCP. FCP also decreases with prerendering, but the difference is less dramatic than FVR.

It may be surprising that median prerendered PFCP is higher than median prerendered FVR. This happens because the browser has to draw the content to the screen after the click. PFCP includes that time, while FVR does not.

Conclusion

Prerendering AMP documents leads to substantial improvements in page load times. Page load time can be measured in different ways, but they consistently show that prerendering lets users see the content they want faster. For now, only AMP can provide the privacy preserving prerendering needed for this speed benefit. In the future, new web platform features, such as Signed Exchanges, will bring privacy-preserving instant loading to non-AMP documents too.

Coral summer updates: Post-training quant support, TF Lite delegate, and new models!

2019-08-06T10:00:00.000-07:00

Posted by Vikram Tank (Product Manager), Coral Team

Coral’s had a busy summer working with customers, expanding distribution, and building new features — and of course taking some time for R&R. We’re excited to share updates, early work, and new models for our platform for local AI with you.

The compiler has been updated to version 2.0, adding support for models built using post-training quantization—only when using full integer quantization (previously, we required quantization-aware training)—and fixing a few bugs. As the Tensorflow team mentions in their Medium post “post-training integer quantization enables users to take an already-trained floating-point model and fully quantize it to only use 8-bit signed integers (i.e. `int8`).” In addition to reducing the model size, models that are quantized with this method can now be accelerated by the Edge TPU found in Coral products.

We've also updated the Edge TPU Python library to version 2.11.1 to include new APIs for transfer learning on Coral products. The new on-device back propagation API allows you to perform transfer learning on the last layer of an image classification model. The last layer of a model is removed before compilation and implemented on-device to run on the CPU. It allows for near-real time transfer learning and doesn’t require you to recompile the model. Our previously released imprinting API, has been updated to allow you to quickly retrain existing classes or add new ones while leaving other classes alone. You can now even keep the classes from the pre-trained base model. Learn more about both options for on-device transfer learning.

Until now, accelerating your model with the Edge TPU required that you write code using either our Edge TPU Python API or in C++. But now you can accelerate your model on the Edge TPU when using the TensorFlow Lite interpreter API, because we've released a TensorFlow Lite delegate for the Edge TPU. The TensorFlow Lite Delegate API is an experimental feature in TensorFlow Lite that allows for the TensorFlow Lite interpreter to delegate part or all of graph execution to another executor—in this case, the other executor is the Edge TPU. Learn more about the TensorFlow Lite delegate for Edge TPU.

Coral has also been working with Edge TPU and AutoML teams to release EfficientNet-EdgeTPU: a family of image classification models customized to run efficiently on the Edge TPU. The models are based upon the EfficientNet architecture to achieve the image classification accuracy of a server-side model in a compact size that's optimized for low latency on the Edge TPU. You can read more about the models’ development and performance on the Google AI Blog, and download trained and compiled versions on the Coral Models page.

And, as summer comes to an end we also want to share that Arrow offers a student teacher discount for those looking to experiment with the boards in class or the lab this year.

We're excited to keep evolving the Coral platform, please keep sending us feedback at coral-support@google.com.

Discontinuing support for JSON-RPC and Global HTTP Batch Endpoints

2019-07-31T12:00:00.000-07:00

Updated by Shilpa Kamalakar, Technical Program Manager

We have invested heavily in our API and service infrastructure to improve performance and security and to add features developers need to build world-class APIs. As we make changes we must address features that are no longer compatible with the latest architecture and business requirements.

The JSON-RPC protocol (http://www.jsonrpc.org/specification) and Global HTTP Batch (example) are two such features. Our support for these features was based on an architecture using a single shared proxy to receive requests for all APIs. As we move towards a more distributed, high performance architecture where requests go directly to the appropriate API server we can no longer support these global endpoints.

We had originally planned to decommission these features by Mar 25, 2019. However, it came to our attention that few highly impacted customers might not have received the earlier notification.

As a result, we are extending the deprecation timeline to Aug 12, 2020, when we will discontinue support for both these features.

Starting February 2020 and running through August 2020, we will periodically inject errors for short windows of time. Closer to February 2020, we will provide exact details and schedule of these error injection windows.

We know that these changes have customer impact and have worked to make the transition steps as clear as possible. Please see the guidance below which will help ease the transition.

How do I know if I should migrate ?

JSON-RPC

To identify whether you use JSON-RPC, you can check whether you send requests to "https://www.googleapis.com/rpc" or "https://content.googleapis.com/rpc". If you do, you should migrate.

HTTP batch

A batch request is homogenous if the inner requests are addressed to the same API, even if addressed to different methods of the same API. Homogenous batching will still be supported but through API specific batch endpoints. If you are currently forming homogeneous batch requests, using Google API Client Libraries or using non-Google API client libraries or no client library (i.e making raw HTTP requests), you should migrate.

A batch request is heterogeneous if the inner requests go to different APIs. Heterogeneous batching will not be supported after the turn down of the Global HTTP batch endpoint. If you are currently forming heterogeneous batch requests, change your client code to send only homogenous batch requests, i.e you should migrate.

What do you need to do to migrate ?

Clients will need to make the changes outlined below to migrate.

JSON-RPC

Using Client Libraries

If you are using JSON-RPC client libraries (either the Google published libraries or other libraries), switch to REST client libraries and modify your application to work with REST client libraries.

Example code for Javascript
Before

// json-rpc request for the list method
gapi.client.rpcRequest('zoo.animals.list', 'v2',
  {name:'giraffe'}).execute(x=>console.log(x))

After

// json-rest request for the list method
gapi.client.zoo.animals.list({name:'giraffe'}).then(x=>console.log(x))

Not Using Client Libraries i.e making raw HTTP requests

If you are not using client libraries (i.e. making raw HTTP requests):

Use the REST URLs, and

Change how you form the request and parse the response.

Example code

Before

// Request URL (JSON-RPC)
POST https://content.googleapis.com/rpc?alt=json&key=xxx
// Request Body (JSON-RPC)
[{
  "jsonrpc":"2.0",
  "id":"gapiRpc",
  "method":"zoo.animals.list",
  "apiVersion":"v2",
  "params":{"name":"giraffe"}
}]

After

// Request URL (JSON-REST)
GET 
https://content.googleapis.com/zoo/v2/animals?name=giraffe&key=xxx

HTTP batch

Heterogeneous batch requests

If you are currently forming heterogeneous batch requests, change your client code to send only homogenous batch requests.

Example code
The example demonstrates how we can split a heterogeneous batch request for 2 apis (urlshortener and zoo) into 2 homogeneous batch requests.

Before

// heterogeneous batch request example.

// Notice that the outer batch request contains inner API requests
// for two different APIs.

// Request to urlshortener API
request1 = gapi.client.urlshortener.url.get({"shortUrl": 
"http://goo.gl/fbsS"});

// Request to zoo API
request2 = gapi.client.zoo.animals.list();

// Request to urlshortener API
request3 = gapi.client.urlshortener.url.get({"shortUrl":
"https://goo.gl/XYFuPH"});

// Request to zoo API
request4 = gapi.client.zoo.animal().get({"name": "giraffe"});

// Creating single heterogeneous batch request object
heterogeneousBatchRequest = gapi.client.newBatch();
// adding the 4 batch requests
heterogeneousBatchRequest.add(request1);
heterogeneousBatchRequest.add(request2);  
heterogeneousBatchRequest.add(request3);
heterogeneousBatchRequest.add(request4);
// print the heterogeneous batch request
heterogeneousBatchRequest.then(x=>console.log(x));

After

// Split heterogeneous batch request into two homogenous batch requests

// Request to urlshortener API
request1 = gapi.client.urlshortener.url.get({"shortUrl": "http://goo.gl/fbsS"});

// Request to zoo API
request2 = gapi.client.zoo.animals.list();

// Request to urlshortener API
request3 = gapi.client.urlshortener.url.get({"shortUrl": "http://goo.gl/fbsS"})

// Request to zoo API
request4 = gapi.client.zoo.animals.list();

// Creating homogenous batch request object for urlshorterner
homogenousBatchUrlshortener = gapi.client.newBatch();
// adding the 2 batch requests for urlshorterner
homogenousBatchUrlshortener.add(request1); 
homogenousBatchUrlshortener.add(request3); 

// Creating homogenous batch request object for zoo
homogenousBatchZoo = gapi.client.newBatch();

// adding the 2 batch requests for zoo
homogenousBatchZoo.add(request2); 
homogenousBatchZoo.add(request4);
// print the 2 homogenous batch request
Promise.all([homogenousBatchUrlshortener,homogenousBatchZoo])
    .then(x=>console.log(x));

Homogeneous batch requests

Google API client libraries

If you are using Google API Client Libraries, these libraries have been regenerated to no longer make requests to the global HTTP batch endpoint. Recommendation for clients using these libraries is to upgrade to the latest version if possible. Please see the language specific guidance below for minimum Google API Client Library to upgrade to.

1. Java

Minimum Google Client Library Version supported is 1.23.1.
Consumer Steps
1. Update all Google API Service packages (`com.google.apis`) to a version where the supporting library version is 1.23.1 or higher. For example, upgrade `com.google.apis:google-api-services-drive` from version `v3-rev159-1.22.0` to `v3-rev20190620-1.30.1`.
2. Please ensure you are creating your BatchRequest (i.e) com.google.api.client.googleapis.batch.BatchRequest instance via your service client. The BatchRequest constructor is now deprecated and will not work in the future. Instead, use your service client’s batch() method to create a new BatchRequest using below example
3. For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
4. Rebuild

2. Python

Minimum Google Client Library Version supported is 1.6.6.
Consumer Steps
- Update to version 1.6.6 or higher
- For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
- Rebuild
Please note, a warning is included if users try to construct a request with the legacy batch endpoint. See Release notes for reference.

3. PHP

Minimum Google Client Library Version supported is 0.86.
Consumer Steps
- Update to version 0.86 or higher
- For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
- Rebuild

4. .NET

Minimum Google Client Library Version supported is 1.32.2.
Consumer Steps
- Update to version 1.32.2 or higher
- For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
- Rebuild

5. Javascript

If you are using Javascript client lib, please reach out to us with your questions and we will do our best to support

6. Objective-C

Minimum Google Client Library Version supported is 1.3.0.
Consumer Steps
- Update to version 1.3.0 or higher
- For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
- Rebuild

7. Dart

The Google API Dart Client Library does not support these features.

8. Ruby

Minimum Google Client Library Version supported is 0.11.0.
Consumer Steps
- Update to version 0.11.0 or higher
- For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
- Rebuild

9. Node.js

Minimum Google Client Library Version supported is 1.0.
Consumer Steps
- Update to version 1.0 or higher
- For global batch, confirm that your code does not explicitly specify the global batch path (i.e. "/batch" at the end of the path). If it does, change it to refer to the api/version specific path (example "/batch/library/v1").
- Rebuild

10. Go

The Google API Go Client Library does not support these features.

11. C++

The Google C++ API Client Library has been deprecated due to unrelated reasons. However, should you need to use the C++ client with batching in the short term, see consumer steps below.
Consumer Steps
- Change app code to explicitly pass the non-global batch URL to the C++ client library i.e pass the API-version specific endpoint (example “/batch/library/v1") to the overload method that takes the batch endpoint as an explicit parameter; merely updating the C++ client library to the latest version will not help.
  Example code
  Before
```
HttpRequestBatch batch(service->transport());
```
  After
```
HttpRequestBatch batch(service->transport(), 
service->batch_url());
```
- Link, rebuild and redeploy

Non-Google API client libraries or no client library

If you are currently forming homogeneous batch requests and using non-Google API client libraries or no client library (i.e making raw HTTP requests), then:

Change the endpoint from www.googleapis.com/batch to www.googleapis.com/batch/<api>/<version>.
Or, simply read the value of 'batchPath' from the API's discovery doc and use that value.

Women Techmakers Summit Europe: Supporting Diversity & Inclusion in Tech

2019-07-31T10:05:00.001-07:00

Posted By Franziska Hauck and Katharina Lindenthal , Google Developer Relations Europe

Once a year, we invite community organizers and influencers from developer groups that support diversity and inclusion in their local tech ecosystem to the Women Techmakers Summit Europe. The Women Techmakers Summit is designed to provide training opportunities, share best practices, show success stories and build meaningful relationships. The fourth edition of the WTM Summit in Europe took place in Warsaw, one of Europe’s most innovative tech and startup ecosystems.

Such positive energy! All 120 attendees of the WTM Summit Europe 2019

Expertise from the Community for the Community

The Women Techmakers Summit hosted 120 people, all women and men that are leading tech communities across Europe. With more than half of the sessions being delivered by community influencers, the group came together to share their best practices, learn from each other and discuss all things related to diversity & inclusion. “A fantastic opportunity to meet other community organizers across Europe and learn from each other.”

We also invited role models to draw inspiration and motivation from. Head of Google for Startups, Agnieszka Hryniewicz-Bieniek, and Cloud Engineer, Ewa Maciaś, demonstrated that stepping out of our comfort zone is something we should do more and more. No one has the right answers from the start but by trying out new ways, we can carve our individual paths. Fear of failure is real. It should not keep us from experimenting, though.

Google’s Natalie Villalobos, head of the Women Techmakers program, and Emma Haruka Iwao, record breaker for calculating the most accurate value of Pi with Google Cloud, gave a glimpse into their personal stories. Their insights? Sometimes we need to go through hard times. They equipped us with the right mindset to push through, become your boss and succeed.

This left the attendees with the right motivation to get back to their communities: “This was my first WTM Summit, and it was an incredible experience. I met some amazing ladies and role models, and will be happy to share the inspiration I got with my local community.”

Googler Emma Haruka Iwao sharing her journey to break the world record for calculating the most accurate value of Pi

Building the Basis for Diversity and Inclusion

“Being at the WTM Summit felt like being inside a family. I felt really included like at no conference before." To make everyone feel welcome, a code of conduct was visible for all attendees, and prayers and parents spaces were provided for all attendees. The itself needed to become the inspiration for community organizers and influencers to carry the learnings back to the communities.

Organizers working together to develop best practices to foster diversity and inclusion in their tech communities

Women Techmakers: Changing the Narrative

One of the core elements of Women Techmakers is creating and providing community for women in tech. Women Techmakers Ambassadors thrive diversity and inclusion initiatives in their local tech community to help to bring more women into the industry. In Europe, more than 150 WTM Ambassadors from 25 countries support their local tech communities to close the gap between the number of women and men in the industry. Meetup organizers and community advocates who want to achieve parity can join the Women Techmakers program. As members, they are given the tools and opportunities to change the narrative.

If you are interested in joining the WTM Ambassadors Program, reach out to WTM-Europe@google.com

International Women's Day'19 featuring Actions on Google

2019-07-11T11:38:00.000-07:00

Posted by Marisa Pareti, Rubi Martinez & Jessica Earley-Cha

In celebration of International Women’s Day, Women Techmakers hosted its sixth annual summit series to acknowledge and celebrate women in the tech industry, and to create a space for attendees to build community, hear from industry leaders, and learn new skills. The series featured 19 summits and 305 meetups across 87 countries.

This year, Women Techmakers partnered with the Actions on Google team to host technical workshops at these events so attendees could learn the fundamental concepts to develop Actions for the Google Assistant.Together, we created hundreds of new Actions for the Assistant. Check out some of the highlights of this year’s summit in the video below:

Technical Workshop Details

If you couldn’t attend any of our meetups this past year, we’ll cover our technical workshops now so you can start building for the Assistant from home. The technical workshop kicked off by introducing Actions on Google — the platform that enables developers to build Actions for the Google Assistant. Participants got hands-on experience building their first Action with the following features:

Users can start a conversation by explicitly calling the Action by name, which then responds with a greeting message.
Once in conversation, users are prompted to provide their favorite color. The Action parses the user’s input to extract the information it needs (namely, the color parameter).
If a color is provided, the Action processes the color parameter to auto-generate a “lucky number” to send back to the user and the conversation ends.
If no color is provided, the Action sends the user additional prompts until the parameter is extracted.
Users can explicitly leave the conversation at any time.

During Codelab level 1, participants learned how to parse the user’s input by using Dialogflow, a tool that uses Machine Learning and acted as their Natural Language Processor (NLP). Dialogflow processes what the user says and extracts important information from that input to identify how to fulfill the user’s request. Participants configured Dialogflow and connected it to their code’s back-end using Dialogflow’s inline editor. In the editor, participants added their code and tested their Action in the Action Simulator.

In Codelab level 2, participants continued building on their Action, adding features such as:

Supports deep links to directly launch the user into certain points of dialog
Uses utilities provided by the Actions on Google platform to fetch the user’s name and address them personally
Responds with follow-up questions to further the conversation
Presents users with a rich visual response complete with sound effects

Instead of using Dialogflow’s inline editor, participants set up a Cloud Functions for Firebase as their server.

You can learn more about developing your own Actions here. To support developers’ efforts in building great Actions for the Google Assistant, the team also has a developer community program.

Alex Eremia, a workshop attendee, reflected, “I think voice applications will have a huge impact on society both today and in the future. It will become a natural way we interact with the items around us.”

From keynotes, fireside chats, and interactive workshops, the Women Techmakers summit attendees enjoyed a mixture of technical and inspirational content. If you’re interested in learning more and getting involved, follow us WTM on twitter, check out our website and sign up to become a member.

To learn more Actions on Google and how to build for the Google Assistant, be sure to follow us on Twitter, and join our Reddit community!

Developer Preview of Local Home SDK

2019-07-09T09:00:00.000-07:00

Posted by Toni Klopfenstein

Recently at Google I/O, we gave you a sneak peek at our new Local Home SDK, a suite of local technologies to enhance your smart home integrations. Today, the SDK is live as a developer preview. We've been working hard testing the platform with our partners, including GE, LIFX, Philips Hue, TP-Link, and Wemo, and are excited to bring you these additional technologies for connecting smart devices to the Google Assistant.

Figure 1: The local execution path

This SDK enables developers to more deeply integrate their smart devices into the Assistant by building upon the existing Smart Home platform to create a local execution path via Google Home smart speakers and Nest smart displays. Developers can now run their business logic to control new and existing smart devices in JavaScript that executes on the smart speakers and displays, benefitting users with reduced latency and higher reliability.

How it works:

The SDK introduces two new intents, IDENTIFY and REACHABLE_DEVICES. The local home platform scans the user's home network via mDNS, UDP, or UPnP to discover any smart devices connected to the Assistant, and triggers IDENTIFY to verify that the device IDs match those returned from the familiar Smart Home API SYNC intent. If the detected device is a hub or bridge, REACHABLE_DEVICES is triggered and treats the hub as the proxy device for communicating locally. Once the local execution path from Google Home to a device is established, the device properties are updated in Home Graph.

Figure 2: The intents used for each execution path

When a user triggers a smart home Action that has a local execution path, the Assistant sends the EXECUTE intent to the Google Nest device rather than the developer's cloud fulfillment. The developer's JavaScript app is invoked, which then triggers the Local Home SDK to send control commands to the smart device over TCP, UDP socket, or HTTP/HTTPS requests. By defaulting to local execution rather than the cloud, users experience faster fulfillment of their requests. The execution requests can still be sent to the cloud path in case local execution fails. This redundancy minimizes the possibility of a failed request, and improves the overall user experience.

Additional features of the Local Home platform include:

Support for all Wi-Fi-enabled device types and device traits without two-factor authentication enabled.
No user action required to deploy Local Home benefits to all devices.
Easily configure discovery protocols and the hosted JavaScript app URL through the Actions console.

Figure 3: Local Home configuration tool in the Actions console

JavaScript apps can be tested on-device, allowing developers to employ familiar tools like Chrome Developer Console for debugging. Because the Local Home SDK works with the existing smart home framework, you can self-certify new apps through the Test suite for smart home as well.

Get started

To learn more about the Local Home platform, check out the API reference, and get started adding local execution with the developer guide and samples. For general information covering how you can connect smart devices to the Google Assistant, visit the Smart Home documentation, or check out the Local Technologies for the Smart Home talk from Google I/O this year.

You can send us any feedback you have through the bug tracker, or engage with the community at /r/GoogleAssistantDev. You can tag your posts with the flair local-home-sdk to help organize discussion.

Google Pay and PayPal expand their integration to give merchants more ways to accept payments online

2019-06-20T09:48:00.000-07:00

Posted by Jose Ugia, Google Developers Engineer

We’re thrilled to announce we’ve expanded our collaboration with PayPal to make payments easy and seamless no matter how or where your customers like to shop. Now, you’ll be able to accept PayPal with Google Pay on your app or website in all 24 countries where your customers can link their PayPal account to Google Pay.

Here are 5 ways this integration can add value to your business:

1. Reach more customers already set up to pay

Hundreds of millions of users already have their payment methods saved to their Google Account. And as of 2018, customers who use their PayPal account to make a purchase on a Google app or service like Google Play and YouTube can automatically choose that PayPal account when they pay with Google Pay—no new setup required. When you enable PayPal as a payment method on your Google Pay integration, all of these customers will be able to seamlessly check out on your website or app.

Users will be able to choose PayPal—or any other payment method—right from the Google Pay payment sheet.

2. Deliver a faster checkout experience with more customer benefits

Once users link their PayPal account, they won’t need to sign in to PayPal when they use it with Google Pay. This means they’ll enjoy fewer steps at checkout, which often leads to higher conversion rates. In addition, your customers will get all the advantages that come with their PayPal account—like Purchase Protection and Return Shipping—along with Google Pay’s fast, simple checkout experience and increased security.

3. Give customers more choices at checkout

Google Pay lets customers keep all of their payment methods in one place. They’ll easily be able to switch between debit cards, credit cards, their PayPal account, and more just by choosing Google Pay at checkout.

4. Keep the benefits

PayPal merchants who enable the acceptance of PayPal through Google Pay can continue to get the PayPal benefits they already enjoy. This includes the ability to receive payments directly to their PayPal Business Account within minutes, no minimum processing requirements, and seller protection on eligible transactions.

5. Integrate with ease

If you’ve already implemented Google Pay, enabling PayPal is as easy as adding it to your list of allowed payment methods in the body of your requests:


const payPalPaymentMethod = {
  type: "PAYPAL",
  parameters: {
    purchase_context: {
      purchase_units: [{
        payee: {
          merchant_id: "<YOUR_PAYPAL_ACCOUNT_ID>"
        }
      }]
    }
  },
  tokenizationSpecification: {
    type: "DIRECT"
  }
};

paymentRequest.allowedPaymentMethods = [payPalPaymentMethod, cardPaymentMethod];

Once you’ve done that, you’ll receive a token you can send to your servers as soon as your customers confirm their transaction. You’ll use this token to issue a call against PayPal’s payment service—see PayPal’s documentation for more details and best practices.

If you haven’t implemented Google Pay yet, check out our online API introduction video or our step-by-step guided codelabs for Android and Web to learn more about it. If you prefer to explore on your own, read our documentation.

We’re excited to offer developers the best of both worlds with Google Pay and PayPal, all while making payments simpler for customers and businesses around the world. Stay tuned for more updates.

Mail merge with the Google Docs API

2019-06-05T11:50:00.000-07:00

Posted by Wesley Chun, Developer Advocate, Google Cloud

Students and working professionals use Google Docs every day to help enhance their productivity and collaboration. The ability to easily share a document and simultaneously edit it together are some of our users' favorite product features. However, many small businesses, corporations, and educational institutions often find themselves needing to automatically generate a wide variety of documents, ranging from form letters to customer invoices, legal paperwork, news feeds, data processing error logs, and internally-generated documents for the corporate CMS (content management system).

Mail merge is the process of taking a master template document along with a data source and "merging" them together. This process makes multiple copies of the master template file and customizes each copy with corresponding data of distinct records from the source. These copies can then be "mailed," whether by postal service or electronically. Using mail merge to produce these copies at volume without human labor has long been a killer app since word processors and databases were invented, and now, you can do it in the cloud with G Suite APIs!

While the Document Service in Google Apps Script has enabled the creation of Google Docs scripts and Docs Add-ons like GFormit (for Google Forms automation), use of Document Service requires developers to operate within the Apps Script ecosystem, possibly a non-starter for more custom development environments. Programmatic access to Google Docs via an HTTP-based REST API wasn't possible until the launch of the Google Docs API earlier this year. This release has now made building custom mail merge applications easier than ever!

Today's technical overview video walks developers through the concept and flow of mail merge operations using the Docs, Sheets, Drive, and Gmail APIs. Armed with this knowledge, developers can dig deeper and access a fully-working sample application (Python), or just skip it and go straight to its open source repo. We invite you to check out the Docs API documentation as well as the API overview page for more information including Quickstart samples in a variety of languages. We hope these resources enable you to develop your own custom mail merge solution in no time!

Google Pay launches new, dynamic features for Online Payments and Passes APIs

2019-06-04T13:00:00.000-07:00

Posted by Stephen McDonald, Google Developers Engineer and Jose Ugia, Google Developers Engineer

At Google I/O 2019, we shared some of the new features we’re adding to Google Pay and discussed how you can use them to add value to your customers—whether you accept payments on your app or website or engage with customers beyond payments through loyalty cards, offers, event tickets, and boarding passes.

Read on for a summary of what we covered during the event. If you want to hear the full story, check out the recordings of our sessions: Building Powerful Checkout Experiences with Google Pay and Engaging Customers Beyond Payments: Tickets, Transit, and Boarding Passes.

Making online payments even more seamless

Better checkout experiences are more likely to increase your conversions. Here’s a look at some of the ways Google Pay can help you improve your checkout process from start to finish.

Dynamic updates for faster checkout

In an effort to bring customers more detail and transparency, we’ve made some changes to the Google Pay API. Going forward, the Google Pay payment sheet will display pricing information, so customers can double-check their order before they confirm their purchase. We’re also adding modifiers based on transaction conditions (like shipping options), so customers can see all relevant purchase details quickly, without going back to the merchant site, leading to a faster checkout experience.

Users paying online can see the price of the order dynamically before they initiate the transaction.

More payment button options

Along with these improvements to the payment sheet, we’re offering creative new button and onboarding options to encourage customers to choose Google Pay for faster checkout. To start, we launched the createButton API for web developers. This enables a dynamic purchase button that uses the right styling and colors and is localized to your user’s device or browser settings. We’ve also been experimenting with personalized buttons that display important information before users enter the checkout flow. For instance, we can show customers exactly what card they’ll be paying with or let them know if they need to sign in or set up Google Pay – and this information is displayed right on the button. As the button is hosted and rendered by Google Pay, all of this happens without you having to make any changes.

createButton API allows to display card information directly on the checkout button

Delivering extra value with Google Pay Passes

The Google Pay API for Passes lets you connect your business to millions of Android users by linking your loyalty programs, gift cards, offers, boarding passes, and event tickets to their Google Accounts. This year, we’re launching new capabilities and integrations that will help you engage customers at more times and places.

High priority notifications for boarding passes

Your passengers can add their boarding pass to Google Pay for a seamless check-in experience. Google Pay sends the passengers a high priority notification with their boarding pass just a few hours before their flight so they can easily access it when needed. They’ll also receive notifications with important dynamic information like gate changes or flight delays. These notifications are high priority and will stay prominent on passengers’ phones until they dismiss it or their flight takes off.

Integration with the Google Assistant

Google’s ecosystem can help create complete user journeys across multiple touchpoints. Earlier this year, we announced the ability to check-in to flights directly from the Google Assistant. Once a flight is ready for check-in, your passenger will receive a notification that takes them directly to the Assistant to complete the process. At the end of this flow, the user is issued a boarding pass that can be accessed from the Assistant or from Google Pay. This is built on top of the Passes API, which means that as an airline, if you already added support for boarding passes, you can just add the check-in with the Assistant integration on top of it.

From left to right: new high priority notifications, integration of Myki card inside of Google Maps, new transit tickets and automatic Gmail import.

An open API for transit, with support for dynamic barcodes

We’re excited to announce we’re making transit an open API. This means if you’re a transit provider and currently offer barcode tickets for your transportation services, you can now utilize the Passes API to get your tickets digitized in Google Pay. We’ll also be enhancing this API to support dynamic barcodes. The barcodes on customers’ transit tickets or passes will update every few seconds – even if their device is offline. This allows you to increase security -- since your QR codes are changing all the time, it makes it harder to duplicate the ticket.

Loyalty Integration with Gmail

Now you can also give customers the opportunity to import your loyalty cards to Google Pay right from Gmail—just by adding some markup to your emails. When customers open the Google Pay app, they’ll be shown any loyalty cards from Gmail they haven’t added to Google Pay. With just a tap, they can add them all automatically so they can access them at any time. This feature is currently only available with loyalty programs, but we’ll be expanding to other types of passes in the future.

What’s next

We’re working on making Passes available to your users on Google even if they haven’t installed the Google Pay app. We are starting with boarding passes and transit tickets, then plan to extend the same functionality to the other Passes. Stay tuned for more.

Resources

To learn more about Google Pay, visit our developer resources:

YouTube → Google Pay API Explained
Developer documentation → Google Pay API, Google Pay API for Passes
Codelabs → Android, Web
GitHub → Google Pay on GitHub

Developer Student Clubs - Apply to be a Lead today. Deadline extended to June 15!

2019-06-03T15:22:00.000-07:00

Posted by Erica Hanson, Google Developer Relations

This spring, Google and Developer Student Clubs are looking for new passionate student leaders from universities across the globe!

Developer Student Clubs is a program with Google Developers. Through in-person meetups, university students are empowered to learn together and use technology to solve real life problems with local businesses and start-ups.

Less than two years ago, DSC launched in parts of Asia and Africa where 90,000+ students have been trained on Google technologies; 500+ solutions built for 200+ local startups and organizations and 170+ clubs participated in our first Solution Challenge!

Bridging the gap between theory and practical application, Google aims to provide student developers with the resources, opportunities and the experience necessary to be more industry ready.

You may be wondering what the benefit of being a Developer Student Club Lead is? Well, here are a few reasons:

Help students grow as developers
Gain access to Google technology and platforms at no cost
Build prototypes and solutions for local problems
Participate in a global developer competition
Get invitations to select Google events and conferences
Be recognized as a collaborator with Google Developers

Apply to be a Developer Student Club Lead at g.co/dev/dsc.

Deadline to submit applications has been extended to June 15th.

Coral updates: Project tutorials, a downloadable compiler, and a new distributor

2019-05-31T10:25:00.000-07:00

Posted by Vikram Tank (Product Manager), Coral Team

We’re committed to evolving Coral to make it even easier to build systems with on-device AI. Our team is constantly working on new product features, and content that helps ML practitioners, engineers, and prototypers create the next generation of hardware.

To improve our toolchain, we're making the Edge TPU Compiler available to users as a downloadable binary. The binary works on Debian-based Linux systems, allowing for better integration into custom workflows. Instructions on downloading and using the binary are on the Coral site.

We’re also adding a new section to the Coral site that showcases example projects you can build with your Coral board. For instance, Teachable Machine is a project that guides you through building a machine that can quickly learn to recognize new objects by re-training a vision classification model directly on your device. Minigo shows you how to create an implementation of AlphaGo Zero and run it on the Coral Dev Board or USB Accelerator.

Our distributor network is growing as well: Arrow will soon sell Coral products.

Increasing Diversity: Cloud Study Jam for Women Techmakers in Europe

2019-05-16T10:08:00.000-07:00

Posted by Franziska Hauck, DevRel Ecosystem Regional Lead DACH

When we look at the community landscape in programming in 2019, we find people of all backgrounds and with expertise as varied as the people themselves. There are developer groups for every imaginable interest out there. What becomes apparent, though, is that the allocation is not as equally balanced as it might be. In Europe, we observe that more programming women are in front-end development and active in the associated groups.

But what about in cloud? Recently, Global Knowledge published a ranking that showed that Google Cloud Certification is the most coveted achievement in the labor market. We knew that the interest was there. How could we capture it and get more women and diverse poeple involved? [Indeed, we had seen women succeed and in this chosen field at that. It was time to contribute to seeing more success stories coming our way.]

Immediately the Cloud Study Jam came to mind. This campaign is a self-study, highly individualized study jam for Google Developer Groups (GDGs) and other tech meetups. Organizers get access to study materials to help them prepare for their event, register it on the global map and conduct the activity with their attendees in any location they choose. Attendees receive free Qwiklabs credits to complete a number of courses of their choice. The platform even offers a complete Google Cloud environment - the best training ground for aspiring and advanced programmers!

GDGs form one pillar of our community programs. One of the other cornerstones is the Women Techmakers program with which we engage and involve organizers interested in increasing diversity worldwide. Cloud Study Jams in the local groups, with dedicated Women Techmakers, seemed like the most natural fit for us. And, as we soon realized, so thought the organizers.

For us - Almo, Abdallah and Franziska - that was the start of a great initiative and an even bigger road trip. Together with local volunteers from Google and the groups, we held 11 Cloud Study Jams all over Europe in March and April.

Over 450 attendees, 80 % of them women, learned about Cloud technologies.

This was some of their feedback:

“This made me aim for the Cloud Certificate exam as my next goal in my career!”

“I found useful everything! The labs are interesting... and I would like to have more meetups like this.”

“The labs are interesting, at least both that we did. I would like to have more meetups like this!”

As surmised, many attendees were indeed front-end developers. It was amazing to see that, with the courses, they “converted” to Cloud and are now going forward as ambassadors. We also saw quite a big number of data scientists and back-end developers. All in all, it was a great mix of enthusiastic participants.

Cloud Study Jams are a great way to engage group members by guided materials. The way they are designed makes it easy for the organizers to focus on the participants. Since attendees follow their chosen courses on their own organizers act as facilitators. They need only jump in when organizational questions arise.

If you would like to hold a Cloud Study Jam with your group or organization you will find more information here. Register your event via the link to get access to the free Qwiklabs credits for your attendees.

We are very much looking forward to supporting you!

Almo, Abdallah, Franziska & the European DevRel Ecosystem

.App: bringing more people online securely

2019-05-15T03:00:00.000-07:00

Posted by Ben Fried, VP, CIO, & Chief Domains Enthusiast

Celebrating 100 of our favorite .app websites. See the list here.

A year ago, we launched .app, the first open top-level domain (TLD) with built-in security through HSTS preloading. Since then, hundreds of thousands of people have registered .app domains, and we want to take a moment to celebrate them.

People are making more websites and apps than ever before. A recent survey we conducted with The Harris Poll found that nearly half (48%) of U.S. respondents plan to create a website in the near future. And a lot of people, especially students, are already building on the web. Over a third (34%) of 16-24 year olds who’ve already created a website did so for a class project.

Having a meaningful domain name helps students turn their projects into reality. Take Ludwik Trammer, creator of shrew.app, who said: “The site started as a project for my graduate Educational Technology class at Georgia Tech. Getting the perfect domain gave me the initial push to turn it into the real deal (instead of making a prototype, publishing a scientific paper on it, and forgetting it).”

Helping creators launch their sites securely

With so many new creators, it’s essential that everyone does their part to make the internet safer. That’s why Google Registry designed .app to be secure by default, meaning every website on .app requires a HTTPS connection to ensure a secure connection to the internet.

HTTPS helps keep you and your website visitors safe from bad actors, who may exploit connections that aren’t secure by:

intercepting or altering the site’s content
misdirecting traffic
spying on open Wi-Fi networks
injecting ad malware or tracking

“As a social application, data protection is paramount. As cyber attacks increase, the security benefits a .app domain brings was a key factor for us. We also believe that a .app domain is significantly more descriptive than a .com domain, meaning users can find us more easily! All in all it was a no brainer for us switching to .app.”
-Daneh Westropp, Founder, pickle.app

There's still work to be done. One out of two people don’t know the difference between HTTP and HTTPS. Many major browsers (like Chrome) warn users in the URL bar when content is "not secure," but there’s every website creator still has a shared responsibility to keep their users safe.

.App is year in, and we’re happy to see so many people using it to build secure websites and connect with the world. You can read more stories from .app owners here and get your own .app name at get.app. If you’re one of the millions of people planning to build a website, we hope you’ll join us in making the internet safer and take the steps to securely launch your website.

New ML Kit features easily bring Machine Learning to your apps

2019-05-14T10:07:00.001-07:00

Posted by Brahim Elbouchikhi, Director of Product Management and Matej Pfajfar, Engineering Director

We launched ML Kit at I/O last year with the mission to simplify Machine Learning for everyone. We couldn’t be happier about the experiences that ML Kit has enabled thousands of developers to create. And more importantly, user engagement with features powered by ML Kit is growing more than 60% per month. Below is a small sample of apps we have been working with.

But there is a lot more. At I/O this year, we are excited to introduce four new features.

The Object Detection and Tracking API lets you identify the prominent object in an image and then track it in real-time. You can pair this API with a cloud solution (e.g. Google Cloud’s Product Search API) to create a real-time visual search experience.

When you pass an image or video stream to the API, it will return the coordinates of the primary object as well as a coarse classification. The API then provides a handle for tracking this object's coordinates over time.

A number of partners have built experiences that are powered by this API already. For example, Adidas built a visual search experience right into their app.

The On-device Translation API allows you to use the same offline models that support Google Translate to provide fast, dynamic translation of text in your app into 58 languages. This API operates entirely on-device so the context of the translated text never leaves the device.

You can use this API to enable users to communicate with others who don't understand their language or translate user-generated content.

To the right, we demonstrate the use of ML Kit’s text recognition, language detection, and translation APIs in one experience.

We also collaborated with the Material Design team to produce a set of design patterns for integrating ML into your apps. We are open sourcing implementations of these patterns and hope that they will further accelerate your adoption of ML Kit and AI more broadly.

Our design patterns for machine learning powered features will be available on the Material.io site.

With AutoML Vision Edge, you can easily create custom image classification models tailored to your needs. For example, you may want your app to be able to identify different types of food, or distinguish between species of animals. Whatever your need, just upload your training data to the Firebase console and you can use Google’s AutoML technology to build a custom TensorFlow Lite model for you to run locally on your user's device. And if you find that collecting training datasets is hard, you can use our open source app which makes the process simpler and more collaborative.

Wrapping up

We are excited by this first year and really hope that our progress will inspire you to get started with Machine Learning. Please head over to g.co/mlkit to learn more or visit Firebase to get started right away.

Flutter and Chrome OS: Better Together

2019-05-10T11:33:00.000-07:00

Posted by the Flutter and Chrome OS teams

Chrome OS is the fast, simple, and secure operating system that powers Chromebooks, including the Google Pixelbook and millions of devices used by consumers and students every day. The latest Flutter release adds support for building beautiful, tailored Chrome OS applications, including rich support for keyboard and mouse, and tooling to ensure that your app runs well on a Chromebook. Furthermore, Chrome OS is a great developer workstation for building general-purpose Flutter apps, thanks to its support for developing and running Flutter apps locally on the same device.

Flutter is a great way to build Chrome OS apps

Since its inception, Flutter has shared many of the same principles as Chrome OS: productive, fast, and beautiful experiences. Flutter allows developers to build beautiful, fast UIs, while also providing a high degree of developer productivity, and a completely open-source engine, framework and tools. In short, it’s the ideal modern toolkit for building multi-platform apps, including apps for Chrome OS.

Flutter initially focused on providing a UI toolkit for building apps for mobile devices, which typically feature touch input and small screens. However, we’ve been building keyboard and mouse support into Flutter since before our 1.0 release last December. And today, we’re pleased to announce that Flutter for Chrome OS is now stronger with scroll wheel support, hover management, and better keyboard event support. In addition, Flutter has always been great at allowing you to build apps that run at any size (large screen or small), with seamless resizing, as shown here in the Chrome OS Best Practices Sample:

The Chrome OS best practices sample in action

The Chrome OS Hello World sample is an app built with Flutter that is optimized for Chrome OS. This includes a responsive UI to showcase how to reposition items and have layouts that respond well to changes in size from mobile to desktop.

Because Chrome OS runs Android apps, targeting Android is the way to build Chrome OS apps. However, while building Chrome OS apps on Android has always been possible, as described in these guidelines, it’s often difficult to know whether your Android app is going to run well on Chrome OS. To help with that problem, today we are adding a new set of lint rules to the Flutter tooling to catch violations of the most important of the Chrome OS best practice guidelines:

The Flutter Chrome OS lint rules in action

When you’re able to put these Chrome OS lint rules in place, you’ll quickly be able to see any problems in your Android app that would hamper it when running on Chrome OS. To learn how to take advantage of these rules, see the linting docs for Flutter Chrome OS.

But all of that is just the beginning -- the Flutter tools allow you to develop and test your apps directly on Chrome OS as well.

Chrome OS is a great developer platform to build Flutter apps

No matter what platform you're targeting, Flutter has support for rich IDEs and programming tools like Android Studio and Visual Studio Code. Over the last year, Chrome OS has been building support for running the Linux version of these tools with the beta of Linux on Chrome OS (aka Crostini). And, because Chrome OS also supports Android natively, you can configure the Flutter tooling to run your Android apps directly without an emulator involved.

The Flutter development tools running on Chrome OS

All of the great productivity of Flutter is available, including Stateful Hot Reload, seamless resizing, keyboard and mouse support, and so on. Recent improvements in Crostini, such as high DPI support, Crostini file system integration, easier adb, and so on, have made this experience even better! Of course, you don’t have to test against the Android container running on Chrome OS; you can also test against Android devices attached to your Chrome OS box. In short, Chrome OS is the ideal environment in which to develop and test your Flutter apps, especially when you’re targeting Chrome OS itself.

Customers love Flutter on Chrome OS

With its unique combination of simplicity, security, and capability, Chrome OS is an increasingly popular platform for enterprise applications. These apps often work with large quantities of data, whether it’s a chart, or a graph for visualization, or lists and forms for data entry. The support in Flutter for high quality graphics, large screen layout, and input features (like text selection, tab order and mousewheel), make it an ideal way to port mobile applications for the enterprise. One purveyor of such apps is AppTree, who use Flutter and Chrome OS to solve problems for their enterprise customers.

“Creating a Chrome OS version of our app took very little effort. In 10 minutes we tweaked a few values and now our users have access to our app on a whole new class of devices. This is a huge deal for our enterprise customers who have been wanting access to our app on Desktop devices.”
--Matthew Smith, CTO, AppTree Software

By using Flutter to target Chrome OS, AppTree was able to start with their existing Flutter mobile app and easily adapt it to take advantage of the capabilities of Chrome OS.

Try Flutter on Chrome OS today!

If you’d like to target Chrome OS with Flutter, you can do so today simply by installing the latest version of Flutter. If you’d like to run the Flutter development tools on Chrome OS, you can follow these instructions to get started fast. To see a real-world app built with Flutter that has been optimized for Chrome OS, check out the the Developer Quest sample that the Flutter DevRel team launched at the 2019 Google I/O conference. And finally, don’t forget to try out the Flutter Chrome OS linting rules to make sure that your Chrome OS apps are following the most important practices.

Flutter and Chrome OS go great together. What are you going to build?

Adding the Assistant to Bluetooth devices gets easier for device makers

2019-05-09T04:30:00.000-07:00

Posted by Tomer Amarilio, Product Manager, Google Assistant

Building Google Assistant Bluetooth devices gets easier for device makers

Headphones were one of the first devices optimized for the Google Assistant. With just your voice, you can ask the Assistant to make calls to friends or skip to the next song when you’re commuting on the subway to work or biking around on the weekend without having to always glance at your phone.

But as wireless Bluetooth devices like headphones and earbuds become more popular, we need to make it easier to have the same great Assistant experience across many headsets. We collaborated with Qualcomm to design a comprehensive, customizable development kit to provide all device makers with the building blocks needed to create a smart headset with the Google Assistant. The new Qualcomm Smart Headset Development Kit for the Google Assistant is powered by Qualcomm’s QCC5100-series Bluetooth audio chip and supports Google Fast Pair to make pairing Bluetooth accessories a hassle-free process.

To inspire device makers, we also built a Qualcomm Smart Headset Reference Design which delivers high quality audio, noise cancellation capabilities, and supports extended battery life and playback time. The reference design includes a push button to activate the Assistant and is just an example of what manufacturers can engineer.

What’s new in Chrome OS? A faster, simpler, and more secure environment for Web and Android developers

2019-05-07T14:00:00.000-07:00

Posted by Allan Livingston, Product Management Director, Chrome OS App Ecosystem

When Google launched Chrome OS nine years ago, we designed every aspect around three core principles: speed, simplicity, and security. Last year at I/O, Google put those principles at developers’ fingertips by implementing Linux support on Chrome OS. This gave developers the increased flexibility of building and running Linux apps combined with the speed and security of working within Chrome OS.

In just the last year, the Chrome OS ecosystem has grown at an incredible rate. Linux support has been rolled out to over half of all Chromebooks. Plus, all devices launched this year will be Linux-ready right out of the box. The combination of Linux and Chrome OS makes for a great web development environment — and we’re making the process even easier for Android development.

At I/O this year, we showed web and Android developers a few of the most exciting improvements that have made Chrome OS an even faster, simpler, and more secure environment than ever. Let’s get into a few of the highlights:

File sharing
Today we announced that it’s much easier to share files between Linux, Android, and Chrome OS. Now you can use the file manager to move your files safely across Chrome OS, Google Drive, Android, and Linux.

Port forwarding
We’ve also made improvements to port forwarding on Chrome OS, making it easier to connect networking services between Linux and Chrome OS. That way, you can run a web server within the Linux container while debugging on the same machine.

Android Studio one-click installation and integrated debugging
Installing Android Studio on Chrome OS used to be a fairly lengthy process. Now, it takes a simple double-click. There’s no need to use a terminal to download, move, and unzip the file — just download it, click, and install.

Now in beta channel with Chrome OS 75, we also enabled secure USB support for Android phones. You can develop, debug, and push your APK to Android phones on any of the Android developer-recommended Chromebooks.

Chrome OS also automatically handles common installation pain-points, like hardware compatibility and power management set-up.

A growing opportunity for Android developers

App developers have to consider a huge range of factors to deliver amazing experiences on every screen size and form factor. In just the last few years, the app experience has evolved far beyond mobile screens. People are using apps across different devices that blur the lines between mobile and desktop — from attaching keyboards to their tablets to using their smartphones to project onto a desktop screen. And no matter what device they’re using, they expect apps to deliver a seamless experience every time.

When you’re building on and for Chrome OS, you’re on a streamlined path to reaching a massive and fast-growing audience of engaged users. In just the last year, the number of monthly active users who enabled Android apps on Chrome OS has grown by 250%.¹And in Q4 2018, 21% of notebooks sold in the U.S. were Chromebooks — a 23% YoY unit sales growth.²

Because millions of Android apps already run on Chrome OS, you can take the same APK and extend your app’s reach to even more consumers with just a few tweaks. Whether they’re building apps with larger screens in mind from the start or optimizing old apps to reach new users, developers behind some of the most popular mobile apps and games have already seen incredible results from Chromebook users.

Developer spotlight: Concepts & BandLab

As people use apps in more unpredictable and inspiring ways, devs are seeing even higher engagement after optimizing for larger screens. Watch the video below to see how Concepts created a larger, more responsive canvas for aspiring digital designers and how BandLab gave musicians a more immersive platform for exploring and composing new music.

Chrome OS: A fast and secure development environment

It’s never been easier or more secure to develop for the Web and Android on Chrome OS. Between a fast-growing user base, Progressive Web Apps, millions of Android apps, and now, Linux, the potential for developing on and for Chrome OS is only going to keep growing.

Chrome OS delivers the speed and performance app users expect, and it’s now even faster, simpler, and more secure than ever for all developers.

We can’t wait to see the amazing stuff you create with your Chromebooks!

Sources
1. Google Internal Data, March 2018 to March 2019.
2. The NPD Group, Inc., Retail Tracking Service, U.S., Notebook Computers, Chrome OS, based on units, Oct. 8, 2017–Jan. 6, 2018 vs. Oct. 7, 2018–Jan. 5, 2019.

Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

2019-05-07T13:30:00.000-07:00

Posted by the Flutter Team

Today marks an important milestone for the Flutter framework, as we expand our focus from mobile to incorporate a broader set of devices and form factors. At I/O, we’re releasing our first technical preview of Flutter for web, announcing that Flutter is powering Google’s smart display platform including the Google Home Hub, and delivering our first steps towards supporting desktop-class apps with Chrome OS.

From Mobile to Multi-Platform

For a long time, the Flutter team mission has been to build the best framework for developing mobile apps for iOS and Android. We believe that mobile development is ripe for improvement, with developers today forced to choose between building the same app twice for two platforms, or making compromises to use cross-platform frameworks. Flutter hits the sweet spot of enabling a single codebase to deliver beautiful, fast, tailored experiences with high developer productivity for both platforms, and we’ve been excited to see how our early efforts have flourished into one of the most popular open source projects.

As we started to home in on our 1.0 release last year, we began experimenting with broadening the scope of Flutter to other platforms. This was triggered both by internal teams within Google who are increasingly relying on Flutter, as well as the latent potential of the Dart platform for delivering portable experiences. In particular, a small team who were already building a web framework for Dart for internal usage started an exploratory project (codename “Hummingbird”) to evaluate the technical merits of porting the Flutter engine to support the standards-based web.

The results of this project were startling, thanks in large part to the rapid progress in web browsers like Chrome, Firefox, and Safari, which have pervasively delivered hardware-accelerated graphics, animation, and text as well as fast JavaScript execution. Within a few months of beginning the project, we had the core Flutter framework primitives working, and soon after we had demos running on mobile and desktop browsers. Along with Dart’s long pedigree of compiling for the web, this proved that we could also bring the Flutter framework and apps to run on the web.

In parallel, the core Flutter project has been making progress to enable desktop-class apps, with input paradigms such as keyboard and mouse, window resizing, and tooling for Chrome OS app development. The exploratory work that we did for embedding Flutter into desktop-class apps running on Windows, Mac and Linux has also graduated into the core Flutter engine.

A Portable UI Framework for All Screens

It’s worth pausing for a moment to acknowledge the business potential of a high-performance, portable UI framework that can deliver beautiful, tailored experiences to such a broad variety of form factors from a single codebase.

For startups, the ability to reach users on mobile, web, or desktop through the same app lets them reach their full audience from day one, rather than having limits due to technical considerations. Especially for larger organizations, the ability to deliver the same experience to all users with one codebase reduces complexity and development cost, and lets them focus on improving the quality of that experience.

With support for mobile, desktop, and web apps, our mission expands: we want to build the best framework for developing beautiful experiences for any screen.

Flutter for Web

This week, we are releasing the first technical preview of Flutter for the web. While this technology is still in development, we are ready for early adopters to try it out and give us feedback. Our initial vision for Flutter on the web is not as a general purpose replacement for the document experiences that HTML is optimized for; instead we intend it as a great way to build highly interactive, graphically rich content, where the benefits of a sophisticated UI framework are keenly felt.

To showcase Flutter for the web, we worked with the New York Times to build a demo. In addition to world-class news coverage, the New York Times is famous for its crossword and other puzzle games. Since avid puzzlers want to play on whatever device they’re using at the time, their development team was attracted to Flutter as a potential solution for their needs. Discovering that they could reach the web with the same code was a huge boon. At Google I/O this week, you can get a sneak peek of their newly refreshed KENKEN puzzle game, which runs with the same code on Android, iOS, web, Mac, and Chrome OS.

Here’s what Eric von Coelln, Executive Director of Puzzles at the New York Times has to say about their experiences with Flutter:

"The New York Times Crossword has more than 400,000 stand-alone subscriptions and is a daily ritual for puzzle solvers. Along with the Crossword, we’ve grown our portfolio of digital puzzles that reaches more than two million solvers each month.
We were already beginning to explore Flutter as a potential solution to the challenge of quickly developing engaging, high-quality mobile experiences. Now the addition of being able to publish to web makes Flutter an even more appealing option to quickly deploy across all of our user platforms. This update of our old Flash-based KenKen game into a multi-platform playable experience is something we’re excited to bring to our solvers this year.”

There’s lots more to say about Flutter for web than we have space for here, so check out the dedicated article about Flutter for web on the Flutter blog.

At this early stage, we’re eager to get your feedback on how you’d like to use Flutter for web. We expect to rapidly evolve the code, with a particular focus on performance, and harmonizing the codebase with the rest of the Flutter project.

Flutter for Mobile Devices

The core Flutter framework also receives an upgrade this week, with the immediate availability of Flutter 1.5 in our stable channel. Flutter 1.5 includes hundreds of changes in response to developer feedback, including updates for new App Store iOS SDK requirements, updates to the iOS and Material widgets, engine support for new device types, and Dart 2.3 featuring new UI-as-code language features.

As the framework itself matures, we’re investing in building out the supporting ecosystem. The architectural model of Flutter has always prioritized a small core framework, supplemented by a rich package community. In the last few months, Google has contributed production-quality packages for web views, Google Maps, and Firebase ML Vision, and this week, we’re adding initial support for in-app payments. And with over 2,000 open source packages available for Flutter, there are options available for most scenarios.

One particularly exciting project that we’re announcing this week at I/O is the ML Kit Custom Image Classifier. Built using Flutter and Firebase, it offers an easy-to-use app-based workflow for creating custom image classification models. You can collect training data using the phone's camera, invite others to contribute to your datasets, trigger model training, and use trained models, all from the same app.

Flutter continues to grow in popularity and adoption. A growing roster of demanding customers including eBay, Sonos, Square, Capital One, Alibaba and Tencent are developing apps with Flutter. And they’re having fun! Here’s what Larry McKenzie, a senior developer at eBay had to say about Flutter:

“Flutter is fast! Features that once took us multiple days to implement can be finished in a single day. Many problems we used to spend a lot of time on, simply no longer occur. Our team can now focus on creating more polished user experiences and delivering functionality. Flutter is enabling us to exceed expectations!”

More broadly, LinkedIn recently conducted a study that showed Flutter is the single fastest-growing skill among software engineers, based on site members claiming it on their profile over the last 12 months. And in the recent 2019 StackOverflow developer survey, Flutter was listed as one of the most-loved developer frameworks.

Flutter for Desktop

Flutter is also being used on the desktop. For some months, we’ve been working on the desktop as an experimental project. But now we’re graduating this into Flutter engine, integrating this work directly into the mainline repo. While these targets are not production-ready yet, we have published early instructions for developing Flutter apps to run on Mac, Windows, and Linux.

Another quickly growing Flutter platform is Chrome OS, with millions of Chromebooks being sold every year, particularly in education. Chrome OS is a perfect environment for Flutter, both for running Flutter apps, and as a developer platform, since it supports execution of both Android and Linux apps. With Chrome OS, you can use Visual Studio Code or Android Studio to develop a Flutter app that you can test and run locally on the same device without an emulator. You can also publish Flutter apps for Chrome OS to the Play Store, where millions of others can benefit from your creation.

Flutter for Embedded Devices

As the final example of Flutter’s portability, we offer Flutter embedded on other devices. We recently published samples that demonstrate Flutter running directly on smaller-scale devices like Raspberry Pi, and we offer an embedding API for Flutter that allows it to be used in scenarios including home, automotive and beyond.

Perhaps one of the most pervasive embedded platforms where Flutter is already running is on the smart display operating system that powers the likes of Google Home Hub.

Within Google, some Google-built features for the Smart Display platform are powered by Flutter today. And the Assistant team is excited to continue to expand the portfolio of features built with Flutter for the Smart Display in the coming months; the goal this year is to use Flutter to drive the overall system UI.

Other Resources

We often get asked by developers how they can get started with Flutter. We are pleased today to announce a comprehensive new training course for Flutter, built by The App Brewery, authors of the highest-rated iOS training course on Udemy. Their new course has over thirty hours of content for Flutter, including videos, demos and labs, and with Google’s sponsorship, they are announcing today a time-limited discount of this course from the retail price of $199 to just $10.

Many developers are creating inspiring apps with Flutter. In the run-up to Google I/O, we ran a contest called Flutter Create to encourage developers to see what they could build with Flutter in 5KB or less of Dart code. We had over 750 unique entries from around the world, with some amazing examples that pushed what we imagine would be possible in such a small size.

Today, we’re announcing the winners, which can be found on flutter.dev/create. Congratulations to the overall winner, Zebiao Hu, who wins a fully-loaded iMac Pro worth over $10,000!

Flutter is no longer a mobile framework, but a multi-platform framework that can help you reach your users wherever they are. We can’t wait to see what you’ll build with Flutter on the web, desktop, mobile, and beyond!

Actions on Google at I/O 2019: New tools for web, mobile, and smart home developers

2019-05-07T13:06:00.000-07:00

Posted by Chris Turkstra, Director, Actions on Google

People are using the Assistant every day to get things done more easily, creating lots of opportunities for developers on this quickly growing platform. And we’ve heard from many of you that want easier ways to connect your content across the Assistant.

At I/O, we’re announcing new solutions for Actions on Google that were built specifically with you in mind. Whether you build for web, mobile, or smart home, these new tools will help make your content and services available to people who want to use their voice to get things done.

Enhance your presence in Search and the Assistant

Help people with their “how to” questions

Every day, people turn to the internet to ask “how to” questions, like how to tie a tie, how to fix a faucet, or how to install a dog door. At I/O, we’re introducing support for How-to markup that lets you power richer and more helpful results in Search and the Assistant.

Adding How-to markup to your pages will enable the page to appear as a rich result on mobile Search and on Google Assistant Smart Displays. This is an incredibly lightweight way for web developers and creators to connect with millions of people, giving them helpful step-by-step instructions with video, images and text. You can start seeing How-to markup results on Search today, and your content will become available on the Smart Displays in the coming months.

Here’s an example where DIY Network added markup to their existing content on the web to provide a more helpful, interactive result on both Google Search and the Assistant:

For content creators that don’t maintain a website, we created a How-to Video Template where video creators can upload a simple spreadsheet with titles, text and timestamps for their YouTube video, and we’ll handle the rest. This is a simple way to transform your existing how-to videos into interactive, step-by-step tutorials across Google Assistant Smart Displays and Android phones.

Check out how REI is getting extra mileage out of their YouTube video:

How-to Video Templates are in developer preview so you can start building today, and your content will become available on Android phones and Smart Displays in the coming months.

Easier engagement with your apps

Help people quickly get things done with App Actions

If you’re an app developer, people are turning to your apps every day to get things done. And we see people turn to the Assistant every day for a natural way to ask for help via voice. This offers an opportunity to use intents to create voice-based entry points from the Assistant to the right spot in your app.

Last year, we previewed App Actions, a simple mechanism for Android developers that uses intents from the Assistant to deep link to exactly the right spot in your app. At I/O, we are announcing the release of built-in intents for four new App Action categories: Health & Fitness, Finance and Banking, Ridesharing, and Food Ordering. Using these intents, you can integrate with the Assistant in no time.

If I wanted to track my run with Nike Run Club, I could just say “Hey Google, start my run in Nike Run Club” and the app will automatically start tracking my run. Or, let’s say I just finished dinner with my friend Chad and we're splitting the check. I can say "Hey Google, send $15 to Chad on PayPal" and the Assistant takes me right into Paypal, I log in, and all of my information is filled in – all I need to do is hit send.

Each of these integrations were completed in less than a day with the addition of an Actions.xml file that handles the mapping of intents between your app and the Actions platform. You can start building with these new intents today and deploy to Assistant users on Android in the coming months. This is a huge opportunity to offer your fans an effortless way to engage more frequently with your apps.

Build for devices in the home

Take advantage of Smart Displays’ interactive screens

Last year, we saw the introduction of the Smart Display as a new device category. The interactive visual surface opens up many new possibilities for developers.

Today, we’re introducing a developer preview of Interactive Canvas which lets you create full-screen experiences that combine the power of voice, visuals and touch. Canvas works across Smart Displays and Android phones, and it uses open web technologies you’re likely already familiar with, like HTML, CSS and Javascript.

Here’s an example of what you can build when you can leverage the full screen of a Smart Display:

Interactive Canvas is available for building games starting today, and we’ll be adding more categories soon. Visit the Actions Console to be one of the first to try it out.

Enable smart home devices to communicate locally

There are now more than 30,000 connected devices that work with the Assistant across 3,500 brands, and today, we’re excited to announce a new suite of local technologies that are specifically designed to create an even better smart home.

Introducing a preview of the Local Home SDK which enables you to run your smart home code locally on Google Home Speakers and Nest Displays and use its radios to communicate locally with your smart devices. This reduces cloud hops and brings a new level of speed and reliability to the smart home. We’ve been working with some amazing partners including Philips, Wemo, TP-Link, and LIFX on testing this SDK and we’re excited to open it up for all developers next month.

Make setup more seamless

And, through the Local Home SDK, we’re improving the device setup experience by providing users with a seamless setup experience, something we launched in partnership with GE smart lights this past October. So far, people have loved the ability to set up their lights in less than a minute in the Google Home app. We’re now scaling this to more partners, so go here if you’re interested.

Make your devices smart with Assistant Connect

Also, at CES earlier this year we previewed Google Assistant Connect which leverages the Local Home SDK. Assistant Connect enables smart home and appliance developers to easily add Assistant functionality into their devices at low cost. It does this by offloading a lot of work onto the Assistant to complete Actions, display content and respond to commands. We've been hard at work developing the platform along with the first products built on it by Anker, Leviton and Tile. We can't wait to show you more about Assistant Connect later this year.

New device types and traits

For those of you creating Actions for the smart home, we’re also releasing 16 new device types and three new device traits including LockUnlock, ArmDisarm, and Timer. Head over to our developer documentation for the full list of 38 device types and 18 device traits, and check out our sample project on GitHub to start building.

Get started with our new tools for all types of developers

Whether you’re looking to extend the reach of your content, drive more usage in your apps, or build custom Assistant-powered experiences, you now have more tools to do so.

If you want to learn more about how you can start building with these tools, check out our website to get started and our schedule so you can tune in to all of our developer talks that we’ll be hosting throughout the week.

We can’t wait to build together with you!

Google Developers Blog

From Code to Community: Why developers call DevFest home

“As someone who is relatively shy and a loner by nature, I was stunned when I felt myself saying, "I belong here, I'm home."

“DevFest is not only about the talks or workshops, it’s also about the people.”

Get smart about preparing your app for OAuth verification

Getting prepared for verification

Determining if your app is using sensitive or restricted scopes

Setting up the right project structure

Configuring your project

Project Owners

Branding Info and Domain Verification

Scopes

Privacy Policy

Submitting your app for verification

Brand Verification (2-3 days)

Sensitive Scope Verification (3-5 days)

Restricted Scope Verification (4-6 weeks)

Responding to verification questions

ARCore updates to Augmented Faces and Cloud Anchors enable new shared cross-platform experiences

Flutter news from GDD China: uniting Flutter on web and mobile, and introducing Flutter 1.9

Supporting macOS Catalina and iOS 13

New Material widgets

Worldwide language support

Dart 2.5 release

Toolchain improvements

Flutter on the web

Community

Conclusion

Enabling developers and organizations to use differential privacy

Developer Student Clubs: A Walk That Changed Healthcare

“Looking through the cards, you could tell these kids had missed several vaccinations.”

“Developer Student Clubs helped us not be alone and apart from each other while trying to solve this problem. They gave us the space to come together and learn. We could all be in the same room, thinking together.”

“If we wanted to learn something, they gave us the best expert.”

The Speed Benefit of AMP Prerendering

First Viewport Ready

First Contentful Paint

Conclusion

Coral summer updates: Post-training quant support, TF Lite delegate, and new models!

Discontinuing support for JSON-RPC and Global HTTP Batch Endpoints

How do I know if I should migrate ?

JSON-RPC

HTTP batch

What do you need to do to migrate ?

JSON-RPC

Using Client Libraries

Not Using Client Libraries i.e making raw HTTP requests

HTTP batch

Heterogeneous batch requests

Homogeneous batch requests

Google API client libraries

Non-Google API client libraries or no client library

We’re here to help

Women Techmakers Summit Europe: Supporting Diversity & Inclusion in Tech

Expertise from the Community for the Community

Building the Basis for Diversity and Inclusion

Women Techmakers: Changing the Narrative

International Women's Day'19 featuring Actions on Google

Technical Workshop Details

Developer Preview of Local Home SDK

How it works:

Get started

Google Pay and PayPal expand their integration to give merchants more ways to accept payments online

1. Reach more customers already set up to pay

2. Deliver a faster checkout experience with more customer benefits

3. Give customers more choices at checkout

4. Keep the benefits

5. Integrate with ease

Mail merge with the Google Docs API

Google Pay launches new, dynamic features for Online Payments and Passes APIs

Making online payments even more seamless

Dynamic updates for faster checkout

More payment button options

Delivering extra value with Google Pay Passes

High priority notifications for boarding passes

Integration with the Google Assistant

An open API for transit, with support for dynamic barcodes

Loyalty Integration with Gmail

What’s next

Resources

Developer Student Clubs - Apply to be a Lead today. Deadline extended to June 15!