Author Archives: Reto Meier

Always-on and Wi-Fi with the latest Android Wear update

Posted by Wayne Piekarski, Developer Advocate

A new update to Android Wear is rolling out with lots of new features like always-on apps, Wi-Fi connectivity, media browsing, emoji input, and more. Let’s discuss some of the great new capabilities that are available in this release.

Always-on apps

Above all, a watch should make it easy to tell the time. That's why most Android Wear watches have always-on displays, so you can see the time without having to shake your wrist or lift your arm to wake up the display. In this release, we're making it possible for apps to be always-on as well.

With always-on functionality, your app can display dynamic data on the device, even when the app is in ambient mode. This is useful if your app displays information that is continuously updated. For example, running apps like Endomondo, MapMyRun, and Runtastic use the always-on screen to let you keep track of how long and far you’ve been running. Zillow keeps you posted about the median price of homes nearby when you’re house-hunting.

Always-on functionality is also useful for apps that may not update data very frequently, but present information that’s useful for reference over a longer period of time. For example, Bring! lets you keep your shopping list right on your wrist, and Golfshot gives you accurate distances from tee to pin. If you’re at the airport and making your way to your gate, American Airlines, Delta, and KLM let you keep all of your flight info a glance away on your watch.

Note: the above apps will not display always-on functionality on your watch until you receive the update for the latest version of Android Wear.

Always-on functionality works similar to watch faces, in that the power usage of the display and processor is kept to a minimum by reducing the colors and refresh rate of the display. To implement an always-on Activity, you need to make a few small changes to your app's AndroidManifest.xml, your app’s build.gradle, and the Activity to declare that it supports ambient mode. A code sample and documentation are available to show you how it works. Be sure to tune in to the livestream at Google I/O next week for Android Wear: Your app and the always-on screen.

Wi-Fi connectivity and cloud sync

Many existing Android Wear devices already contain hardware support for Wi-Fi, and this release enables software support for Wi-Fi. The saved Wi-Fi networks on your phone are copied to your watch during setup, and your watch automatically connects to those Wi-Fi networks when it loses Bluetooth connection to your phone. Your watch can then connect to your phone over the Internet, even if they’re not on the same Wi-Fi network.

You should continue to use the Data Layer API for all communications between the watch and phone. By using this standard API, your app will always work, no matter what kind of connectivity the user’s wearable supports. Cloud sync also introduces a new virtual node in the Data Layer called the cloud node, which may be returned in calls to getConnectedNodes(). Learn more in the Multi-wearable support section below.

Multi-wearable support

The release of Google Play services 7.3 now allows support for multiple wearable devices to be paired simultaneously to a single phone or tablet, so you can have a wearable for fitness, and another for dressing up. While DataItems will continue to work in the same way, since they are synchronized to all devices, working with the MessageApi is a little different. When you update your build.gradle to use version 7.3 or higher, getConnectedNodes() from the NodeApi will usually return multiple nodes. There is an extra virtual node added to represent the cloud node used to communicate over Wi-Fi, so all developers need to deal with this situation in their code.

To help simplify finding the right node among many devices, we have added a CapabilityApi, allowing your nodes to announce features they provide, for example downloading images or music. You can also now use the ChannelApi to open up a connection to a specific device to transfer large resources such as images or audio streams, without having to send them to all devices like you would when embedding assets into data items. We have updated our Android Wear samples and documentation to show the best practices in implementing this.

MediaBrowser support

The Android 5.0 release added the ability for apps to browse the media content of another app, via the android.media.browse API. With the latest Android Wear update, if your media playback app supports this API, then you will be able to browse to find the next song directly from your watch. This is the same browse capability used in Android Auto. You implement the API once, and it will work across a variety of platforms. To do so, you just need to allow Android Wear to browse your app in the onGetRoot() method validator. You can also add custom actions to the MediaSession that will appear as controls on the watch. We have a Universal Media Player sample that shows you how to implement this functionality.

Updates to existing devices

