Oct 12

Introducing Oboe: A C++ library for low latency audio


Posted by Don Turner, Developer Advocate, Android Audio Framework

This week we released the first production-ready version of Oboe – a C++ library for building real-time audio apps. Oboe provides the lowest possible audio latency across the widest range of Android devices, as well as several other benefits.

Single API

Oboe takes advantage of the improved performance and features of AAudio on Oreo MR1 (API 27+) whilst maintaining backward compatibility (using OpenSL ES) on API 16+. It’s kind of like AndroidX for native audio.

Diagram showing the underlying audio API which Oboe will use

Less code to write and maintain

Using Oboe you can create an audio stream in just 3 lines of code (vs 50+ lines in OpenSL ES):

AudioStreamBuilder builder;
AudioStream *stream = nullptr;
Result result = builder.openStream(&stream);

Other benefits

  • Convenient C++ API (uses the C++11 standard)
  • Fast release process: supplied as a source library, bug fixes can be rolled out in days, quite a bit faster than the Android platform release cycle
  • Less guesswork: Provides workarounds for known audio bugs and has sensible default behaviour for stream properties, such as sample rate and audio data formats
  • Open source and maintained by Google engineers (although we welcome outside contributions)

Getting started

Take a look at the short video introduction:

Check out the documentation, code samples and API reference. There’s even a codelab which shows you how to build a rhythm-based game.

If you have any issues, please file them here, we’d love to hear how you get on.


Android Developers Blog

Sep 08

Introducing the ExifInterface Support Library

With the release of the 25.1.0 Support Library, there’s a new entry in the family: the ExifInterface Support Library. With significant improvements introduced in Android 7.1 to the framework’s ExifInterface, it only made sense to make those available to all API 9+ devices via the Support Library’s ExifInterface.

The basics are still the same: the ability to read and write Exif tags embedded within image files: now with 140 different attributes (almost 100 of them new to Android 7.1/this Support Library!) including information about the camera itself, the camera settings, orientation, and GPS coordinates.

Camera Apps: Writing Exif Attributes

For Camera apps, the writing is probably the most important – writing attributes is still limited to JPEG image files. Now, normally you wouldn’t need to use this during the actual camera capturing itself – you’d instead be calling the Camera2 API CaptureRequest.Builder.set() with JPEG_ORIENTATION, JPEG_GPS_LOCATION or the equivalents in the Camera1 Camera.Parameters. However, using ExifInterface allows you to make changes to the file after the fact (say, removing the location information on the user’s request).

Reading Exif Attributes

For the rest of us though, reading those attributes is going to be our bread-and-butter; this is where we see the biggest improvements.

Firstly, you can read Exif data from JPEG and raw images (specifically, DNG, CR2, NEF, NRW, ARW, RW2, ORF, PEF, SRW and RAF files). Under the hood, this was a major restructuring, removing all native dependencies and building an extensive test suite to ensure that everything actually works.

For apps that receive images from other apps with a content:// URI (such as those sent by apps that target API 24 or higher), ExifInterface now works directly off of an InputStream; this allows you to easily extract Exif information directly out of content:// URIs you receive without having to create a temporary file.

Uri uri; // the URI you've received from the other app
InputStream in;
try {
  in = getContentResolver().openInputStream(uri);
  ExifInterface exifInterface = new ExifInterface(in);
  // Now you can extract any Exif tag you want
  // Assuming the image is a JPEG or supported raw format
} catch (IOException e) {
  // Handle any errors
} finally {
  if (in != null) {
    try {
      in.close();
    } catch (IOException ignored) {}
  }
}

Note: ExifInterface will not work with remote InputStreams, such as those returned from a HttpURLConnection. It is strongly recommended to only use them with content:// or file:// URIs.

For most attributes, you’d simply use the getAttributeInt(), getAttributeDouble(), or getAttribute() (for Strings) methods as appropriate.

One of the most important attributes when it comes to displaying images is the image orientation, stored in the aptly-named TAG_ORIENTATION, which returns one of the ORIENTATION_ constants. To convert this to a rotation angle, you can post-process the value.

int rotation = 0;
int orientation = exifInterface.getAttributeInt(
    ExifInterface.TAG_ORIENTATION,
    ExifInterface.ORIENTATION_NORMAL);
switch (orientation) {
  case ExifInterface.ORIENTATION_ROTATE_90:
    rotation = 90;
    break;
  case ExifInterface.ORIENTATION_ROTATE_180:
    rotation = 180;
    break;
  case ExifInterface.ORIENTATION_ROTATE_270:
    rotation = 270;
    break;
}

There are some helper methods to extract values from specific Exif tags. For location data, the getLatLong() method gives you the latitude and longitude as floats and getAltitude() will give you the altitude in meters. Some images also embed a small thumbnail. You can check for its existence with hasThumbnail() and then extract the byte[] representation of the thumbnail with getThumbnail() – perfect to pass to BitmapFactory.decodeByteArray().

