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:
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.
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.
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.
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:
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:
First you need to create an asymmetric key pair as follows:
KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore"); keyPairGenerator.initialize( new KeyGenParameterSpec.Builder(KEY_NAME, KeyProperties.PURPOSE_SIGN) .setDigests(KeyProperties.DIGEST_SHA256) .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1")) .setUserAuthenticationRequired(true) .build()); keyPairGenerator.generateKeyPair();
Note that .setUserAuthenticationRequired(true) requires that the user authenticate with a registered fingerprint to authorize every use of the private key.
.setUserAuthenticationRequired(true)
Then you can retrieve the created private and public keys with as follows:
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore"); keyStore.load(null); PublicKey publicKey = keyStore.getCertificate(MainActivity.KEY_NAME).getPublicKey(); KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore"); keyStore.load(null); PrivateKey key = (PrivateKey) keyStore.getKey(KEY_NAME, null);
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);
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:
Signature.getInstance("SHA256withECDSA"); KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore"); keyStore.load(null); PrivateKey key = (PrivateKey) keyStore.getKey(KEY_NAME, null); signature.initSign(key); CryptoObject cryptObject = new FingerprintManager.CryptoObject(signature); CancellationSignal cancellationSignal = new CancellationSignal(); FingerprintManager fingerprintManager = context.getSystemService(FingerprintManager.class); fingerprintManager.authenticate(cryptoObject, cancellationSignal, 0, this, null);
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 { signature.update(transaction.toByteArray()); byte[] sigBytes = signature.sign(); // Send the transaction and signedTransaction to the dummy backend if (mStoreBackend.verify(transaction, sigBytes)) { mActivity.onPurchased(sigBytes); dismiss(); } else { mActivity.onPurchaseFailed(); dismiss(); } } catch (SignatureException e) { throw new RuntimeException(e); }
Last, verify the signed data in the backend using the public key enrolled in step 2:
@Override 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; } mReceivedTransactions.add(transaction); PublicKey publicKey = mPublicKeys.get(transaction.getUserId()); Signature verificationFunction = Signature.getInstance("SHA256withECDSA"); verificationFunction.initVerify(publicKey); verificationFunction.update(transaction.toByteArray()); 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!
We also have a couple of Marshmallow-related updates to the Android For Work APIs this month for you to peruse:
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.
Posted by Mugur Marculescu, Product Manager
The gRPC team is excited to announce the immediate availability of gRPC Beta. This release marks an important point in API stability and going forward most API changes are expected to be additive in nature. This milestone opens the door for gRPC use in production environments.
We’re also taking a big step forward in improving the installation process. Over the past few weeks, we’ve rolled out gRPC packages to Debian Stable/Backports. Installation in most cases is now a two line install using the Debian package and available language specific package managers (e.g. maven, pip, gem, composer, pecl, npm, nuget, pod). In addition gRPC docker images are now available on Docker Hub.
We’ve updated the documentation on grpc.io to reflect the latest changes and released additional language-specific reference docs. See what’s changed with the Beta release in the release notes on Github for Java, Go and all other languages.
In the coming months, the focus of the gRPC project will be to keep improving performance and stability and adding carefully chosen features for production use cases. This is part of our principles and goals to enable highly performant and scalable APIs and microservices on top of HTTP/2. Documentation will also be clarified and will continue to improve with new examples and guides.
We’ve been very excited to see the community response to gRPC and the various projects starting to use it (etcd v3 experimental api, grpc-gateway for RESTful APIs and others). We really want to thank everyone who contributed code, gave presentations, adopted the technology and engaged in the community. With your help support we look forward to the 1.0!
Posted by Shanea King-Roberson, Program Manager
As a developer, writing your app is important. But even more important is getting it into the hands of users. Ideally millions of users. To that end, you can now learn what it takes to design, validate, prototype, monetize, and market app ideas from the ground up and grow them into a scalable business with the new Tech Entrepreneur Nanodegree.
Designed by Google in partnership with Udacity, the Tech Entrepreneur Nanodegree, takes 4-7 months to complete. We have teamed up with most successful thought leaders in this space to provide students with a unique and battle-tested perspective. You’ll meet Geoffrey Moore, author of “Crossing the Chasm”, Pete Koomen, co-founder of Optimizely; Aaron Harris and Kevin Hale, Partners at Y-Combinator; Nir Eyal, author of the book “Hooked: How to build habit forming products” and co-founder of Product Hunt; Steve Chen, Co-Founder of YouTube, rapid prototyping company InVision and many more.
All of the content that make up this nanodegree is available online for free at udacity.com/google. In addition, Udacity provides paid services, including access to coaches, guidance on your project, help staying on track, career counseling, and a certificate when you complete the nanodegree.
The Tech Entrepreneur offering will consist of the following courses:
Upon completion, students will receive a joint certificate from Udacity and Google. The top graduates will also be invited to an exclusive pitch event, where they will have the opportunity to pitch their final product to venture capitalists at Google.
Originally posted on Google Apps Developer Blog
Posted by Saurabh Gupta, Product Manager, Google Apps Script
Back in December 2014, we announced the IFRAME sandbox mode for HtmlService which has helped improve the speed of an application’s user interface (UI). It also gives users a choice of using a variety of JS libraries on the client. We have been working hard to improve IFRAME sandbox mode and have added many features since then, including: Firefox support, file uploads, top navigation support, and improved Google Picker API support. Since IFRAME sandbox provides faster UIs and has more capabilities than NATIVE and EMULATED modes, developers should only be using IFRAME sandbox mode moving forward.
As of today, both EMULATED and NATIVE modes in HtmlService are deprecated. Over the next few months, we plan on sunsetting both EMULATED and NATIVE modes in stages to give you enough time to migrate your scripts.
We have created a migration guide to help you with this transition. For many scripts, no changes will be needed, unless they use a small set of features described in the migration guide. The guide also describes a few potential breaking changes. It is important that you review all your scripts that use HtmlService to ensure that the switch to IFRAME sandbox mode does not cause them to fail.
Here’s the timeline:
In November 2015, all new scripts will default to IFRAME sandbox mode unless NATIVE mode is explicitly specified. For example, if you make a copy of an existing script, the new script will use IFRAME sandbox mode unless you have explicitly set the sandbox mode to NATIVE.
In December 2015 (see sunset schedule for exact dates), EMULATED mode will be shutdown. Any scripts explicitly using EMULATED mode will default to IFRAME sandbox mode.
On April 28th, 2016, all scripts will default to IFRAME sandbox unless you have explicitly specified NATIVE mode in your script. For example, if your script has not specified any mode, then it will change from using NATIVE mode to IFRAME sandbox mode. Please make sure that your UI works well in IFRAME sandbox mode.
On June 30th 2016, NATIVE mode will be shutdown. All scripts explicitly using NATIVE mode will default to IFRAME sandbox mode.
While deprecations may at times seem inconvenient, this staged deprecation should ease in the migration process. Our goal is to provide a modern and secure environment enabling developers to create great apps for their users with Google Apps Script.
Posted by Wesley Chun, Developer Advocate, Google Apps
Happy Monday! Have you ever been asked by your boss to do something simple (good) but long and tedious (bad)? Take for example, the simple task of counting up all of the YouTube views for your corporate videos and your competitors’. It doesn’t even have to be your boss. What if you and your gamer friends are competing to see whose gameplay clips are garnering the most attention? It’s easy to manually track ten videos, but how about 100 or even 1,000? While simple -- you can visit the YouTube to grab the view count for each video -- you know the real problem with a task like this is that you don’t scale with the amount of content, so it’s better to automate with a simple app instead. This is the exact scenario that my colleagues and I set out to address in the latest episode of the Launchpad Online, introducing users to a pair of Google developer tools that can help solve this particular problem:
The first developer tool covered is the YouTube Data API. You can access it like most modern Google APIs from your preferred programming environment using one of the Google APIs Client Libraries. However, this type of data generally lives in a spreadsheet, and if you’re using Google Sheets, you can instead write the app with Google Apps Script, a JavaScript environment running in Google’s cloud that, if authorized, can write that video information to the cells in your Sheet. YouTube is just one of the many supported services available to Apps Script developers.
As with all my Launchpad Online episodes, I walk you through a short code snippet (only eight lines this time) that will get you started building your own custom solution. If you’re new to the developer series, we share technical content aimed at novice Google developers… current tools with a little bit of code to help you launch your next app. Please give us your feedback below and tell us what topics you would like to see in future episodes!
Posted by Brandon Wuest, Software Engineer & Stereoscopic Sightseer
Google Cardboard is bringing virtual reality worldwide. Starting today, the Google Cardboard app is available in 39 languages and over 100 countries on both Android and iOS devices. Additionally, the Cardboard developer docs are now published in 10 languages to help developers build great VR experiences. With more than 15 million installs of Cardboard apps from Google Play, we're excited to bring VR to even more people around the world.
Anyone can make their own Cardboard viewer with the open designs ready for download. If you'd rather not DIY, choose from the growing family of certified viewers, including the Mattel View-Master and Zeiss VR One GX, on sale now.
The Cardboard SDKs for Android and Unity have been updated to address your top two requests: drift correction and Unity performance. This update includes a major overhaul of the sensor fusion algorithms that integrate the signals from the gyroscope and accelerometer. These improvements substantially decrease drift, especially on phones with lower-quality sensors. The Cardboard SDK for Unity now supports a fully Unity-native distortion pass. This improves performance by avoiding all major plugin overhead, and enables Cardboard apps to work with Metal rendering on iOS and multi-threaded rendering on Android. All of this adds up to better VR experiences for your users.
Finally, to help bring you to more places, you can now explore Google Street View in Cardboard. So, download the updated Google Street View app for Android or iOS, and grab your Cardboard to immerse yourself in destinations around the world.
With Cardboard available in more places, we're hoping to bring the world just a little bit closer to everyone. Happy exploring!
