Originally posted on Chromium Blog

Posted by Darin Fisher, VP Engineering, Chrome

The last sessions of the Chrome Dev Summit 2015 are coming to a close, so it’s the perfect time to reflect on the event. We started our annual summit back in 2012, where we first introduced Chrome on Android. Today, there are more than 800 million monthly active users on Chrome for Android.

The greatest power of the Web is in its reach—not just across devices and operating systems, but in reaching users. Top mobile web properties are seeing 2.5 times the number of monthly unique visitors compared to the top mobile apps, and mobile web reach is growing at more than twice the rate of mobile app reach. This reach offers a unique opportunity to engage with more users.  

We believe this is a pivotal moment for the web platform, as early adopters of a set of key enabling technologies and tools are seeing success. During the keynote, we covered the evolution of the mobile platform and the shift towards “progressive web apps,” which are fast, robust, app-like experiences built using modern web capabilities. The web has come a long way, and building immersive apps with web technology on mobile no longer requires giving up properties of the web you’ve come to love. Flipkart’s new mobile web experience is a great example of a progressive web app that uses the new capabilities to provide a next-generation user experience.

In practice, progressive web apps have three main aspects that separate them from traditional websites: reliability, performance, and engagement.

Every web app should load quickly, regardless of whether a user is connected to fast Wi-Fi, a 2G cell network, or no connection at all. We envision service workers as the ideal way for developers to build web apps that are resilient despite changing and unreliable networks. We've released two libraries to help take the work out of writing your own service worker: sw-precache and sw-toolbox for your App Shell and dynamic content, respectively. Once your implementation is up and running, you can easily test it on different network connections using Chrome DevTools and WebPageTest. Service workers are already seeing great adoption by developers: there are currently 2.2 billion page loads a day using service workers, not counting its use in the New Tab page in Chrome.

The RAIL performance model helps you figure out what a user expects from each interaction with your site or app, breaking down performance into four key goals: 
  • Responses (tap to response) should be less than 100ms 
  • Animations (scrolling, gestures, and transitions) should run at 60 frames per second
  • Idle time should be used to opportunistically schedule non-essential work in 50ms chunks
  • Loading should be finished in under 1 second

In practice, we've found improving even just one area of RAIL performance can make a dramatic difference on the user experience. For example, a one second difference in loading time can have as much as an 11% impact on overall page views and a 16% impact on customer satisfaction.

Traditionally, users have had a hard time re-engaging with sites on the web. Push notifications enable you to build experiences that users can engage with "outside of the tab"--they don’t need to have the browser open, or even be actively using your web app, in order to engage with your experience. Best of all, these notifications appear just like other app notifications. Currently we’re seeing over 350 million push notifications sent every day in Chrome, and it’s growing quickly. Beyond the Rack has found that users arriving to their site by push notifications browse 72% longer than average users and spend 26% more.

Tools for Success
Finally, Google is committed to making web developers successful. As our generalized library for building components on the web, Polymer is also deeply focused on helping developers achieve RAIL. Since its 1.0 release at Google I/O earlier this year, it has grown to be used on over 1 million web pages, including more than 300 projects within Google. Polymer 1.0 was 3 to 4 times faster than the previous 0.5 version, and the latest 1.2 release is even 20% faster than that. To get started with this modern way of thinking about web development, take a quick tour of Polymer, watch the Polymer Summit talks, check out the Polymer codelabs, or try the Polymer Starter Kit.

We already have great resources like Web Fundamentals that we continue to expand and improve.  We’re also committed to documenting each new feature we ship on the Mozilla Developer Network. In the past year alone, we’ve made 2,800 individual edits to MDN and created 212 new pages. To further our commitment to educating web developers, we’ve partnered with Udacity to offer a senior web nanodegree, an education credential focused on modern web technologies and techniques like service workers, Promises, HTTP/2 and more.

For all the details on Chrome Dev Summit 2015, you can watch full session videos, which we will continue to upload as they’re ready. Thanks for coming, thanks for watching, and most of all, thank you for developing for the web!


