We're constantly working to secure our users and their data. Earlier this year, we detailed some of our latest anti-phishing tools and rolled-out developer-focused updates to our app publishing processes, risk assessment systems, and user-facing consent pages. Most recently, we introduced OAuth apps whitelisting in G Suite to enable admins to choose exactly which third-party apps can access user data.
Over the past few months, we've required that some new web applications go through a verification process prior to launch based upon a dynamic risk assessment.
Today, we're expanding upon that foundation, and introducing additional protections: bolder warnings to inform users about newly created web apps and Apps Scripts that are pending verification. Additionally, the changes we're making will improve the developer experience. In the coming months, we will begin expanding the verification process and the new warnings to existing apps as well.
Beginning today, we're rolling out an "unverified app" screen for newly created web applications and Apps Scripts that require verification. This new screen replaces the "error" page that developers and users of unverified web apps receive today.
The "unverified app" screen precedes the permissions consent screen for the app and lets potential users know that the app has yet to be verified. This will help reduce the risk of user data being phished by bad actors.
This new notice will also help developers test their apps more easily. Since users can choose to acknowledge the 'unverified app' alert, developers can now test their applications without having to go through the OAuth client verification process first (see our earlier post for details).
Developers can follow the steps laid out in this help center article to begin the verification process to remove the interstitial and prepare your app for launch.
We're also extending these same protections to Apps Script. Beginning this week, new Apps Scripts requesting OAuth access to data from consumers or from users in other domains may also see the "unverified app" screen. For more information about how these changes affect Apps Script developers and users, see the verification documentation page.
Apps Script is proactively protecting users from abusive apps in other ways as well. Users will see new cautionary language reminding them to "consider whether you trust" an application before granting OAuth access, as well as a banner identifying web pages and forms created by other users.
In the coming months, we will continue to enhance user protections by extending the verification process beyond newly created apps, to existing apps as well. As a part of this expansion, developers of some current apps may be required to go through the verification flow.
To help ensure a smooth transition, we recommend developers verify that their contact information is up-to-date. In the Google Cloud Console, developers should ensure that the appropriate and monitored accounts are granted either the project owner or billing account admin IAM role. For help with granting IAM roles, see this help center article.
In the API manager, developers should ensure that their OAuth consent screen configuration is accurate and up-to-date. For help with configuring the consent screen, see this help center article.
We're committed to fostering a healthy ecosystem for both users and developers. These new notices will inform users automatically if they may be at risk, enabling them to make informed decisions to keep their information safe, and will make it easier to test and develop apps for developers.
I'm happy to share that we opened registrations for the European installment of our global event series — Google Developer Days (GDD). Google Developer Days showcase our latest developer product and platform updates to help you develop high quality apps, grow & retain an active user base, and tap into tools to earn more.
Google Developer Days — Europe (GDD Europe) will take place on September 5-6 2017, in Krakow, Poland. We'll feature technical talks on a range of products including Android, the Mobile Web, Firebase, Cloud, Machine Learning, and IoT. In addition, we'll offer opportunities for you to join hands-on training sessions, and 1:1 time with Googlers and members of our Google Developers Experts community. We're looking forward to meeting you face-to-face so we can better understand your needs and improve our offerings for you.
If you're interested in joining us at GDD Europe, registration is now open.
Can't make it to Krakow? We've got you covered. All talks will be livestreamed on the Google Developers YouTube channel, and session recordings will be available there after the event. Looking to tune into the action with developers in your own neighborhood? Consider joining a GDD Extended event or organizing one for your local developer community .
Whether you're planning to join us in-person or remotely, stay up-to-date on the latest announcements using #GDDEurope on Twitter, Facebook, and Google+.
We're looking forward to seeing you in Europe soon!
You might be using the Google Calendar API, or alternatively email markup, to insert events into your users' calendars. Thankfully, these tools allow your apps to do this seamlessly and automatically, which saves your users a lot of time. But what happens if plans change? You need your apps to also be able to modify an event.
While email markup does support this update, it's limited in what it can do, so in today's video, we'll show you how to modify events with the Calendar API. We'll also show you how to create repeating events. Check it out:
Imagine a potential customer being interested in your product, so you set up one or two meetings with them. As their interest grows, they request regularly-scheduled syncs as your product makes their short list—your CRM should be able to make these adjustments in your calendar without much work on your part. Similarly, a "dinner with friends" event can go from a "rain check" to a bi-monthly dining experience with friends you've grown closer to. Both of these events can be updated with a JSON request payload like what you see below to adjust the date and make it repeating:
JSON
var TIMEZONE = "America/Los_Angeles"; var EVENT = { "start": {"dateTime": "2017-07-01T19:00:00", "timeZone": TIMEZONE}, "end": {"dateTime": "2017-07-01T22:00:00", "timeZone": TIMEZONE}, "recurrence": ["RRULE:FREQ=MONTHLY;INTERVAL=2;UNTIL=20171231"] };
This event can then be updated with a single call to the Calendar API's events().patch() method, which in Python would look like the following given the request data above, GCAL as the API service endpoint, and a valid EVENT_ID to update:
events().patch()
GCAL
EVENT_ID
GCAL.events().patch(calendarId='primary', eventId=EVENT_ID, sendNotifications=True, body=EVENT).execute()
If you want to dive deeper into the code sample, check out this blog post. Also, if you missed it, check out this video that shows how you can insert events into Google Calendar as well as the official API documentation. Finally, if you have a Google Apps Script app, you can access Google Calendar programmatically with its Calendar service.
We hope you can use this information to enhance your apps to give your users an even better and timely experience.
At Area 120, Google's internal workshop for experimental ideas, we're working on early-stage projects and quickly iterate to test concepts. We heard from developers that they're looking at how to make money to fund their VR applications, so we started experimenting with what a native, mobile VR ad format might look like.
Developers and users have told us they want to avoid disruptive, hard-to-implement ad experiences in VR. So our first idea for a potential format presents a cube to users, with the option to engage with it and then see a video ad. By tapping on the cube or gazing at it for a few seconds, the cube opens a video player where the user can watch, and then easily close, the video. Here's how it works:
Our work focuses on a few key principles - VR ad formats should be easy for developers to implement, native to VR, flexible enough to customize, and useful and non-intrusive for users. Our Area 120 team has seen some encouraging results with a few test partners, and would love to work with the developer community as this work evolves - across Cardboard (on Android and iOS), Daydream and Samsung Gear VR.
If you're a VR developer (or want to be one) and are interested in testing this format with us, please fill out this form to apply for our early access program. We have an early-stage SDK available and you can get up and running easily. We're excited to continue experimenting with this format and hope you'll join us for the ride!
Our goal is to help publishers monetize their content and build sustainable businesses through advertising products that allow sites to load as fast as possible to minimize impact to user experience.
Almost two years ago, our compression team announced a new compression algorithm called Brotli. Today, we are happy to announce that the Brotli compression algorithm is now being used to compress Google Display Ads whenever possible. In our experiments, we see data savings of 15% in aggregate over standard gzip compression, and in some instances, a savings of over 40%! This reduces the amount of data sent to end users by tens of thousands of gigabytes every day! This also results in faster page loads and less battery consumption.
We hope results like this will encourage wider adoption and will advance web standards such as Brotli compression.
Enterprises are always looking for ways to operate more efficiently, and equipping developers with the right tools can make a difference. We launched Team Drives this year to bring the best of what users love about Drive to enterprise teams. We also updated the Google Drive API, so that developers can leverage Team Drives in the apps they build.
In this latest G Suite Dev Show video, we cover how you can leverage the functionality of Team Drives in your apps. The good news is you don't have to learn a completely new API—Team Drives features are built into the Drive API so you can build on what you already know. Check it out:
By the end of this video, you'll be familiar with four basic operations to help you build Team Drives functionality right into your apps:
Want to explore the code further? Check out the deep dive blog post. In all, the Drive API can help a variety of developers create solutions that work with both Google Drive and Team Drives. Whether you're an Independent Software Vendor (ISV), System Integrator (SI) or work in IT, there are many ways to use the Drive API to enhance productivity, help your company migrate to G Suite, or build tools to automate workflows.
Team Drives features are available in both Drive API v2 and v3, and more details can be found in the Drive API documentation. We look forward to seeing what you build with Team Drives!
Over the past five years, developers have created hundreds of projects with Blockly, our open source library for creating block-based coding experiences. These have ranged from education platforms like Code.org to electronics kits like littleBits and even Android app creation tools like MIT App Inventor. Last year, we also announced our collaboration with the Scratch Team to develop Scratch Blocks—a fork of Blockly optimized for creating coding apps for kids.
Today, we're finalizing our 1.0 release of Blockly on Android and iOS. These versions have everything you need to use Blockly natively in your mobile app, including:
While our 1.0 update today is focused on native mobile, we've also made several updates to the web project over the past six months. We've made major improvements to performance and testing, added more structured APIs, and improved touch support for the mobile web. In addition, we improved Internet Explorer and Edge support; Blockly is fully supported on IE10+.
We've done a lot of work to ease cross platform development, too! All blocks can now be defined by JSON, allowing a single set of block definitions to be used for web, iOS, and Android. Check out the documentation for more details on all three platforms.
Get started right away with our iOS Codelab (Android coming soon)! To learn more about Blockly, check out the above intro video, visit our developer site, join our mailing list, or jump right into the code for web, Android, or iOS.
Recently we announced the addition of Brotli compression to the Google AMP Cache. All AMP documents served from the Google AMP Cache can now be served with Brotli, which will save a considerable amount of bandwidth for our users and further our goal of improving the mobile experience.
Brotli is a newer, more efficient compression algorithm created by Jyrki Alakuijala and Zoltán Szabadka with the Google Research Europe Compression Team. Launched in 2015, it has already been used to enable considerable savings in other areas of Google. While it is a generic compression algorithm, it has particularly impressive performance when applied to web documents; we have seen an average decrease in document size of around 10% when using Brotli instead of gzip, which has amounted to hundreds of gigabytes of bandwidth saved per day across the Google AMP Cache.
With smaller document sizes, pages load faster while also saving bandwidth which can amount to noticeable savings for users on limited data plans. The Google AMP Cache is just the beginning though, as engineering teams are working on Brotli support in many other products which can enable bandwidth savings throughout Google.
When her grandmother turned 80, Christina Hayek — Arabic Language Manager at Google — and her sisters wanted to give their beloved sitto a gift that would bring her closer to them. Chadia lives in Lebanon but her children and grandchildren are spread across the world. To bridge this geographical gap, Christina and her siblings gave their grandmother an Android smartphone. Much to Chadia’s surprise, she was able to use her phone in Arabic straight out of the box.
This isn’t magic—it’s the work of a dedicated localization team at Google. Spread over more than 30 countries, our team makes sure that all Google products are fun and easy to use in more than 70 languages. Localization goes beyond translation. While references to baseball and donuts work well in the US, these are not necessarily popular concepts in other cultures. Therefore we change these, for example, to football in Italy and croissant in France. Our mission is to create a diverse user experience that fits every language and every culture. We do this through a network of passionate translators and reviewers who localize Google products to make sure they sound natural to people everywhere.
With more and more people from around the world coming online every day, the localization industry keeps growing—and so does the demand for great translators, reviewers, and localization professionals. So, as part of Google’s mission to build products for everyone and make the web globally accessible, no matter where users are, we’re launching a massive open online course (MOOC) called Localization Essentials. In the words of Peter Lubbers, Google's Head of Developer Training:
"The language industry is one of the fastest growing in the world today, and as a former Internationalization Product Manager (and Dutch translator), I am absolutely thrilled that we've added Localization Essentials to our Google/Udacity training course catalog. The course is now available—free of charge—to students all over the world. This was a huge cross-functional effort; a large team of localization experts across Google came together and rallied to create this course. It was great to see how everybody poured their heart and soul into this effort and it really shows in the course quality."
Localization Essentials was developed in collaboration with Udacity, and is free to access. It covers all localization basics needed to develop global products. This is how Bert Vander Meeren, Director of Localization at Google, described the collaboration:
“Today, localization is becoming more and more important because the internet user base is growing rapidly, especially in non-English speaking countries. At the same time, education opportunities in the field are limited. This is an issue for our team and any business in need of large numbers of localization resources. So we decided to take the lead and address the issue, because who knows localization better than dedicated localization professionals with years of experience? Udacity already helped us develop and host several successful courses for Android developers, so this partnership was more than logical. This course is a great opportunity for anyone who wants to get knowledge and new skills in a still lesser-known field that’s important to develop products for a truly global audience. Whether you are a student, a professional, or an entrepreneur, you will learn a lot and expand your horizons.”
By sharing our knowledge we hope that more culturally relevant products will become available to users everywhere, to provide opportunities to them that they didn’t have before.
We’re looking forward to seeing how sharing this localization knowledge will impact users from all over the world.
It's been an exciting year! Last May, we expanded Firebase into our unified app platform, building on the original backend-as-a-service and adding products to help developers grow their user base, as well as test and monetize their apps. Hearing from developers like Wattpad, who built an app using Firebase in only 3 weeks, makes all the hard work worthwhile.
We're thrilled by the initial response from the community, but we believe our journey is just getting started. Let's talk about some of the enhancements coming to Firebase today.
In January, we announced that we were welcoming the Fabric team to Firebase. Fabric initially grabbed our attention with their array of products, including the industry-leading crash reporting tool, Crashlytics. As we got to know the team better, we were even more impressed by how closely aligned our missions are: to help developers build better apps and grow successful businesses. Over the last several months, we've been working closely with the Fabric team to bring the best of our platforms together.
We plan to make Crashlytics the primary crash reporting product in Firebase. If you don't already use a crash reporting tool, we recommend you take a look at Crashlytics and see what it can do for you. You can get started by following the Fabric documentation.
Phone number authentication has been the biggest request for Firebase Authentication, so we're excited to announce that we've worked with the Fabric Digits team to bring phone auth to our platform. You can now let your users sign in with their phone numbers, in addition to traditional email/password or identity providers like Google or Facebook. This gives you a comprehensive authentication solution no matter who your users are or how they like to log in.
At the same time, the Fabric team will be retiring the Digits name and SDK. If you currently use Digits, over the next couple weeks we'll be rolling out the ability to link your existing Digits account with Firebase and swap in the Firebase SDK for the Digits SDK. Go to the Digits blog to learn more.
We recognize that poor app performance and stability are the top reasons for users to leave bad ratings on your app and possibly churn altogether. As part of our effort to help you build better apps, we're pleased to announce the beta launch of Performance Monitoring.
Firebase Performance Monitoring is a new free tool that helps you understand when your user experience is being impacted by poorly performing code or challenging network conditions. You can learn more and get started with Performance Monitoring in the Firebase documentation.
Analytics has been core to the Firebase platform since we launched last I/O. We know that understanding your users is the number one way to make your app successful, so we're continuing to invest in improving our analytics product.
First off, you may notice that you're starting to see the name "Google Analytics for Firebase" around our documentation. Our analytics solution was built in conjunction with the Google Analytics team, and the reports are available both in the Firebase console and the Google Analytics interface. So, we're renaming Firebase Analytics to Google Analytics for Firebase, to reflect that your app analytics data are shared across both.
For those of you who monetize your app with AdMob, we've started sharing data between the two platforms, helping you understand the true lifetime value (LTV) of your users, from both purchases and AdMob revenue. You'll see these new insights surfaced in the updated Analytics dashboard.
Many of you have also asked for analytics insights into custom events and parameters. Starting today, you can register up to 50 custom event parameters and see their details in your Analytics reports. Learn more about custom parameter reporting.
Firebase's mission is to help all developers build better apps. In that spirit, today we're announcing expanded platform and vertical support for Firebase.
First of all, as Swift has become the preferred language for many iOS developers, we've updated our SDK to handle Swift language nuances, making Swift development a native experience on Firebase.
We've also improved Firebase Cloud Messaging by adding support for token-based authentication for APNs, and greatly simplifying the connection and registration logic in the client SDK.
Second, we've heard from our game developer community that one of the most important stats you monitor is frames per second (FPS). So, we've built Game Loop support & FPS monitoring into Test Lab for Android, allowing you to evaluate your game's frame rate before you deploy. Coupled with the addition of Unity plugins and a C++ SDK, which we announced at GDC this year, we think that Firebase is a great option for game developers. To see an example of a game built on top of Firebase, check out our Mecha Hamster app on Github.
Finally, we've taken a big first step towards open sourcing our SDKs. We believe in open source software, not only because transparency is an important goal, but also because we know that the greatest innovation happens when we all collaborate. You can view our new repos on our open sourceproject page and learn more about our decision in this blog post.
In March, we launched Cloud Functions for Firebase, which lets you run custom backend code in response to events triggered by Firebase features and HTTP requests. This lets you do things like send a notification when a user signs up or automatically create thumbnails when an image is uploaded to Cloud Storage.
Today, in an effort to better serve our web developer community, we're expanding Firebase Hosting to integrate with Cloud Functions. This means that, in addition to serving static assets for your web app, you can now serve dynamic content, generated by Cloud Functions, through Firebase Hosting. For those of you building progressive web apps, Firebase Hosting + Cloud Functions allows you to go completely server-less. You can learn more by visiting our documentation.
Our goal is to build the best developer experience: easy-to-use products, great documentation, and intuitive APIs. And the best resource that we have for improving Firebase is you! Your questions and feedback continuously push us to make Firebase better.
In light of that, we're excited to announce a Firebase Alpha program, where you will have the opportunity to test the cutting edge of our products. Things might not be perfect (in fact, we can almost guarantee they won't be), but by participating in the alpha community, you'll help define the future of Firebase. If you want to get involved, please register your interest in the Firebase Alpha form.
Thank you for your support, enthusiasm, and, most importantly, feedback. The Firebase community is the reason that we've been able to grow and improve our platform at such an incredible pace over the last year. We're excited to continue working with you to build simple, intuitive products for developing apps and growing mobile businesses. To get started with Firebase today, visit our newly redesigned website. We're excited to see what you build!