Working with Exif: Everything is optional

One thing that is important to understand with Exif data is that there are no required tags: each and every tag is optional – some services even specifically strip Exif data. Therefore throughout your code, you should always handle cases where there is no Exif data, either due to no data for a specific attribute or an image format that doesn’t support Exif data at all (say, the ubiquitous PNGs or WebP images).

Add the ExifInterface Support Library to your project with the following dependency:

compile "com.android.support:exifinterface:25.1.0"

But when an Exif attribute is exactly what you need to prevent a mis-rotated image in your app, the ExifInterface Support Library is just what you need to #BuildBetterApps


Android Developers Blog

Sep 03

Adding TV Channels to Your App with the TIF Companion Library

Posted by Nick Felker and Sachit Mishra, Developer
Programs Engineers

The TV
Input Framework (TIF) on Android TV makes it easy for third-party app
developers to create their own TV channels with any type of linear media. It
introduces a new way for apps to engage with users with a high-quality channel
surfing experience, and it gives users a single interface to browse and watch
all of their channels.

To help developers get started with building TV channels, we have created the TV Input
Framework Companion Library, which includes a number of helper methods and
classes to make the development process as easy as possible.

This library provides standard classes to set up a background task that updates
the program guide and an interface that helps integrate your media player with
the playback controller, as well as supports the new TV Recording APIs that are
available in Android Nougat. It includes everything you need to start showing
your content on your Android TV’s live TV app.

(Note: source from
android-tv-sample-inputs
sample)

To get started, take a look at the sample app
and documentation.
The sample demonstrates how to extend this library to create custom channels and
manage video playback. Developers can immediately get started with the sample
app by updating the XMLTV
file with their own content or dynamically creating channels in the SampleJobService.

You can include this library in your app by copying the library
directory from the sample into your project root directory. Then, add the
following to your project’s settings.gradle file:

include ':library'

In your app’s build.gradle file, add the following to your
dependencies:

compile project(':library')

Android TV continues to grow, and whether your app has on-demand or live media,
TIF is a great way to keep users engaged with your content. One partner for
example, Haystack TV, recently integrated TIF into their app and it now accounts
for 16% of watch time for new users on Android TV.

Check out our TV developer
site to learn more about Android TV, and join our developer community on
Google+ at g.co/androidtvdev to discuss
this library and other topics with TV developers.


Android Developers Blog

Jul 04

Adding TV Channels to Your App with the TIF Companion Library

Posted by Nick Felker and Sachit Mishra, Developer
Programs Engineers

The TV
Input Framework (TIF) on Android TV makes it easy for third-party app
developers to create their own TV channels with any type of linear media. It
introduces a new way for apps to engage with users with a high-quality channel
surfing experience, and it gives users a single interface to browse and watch
all of their channels.

To help developers get started with building TV channels, we have created the TV Input
Framework Companion Library, which includes a number of helper methods and
classes to make the development process as easy as possible.

This library provides standard classes to set up a background task that updates
the program guide and an interface that helps integrate your media player with
the playback controller, as well as supports the new TV Recording APIs that are
available in Android Nougat. It includes everything you need to start showing
your content on your Android TV’s live TV app.

(Note: source from
android-tv-sample-inputs
sample)

To get started, take a look at the sample app
and documentation.
The sample demonstrates how to extend this library to create custom channels and
manage video playback. Developers can immediately get started with the sample
app by updating the XMLTV
file with their own content or dynamically creating channels in the SampleJobService.

You can include this library in your app by copying the library
directory from the sample into your project root directory. Then, add the
following to your project’s settings.gradle file:

include ':library'

In your app’s build.gradle file, add the following to your
dependencies:

compile project(':library')

Android TV continues to grow, and whether your app has on-demand or live media,
TIF is a great way to keep users engaged with your content. One partner for
example, Haystack TV, recently integrated TIF into their app and it now accounts
for 16% of watch time for new users on Android TV.

Check out our TV developer
site to learn more about Android TV, and join our developer community on
Google+ at g.co/androidtvdev to discuss
this library and other topics with TV developers.


Android Developers Blog

Jun 22

Android Things client library for Google Cloud IoT Core


Posted by Wayne Piekarski, Developer Advocate for IoT +WaynePiekarski @WaynePiekarski

We’re releasing a client library to make it easy to use Google Cloud IoT Core from Android Things devices. With just a few lines of code, you can easily connect to the IoT Core MQTT bridge, authenticate the device, publish device telemetry and state, subscribe to configuration changes, and handle errors and network outages.

What is Cloud IoT Core?

Cloud IoT Core is a fully managed service on Google Cloud Platform that allows you to easily and securely connect, manage, and ingest data from millions of globally dispersed devices. Cloud IoT Core, in combination with other services which make up Google’s Cloud IoT platform, provides a complete solution for collecting, processing, analyzing, and visualizing IoT data in real time, to support improved operational efficiency, compliance, or revenue management. Android Things is designed to support everything from collecting telemetry data to powerful computer vision, audio processing, and machine learning applications, all on device, and using Cloud IoT Core, push your data into Google Cloud Platform for further analysis.

