19 Dec 2014

feedAndroid Developers Blog

Build Mobile App Services with Google Cloud Tools for Android Studio v1.0

Posted by Chris Sells, Product Manager, Cloud Tools for Android Studio

Cloud Tools for Android Studio allows you to simultaneously build the service- and client-side of your mobile app. Earlier this month, we announced the release of Android Studio 1.0 that showed just how much raw functionality there is available for Android app developers. However, the client isn't the whole picture, as most mobile apps also need one or more web services. It was for this reason that the Cloud Tools for Android Studio were created.

Cloud Tools put the power of Google App Engine in the same IDE alongside of your mobile client, giving you all the same Java language tools for both sides of your app, as well as making it far easier for you to keep them in sync as each of them changes.

Getting Started

To get started with Cloud Tools for Android Studio, add a New Module to your Android Studio project, choose Google Cloud Module and you'll have three choices:

You can add three Google Cloud module types to your Android Studio project

The Java Servlet Module gives you a plain servlet class for you to implement as you see fit. If you'd like help building your REST endpoints with declarative routing and HTTP verbs and automatic Java object serialization to and from JSON, then you'll want the Java Endpoints Module. If you want the power of endpoints, along with the ability to send notifications from your server to your clients, then choose Backend with Google Cloud Messaging.

Once you're done, you'll have your service code right next to your client code:

You can build your mobile app's client and service code together in a single project

Not only does this make it very convenient to build and test your entire end-to-end, but we also dropped a little extra something into your app's build.gradle file:

The android-endpoints configuration build step in your build.gradle file creates a client-side library for your server-side endpoint

The updated Gradle file will now create a library for use in your app's client code that changes when your service API changes. This library lets you call into your service from your client and provides full code completion as you do:

The client-side endpoint library provides code completion and documentation


Instead of writing the code to create HTTP requests by hand, you can make calls via the library in a typesafe manner and the marshalling from JSON to Java will be handled for you, just like on the server-side (but in reverse, of course).

Endpoints Error Detection

Meanwhile, back on the server-side, as you make changes to your endpoints, we're watching to make sure that they're in good working order even before you compile by checking the attributes as you type:

Cloud Tools will detect errors in your endpoint attributes


Here, Cloud Tools have found a duplicate name in the ApiMethod attribute, which is easy to do if you're creating a new method from an existing method.

Creating an Endpoint from an Objectify Entity

If, as part of your endpoint implementation, you decide to take advantage of the popular Objectify library, you'll find that Cloud Tools provides special support for you. When you right-click (or control-click on the Mac) on a file containing an Objectify entity class, you'll get the Generate Cloud Endpoint from Java class option:

The generate Cloud Endpoint from Java class option will create a CRUD endpoint for you


If you're running this option on a Java class that isn't built with Objectify, then you're going to get an endpoint with empty methods for get and insert operations that you can implement as appropriate. However, if you do this with an Objectify entity, you'll get a fully implemented endpoint:

Cloud Tools has built-in support for generating Objectify-based cloud endpoint implementations


Using your Cloud Endpoint

As an Android developer, you're used to deploying your client first in the emulator and then into a local device. Likewise, with the service, you'll want to test first to your local machine and then, when you're ready, deploy into a Google App Engine project. You can run your service app locally by simply choosing it from the Configurations menu dropdown on the toolbar and pressing the Run button:

The Configurations menu in the toolbar lets you launch your service for testing


This will build and execute your service on http://localhost:8080/ (by default) so that you can test against it with your Android app running in the emulator. Once you're ready to deploy to Google Cloud Platform, you can do so by selecting the Deploy Module to App Engine option from the Build menu, where you'll be able to choose the source module you want to deploy, log into your Google account and pick the target project to which you'd like to deploy:

The Deploy to App Engine dialog will use your Google credentials to enumerate your projects for you


Cloud Tools beta required some extra copying and pasting to get the Google login to work, but all of that's gone now in this release.

What's Next?

We're excited to get this release into your hands, so if you've haven't downloaded it yet, then go download Android Studio 1.0 right now! To take advantage of Cloud Tools for Android Studio, you'll want to sign up for a free Google Cloud Platform trial. Nothing is stopping you from building great Android apps from front to back. If you've got suggestions, drop us a line so that we can keep improving. We're just getting started putting Google Cloud Platform tools in your hands. We can't wait to see what you'll build.

Join the discussion on

+Android Developers

19 Dec 2014 9:41pm GMT

Google Play game services ends year with a bang!

Posted by Benjamin Frenkel, Product Manager, Play Games

In an effort to supercharge our Google Play games services (GPGS) developer tools, we're introducing the Game services Publishing API, a revamped Unity Plugin, additional enhancements to the C++ SDK, and improved Leaderboard Tamper Protection.

Let's dig into what's new for developers:

Publishing API to automate game services configuration

At Google I/O this past June, the pubsite team launched the Google Play Developer Publishing APIs to automate the configuration and publishing of applications to the Play store. Game developers can now also use the Google Play game services Publishing API to automate the configuration and publishing of game services resources, starting with achievements and leaderboards.

For example, if you plan on publishing your game in multiple languages, the game services Publishing API will enable you to pull translation data from spreadsheets, CSVs, or a Content Management System (CMS) and automatically apply those translations to your achievements.

Early adopter Square Enix believes the game services Publishing API will be an indispensable tool to manage global game rollouts:


Achievements are the most used feature in Google Play game services for us. As our games support more languages, achievement management has become increasingly difficult. With the game services Publishing API, we can automate this process, which is really helpful. The game services Publishing API also comes with great samples that we were able to easily customize for our needs

Keisuke Hata, Manager / Technical Director, SQUARE ENIX Co., Ltd.





To get started today, take a look at the developer documentation here.

Updated Unity plugin and Cross-platform C++ SDK

We also include some important bug fixes and stability improvements. Check out the release notes for the Unity Plugin and the getting started page for the C++ SDK for more details.

Leaderboard Tamper Protection

Turn on Leaderboard Tamper Protection to automatically hide suspected tampered scores from your leaderboards. To enable tamper protection on an existing leaderboard, go to your leaderboard in the Play developer console and flip the "Leaderboard tamper protection" toggle to on. Tamper protection will be on by default for new leaderboards.Learn more.

To learn more about cleaning up previously submitted suspicious scores refer to the Google Play game services Management APIs documentation or get the web demo console for the Management API directly from github here.

In addition, if you prefer command-line tools, you can use the python-based option here.

Join the discussion on

+Android Developers

19 Dec 2014 7:26pm GMT

18 Dec 2014

feedAndroid Developers Blog

Making a performant watch face

Posted by Hoi Lam, Developer Advocate, Android Wear

What's a better holiday gift than great performance? You've got a great watch face idea -- now, you want to make sure the face you're presenting to the world is one of care and attention to detail.

At the core of the watch face's process is an onDraw method for canvas operations. This allows maximum flexibility for your design, but also comes with a few performance caveats. In this blog post, we will mainly focus on performance using the real life journey of how we optimised the Santa Tracker watch face, more than doubling the number of fps (from 18 fps to 42 fps) and making the animation sub-pixel smooth.

Starting point - 18 fps

Our Santa watch face contains a number of overlapping bitmaps that are used to achieve our final image. Here's a list of them from bottom to top:

  1. Background (static)
  2. Clouds which move to the middle
  3. Tick marks (static)
  4. Santa figure and sledge (static)
  5. Santa's hands - hours and minutes
  6. Santa's head (static)

The journey begins with these images...

Large images kill performance (+14 fps)

Image size is critical to performance in a Wear application, especially if the images will be scaled and rotated. Wasted pixel space (like Santa's arm here) is a common asset mistake:

Before: 584 x 584 = 341,056 pixels After: 48*226 = 10,848 (97% reduction)

It's tempting to use bitmaps from the original mock up that have the exact location of watch arms and components in absolute space. Sadly, this creates problems, like in Santa's arm here. While the arm is in the correct position, even transparent pixels increase the size of the image, which can cause performance problems due to memory fetch. You'll want to work with your design team to extract padding and rotational information from the images, and rely on the system to apply the transformations on our behalf.

Since the original image covers the entire screen, even though the bitmap is mostly transparent, the system still needs to check every pixel to see if they have been impacted. Cutting down the area results in significant gains in performance. After correcting both of the arms, the Santa watch face frame rate increased by 10 fps to 28 fps (fps up 56%). We saved another 4 fps (fps up 22%) by cropping Santa's face and figure layer. 14 fps gained, not bad!

Combine Bitmaps (+7 fps)

Although it would be ideal to have the watch tick marks on top of our clouds, it actually does not make much difference visually as the clouds themselves are transparent. Therefore there is an opportunity to combine the background with the ticks.

+

When we combined these two views together, it meant that the watch needed to spend less time doing alpha blending operations between them, saving precious GPU time. So, consider collapsing alpha blended resources wherever we can in order to increase performance. By combining two full screen bitmaps, we were able to gain another 7 fps (fps up 39%).

Anti-alias vs FilterBitmap flags - what should you use? (+2 fps)

Android Wear watches come in all shapes and sizes. As a result, it is sometimes necessary to resize a bitmap before drawing on the screen. However, it is not always clear what options developers should select to make sure that the bitmap comes out smoothly. With canvas.drawBitmap, developers need to feed in a Paint object. There are two important options to set - they are anti-alias and FilterBitmap. Here's our advice:

18 Dec 2014 9:23pm GMT