Posted by Alex Ames, Fun Propulsion Labs*

At Fun Propulsion Labs we spend some of our time building sample games to help demonstrate how to make easy-to-build, performant, cross-platform games. With the growth of Google Cardboard, we got to work and over many long evenings, feeding our animal hunger on sushi, we came up with Zooshi. Zooshi is an open source, cross-platform game written in C++ which supports:

  • Android, Android TV, Windows, OSX, and Linux
  • Google Cardboard
  • Google Play Games Services sign-in and leaderboards on Android
  • Level customization

Zooshi serves as a demonstration of how to build Android games using a suite of newly released and updated open source game technologies from Google:

  • Motive drives our Animation system, giving life and movement to the characters and environment.
  • CORGI, the Component Oriented Reusable Game Interface, is an Entity-Component system designed to allow users to define complicated game objects as collections of modular, custom-defined behaviors.
  • FlatUI is a straightforward immediate mode GUI system with a light footprint that makes building up user interfaces a breeze.
  • Scene Lab allows designers to design levels and edit entities from right in the game without needing to use an external editor.
  • Breadboard provides an easy to use node based scripting system for editing entity behaviors that's accessible to designers without deep knowledge of programming.
  • FPLBase is a cross-platform API layer, for abstracting low-level tasks like reading input and creation of graphical contexts.

As in our previous release, Pie Noon, we also made extensive use of Flatbuffers, Mathfu, fplutil, and WebP.

You can download the game in the Play Store and the latest open source release from our GitHub page. We invite you to learn from the code to see how you can apply these libraries and utilities in your own Android games. Take advantage of our discussion list if you have any questions, and don’t forget to toss some sushi around while you’re at it!

* Fun Propulsion Labs is a team within Google that's dedicated to advancing gaming on Android and other platforms.


Posted by Paul Kinlan, Chrome Developer Relations

Welcome to day two of the Chrome Dev Summit livestream 2015! Today, we’ll have a full day of sessions covering every aspect of performance on the web. Flipkart will also be joining us on stage later today to talk about their experience building a Progressive web app. Tune in to the livestream below. We look forward to engaging in the conversation with you at #ChromeDevSummit.


Posted by Sarah Clark, Program Manager, Google Developer Training

What do you need to stand out from the crowd of web developers, and ultimately, land that perfect job?

We asked ourselves that same question and decided to help by introducing the Senior Web Developer Nanodegree. Built in collaboration with Udacity, this online program is designed to teach you the tools, frameworks, and techniques needed to write robust code for progressive web applications that are secure and easy to use. Spending about 10 hours a week, most students can earn this Nanodegree credential in 9-12 months at a cost of $200 per month with 50% returned upon completion.

Along the way, you will also learn how to integrate new technologies, such as Service Worker and Web Components, and work extensively with Gulp and other tools. You’ll hear from Google experts, such as Ido Green, Jake Archibald (co-author of the Service Worker spec), Luke Wroblewski (author and strategist), Paul Bakaus (Studio 5 CTO, Zynga) and Alice Boxhall (author of the Chrome accessibility developer tools).

How can you get started? There are two different ways to participate. One option is the paid Nanodegree program, which includes code-level project reviews and feedback, coaching, support from a cohort of peers, building a portfolio of work, and career support services. The second option is entirely free and includes the same instructional courses, quizzes and projects individually, which you can take at your own pace.

For more details, and to be notified when enrollment opens, check out


Posted by Paul Kinlan, Chrome Developer Relations

Welcome to the Chrome Dev Summit livestream 2015! Today, Darin Fisher, VP of Chrome, has some exciting announcements and will speak about how the Chrome team is thinking about the future of the web. Tune in to the livestream below. We look forward to engaging in the conversation with you at #ChromeDevSummit.


Originally posted on Google Cloud Platform Blog

Posted by Benjamin Wulfe, Firebase