Cloud IoT Core client library

The Cloud IoT Core client library was designed to enable Android Things developers to get started with just a few lines of code. The client library handles the networking, threading, and message handling, implementing best practices for authentication, security, error handling, and offline operation.

Cloud IoT Core maintains a device registry that keeps track of approved devices, and each device uses a public key to authenticate with the server. Android Things provides many features to support secure IoT applications, including a hardware-backed Android Keystore that ensures cryptographic key material is protected. The client library supports both RSA and ECC keys, and implements the generation of JSON Web Tokens (JWTs) for authentication with Cloud IoT Core.

Once the connection is established, devices can publish their telemetry data to one or more buckets in the telemetry topic, as well as report their internal state to a separate device state topic. The device state is intended to store information such as software versions or the number of working sensors. The telemetry messages are for all other data from the device, such as actual sensor measurements. Devices can also subscribe to configuration changes published from Cloud IoT Core.

Because IoT devices operate in the real world with poor wireless conditions, the client library provides extensive support for handling errors, and for caching and retransmitting events later. For developers requiring custom offline behavior, the library’s queue is configurable and even replaceable. This provides detailed control over which events to save and the order in which they are sent when back online.

Device provisioning and authentication with Android Things

The Cloud IoT Core client library is part of our overall vision for device provisioning and authentication with Android Things. To learn more about this, watch the video of our presentation from Google I/O 2018:

Sample code

Getting started with the Cloud IoT Core client library is simple. You can simply add the following to the build.gradle file in your Android Things project:

implementation 'com.google.android.things:cloud-iot-core:1.0.0'

The library is also available as open source on GitHub if you prefer to build it yourself. We also have a sample that shows how to implement a sensor hub on Android Things, collecting sensor data from connected sensors and publishing them to a Google Cloud IoT Pub/Sub topic.

It is easy to start using the client library in your own code. The following Kotlin example demonstrates how to create a new configuration and client based on your project.

var configuration = IotCoreConfiguration.Builder().
                         .setProjectId("my-gcp-project")
                         .setRegistry("my-device-registry", "us-central1")
                         .setDeviceId("my-device-id")
                         .setKeyPair(keyPairObject)
                         .build()

var iotCoreClient = IotCoreClient.Builder()
              .setIotCoreConfiguration(configuration)
              .setOnConfigurationListener(onConfigurationListener)
              .setConnectionCallback(connectionCallback)
              .build()

iotCoreClient.connect()

Next, you can publish telemetry information or device state, using the following Kotlin examples.

private fun publishTelemetry(temperature: Float, humidity: Float) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"temperature" : $  temperature,
        |"humidity": $  humidity
        |}""".trimMargin().toByteArray()
    val event = TelemetryEvent(examplePayload, topicSubpath, TelemetryEvent.QOS_AT_LEAST_ONCE)
    iotCoreClient.publishTelemetry(event)
}

private fun publishDeviceState(telemetryFrequency: Int, enabledSensors: Array<String>) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"telemetryFrequency": $  telemetryFrequency,
        |"enabledSensors": $  {enabledSensors.contentToString()}
        |}""".trimMargin().toByteArray()
    iotCoreClient.publishDeviceState(examplePayload)
}

Additional resources

You can learn more about building for Android Things at the developer site. For more information about getting started with Cloud IoT Core, visit the information page and documentation. Finally, join Google’s IoT Developers Community on Google+ to let us know what you’re building with Android Things and Cloud IoT Core!


Android Developers Blog

Jun 09

Porting Your Android Wear Developer Preview Code to the Latest Support Library

Today’s post on #AndroidWear is from +Wayne Piekarski.

Now that the full Android Wear SDK is available, it’s time to port your existing wearable-enabled notification code from the Developer Preview. In the process, you’ll switch to using the latest Android support library, and there are some small API changes that will require you to update your code. This article will show you how to update my previous code samples that were released earlier for stacks and pages, which you can use to guide the conversion of your own code as well.

To get started with an existing project in Android Studio, you should update to the 0.8 or later release. You also need to make sure you’ve downloaded the Google Support Library version 20 or later from the SDK Manager. Since this is only a notification-based example, there’s no need to download the full Android Wear SDK, which is only needed if you want to create an APK to run on the wearable device.

Unix diff output is used to show the necessary changes in an easy to understand way. Do not copy the + or – symbols at the start of each line, and ignore the lines starting with @@ which are used to indicate the line number that changed. For the curious, I used the following command to generate the diff output from the last commit in my GIT repository (the -U1 shows one line of context to keep the output simple):

git show HEAD -U1

Gradle changes