The latest version of Android Wear will roll out via an over-the-air (OTA) update to all Android Wear watches over the coming weeks. To take advantage of these new features, you will need to use targetSdkVersion 22 and add the necessary dependencies for always-on support. We have also expanded the collection of emulators available via the SDK Manager, to simulate the experience on all the currently available devices, resolutions, and shapes, including insets like the Moto 360.

In this update, we have also disabled support for apps that use the unofficial, activity-based approach for displaying watch faces, as announced in December. These watch faces will no longer work and should be updated to use the new watch face API.

Since the launch of Android Wear last summer, Android Wear has grown into a platform that gives users many possibilities to personalize their watches, with a variety of shapes and styles, a range of watch bands, and thousands of apps and watch faces. Features such as always-on apps and Wi-Fi allow developers even more flexibility to give users amazing experiences with Android Wear.

Android Developer Story: Wooga’s fast iterations on Android and Google Play

Posted by Leticia Lago, Google Play team

In order to make the best possible games, Wooga works on roughly 40 concepts and prototypes per year, out of which 10 go into production, around seven soft launch, and only two make it to global launch. It’s what they call “the hit filter." For their latest title, Agent Alice, they follow up with new episodes every week to maintain player interest and engagement over time.

The ability to quickly iterate both live and under development games is therefore key to Wooga’s business model — Android and Google Play provide them the tools they need and mean that new features and updates are made on Android first, before they get to other platforms.

Find out more from Sebastian Kriese, Head of Partnerships, and Pal Tamas Feher, Head of Engineering, and learn how the iteration features of Android and Google Play have contributed to successes such as Diamond Dash, Jelly Splash, and Agent Alice.

You can find out more about building successful games businesses on Android and Google Play at Google I/O 2015: in person, on the live stream, or session recordings after the event. Check out the following:

  • Developers connecting the world through Google Play - Hear how the new mobile ecosystem including Google Play and Android are empowering developers to make good on the dream of connecting the world through technology to improve people's lives. This session will be live streamed.
  • Growing games with Google — In addition to consoles, PC, and browser gaming, as well as phone and tablet games, there are emerging fields including virtual reality and mobile games in the living room. This talk covers how Google is helping developers across this broad range of platforms. This session will be live streamed.
  • What’s new in the Google Play Developer Console - Google Play’s new launches will help you acquire more users and improve the quality of your app. Hear an overview of the latest features and how you can start taking advantage of them in the Developer Console.
  • Smarter approaches to app testing — Hear about the new ways Google can help maximize the success of your next app launch with cheaper and easier testing strategies.

Exercise or Games? Why Not Both!

Posted by Alice Ching, Google Engineer

We are pleased to announce the release of Games in Motion, an open source game sample to demonstrate how developers can make fun games using Google Fit and Android Wear. Do you ever go on a jog and feel like there is a lack of incentive to help you run better? What if you were a secret agent and had to use your speed and your nifty gadget to complete missions?

With Games in Motion, you can enhance your exercise with missions and actions on your Android Wear device, while logging your jogs to the cloud.

Games in Motion is written in Java programming language using Android Studio. It demonstrates multiple Android technologies.

  • Android Wear bridges notifications from a phone or tablet to a paired Android Wear device. The notifications are stacked so we can show multiple stats at the same time.
  • Google Fit API collects and processes fitness data and sessions. This allows us to use the fitness data to show user progress. All exercise sessions done in Games in Motion will be recorded to Google Fit as well.
  • Google Play Games Services is used to create and unlock achievements.
  • Several different Android audio APIs are integrated.
  • JUnit tests are present for the data-driven parser, which demonstrates how unit testing can be done within Android Studio.

You can download the latest open source release from GitHub. We hope to inspire similar Android games, where multiple different form factors are combined for a fun experience.

Android Developer Story: The Hunt — Increased engagement with material design and Google Play

Posted by Laura Della Torre, Google Play team

We've been in San Francisco talking with the team from The Hunt — a style and product sharing community. They've recently lifted the rate at which Android users start hunts to 20 percent after successfully implementing material design in the app, which is a 30 percent improvement over other platforms. As The Hunt’s Product Designer Jenny Davis puts it, “it felt like having a team of design experts on hand,” which lets them focus on what matters to the Android user.