Firebase is a platform for building Android, iOS and web-based mobile apps, offering real-time data storage and automatic synchronization across devices. But what about when you need to run backend processes on the data? By connecting an App Engine application to your Firebase database, you can perform complex logic on the data without having to manage synchronization and updates; Firebase handles that for you. Updates in the Android client release of Firebase 2.4.0 make it easy to access a Firebase database from an App Engine application.
The tutorial, Use Firebase and Google App Engine in an Android App, walks you through the steps to create an Android app that stores a to-do list in Firebase, and uses backend logic running on App Engine to send daily reminder emails. In the process of working through the tutorial, you’ll learn how to use the following technologies:
  • Firebase — a platform for building mobile apps, offering realtime data storage and synchronization, user authentication, and more.
  • Android Studio — an Android development environment based on IntelliJ IDEA.
  • Cloud Tools for Android Studio — a set of tools included with Android Studio, that integrate with Google Cloud Platform services.
  • Google App Engine — an environment for running application code in the cloud; Platform as a service (PaaS).


Posted by Paul Kinlan, Chrome Developer Relations

The Chrome Dev Summit is almost here! We’ll kick off live from Mountain View, California at 9:00AM PT this coming Tuesday, November 17th. To get the most out of the event, make sure to check out the speaker list and talk schedule on our site.

Can’t join us in person? Don’t worry, we’ve got you covered! You can tune into the summit live on We will stream the keynote and all sessions over the course of the event. If you want us to send you a reminder to tune into the livestream, sign up here. We’ll also be publishing all of the talks as videos on the Chrome Developers YouTube Channel.

We’re looking forward to seeing you in person or remotely on Tuesday. Don’t forget to join the social conversations at #ChromeDevSummit!


Originally posted on Android Developer blog

Posted by Lily Sheringham, Developer Marketing at Google Play

Editor’s note: This is another post in our series featuring tips from developers finding success on Google Play. We recently spoke to games developer Kongregate, to find out how they use Store Listing Experiments successfully. - Ed.

With Store Listing Experiments in the Google Play Developer Console, you can conduct A/B tests on the content of your store listing pages. Test versions of the text and graphics to see which ones perform best, based on install data.

Kongregate increases installs by 45 percent with Store Listing Experiments

Founded in 2006 by brother and sister Jim and Emily Greer, Kongregate is a leading mobile games publisher specializing in free to play games. Kongregate used Store Listing Experiments to test new content for the Global Assault listing page on Google Play. By testing with different audience sizes, they found a new icon that drove 92 percent more installs, while variant screenshots achieved an impressive 14 percent improvement. By picking the icons, screenshots, and text descriptions that were the most sticky with users, Kongregate saw installs increase by 45 percent on the improved page.

Kongregate’s Mike Gordon, VP of Publishing; Peter Eykemans, Senior Producer; and Tammy Levy, Director of Product for Mobile Games, talk about how to successfully optimise mobile game listings with Store Listing Experiments.

Kongregate’s tips for success with Store Listing Experiments

Jeff Gurian, Sr. Director of Marketing at Kongregate also shares his do’s and don’ts on how to use experiments to convert more of your visitors, thereby increasing installs. Check them out below:

Do’s Don’ts
Do start by testing your game’s icon. Icons can have the greatest impact (positive or negative) on installs — so test early! Don’t test too many variables at once. It makes it harder to determine what drove results. The more variables you test, the more installs (and time) you’ll need to identify a winner.
Do have a question or objective in mind when designing an experiment. For example, does artwork visualizing gameplay drive more installs than artwork that doesn’t? Don’t test artwork only. Also test screenshot ordering, videos, and text to find what combinations increase installs.
Do run experiments long enough to achieve statistical significance. How long it takes to get a result can vary due to changes in traffic sources, location of users, and other factors during testing. Don’t target too small an audience with your experiment variants. The more users you expose to your variants, the more data you collect, the faster you get results!
Do pay attention to the banner, which tells you if your experiment is still “in progress.” When it has collected enough data, the banner will clearly tell you which variant won or if it was a tie. Don’t interpret a test where the control attribute performs better than variants as a waste. You can still learn valuable lessons from what “didn’t work.” Iterate and try again!