To add the new support-v4 library, you need to edit your build.gradle file like so:

@@ -24,2 +24,3 @@ dependencies {
     compile 'com.android.support:appcompat-v7:19.+'
+    compile 'com.android.support:support-v4:20.0+'
 }

Make sure you remove the wearable-preview-support.jar that was provided with the Developer Preview from your libs directory and build.gradle file, since these features are now in the standard support library.

Package imports

Since the APIs and package names have changed, the import statements at the top of MainActivity.java need to be adjusted like this:

@@ -7,3 +7,2 @@ import android.view.MenuItem;
-import android.support.v4.app.NotificationCompat;
 import android.app.Notification;
@@ -13,4 +12,9 @@ import android.graphics.Bitmap;
 import android.graphics.BitmapFactory;
-import android.preview.support.v4.app.NotificationManagerCompat;
-import android.preview.support.wearable.notifications.WearableNotifications;
+import android.support.v4.app.NotificationCompat;
+import android.support.v4.app.NotificationManagerCompat;
+
+// Extra dependencies needed for the pages example
+import java.util.ArrayList;
+import java.util.List;
+import android.support.v4.app.NotificationCompat.BigTextStyle;

Stacking notifications

Since the preview SDK, we have simplified how notifications are implemented. The existing NotificationCompat.Builder() was extended to support groups directly, instead of a separate WearableNotifications class. The steps are a lot simpler, as can be seen with the following changes to showStackNotifications():

@@ -63,3 +67,3 @@ public class MainActivity extends ActionBarActivity {
         // Group notification that will be visible on the phone
-    NotificationCompat.Builder builderG = new NotificationCompat.Builder(this)
+    Notification summaryNotification = new NotificationCompat.Builder(this)
             .setContentTitle("2 Pet Notifications")
@@ -67,5 +71,5 @@ public class MainActivity extends ActionBarActivity {
             .setSmallIcon(R.drawable.ic_launcher)
-                .setLargeIcon(bitmapMila);
-    Notification summaryNotification = new WearableNotifications.Builder(builderG)
-            .setGroup(GROUP_KEY_MESSAGES, WearableNotifications.GROUP_ORDER_SUMMARY)
+                .setLargeIcon(bitmapMila)
+            .setGroup(GROUP_KEY_MESSAGES)
+            .setGroupSummary(true)
             .build();
@@ -76,3 +80,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0);
-    NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this)
+    Notification notification1 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Treat Fed", viewPendingIntent1)
@@ -81,4 +85,3 @@ public class MainActivity extends ActionBarActivity {
                     + "Can we have steak?")
-                .setSmallIcon(R.drawable.ic_launcher);
-    Notification notification1 = new WearableNotifications.Builder(builder1)
+            .setSmallIcon(R.drawable.ic_launcher)
             .setGroup(GROUP_KEY_MESSAGES)