But as we find out, that's not the whole story. Beta testing — managed from the Google Play Developer Console — also allowed them to iterate design and features daily. Based on feedback, they introduced the floating action button, which helped boost new hunts and helpful responses from the community. This speed and freedom is something the team thought possible only with their mobile website, until they started working with the Android tools.

Watch the video to discover more about how design and rapid iteration has been key to building a strong community.

Learn about using the tools that have helped improve user engagement for The Hunt:

  • Material design — learn more about material design and how it helps you create beautiful, engaging apps.
  • Beta testing — discover how to easily deliver test versions of your app to users for feedback before release.

Integrate Play data into your workflow with data exports

Posted by Frederic Mayot, Google Play team

The Google Play Developer Console makes a wealth of data available to you so you have the insight needed to successfully publish, grow, and monetize your apps and games. We appreciate that some developers want to access and analyze their data beyond the visualization offered today in the Developer Console, which is why we’ve made financial information, crash data, and user reviews available for export. We're now also making all the statistics on your apps and games (installs, ratings, GCM usage, etc.) accessible via Google Cloud Storage.

New Reports section in the Google Play Developer Console

We’ve added a Reports tab to the Developer Console so that you can view and access all available data exports in one place.

A reliable way to access Google Play data

This is the easiest and most reliable way to download your Google Play Developer Console statistics. You can access all of your reports, including install statistics, reviews, crashes, and revenue.

Programmatic access to Google Play data

This new Google Cloud Storage access will open up a wealth of possibilities. For instance, you can now programmatically:

  • import install and revenue data into your in-house dashboard
  • run custom analysis
  • import crashes and ANRs into your bug tracker
  • import reviews into your CRM to monitor feedback and reply to your users

Your data is available in a Google Cloud Storage bucket, which is most easily accessed using gsutil. To get started, follow these three simple steps to access your reports:

  1. Install the gsutil tool.
    • Authenticate to your account using your Google Play Developer Console credentials.
  2. Find your reporting bucket ID on the new Reports section.
    • Your bucket ID begins with: pubsite_prod_rev (example:pubsite_prod_rev_1234567890)
  3. Use the gsutil ls command to list directories/reports and gsutil cp to copy the reports. Your reports are organized in directories by package name, as well as year and month of their creation.

Read more about exporting report data in the Google Play Developer Help Center.

Note about data ownership on Google Play and Cloud Platform: Your Google Play developer account is gaining access to a dedicated, read-only Google Cloud Storage bucket owned by Google Play. If you’re a Google Cloud Storage customer, the rest of your data is unaffected and not connected to your Google Play developer account. Google Cloud Storage customers can find out more about their data storage on the terms of service page.

There’s a lot to explore with Google Play services 7.3

Posted by Ian Lake, Developer Advocate

Today, we’re excited to give you new tools to build better apps with the rollout of Google Play services 7.3. With new Android Wear APIs, the addition of nutrition data to Google Fit, improvements to retrieving the user’s activity and location, and better support for optional APIs, there’s a lot to explore in this release.

Android Wear

Google Play services 7.3 extends the Android Wear network by enabling you to connect multiple Wear devices to a single mobile device.

While the DataApi will automatically sync DataItems across all nodes in the Wear network, the directed nature of the MessageApi is faced with new challenges. What node do you send a message to when the NodeApi starts showing multiple nodes from getConnectedNodes()? This is exactly the use case for the new CapabilityApi, which allows different nodes to advertise that they provide a specific functionality (say, the phone node being able to download images from the internet). This allows you to replace a generic NodeListener with a more specific CapabilityListener, getting only connection results and a list of nodes that have the specific functionality you need. We’ve updated the Sending and Receiving Messages training to explore this new functionality.