Learn more about how Kongregate optimized their Play Store listing with Store Listing Experiments. Learn more about Google Play products and best practices to help you grow your business globally.


Posted by Gayathri Rajan & Ryan Cairns

Earlier this year at Google I/O, we previewed Brillo and Weave, our complete solution for building connected devices. Since May, we’ve opened up the Brillo operating system (OS) and Weave communication platform to early access partners. Today, we’re extending this to the broader developer community as part of our invite program. Read on to find out how you can receive an invitation.

Brillo brings the simplicity and speed of software development to hardware by offering you a lightweight embedded OS based on Android, core services, a developer kit, and a developer console. You can choose from a variety of hardware capabilities and customization options, quickly move from prototype to production, and manage at scale with over the air (OTA) updates, metrics, and crash reporting.

Watch this video to learn more about Brillo:

Once you’ve built your connected device, you’ll need to find a way for it to communicate with other devices and allow users to interact with it. That’s where Weave comes in. With Weave, you can build interoperable communications directly into your devices. Weave provides a messaging service that enables phones and devices to talk to each other locally and remotely through the cloud. The Weave cloud server handles remote communication and access to your web-connected device, safely and at scale. With Weave you also get a set of services to securely set up the device and provide controlled access. Additionally, Weave works seamlessly with, and is actually built right into, Brillo; but, you can also use Weave libraries with your existing Linux-based OS.

Check out this video we created to help you understand the power of Weave:

Weave comes with a mobile SDK for both iOS and Android, so that you can build apps to control and enhance the connected device experience for mobile users. If you’re an app developer interested in extending the reach of your apps to the physical world of devices, you can use Weave mobile and web APIs to control multiple Weave devices across brands in a single app.

Both Brillo and Weave are open, extensible, and secure by default to support a variety of devices and use cases. Brillo and Weave provide the platform, tools and services, so you can do what you do best: build great device and app experiences.

In addition to the Brillo and Weave platforms, we’re also unveiling our Weave compatibility program to ship certified Weave-branded devices as well as a hardware program for silicon vendors to build and sell Brillo-compliant hardware.

If you’d like to be part of our developer invite program, visit our website and request an invite. We’ll send you more details as well as access to our code, documentation and developer console. We look forward to making the Internet of Things better, together!


Posted by Takeshi Hagikura, Yuichi Araki, Developer Programs Engineer

Originally posted on Google Android Developer blog

As we announced in the previous blog post, Android 6.0 Marshmallow is now publicly available to users. Along the way, we’ve been updating our samples collection to highlight exciting new features available to developers.

This week, we’re releasing AsymmetricFingerprintDialog, a new sample demonstrating how to securely integrate with compatible fingerprint readers (like Nexus Imprint) in a client/server environment.

Let’s take a closer look at how this sample works, and talk about how it complements the FingerprintDialog sample we released earlier during the public preview.

Symmetric vs Asymmetric Keys

The Android Fingerprint API protects user privacy by keeping users’ fingerprint features carefully contained within secure hardware on the device. This guards against malicious actors, ensuring that users can safely use their fingerprint, even in untrusted applications.

Android also provides protection for application developers, providing assurances that a user’s fingerprint has been positively identified before providing access to secure data or resources. This protects against tampered applications, providing cryptographic-level security for both offline data and online interactions.

When a user activates their fingerprint reader, they’re unlocking a hardware-backed cryptographic vault. As a developer, you can choose what type of key material is stored in that vault, depending on the needs of your application:

  • Symmetric keys: Similar to a password, symmetric keys allow encrypting local data. This is a good choice securing access to databases or offline files.
  • Asymmetric keys: Provides a key pair, comprised of a public key and a private key. The public key can be safely sent across the internet and stored on a remote server. The private key can later be used to sign data, such that the signature can be verified using the public key. Signed data cannot be tampered with, and positively identifies the original author of that data. In this way, asymmetric keys can be used for network login and authenticating online transactions. Similarly, the public key can be used to encrypt data, such that the data can only be decrypted with the private key.