@@ -89,3 +92,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+2, viewIntent2, 0);
-    NotificationCompat.Builder builder2 = new NotificationCompat.Builder(this)
+    Notification notification2 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Water Filled", viewPendingIntent2)
@@ -93,4 +96,3 @@ public class MainActivity extends ActionBarActivity {
             .setContentText("Can you refill our water bowl?")
-            .setSmallIcon(R.drawable.ic_launcher);
-        Notification notification2 = new WearableNotifications.Builder(builder2)
+            .setSmallIcon(R.drawable.ic_launcher)
             .setGroup(GROUP_KEY_MESSAGES)

Page notifications

Page notifications have also changed to use a WearableExtender() class instead of the WearableNotifications class, as can be seen here in showPageNotifications():

@@ -151,3 +153,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0);
-    NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this)
+    Notification notification1 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Returned", viewPendingIntent1)
@@ -155,5 +157,4 @@ public class MainActivity extends ActionBarActivity {
             .setContentText("You have " + numOverdue + " books due at the library")
-            .setSmallIcon(R.drawable.ic_launcher);
-    Notification notification1 = new WearableNotifications.Builder(builder1)
-            .addPages(extras)
+                .setSmallIcon(R.drawable.ic_launcher)
+            .extend(new NotificationCompat.WearableExtender().addPages(extras))
             .build();

Conclusion

If you want to download the final source code of showStackNotifications() and showPageNotifications(), you can download the MainActivity.java file. You can build this file easily by creating a new project in Android Studio, adding the support library, and then copying in this MainActivity.java.

As you can see, porting this previous code over to the latest Android Wear SDK is really easy! It should take you hardly any time at all to get your experimental applications ported over and ready for publishing on the Google Play!

Join the discussion on
+Android Developers


Android Developers Blog

Apr 04

FlatBuffers: A Memory-Efficient Serialization Library

By Wouter van Oortmerssen, Fun Propulsion Labs at Google

Game developers, we’ve just released FlatBuffers, a C++ serialization library that allows you to read data without unpacking or allocating additional memory, as an open source project.

FlatBuffers stores serialized data in buffers in a cross-platform way, supporting format evolution that is fully forwards and backwards compatible through a schema. These buffers can be stored in files or sent across the network as-is, and accessed in-place without parsing overhead.

The FlatBuffers schema compiler and runtime is written in platform independent C++ with no library dependencies outside the STL, which makes it possible to use on any platform that has a C++ compiler. We have provided methods to build the FlatBuffers library, example applications, and unit tests for Android, Linux, OSX and Windows.
The schema compiler can generate code to read and write FlatBuffers binary files for C++ and Java. It can additionally parse JSON-formatted data into type-safe binaries.

Game developers can use this library to store game data with less overhead than alternative solutions (e.g. Protocol Buffers or JSON). We’re excited about the possibilities, and want to hear from you about how we can make this even better!

Download the latest release from the FlatBuffers page in GitHub and join our discussion list!

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


Android Developers Blog

Mar 04

Android Design Support Library

Posted by Ian Lake, Developer Advocate

Android 5.0 Lollipop was one of the most significant Android releases ever, in no small part due to the introduction of material design, a new design language that refreshed the entire Android experience. Our detailed spec is a great place to start to adopt material design, but we understand that it can be a challenge for developers, particularly ones concerned with backward compatibility. With a little help from the new Android Design Support Library, we’re bringing a number of important material design components to all developers and to all Android 2.1 or higher devices. You’ll find a navigation drawer view, floating labels for editing text, a floating action button, snackbar, tabs, and a motion and scroll framework to tie them together.

Navigation View

The navigation drawer can be an important focal point for identity and navigation within your app and consistency in the design here can make a considerable difference in how easy your app is to navigate, particularly for first time users. NavigationView makes this easier by providing the framework you need for the navigation drawer as well as the ability to inflate your navigation items through a menu resource.

You use NavigationView as DrawerLayout’s drawer content view with a layout such as:

<android.support.v4.widget.DrawerLayout
        xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:fitsSystemWindows="true">

    <!-- your content layout -->

    <android.support.design.widget.NavigationView
            android:layout_width="wrap_content"
            android:layout_height="match_parent"
            android:layout_gravity="start"
            app:headerLayout="@layout/drawer_header"
            app:menu="@menu/drawer"/>
</android.support.v4.widget.DrawerLayout>

You’ll note two attributes for NavigationView: app:headerLayout controls the (optional) layout used for the header. app:menu is the menu resource inflated for the navigation items (which can also be updated at runtime). NavigationView takes care of the scrim protection of the status bar for you, ensuring that your NavigationView interacts with the status bar appropriately on API21+ devices.

The simplest drawer menus will be a collection of checkable menu items:

<group android:checkableBehavior="single">
    <item
        android:id="@+id/navigation_item_1"
        android:checked="true"
        android:icon="@drawable/ic_android"
        android:title="@string/navigation_item_1"/>
    <item
        android:id="@+id/navigation_item_2"
        android:icon="@drawable/ic_android"
        android:title="@string/navigation_item_2"/>
</group>

The checked item will appear highlighted in the navigation drawer, ensuring the user knows which navigation item is currently selected.

You can also use subheaders in your menu to separate groups of items:

<item
    android:id="@+id/navigation_subheader"
    android:title="@string/navigation_subheader">
    <menu>
        <item
            android:id="@+id/navigation_sub_item_1"
            android:icon="@drawable/ic_android"
            android:title="@string/navigation_sub_item_1"/>
        <item
            android:id="@+id/navigation_sub_item_2"
            android:icon="@drawable/ic_android"
            android:title="@string/navigation_sub_item_2"/>
    </menu>
</item>

You’ll get callbacks on selected items by setting a OnNavigationItemSelectedListener using setNavigationItemSelectedListener(). This provides you with the MenuItem that was clicked, allowing you to handle selection events, changed the checked status, load new content, programmatically close the drawer, or any other actions you may want.

Floating labels for editing text

Even the humble EditText has room to improve in material design. While an EditText alone will hide the hint text after the first character is typed, you can now wrap it in a TextInputLayout, causing the hint text to become a floating label above the EditText, ensuring that users never lose context in what they are entering.

In addition to showing hints, you can also display an error message below the EditText by calling setError().

Floating Action Button

A floating action button is a round button denoting a primary action on your interface. The Design library’s FloatingActionButton gives you a single consistent implementation, by default colored using the colorAccent from your theme.

In addition to the normal size floating action button, it also supports the mini size (fabSize="mini") when visual continuity with other elements is critical. As FloatingActionButton extends ImageView, you’ll use android:src or any of the methods such as setImageDrawable() to control the icon shown within the FloatingActionButton.

Snackbar

Providing lightweight, quick feedback about an operation is a perfect opportunity to use a snackbar. Snackbars are shown on the bottom of the screen and contain text with an optional single action. They automatically time out after the given time length by animating off the screen. In addition, users can swipe them away before the timeout.

By including the ability to interact with the Snackbar through swiping it away or actions, these are considerably more powerful than toasts, another lightweight feedback mechanism. However, you’ll find the API very familiar:

Snackbar
  .make(parentLayout, R.string.snackbar_text, Snackbar.LENGTH_LONG)
  .setAction(R.string.snackbar_action, myOnClickListener)
  .show(); // Don’t forget to show!

You’ll note the use of a View as the first parameter to make() - Snackbar will attempt to find an appropriate parent of the Snackbar’s view to ensure that it is anchored to the bottom.

Tabs

Switching between different views in your app via tabs is not a new concept to material design and they are equally at home as a top level navigation pattern or for organizing different groupings of content within your app (say, different genres of music).

The Design library’s TabLayout implements both fixed tabs, where the view’s width is divided equally between all of the tabs, as well as scrollable tabs, where the tabs are not a uniform size and can scroll horizontally. Tabs can be added programmatically:

TabLayout tabLayout = ...;
tabLayout.addTab(tabLayout.newTab().setText("Tab 1"));

However, if you are using a ViewPager for horizontal paging between tabs, you can create tabs directly from your PagerAdapter’s getPageTitle() and then connect the two together using setupWithViewPager(). This ensures that tab selection events update the ViewPager and page changes update the selected tab.

CoordinatorLayout, motion, and scrolling

Distinctive visuals are only one part of material design: motion is also an important part of making a great material designed app. While there are a lot of parts of motion in material design including touch ripples and meaningful transitions, the Design library introduces CoordinatorLayout, a layout which provides an additional level of control over touch events between child views, something which many of the components in the Design library take advantage of.

CoordinatorLayout and floating action buttons

A great example of this is when you add a FloatingActionButton as a child of your CoordinatorLayout and then pass that CoordinatorLayout to your Snackbar.make() call – instead of the snackbar displaying over the floating action button, the FloatingActionButton takes advantage of additional callbacks provided by CoordinatorLayout to automatically move upward as the snackbar animates in and returns to its position when the snackbar animates out on Android 3.0 and higher devices – no extra code required.

CoordinatorLayout also provides an layout_anchor attribute which, along with layout_anchorGravity, can be used to place floating views, such as the FloatingActionButton, relative to other views.

CoordinatorLayout and the app bar

The other main use case for the CoordinatorLayout concerns the app bar (formerly action bar) and scrolling techniques. You may already be using a Toolbar in your layout, allowing you to more easily customize the look and integration of that iconic part of an app with the rest of your layout. The Design library takes this to the next level: using an AppBarLayout allows your Toolbar and other views (such as tabs provided by TabLayout) to react to scroll events in a sibling view marked with a ScrollingViewBehavior. Therefore you can create a layout such as:

 <android.support.design.widget.CoordinatorLayout
        xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        android:layout_width="match_parent"
        android:layout_height="match_parent">

     <! -- Your Scrollable View -->
    <android.support.v7.widget.RecyclerView
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            app:layout_behavior="@string/appbar_scrolling_view_behavior" />

    <android.support.design.widget.AppBarLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content">
   <android.support.v7.widget.Toolbar
                  ...
                  app:layout_scrollFlags="scroll|enterAlways">

        <android.support.design.widget.TabLayout
                  ...
                  app:layout_scrollFlags="scroll|enterAlways">
     </android.support.design.widget.AppBarLayout>
</android.support.design.widget.CoordinatorLayout>

Now, as the user scrolls the RecyclerView, the AppBarLayout can respond to those events by using the children’s scroll flags to control how they enter (scroll on screen) and exit (scroll off screen). Flags include:

  • scroll: this flag should be set for all views that want to scroll off the screen – for views that do not use this flag, they’ll remain pinned to the top of the screen
  • enterAlways: this flag ensures that any downward scroll will cause this view to become visible, enabling the ‘quick return’ pattern
  • enterAlwaysCollapsed: When your view has declared a minHeight and you use this flag, your View will only enter at its minimum height (i.e., ‘collapsed’), only re-expanding to its full height when the scrolling view has reached it’s top.
  • exitUntilCollapsed: this flag causes the view to scroll off until it is ‘collapsed’ (its minHeight) before exiting

One note: all views using the scroll flag must be declared before views that do not use the flag. This ensures that all views exit from the top, leaving the fixed elements behind.

Collapsing Toolbars

Adding a Toolbar directly to an AppBarLayout gives you access to the enterAlwaysCollapsed and exitUntilCollapsed scroll flags, but not the detailed control on how different elements react to collapsing. For that, you can use CollapsingToolbarLayout:

<android.support.design.widget.AppBarLayout
        android:layout_height="192dp"
        android:layout_width="match_parent">
    <android.support.design.widget.CollapsingToolbarLayout
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            app:layout_scrollFlags="scroll|exitUntilCollapsed">
        <android.support.v7.widget.Toolbar
                android:layout_height="?attr/actionBarSize"
                android:layout_width="match_parent"
                app:layout_collapseMode="pin"/>
        </android.support.design.widget.CollapsingToolbarLayout>
</android.support.design.widget.AppBarLayout>

This setup uses CollapsingToolbarLayout’s app:layout_collapseMode="pin" to ensure that the Toolbar itself remains pinned to the top of the screen while the view collapses. Even better, when you use CollapsingToolbarLayout and Toolbar together, the title will automatically appear larger when the layout is fully visible, then transition to its default size as it is collapsed. Note that in those cases, you should call setTitle() on the CollapsingToolbarLayout, rather than on the Toolbar itself.

In addition to pinning a view, you can use app:layout_collapseMode="parallax" (and optionally app:layout_collapseParallaxMultiplier="0.7" to set the parallax multiplier) to implement parallax scrolling (say of a sibling ImageView within the CollapsingToolbarLayout). This use case pairs nicely with the app:contentScrim="?attr/colorPrimary" attribute for CollapsingToolbarLayout, adding a full bleed scrim when the view is collapsed.

CoordinatorLayout and custom views

One thing that is important to note is that CoordinatorLayout doesn’t have any innate understanding of a FloatingActionButton or AppBarLayout work – it just provides an additional API in the form of a Coordinator.Behavior, which allows child views to better control touch events and gestures as well as declare dependencies between each other and receive callbacks via onDependentViewChanged().

Views can declare a default Behavior by using the CoordinatorLayout.DefaultBehavior(YourView.Behavior.class) annotation,or set it in your layout files by with the app:layout_behavior="com.example.app.YourView$ Behavior" attribute. This framework makes it possible for any view to integrate with CoordinatorLayout.

Available now!

The Design library is available now, so make sure to update the Android Support Repository in the SDK Manager. You can then start using the Design library with a single new dependency:

 compile 'com.android.support:design:22.2.0'

Note that as the Design library depends on the Support v4 and AppCompat Support Libraries, those will be included automatically when you add the Design library dependency. We also took care that these new widgets are usable in the Android Studio Layout Editor’s Design view (find them under CustomView), giving you an easier way to preview some of these new components.

The Design library, AppCompat, and all of the Android Support Library are important tools in providing the building blocks needed to build a modern, great looking Android app without building everything from scratch.

Join the discussion on

+Android Developers


Android Developers Blog

Jan 05

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 Developers Blog

Sep 20

Google Play Billing Library 1.0 released

Posted by Neto Marin, Developer Advocate

In June we announced the developer
preview for a new Google Play Billing Library. Today, we are pleased to
announce the official release of the Play Billing Library 1.0. This library
simplifies the development process for Google Play Billing, allowing you to
focus your efforts on your app.

Thank you for your valuable feedback and suggestions that helped us reach the
1.0 release. Watch the video below for a quick overview of the library’s
features.



Before you start

With Play Billing, you can receive payments from users around the world via a
payment system they trust and you can take advantage of features and reports in
the Play Console to manage and earn more revenue.

If you have never implemented in-app billing in your apps, or you want to know
what you can offer using Play Billing Library, read the In-app
Billing Overview to familiarize yourself with concepts and terminology that
make it easier for you to implement In-app Billing using the Play Billing
Library.

Getting started

Play Billing Library is available through Maven repository, and adding Play
Billing Library to your project is simple as adding the following dependency
into your app’s build.gradle file:

dependencies {
    ...
    compile 'com.android.billingclient:billing:1.0'
}

The Play Billing Library 1.0 automatically adds the
com.android.vending.BILLING permission to your APK. This means you
no longer need to manually include it in your application module’s manifest.

BillingClient and PurchasesUpdatedListener

These classes are the most important pieces when integrating the library into
your Android app. The BillingClient
is the bridge between your app and Google Play. You will use it for listing
available products, starting the billing flow for in-app products or
subscriptions (i.e. opening the payment interface), getting user purchases, and
creating or modifying subscriptions.

When creating your BillingClient
instance, you’ll need to set a PurchasesUpdatedListener.
This allows your app to receive updates from the In-app Billing API, including
transaction results after the billing flow, as well as purchases completed
outside of your app, e.g. user redeemed a Promo Code or bought a product on
another device.

The following code demonstrates how you could override the )">onPurchasesUpdated()
method of your PurchasesUpdatedListener:

@Override
void onPurchasesUpdated(@BillingResponse int responseCode,
        List<Purchase> purchases) {
    if (responseCode == BillingResponse.OK
            && purchases != null) {
        for (Purchase purchase : purchases) {
            handlePurchase(purchase);
        }
    } else if (responseCode == BillingResponse.USER_CANCELED) {
        // Handle an error caused by a user canceling the purchase flow.
    } else {
        // Handle any other error codes.
    }
}

You can implement the PurchasesUpdatedListener
in your Activity or in any other class you want, according to your app’s
architecture. And here’s the code for creating the BillingClient
instance, and setting the PurchasesUpdatedListener:

mBillingClient = BillingClient.newBuilder(mContext)
                              .setListener(mPurchasesUpdatedListener)
                              .build();

Listing and selling products

To sell products in your app, first, you need to add them using the Play
Console. For more details about how to add in-app products see the page Administering
In-app Billing.

Attention: If this is a brand new app, before adding
the products you must publish it to the alpha or beta distribution channel. For
more information, see Draft
Apps are No Longer Supported.

To get a list of product details with prices for current user, call ,
com.android.billingclient.api.SkuDetailsResponseListener)">querySkuDetailsAsync()
.
You must also specify a listener which implements the SkuDetailsResponseListener
interface. You can then override the onSkuDetailsResponse()
method which notifies the listener when the query finishes, as illustrated by
the following sample code:

List<String> skuList = new ArrayList<> ();
skuList.add("premiumUpgrade");
skuList.add("gas");
SkuDetailsParams.Builder params = SkuDetailsParams.newBuilder();
params.setSkusList(skuList).setType(SkuType.INAPP);
mBillingClient.querySkuDetailsAsync(params.build(),
    new SkuDetailsResponseListener() {
        @Override
        public void onSkuDetailsResponse(SkuDetailsResult result) {
            // Process the result.
        }
    })

After the user chooses a product to buy, you’ll need to start the billing flow
and handle the transaction result. To start a purchase request from your app,
call the launchBillingFlow()
method on the Play Billing Library client. You must call the launchBillingFlow()
method (and all the other methods from BillingClient)
from the UI thread.

The launchBillingFlow()
method needs BillingFlowParams
object that contains relevant data for completing the purchase, such as the
product ID of the item to purchase and the product type (in this case, SkuType.INAPP).
To get an instance of BillingFlowParams,
construct it with newBuilder()
method:

BillingFlowParams.Builder builder = BillingFlowParams
                                       .newBuilder()
                                       .setSku(skuId).setType(SkuType.INAPP);
int responseCode = mBillingClient.launchBillingFlow(builder.build());

As we mentioned earlier, the transaction result will be sent to the )">onPurchasesUpdated()
method. For details how to process the data received on )">onPurchasesUpdated()
and how to handle a purchase, check the section Purchase
an item in our training guide.