Another new addition for Android Wear is the ChannelApi, which provides a bidirectional data connection between two nodes. While assets are the best way to efficiently add binary data to the data layer for synchronization to all devices, this API focuses on sending larger binary data directly between specific nodes. This comes in two forms: sending full files via the sendFile() method (perfect for later offline access) or opening an OutputStream to stream real time binary data. We hope this offers a flexible, low level API to complement the DataApi and MessageApi.

We’ve updated our samples with these changes in mind so go check them out here!

Google Fit

Google Fit makes building fitness apps easier with fitness specific APIs on retrieving sensor data like current location and speed, collecting and storing activity data in Google Fit’s open platform, and automatically aggregating that data into a single view of the user’s fitness data.

To make it even easier to retrieve up-to-date information, Google Play Services 7.3 adds a new method to the HistoryApi: readDailyTotal(). This automatically aggregates data for a given DataType from midnight on the current day through now, giving you a single DataPoint. For TYPE_STEP_COUNT_DELTA, this method does not require any authentication, making it possible to retrieve the current number of steps for today from any application whether on mobile devices or on Android Wear - great for watch faces!

Google Fit is also augmenting its existing data types with granular nutrition information, including protein, fat, cholesterol, and more. By leveraging these details about the user’s diet, developers can help users stay more informed about their health and fitness.

Location

LocationRequest is the heart of the FusedLocationProviderApi, encapsulating the type and frequency of location information you’d like to receive. An important, but small change to LocationRequest is the addition of a maximum wait time for location updates via setMaxWaitTime(). By using a value at least two times larger than the requested interval, the system can batch location updates together, reducing battery usage and, on some devices, actually improving location accuracy.

For any ongoing location requests, it is important to know that you will continue to get good location data back. The SettingsApi is still incredibly useful for confirming that user settings are optimal before you put in a LocationRequest, however, it isn’t the best approach for continual monitoring. For that, you can use the new LocationCallback class in place of your existing LocationListener to receive LocationAvailability updates in addition to location updates, giving you a simple callback whenever settings might have changed which will affect the current set of LocationRequests. You can also use FusedLocationProviderApi’s getLocationAvailability() to retrieve the current state on demand.

Connecting to Google Play services

One of the biggest benefits of GoogleApiClient is that it provides a single connection state, whether you are connecting to a single API or multiple APIs. However, this made it hard to work with APIs that might not be available on all devices, such as the Wearable API. This release makes it much easier to work with APIs that may not always be available with the addition of an addApiIfAvailable() method ensuring that unavailable APIs do not hold up the connection process. The current state for each API can then be retrieved via getConnectionResult(), giving you a way to check at runtime whether an API is available and connected.

While GoogleApiClient’s connection process already takes care of checking for Google Play services availability, if you are not using GoogleApiClient, you’ll find many of the static utility methods in GooglePlayServicesUtil such as isGooglePlayServicesAvailable() have now been moved to the singleton GoogleApiAvailability class. We hope the move away from static methods helps you when writing tests, ensuring your application can properly handle any error cases.

SDK is now available!

Google Play services 7.3 is now available: get started with updated SDK now!

To learn more about Google Play services and the APIs available to you through it, visit the Google Play services section on the Android Developer site.

New Android Code Samples

Posted by Rich Hyndman, Developer Advocate

A new set of Android code samples, covering Android Wear, Android for Work, NFC and Screen capturing, have been committed to our Google Samples repository on GitHub. Here’s a summary of the new code samples:

XYZTouristAttractions

This sample mimics a real world mobile and Android Wear app. It has a more refined design and also provides a practical example of how a mobile app would interact and communicate with its Wear counterpart.

The app itself is modeled after a hypothetical tourist attractions experience that notifies the user when they are in close proximity to notable points of interest. In parallel,the Wear component shows tourist attraction images and summary information, and provides quick actions for nearby tourist attractions in a GridViewPager UI component.

DeviceOwner - A Device Owner is a specialized type of device administrator that can control device security and configuration. This sample uses the DevicePolicyManager to demonstrate how to use device owner features, including configuring global settings (e.g.automatic time and time-zone) and setting the default launcher.