This sample demonstrates how to use an asymmetric key, in the context of authenticating an online purchase. If you’re curious about using symmetric keys instead, take a look at the FingerprintDialog sample that was published earlier.

Here is a visual explanation of how the Android app, the user, and the backend fit together using the asymmetric key flow:

1. Setting Up: Creating an asymmetric keypair

First you need to create an asymmetric key pair as follows:

KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
        new KeyGenParameterSpec.Builder(KEY_NAME,
                .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))

Note that .setUserAuthenticationRequired(true) requires that the user authenticate with a registered fingerprint to authorize every use of the private key.

Then you can retrieve the created private and public keys with as follows:

KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
PublicKey publicKey =

KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
PrivateKey key = (PrivateKey) keyStore.getKey(KEY_NAME, null);

2. Registering: Enrolling the public key with your server

Second, you need to transmit the public key to your backend so that in the future the backend can verify that transactions were authorized by the user (i.e. signed by the private key corresponding to this public key). This sample uses the fake backend implementation for reference, so it mimics the transmission of the public key, but in real life you need to transmit the public key over the network.

boolean enroll(String userId, String password, PublicKey publicKey);

3. Let’s Go: Signing transactions with a fingerprint

To allow the user to authenticate the transaction, e.g. to purchase an item, prompt the user to touch the fingerprint sensor.

Then start listening for a fingerprint as follows:

KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
PrivateKey key = (PrivateKey) keyStore.getKey(KEY_NAME, null);
CryptoObject cryptObject = new FingerprintManager.CryptoObject(signature);

CancellationSignal cancellationSignal = new CancellationSignal();
FingerprintManager fingerprintManager =
fingerprintManager.authenticate(cryptoObject, cancellationSignal, 0, this, null);

4. Finishing Up: Sending the data to your backend and verifying

After successful authentication, send the signed piece of data (in this sample, the contents of a purchase transaction) to the backend, like so:

Signature signature = cryptoObject.getSignature();
// Include a client nonce in the transaction so that the nonce is also signed 
// by the private key and the backend can verify that the same nonce can't be used 
// to prevent replay attacks.
Transaction transaction = new Transaction("user", 1, new SecureRandom().nextLong());
try {
    byte[] sigBytes = signature.sign();
    // Send the transaction and signedTransaction to the dummy backend
    if (mStoreBackend.verify(transaction, sigBytes)) {
    } else {
} catch (SignatureException e) {
    throw new RuntimeException(e);

Last, verify the signed data in the backend using the public key enrolled in step 2:

public boolean verify(Transaction transaction, byte[] transactionSignature) {
    try {
        if (mReceivedTransactions.contains(transaction)) {
            // It verifies the equality of the transaction including the client nonce
            // So attackers can't do replay attacks.
            return false;
        PublicKey publicKey = mPublicKeys.get(transaction.getUserId());
        Signature verificationFunction = Signature.getInstance("SHA256withECDSA");
        if (verificationFunction.verify(transactionSignature)) {
            // Transaction is verified with the public key associated with the user
            // Do some post purchase processing in the server
            return true;
    } catch (NoSuchAlgorithmException | InvalidKeyException | SignatureException e) {
        // In a real world, better to send some error message to the user
    return false;

At this point, you can assume that the user is correctly authenticated with their fingerprints because as noted in step 1, user authentication is required before every use of the private key. Let’s do the post processing in the backend and tell the user that the transaction is successful!

Other updated samples

We also have a couple of Marshmallow-related updates to the Android For Work APIs this month for you to peruse:

  • AppRestrictionEnforcer and AppRestrictionSchema These samples were originally released when the App Restriction feature was introduced as a part of Android for Work API in Android 5.0 Lollipop. AppRestrictionEnforcer demonstrates how to set restriction to other apps as a profile owner. AppRestrictionSchema defines some restrictions that can be controlled by AppRestrictionEnforcer. This update shows how to use 2 additional restriction types introduced in Android 6.0.
  • We hope you enjoy the updated samples. If you have any questions regarding the samples, please visit us on our GitHub page and file issues or send us pull requests.