Consuming products

By default, all in-app products are managed. It means that Google Play tracks
the product ownership and doesn’t allow to buy multiple times. To be able to buy
a product again, you must consume the product before it becomes available again.

It’s common to implement consumption for in-app products which users may want to
purchase multiple times, such as in-game currency or equipment. You typically
don’t want to implement consumption for in-app products that user purchases once
and provide a permanent effect, such as a premium upgrade.

To consume a product, call the consumeAsync()
method on the Play Billing Library client and pass in the
purchaseToken String value returned when you made the purchase. The
consumption result is returned via onConsumeResponse() method of the ConsumeResponseListener
interface, that you must override to handle the consumption result.

The following example illustrates consuming a product using the associated
purchaseToken:

ConsumeResponseListener listener = new ConsumeResponseListener() {
    @Override
    public void onConsumeResponse(@BillingResponse int responseCode,
                                  String outToken) {
        if (responseCode == BillingResponse.OK) {
            // Handle the success of the consume operation.
            // For example, increase the number of player's coins,
            // that provide temporary benefits
        }
    }
};
mBillingClient.consumeAsync(purchaseToken, listener);

Sample updated: Trivial Drive V2

With a new library comes a refreshed sample! To help you to understand how to
implement in-app billing in your app using the new Play Billing Library, we’ve
rewritten the Trivial
Drive sample from the ground up.

Since we released Trivial Drive back in 2013, many new features, devices, and
platforms have been added to the Android ecosystem. To reflect this evolution,
the Trivial
Drive v2 sample now runs on Android TV and Android Wear.

What’s next?

Before integrating within your app, you can try the Play Billing Library with
the codelab published during Google I/O 2017: Buy
and Subscribe: Monetize your app on Google Play.

In this codelab, you will start with a simplified version of Trivial Drive V2
that lets users to “drive” and then you will add in-app billing to it. You’ll
learn how to integrate purchases and subscriptions as well as the best practices
for developing reliable apps that handle purchases.

Get more info on the Play
Billing Library and the official
reference for classes and methods documentation on the Android Developers
website. For a step-by-step guide to implementing the Play Billing Library in
your project, visit the library’s
training class.

We still want your feedback

If you have issues or questions, file a bug
report on the Google Issue Tracker, and for issues and suggestions on the
sample (like a bug or a new feature), contact us on the Trivial
Drive issues page.

For technical questions on implementation, library usage, and best practices,
you can use the tags google-play
and play-billing-library
on StackOverflow or visit the communities on our
Google+ page.


Android Developers Blog