NfcProvisioning - This sample demonstrates how to use NFC to provision a device with a device owner. This sample sets up the peer device with the DeviceOwner sample by default. You can rewrite the configuration to use any other device owner.

NFC BeamLargeFiles - A demonstration of how to transfer large files via Android Beam on Android 4.1 and above. After the initial handshake over NFC, file transfer will take place over a secondary high-speed communication channel such as Bluetooth or WiFi Direct.

ScreenCapture - The MediaProjection API was added in Android Lollipop and allows you to easily capture screen contents and/or record system audio. The ScreenCapture sample demonstrates how to use the API to capture device screen in real time and show it on a SurfaceView.

As an additional bonus, the Santa Tracker Android app, including three games, two watch-faces and other goodies, was also recently open sourced and is now available on GitHub.

As with all the Android samples, you can also easily access these new additions in Android Studio using the built in Import Samples feature and they’re also available through our Samples Browser.

Check out a sample today to help you with your development!

Game Performance: Explicit Uniform Locations

Posted by Shanee Nishry, Games Developer Advocate

Uniforms variables in GLSL are crucial for passing data between the game code on the CPU and the shader program on the graphics card. Unfortunately, up until the availability of OpenGL ES 3.1, using uniforms required some preparation which made the workflow slightly more complicated and wasted time during loading.

Let us examine a simple vertex shader and see how OpenGL ES 3.1 allows us to improve it:

#version 300 es

layout(location = 0) in vec4 vertexPosition;
layout(location = 1) in vec2 vertexUV;

uniform mat4 matWorldViewProjection;

out vec2 outTexCoord;

void main()
{
    outTexCoord = vertexUV;
    gl_Position = matWorldViewProjection * vertexPosition;
}

Note: You might be familiar with this shader from a previous Game Performance article on Layout Qualifiers. Find it here.

We have a single uniform for our world view projection matrix:

uniform mat4 matWorldViewProjection;

The inefficiency appears when you want to assign the uniform value.

You need to use glUniformMatrix4fv or glUniform4f to set the uniform’s value but you also need the handle for the uniform’s location in the program. To get the handle you must call glGetUniformLocation.

GLuint program; // the shader program
float matWorldViewProject[16]; // 4x4 matrix as float array

GLint handle = glGetUniformLocation( program, “matWorldViewProjection” );
glUniformMatrix4fv( handle, 1, false, matWorldViewProject );

That pattern leads to having to call glGetUniformLocation for each uniform in every shader and keeping the handles or worse, calling glGetUniformLocation every frame.

Warning! Never call glGetUniformLocation every frame! Not only is it bad practice but it is slow and bad for your game’s performance. Always call it during initialization and save it somewhere in your code for use in the render loop.

This process is inefficient, it requires you to do more work and costs precious time and performance.

Also take into consideration that you might have multiple shaders with the same uniforms. It would be much better if your code was deterministic and the shader language allowed you to explicitly set the locations of your uniforms so you don’t need to query and manage access handles. This is now possible with Explicit Uniform Locations.

You can set the location for uniforms directly in the shader’s code. They are declared like this

layout(location = index) uniform type name;

For our example shader it would be:

layout(location = 0) uniform mat4 matWorldViewProjection;

This means you never need to use glGetUniformLocation again, resulting in simpler code, initialization process and saved CPU cycles.

This is how the example shader looks after the change. Changes are marked in bold:

#version 310 es

layout(location = 0) in vec4 vertexPosition;
layout(location = 1) in vec2 vertexUV;

layout(location = 0) uniform mat4 matWorldViewProjection;

out vec2 outTexCoord;

void main()
{
    outTexCoord = vertexUV;
    gl_Position = matWorldViewProjection * vertexPosition;
}

As Explicit Uniform Locations are only supported from OpenGL ES 3.1 we also changed the version declaration to 310.

Now all you need to do to set your matWorldViewProjection uniform value is call glUniformMatrix4fv for the handle 0:

const GLint UNIFORM_MAT_WVP = 0; // Uniform location for WorldViewProjection
float matWorldViewProject[16]; // 4x4 matrix as float array

glUniformMatrix4fv( UNIFORM_MAT_WVP, 1, false, matWorldViewProject );

This change is extremely simple and the improvements can be substantial, producing cleaner code, asset pipeline and improved performance. Be sure to make these changes If you are targeting OpenGL ES 3.1 or creating multiple APKs to support a wide range of devices.

To learn more about Explicit Uniform Locations check out the OpenGL wiki page for it which contains valuable information on different layouts and how arrays are represented.

Android Support Library 22.1

Posted by Ian Lake, Developer Advocate

You may have heard the phrase ‘the best code is no code.’ While we don’t recommend not writing any code at all, the code you do write should be adding unique value to your app rather than replicating common boilerplate code. The Android Support Library is one of the best resources for accomplishing this by taking care of the little things for you.

The latest release of the Android Support Library is no different, adding a number of extremely helpful components and changes across the Support V4, AppCompat, Leanback, RecyclerView, Palette, and Renderscript libraries. From the new AppCompatActivity and AppCompatDialog to a new guided step flow for Android TV, there’s a lot to get excited about in this release.

Support V4

The Support V4 library serves as the base of much of the Android Support Library and contains many of the classes focused on making backward compatibility much easier.

DrawableCompat now brings drawable tinting back to API 4: simply wrap your Drawable via DrawableCompat.wrap(Drawable) and setTint(), setTintList(), and setTintMode() will just work: no need to create and maintain separate drawables only to support multiple colors!

In addition, we’re making some of the internals of Palette available to all via the ColorUtils class, giving you pre-built tools to better work with colors. ColorUtils makes it easy to calculate the contrast ratio between colors, determine the minimum alpha value to maintain a minimum contrast (perfect for ensuring readable text), or convert colors to their HSL components.

Interpolators are an important part of any animation system, controlling the rate of change in an animation (say accelerating, decelerating, etc). A number of interpolators were added in Lollipop to android.R.interpolator including fast_out_linear_in, fast_out_slow_in, and linear_out_slow_in: important parts of building authentic motion. These are now available via the Support Library via the FastOutLinearInInterpolator, FastOutSlowInInterpolator, and LinearOutSlowInInterpolator classes, making it possible to use these via code for all animations. In addition to those pre-built interpolators, we’ve also created PathInterpolatorCompat, allowing you to build quadratic and cubic Bezier curves as well.

This release also moves the Space widget from the GridLayout library into Support V4, making it available without requiring a separate dependency. The Space widget is a lightweight, invisible View that can be used to create gaps between components.

AppCompat

The AppCompat Support Library started with humble, but important beginnings: a single consistent Action Bar for all API 7 and higher devices. In revision 21, it took on new responsibility: bringing material color palette, widget tinting, Toolbar support, and more to all API 7+ devices. With that, the name ActionBarActivity didn’t really cover the full scope of what it really did.

In this release, ActionBarActivity has been deprecated in favor of the new AppCompatActivity. However, this wasn’t just a rename. In fact, the internal logic of AppCompat is now available via AppCompatDelegate - a class you can include in any Activity, hook up the appropriate lifecycle methods, and get the same consistent theming, color tinting, and more without requiring you to use AppCompatActivity (although that remains the easiest way to get started).

With the help of the new AppCompatDelegate, we’ve also added support for consistent, material design dialogs via the AppCompatDialog class. If you’ve used AlertDialog before, you’ll be happy to know there is also now a Support Library version in support.v7.app.AlertDialog, giving you the same API as well as all the benefits of AppCompatDialog.

The ability to tint widgets automatically when using AppCompat is incredibly helpful in keeping strong branding and consistency throughout your app. This is done automatically when inflating layouts - replacing Button with AppCompatButton, TextView with AppCompatTextView, etc. to ensure that each could support tinting. In this release, those tint aware widgets are now publicly available, allowing you to keep tinting support even if you need to subclass one of the supported widgets.

The full list of tint aware widgets at this time is:
  • AppCompatAutoCompleteTextView
  • AppCompatButton
  • AppCompatCheckBox
  • AppCompatCheckedTextView
  • AppCompatEditText
  • AppCompatMultiAutoCompleteTextView
  • AppCompatRadioButton
  • AppCompatRatingBar
  • AppCompatSpinner
  • AppCompatTextView

Lollipop added the ability to overwrite the theme at a view by view level by using the android:theme XML attribute - incredibly useful for things such as dark action bars on light activities. Now, AppCompat allows you to use android:theme for Toolbars (deprecating the app:theme used previously) and, even better, brings android:theme support to all views on API 11+ devices.

If you’re just getting started with AppCompat, check out how easy it is to get started and bring a consistent design to all of your users:


Leanback

With the Leanback library serving as the collection of best practices for Android TV apps, we’d be remiss to not make an even better 10’ experience as part of the release. You’ll notice immediately upon loading up the updated Leanback sample the new guided step functionality.

This set of classes and themes can be used to build a multiple step process that looks great on Android TV. It is constructed from a guidance view on the left and a list of actions on the right. Each is customizable via themes with a parent of Theme.Leanback.GuidedStep or, if even more customization is needed, through custom a GuidanceStylist and GuidedActionsStylist.

You’ll also find a large number of bug fixes, performance improvements, and an extra coat of polish throughout the library - all with the goal of making the Leanback experience even better for users and developers alike.

RecyclerView

Besides a healthy set of bug fixes, this release adds a new SortedList data structure. This collection makes it easy to maintain a sorted list of custom objects, correctly dispatching change events as the data changes through to RecyclerView.Adapter: maintaining the item added/deleted/moved/changed animations provided by RecyclerView.

In addition, SortedList also supports batching changes together, dispatching just a single set of operations to the Adapter, ensuring the best user experience when a large number of items change simultaneously.

Palette

If you’ve been using Palette to extract colors from images, you’ll be happy to know that it is now 6-8 times faster without sacrificing quality!

Palette now uses a Builder pattern for instantiation. Rather than directly calling Palette.generate(Bitmap) or their equivalents, you’ll use Palette.from(Bitmap) to retrieve a Palette.Builder. You can then optionally change the maximum number of colors to generate and set the maximum size of the image to run Palette against before calling generate() or generateAsync() to retrieve the color Swatches.

Renderscript

Renderscript gives you massive compute potential and the Support Library version makes a number of the pre-defined scripts, called script intrinsics, available to all API 8+ devices. This release improves reliability and performance across all devices with an improved detection algorithm in determining whether the native Renderscript functionality can be used - ensuring the fastest, most reliable implementation is always chosen. Two additional intrinsics are also added in this release: ScriptIntrinsicHistogram and ScriptIntrinsicResize, rounding out the collection to ten.

SDK available now!

There’s no better time to get started with the Android Support Library. You can get started developing today by downloading the Android Support Library and Android Support Repository from the Android SDK Manager.

To learn more about the Android Support Library and the APIs available to you through it, visit the Support Library section on the Android Developer site.

Android Developer Story: Jelly Button Games grows globally through data driven development

Posted by Leticia Lago, Google Play team

For Jelly Button Games, understanding users is the key to creating and maintaining a successful game, particularly when growth relies on moving into overseas markets. The team makes extensive use of Google Analytics and Google BigQuery to analyze more than 3 billion events each month. By using this data, Jelly Button can pinpoint exactly where, when, and why people play their highly-rated game, Pirate Kings. Feeding this information back into development has driven active daily users up 1500 percent in just five months.

We caught up with Mor Shani, Moti Novo, and Ron Rejwan — some of the co-founders — in Tel Aviv, Israel, to discover how they created an international hit and keep it growing.


Learn about Google Analytics and taking your game to an international audience:

  • Analyze — discover the power of data from the Google Play Developer Console and Google Analytics.
  • Query — find out how Google BigQuery can help you extract the essential information you need from millions or billions of data points.
  • Localize — guide the localization of your app with best practices and tools.