What's New in Android 5.0 Lollipop

Android 5.0 Lollipop is the biggest update of
Android to date, introducing an all new visual style, improved
performance, and much more. Android 5.0 Lollipop also extends across
screens big and small, including phones, tablets, wearables, TVs and
cars, to give your users access to information when they need it most.

To get you started on developing and testing on Android 5.0 Lollipop,
here are some of the developer highlights with links to related videos
and documentation.

User experience

• Material design for the
  multiscreen world — Material Design is a new approach for designing apps
  in today’s multi-device world that takes a comprehensive strategy to
  visual, motion, and interaction design across a number of platforms and
  form factors. Android 5.0 brings Material Design to the platform, with a
  full set of tools for implementing material design
  in your apps. The system is incredibly flexible, allowing your app to
  express its individual character and brand with bold colors and a
  variety of responsive UI patterns and themeable elements.
• Enhanced notifications
  — New lockscreen notifications let you surface content, updates, and
  actions to users at a glance, without needing to unlock their device.
  Heads-up notifications let you display content and actions in a small
  floating window managed by the system, no matter which app is in the
  foreground. Notifications are refreshed for Material Design and you can
  use accent colors to express your brand.
• Concurrent documents in Overview
  — Now you can organize your app by tasks and present these concurrently
  as individual “documents” on the Overview screen. For example, instant
  messaging apps could declare each chat as a separate document. Users can
  flip through these on the Overview screen to find the specific chat
  they want and jump straight to it.

Performance

• Android Runtime (ART)
  — Android 5.0 runs exclusively on the ART runtime. ART offers
  ahead-of-time (AOT) compilation, more efficient garbage collection, and
  improved development and debugging features. In many cases it improves
  performance of the device, without you having to change your code.
• 64-bit support — Support for 64-bit ABIs provides additional
  address space and improved performance with certain compute workloads.
  Apps written in the Java language can run immediately on 64-bit
  architectures with no modifications required. NDK r10c includes 64-bit support, for apps and games using native code.
• Project Volta
  — New tools and APIs help you build battery-efficient apps. Battery
  Historian, a tool included in the SDK, lets you visualize power events
  over time and understand how your app is using battery. The JobScheduler
  API lets you set the conditions under which your background tasks and
  other jobs should run, such as when the device is idle or connected to
  an unmetered network or to a charger, to minimize battery impact. More
  in this I/O video.
• OpenGL ES 3.1 and Android Extension Pack
  — With OpenGL ES 3.1, you get compute shaders, stencil textures, and
  texture gather for your games. Android Extension Pack (AEP) is a new set
  of extensions to OpenGL ES that bring desktop-class graphics to Android
  including tessellation and geometry shaders, and use ASTC texture
  compression across GPU technologies. More on what's new for game
  developers in this DevBytes video.
• WebView updates — We’ve updated WebView to support WebRTC,
  WebAudio and WebGL will be supported. WebView also includes native
  support for all of the Web Components specifications: Custom Elements,
  Shadow DOM, HTML Imports, and Templates. WebView is now unbundled from
  the system and will be regularly updated through Google Play.

Workplace

• Managed provisioning and unified view of apps
  — to make it easier for employees to have a single device for personal
  and work use, framework enhancements offer a unified view of apps,
  notifications & recents across work apps and personal apps. Profile
  owner APIs, in the workplace context, let administrators create and
  manage work profiles and defined as part of a new managed provisioning
  process. More in this I/O video.

Media

• Advanced camera capabilities
  — A new camera API gives you new capabilities for advanced image
  capture and processing. On supported devices, your app can capture
  uncompressed YUV capture at full 8 megapixel resolution at 30 FPS. You
  can also capture raw sensor data and control parameters such as exposure
  time, ISO sensitivity, and frame duration, on a per-frame basis.
• Audio improvements
  — The sound architecture has been enhanced, with lower input latency in
  OpenSL, the addition of multichannel-mixing, and USB digital audio mode
  support. More in this I/O video.

Connectivity

• BLE Peripheral Mode
  — Android devices can now function in Bluetooth Low Energy (BLE)
  peripheral mode. Apps can use this capability to broadcast their
  presence to nearby devices — for example, you can now build apps that
  let a device function as a beacon and transmit data to another BLE
  device. More in this I/O video.
• Multi-networking
  — Apps can dynamically request networks based on capabilities such as
  metered or unmetered. This is useful when you want to use a specific
  network, such as cellular. Apps can also request platform to re-evaluate
  networks for an internet connection. This is useful when your app sees
  unusually high latency on a particular network, it can enable the
  platform to switch to a better network (if available) sooner with a
  graceful handoff.

Get started!

You can get started developing and testing on Android 5.0
right away by downloading the Android 5.0 Platform (API level 21), as
well as the SDK Tools, Platform Tools, and Support Package from the Android SDK Manager.

Check out the DevByte video below for more of what’s new in Lollipop!

Read More

AppCompat v21 — Material Design for Pre-Lollipop Devices!

The Android 5.0 SDK
was released last Friday, featuring new UI widgets and material design,
our visual language focused on good design. To enable you to bring your
latest designs to older Android platforms we have expanded our support
libraries, including a major update to AppCompat, as well as new RecyclerView, CardView and Palette libraries.

In this post we'll take a look at what’s new in AppCompat and how you can use it to support material design in your apps.

What's new in AppCompat?

AppCompat (aka ActionBarCompat) started out as a backport of the
Android 4.0 ActionBar API for devices running on Gingerbread, providing a
common API layer on top of the backported implementation and the
framework implementation. AppCompat v21 delivers an API and feature-set
that is up-to-date with Android 5.0



In this release, Android introduces a new Toolbar widget. This is a generalization of the Action Bar pattern that gives you much more control and flexibility. Toolbar
is a view in your hierarchy just like any other, making it easier to
interleave with the rest of your views, animate it, and react to scroll
events. You can also set it as your Activity’s action bar, meaning that
your standard options menu actions will be display within it.



You’ve likely already been using the latest update to AppCompat for a
while, it has been included in various Google app updates over the past
few weeks, including Play Store and Play Newsstand. It has also been
integrated into the Google I/O Android app, pictured above, which is open-source.

Setup

If you’re using Gradle, add appcompat as a dependency in your build.gradle file:

dependencies {
    compile "com.android.support:appcompat-v7:21.0.+"
}

New integration

If you are not currently using AppCompat, or you are starting from scratch, here's how to set it up:

• All of your Activities must extend from ActionBarActivity, which extends from FragmentActivity from the v4 support library, so you can continue to use fragments.
• All of your themes (that want an Action Bar/Toolbar) must inherit from Theme.AppCompat. There are variants available, including Light and NoActionBar.
• When inflating anything to be displayed on the action bar (such as a SpinnerAdapter for list navigation in the toolbar), make sure you use the action bar’s themed context, retrieved via getSupportActionBar().getThemedContext().
• You must use the static methods in MenuItemCompat for any action-related calls on a MenuItem.

For more information, see the Action Bar API guide which is a comprehensive guide on AppCompat.

Migration from previous setup

For most apps, you now only need one theme declaration, in values/:

values/themes.xml:
<style name="Theme.MyTheme" parent="Theme.AppCompat.Light">
    <!-- Set AppCompat’s actionBarStyle -->
    <item name="actionBarStyle">@style/MyActionBarStyle</item>

    <!-- Set AppCompat’s color theming attrs -->
    <item name=”colorPrimary”>@color/my_awesome_red</item>
    <item name=”colorPrimaryDark”>@color/my_awesome_darker_red</item>
    
    <!-- The rest of your attributes -->
</style>

You can now remove all of your values-v14+ Action Bar styles.

Theming

AppCompat has support for the new color palette theme attributes which allow you to easily customize your theme to fit your brand with primary and accent colors. For example:

values/themes.xml:
<style name="Theme.MyTheme" parent="Theme.AppCompat.Light">
    <!-- colorPrimary is used for the default action bar background -->
    <item name=”colorPrimary”>@color/my_awesome_color</item>

    <!-- colorPrimaryDark is used for the status bar -->
    <item name=”colorPrimaryDark”>@color/my_awesome_darker_color</item>

    <!-- colorAccent is used as the default value for colorControlActivated,
         which is used to tint widgets -->
    <item name=”colorAccent”>@color/accent</item>

    <!-- You can also set colorControlNormal, colorControlActivated
         colorControlHighlight, and colorSwitchThumbNormal. -->
    
</style>

When you set these attributes, AppCompat automatically propagates
their values to the framework attributes on API 21+. This automatically
colors the status bar and Overview (Recents) task entry.



On older platforms, AppCompat emulates the color theming where
possible. At the moment this is limited to coloring the action bar and
some widgets.

Widget tinting

When running on devices with Android 5.0, all of the widgets are
tinted using the color theme attributes we just talked about. There are
two main features which allow this on Lollipop: drawable tinting, and
referencing theme attributes (of the form ?attr/foo) in drawables.



AppCompat provides similar behaviour on earlier versions of Android for a subset of UI widgets:

• Everything provided by AppCompat’s toolbar (action modes, etc)
• EditText
• Spinner
• CheckBox
• RadioButton
• Switch (use the new android.support.v7.widget.SwitchCompat)
• CheckedTextView

You don’t need to do anything special to make these work, just use
these controls in your layouts as usual and AppCompat will do the rest
(with some caveats; see the FAQ below).

Toolbar Widget

Toolbar is fully supported in AppCompat and has feature and API parity with the framework widget. In AppCompat, Toolbar is implemented in the android.support.v7.widget.Toolbar class. There are two ways to use Toolbar:

• Use a Toolbar as an Action Bar when you want to use the existing Action Bar facilities (such as menu inflation and selection, ActionBarDrawerToggle, and so on) but want to have more control over its appearance.
• Use a standalone Toolbar when you want to use the
  pattern in your app for situations that an Action Bar would not support;
  for example, showing multiple toolbars on the screen, spanning only
  part of the width, and so on.

Action Bar

To use Toolbar as an Action Bar, first disable the decor-provided Action Bar. The easiest way is to have your theme extend from Theme.AppCompat.NoActionBar (or its light variant).



Second, create a Toolbar instance, usually via your layout XML:

<android.support.v7.widget.Toolbar
    android:id=”@+id/my_awesome_toolbar”
    android:layout_height=”wrap_content”
    android:layout_width=”match_parent”
    android:minHeight=”?attr/actionBarSize”
    android:background=”?attr/colorPrimary” />

The height, width, background, and so on are totally up to you; these are just good examples. As Toolbar is just a ViewGroup, you can style and position it however you want.



Then in your Activity or Fragment, set the Toolbar to act as your Action Bar:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.blah);

    Toolbar toolbar = (Toolbar) findViewById(R.id.my_awesome_toolbar);
    setSupportActionBar(toolbar);
}

From this point on, all menu items are displayed in your Toolbar, populated via the standard options menu callbacks.

Standalone

The difference in standalone mode is that you do not set the Toolbar
to act as your action bar. For this reason, you can use any AppCompat
theme and you do not need to disable the decor-provided Action Bar.



In standalone mode, you need to manually populate the Toolbar with
content/actions. For instance, if you want it to display actions, you
need to inflate a menu into it:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.blah);

    Toolbar toolbar = (Toolbar) findViewById(R.id.my_awesome_toolbar);

    // Set an OnMenuItemClickListener to handle menu item clicks
    toolbar.setOnMenuItemClickListener(new Toolbar.OnMenuItemClickListener() {
        @Override
        public boolean onMenuItemClick(MenuItem item) {
            // Handle the menu item
            return true;
        }
    });

    // Inflate a menu to be displayed in the toolbar
    toolbar.inflateMenu(R.menu.your_toolbar_menu);
}

There are many other things you can do with Toolbar. For more information, see the Toolbar API reference.

Styling

Styling of Toolbar is done differently to the standard action bar, and is set directly onto the view.



Here's a basic style you should be using when you're using a Toolbar as your action bar:

<android.support.v7.widget.Toolbar  
    android:layout_height="wrap_content"
    android:layout_width="match_parent"
    android:minHeight="?attr/actionBarSize"
    app:theme="@style/ThemeOverlay.AppCompat.ActionBar" />

The app:theme declaration will make sure that your text and items are using solid colors (i.e 100% opacity white).

DarkActionBar

You can style Toolbar instances directly using layout attributes. To achieve a Toolbar which looks like 'DarkActionBar' (dark content, light overflow menu), provide the theme and popupTheme attributes:

<android.support.v7.widget.Toolbar
    android:layout_height=”wrap_content”
    android:layout_width=”match_parent”
    android:minHeight=”@dimen/triple_height_toolbar”
    app:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"
    app:popupTheme="@style/ThemeOverlay.AppCompat.Light" />

SearchView Widget

AppCompat offers Lollipop’s updated SearchView API,
which is far more customizable and styleable (queue the applause). We
now use the Lollipop style structure instead of the old searchView* theme attributes.



Here’s how you style SearchView:

values/themes.xml:
<style name=”Theme.MyTheme” parent=”Theme.AppCompat”>
    <item name=”searchViewStyle”>@style/MySearchViewStyle</item>
</style>
<style name=”MySearchViewStyle” parent=”Widget.AppCompat.SearchView”>
    <!-- Background for the search query section (e.g. EditText) -->
    <item name="queryBackground">...</item>
    <!-- Background for the actions section (e.g. voice, submit) -->
    <item name="submitBackground">...</item>
    <!-- Close button icon -->
    <item name="closeIcon">...</item>
    <!-- Search button icon -->
    <item name="searchIcon">...</item>
    <!-- Go/commit button icon -->
    <item name="goIcon">...</item>
    <!-- Voice search button icon -->
    <item name="voiceIcon">...</item>
    <!-- Commit icon shown in the query suggestion row -->
    <item name="commitIcon">...</item>
    <!-- Layout for query suggestion rows -->
    <item name="suggestionRowLayout">...</item>
</style>

You do not need to set all (or any) of these, the defaults will work for the majority of apps.

Toolbar is coming...

Hopefully this post will help you get up and running with AppCompat
and let you create some awesome material apps. Let us know in the
comments/G+/Twitter if you’re have questions about AppCompat or any of
the support libraries, or where we could provide more documentation.

FAQ

Why is my EditText (or other widget listed above) not being tinted correctly on my pre-Lollipop device?

The widget tinting in AppCompat works by intercepting any layout inflation and inserting a special tint-aware version of the widget in its place. For most people this will work fine, but I can think of a few scenarios where this won’t work, including:

• You have your own custom version of the widget (i.e. you’ve extended EditText)
• You are creating the EditText without a LayoutInflater (i.e., calling new EditText()).

The special tint-aware widgets are currently hidden as they’re an unfinished implementation detail. This may change in the future.

Why has X widget not been material-styled when running on pre-Lollipop?

Only some of the most common widgets have been updated so far. There are more coming in future releases of AppCompat.

Why does my Action Bar have a shadow on Android Lollipop? I’ve set android:windowContentOverlay to null.

On Lollipop, the action bar shadow is provided using the new elevation API. To remove it, either call getSupportActionBar().setElevation(0), or set the elevation attribute in your Action Bar style.

Why are there no ripples on pre-Lollipop?

A lot of what allows RippleDrawable to run smoothly is Android 5.0’s new RenderThread. To optimize for performance on previous versions of Android, we've left RippleDrawable out for now.

How do I use AppCompat with Preferences?

You can continue to use PreferenceFragment in your ActionBarActivity when running on an API v11+ device. For devices before that, you will need to provide a normal PreferenceActivity which is not material-styled.

Read More

GPS on Android Wear Devices

With the latest release of Android Wear, wearables with built-in GPS like the Sony Smartwatch 3
can now give you a GPS location update directly from the wearable,
without a paired phone nearby. You can now build an app like MyTracks
that lets a user track their run even when they leave their phone at
home. For wearable devices that do not have built-in GPS, a software
solution has always existed in Google Play Services that automatically
uses the GPS from your connected phone.

The Golfshot wearable app uses built-in GPS to calculate your distance to the next hole, even when you don’t have your phone with you.

Implementing GPS location updates

Implementing GPS location updates for Android Wear is simple. On the wearable, use the FusedLocationProviderApi from Google Play services
to request location updates. This is the same API that has been
available on mobile, so you can easily reuse your existing code and
samples.

FusedLocationProviderApi
automatically makes the most power-efficient decision about where to
get location updates. If the phone is connected to the wearable, it uses
the GPS on the phone and sends the updates to the wearable. If the
phone is not connected to the wearable and the wearable has a built-in
GPS, then it uses the wearable’s GPS.

One case you’ll need to handle is if the phone is not connected to
the wearable and the wearable does not have built-in GPS. You will need
to detect this
and provide a graceful recovery mechanism, such as a message telling
the user to bring their phone with them. However, for the most part,
deciding which GPS to use, and sending the position from the phone to
the wearable, is handled automatically. You do not need to deal with the
low-level implementation details yourself.

Data synchronization

When writing an app that runs on the wearable, you will eventually
want to synchronize the data it collects with the paired phone. When the
wearable is being taken out for a run, especially with the built-in
GPS, there may not be a phone present. So you will want to store your
location data using the Data Layer API, and when the phone reconnects with the wearable later, the data will be automatically synchronized.

For more details about how to use the location API, check out the extensive documentation and sample here.

Android Wear apps on Google Play

Also, as a heads up, starting on November 3 with the public release of Android 5.0,
you will be able to submit your apps for clearer designation as Android
Wear apps on Google Play. If your apps follow the criteria in the Wear App Quality checklist
and are accepted as Wear apps on Play, it will be easier for Android
Wear users to discover your apps. Stay tuned for more information about
how to submit your apps for Android Wear review through the Google Play
Developer Console.

Read More

Getting Your Apps Ready for Nexus 6 and Nexus 9

Updated material design Tumblr app on Nexus 6.

Last week, we unveiled the Nexus 6 and Nexus 9, the newest additions to
our Nexus family that will ship with Android 5.0 Lollipop. Together,
they deliver a pure Google experience, showcasing fresh visual styles
with material design, improved performance, and additional features.

Let’s make sure your apps and games are optimized to give your users
the best mobile experience on these devices. We’ve outlined some best
practices below.

Nexus 6

Screen

The Nexus 6 boasts an impressive 5.96” Quad HD screen display at a resolution of 2560 x 1440 (493 ppi). This translates to ~ 730 x 410 dp (density independent pixels).

Check your assets

It has a quantized density of 560 dpi, which falls in between the xxhdpi and xxxhdpi primary density buckets. For the Nexus 6, the platform will scale down xxxhdpi assets, but if those aren’t available, then it will scale up xxhdpi assets.

Provide at least an xxxhdpi app icon because devices can display large app icons on the launcher. It’s best practice to place your app icons in mipmap- folders (not the drawable- folders) because they are used at resolutions different from the device’s current density. For example, an xxxhdpi app icon can be used on the launcher for an xxhdpi device.

res/
   mipmap-mdpi/
      ic_launcher.png
   mipmap-hdpi/
      ic_launcher.png
   mipmap-xhdpi/
      ic_launcher.png  
   mipmap-xxhdpi/
      ic_launcher.png
   mipmap-xxxhdpi/   
      ic_launcher.png  # App icon used on Nexus 6 device launcher

Choosing to add xxxhdpi versions for the rest of your
assets will provide a sharper visual experience on the Nexus 6, but does
increase apk size, so you should make an appropriate decision for your
app.

res/
   drawable-mdpi/
      ic_sunny.png
   drawable-hdpi/
      ic_sunny.png
   drawable-xhdpi/   
      ic_sunny.png
   drawable-xxhdpi/  # Fall back to these if xxxhdpi versions aren’t available
      ic_sunny.png 
   drawable-xxxhdpi/ # Higher resolution assets for Nexus 6
      ic_sunny.png

Make sure you are not filtered on Google Play

If you are using the <compatible-screens> element in the AndroidManifest.xml file, you should stop using it
because it’s not scalable to re-compile and publish your app each time
new devices come out. However, if you must use it, make sure to update
the manifest to add the configuration for these devices (by screen size and density). Otherwise your app may be excluded from Google Play search results on these devices.

Nexus 9

Screen

The Nexus 9 is a premium 8.9” tablet with a screen size of 2048 x 1536 pixels (288 ppi), which translates to 1024 x 768 dip. This is a 4:3 aspect ratio, which is unique compared to earlier tablets. The Nexus 9 falls into the xhdpi density bucket, and you should already have assets in the drawable-xhdpi folder. 

Updated Material Design Wall Street Journal app on Nexus 9.

Enable NDK apps for 64-bit

The Nexus 9 runs on a 64-bit Dual Core processor, which makes it the
first Android device to ship with a 64-bit ARM instruction set. Support
for 64-bit processors was just added in Android 5.0, so if you have an
NDK app, enable it by updating the APP_ABI value in your Application.mk file:

APP_ABI := armeabi armeabi-v7a arm64-v8a x86 x86_64 mips mips64

More detailed instructions are provided in the developer site.
You can test your 64-bit enabled app on a physical device with a 64-bit
processor running Android 5.0, or take advantage of the recently
announced 64-bit emulator in Android Studio.

Update your hardware keyboard support

The Nexus 9 Keyboard Folio will be available as an accessory in Google Play. It’s very important that you don’t lock your app to a single orientation.
The Nexus 9’s natural orientation is portrait mode, while it’s used in
landscape mode with the keyboard. If you lock to the device’s natural
orientation, the app may appear sideways for devices with keyboards.

Users should be able to navigate around the main content of the app
with the keyboard, while relying on touch input or keyboard shortcuts
for toolbar actions and button bars. Therefore, ensure that your app has proper keyboard navigation and shortcuts for primary actions. Keyboard shortcuts that are invoked with Ctrl + [shortcut] combo can be defined via menu items using:

<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item
        android:id="@+id/menu_create"
        android:title="@string/menu_create"
        android:alphabeticShortcut="c” />
</menu/>

Alternatively, shortcuts can be defined using Activity#onKeyShortcut or View#onKeyShortcut. Learn more about keyboard actions here.

In MainActivity.java:
@Override
public boolean onKeyShortcut(int keyCode, KeyEvent event) {
    switch (keyCode) {
        case KeyEvent.KEYCODE_R:
            Toast.makeText(this, "Reply", Toast.LENGTH_SHORT).show();
            return true;
        default:
            return super.onKeyShortcut(keyCode, event);
    }
}

Responsive layouts with w- and sw- qualifiers

In order to take advantage of the screen real estate on the Nexus 6
and Nexus 9, we emphasize the importance of responsive design. In the
past, if you assumed that landscape mode is significantly wider than
portrait mode, you may run into problems on a device like the Nexus 9,
which has an aspect ratio of 4:3. Instead of declaring layouts using the
layout-land or layout-port resource folder qualifiers, we strongly recommend switching to the w<N>dp width resource folder qualifier so that content is laid out based on available screen width.

Think about content first and foremost. Decide on min and max screen
real estate that your content requires, and determine cutoff points at
different screen widths where you can modify the layout composition for
your app (# of grid columns, multi-pane layout, etc…).

For example, a single pane layout for your main activity on phones can be defined in:

res/layout/activity_main.xml

On larger screen devices, where the current orientation is at least
600dp in width, a new two-pane layout with a list alongside a detail
pane could be declared in:

res/layout-w600dp/activity_main.xml

On even larger screen devices, where the current orientation is at
least 720dp in width, a new multi-pane layout where the detail pane
requires even more horizontal space could be declared in:

res/layout-w720dp/activity_main.xml

As for attributes based on form factor, instead of declaring them in
values-large or values-xlarge resource directories, use the sw<N>dp smallest width qualifier. For example, you could style your TextViews to have a medium font size on phones.

In res/values/styles.xml:
<style name="DescriptionTextStyle">
  <item name="android:textAppearance">?android:attr/textAppearanceMedium</item>
</style>

Meanwhile, TextViews could have a large font size when the smallest
width of the device (taking the minimum of the landscape and portrait
widths) is 600dp or wider. This ensures the font size of your app
doesn’t change when you rotate this large screen device.

In res/values-sw600dp/styles.xml:
<style name="DescriptionTextStyle">
  <item name="android:textAppearance">?android:attr/textAppearanceLarge</item>
</style> 

Take advantage of 5.0 and Material

Set your android:targetSdkVersion to "21". Take note of the important behavior changes
in Android 5.0 Lollipop including ART, the new Android runtime, to
ensure that your app continues to run well. You can also leverage new platform APIs like richer notifications.

Nexus 6 and Nexus 9 users will be immersed in the new world of material design,
and they’ll expect the same seamless transitions, bold colors, and
delightful details from your app. As you invest time in bringing your
app up to date with our latest design language, there’s a whole host of
resources to help you make the leap, including important new updates to
the support library, videos, and a getting started guide. Good luck and we can’t wait to see your apps!

Read More

Implementing Material Design in Your Android app

 

 

Material design
is a comprehensive approach to visual, interaction and motion design
for the multi-screen world. Android 5.0 Lollipop and the updated
support libraries help you to create material UIs. Here’s a rundown of
some of the major elements of material design and the APIs and widgets
that you can use to implement them in your app.

Tangible surfaces

In material design, UIs are composed of pieces of digital paper & ink.
The surfaces and the shadows they cast provide visual cues to the
structure of the application, what you can touch and how it will move.
This digital material can move, expand and reform to create flexible
UIs.

Shadows

A surface’s position and depth result in subtle changes in lighting
and shadows. The new elevation property lets you specify a view’s
position on the Z-axis and the framework then casts a real-time dynamic
shadow on items behind it. You can set the elevation declaratively in
your layouts, defined in dips:

<ImageView …
    android:elevation="8dp" />

You can also set this from code using getElevation()/setElevation() (with shims in ViewCompat).
The shadow a view casts is defined by its outline, which by default is
derived from its background. For example if you set a circular shape
drawable as the background for a floating action button, then it would cast an appropriate shadow. If you need finer control of a view’s shadow, you can set a ViewOutlineProvider which can customise the Outline in getOutline().

Cards

Cards are a common pattern for creating surfaces holding a distinct piece of information. The new CardView
support library allows you to create them easily, providing outlines
and shadows for you (with equivalent behaviour on prior platforms).

<android.support.v7.widget.CardView
    android:layout_width="match_parent"
    android:layout_height="wrap_content">
    <!-- Your card content -->
</android.support.v7.widget.CardView>

CardView extends FrameLayout and provides
default elevation and corner radius for you so that cards have a
consistent appearance across the platform. You can customise these via
the cardElevation and cardCornerRadius attributes, if required. Note that Cards are not the only way of achieving dimensionality and you should be wary of over-cardifying your UI!

Print-like Design

Material utilises classic principles from print design to create
clean, simple layouts that put your content front and center. Bold
deliberate color choices, intentional whitespace, tasteful typography
and a strong baseline grid create hierarchy, meaning and focus.

Typography

Android 5.0 updates the system font Roboto to beautifully and clearly
display text no matter the display size. A new medium weight has been
added (android:fontFamily=”sans-serif-medium”) and new TextAppearance styles implement the recommended typographic scale for balancing content density and reading comfort. For instance you can easily use the ‘Title’ style by setting android:textAppearance=”@android:style/TextAppearance.Material.Title”. These styles are available on older platforms through the AppCompat support library, e.g. “@style/TextAppearance.AppCompat.Title”.

Color

 

 

Your application’s color palette
brings branding and personality to your app so we’ve made it simple to
colorize UI controls by using the following theme attributes:

• colorPrimary. The primary branding color for the app; used as the action bar background, recents task title and in edge effects.
• colorAccent. Vibrant complement to the primary branding color. Applied to framework controls such as EditText and Switch.
• colorPrimaryDark. Darker variant of the primary branding color; applied to the status bar.

Further attributes give fine grained control over colorizing controls, see: colorControlNormal, colorControlActivated, colorControlHighlight, colorButtonNormal, colorSwitchThumbNormal, colorEdgeEffect, statusBarColor and navigationBarColor.

AppCompat provides a large subset of the functionality above, allowing you to colorize controls on pre-Lollipop platforms.

Dynamic color

Material Design encourages dynamic use of color, especially when you
have rich images to work with. The new Palette support library lets you
extract a small set of colors from an image to style your UI controls
to match; creating an immersive experience. The extracted palette will
include vibrant and muted tones as well as foreground text colors for
optimal legibility. For example:

Palette.generateAsync(bitmap,
        new Palette.PaletteAsyncListener() {
    @Override
    public void onGenerated(Palette palette) {
         Palette.Swatch vibrant =
                 palette.getVibrantSwatch();
          if (swatch != null) {
              // If we have a vibrant color
              // update the title TextView
              titleView.setBackgroundColor(
                  vibrant.getRgb());
              titleView.setTextColor(
                  vibrant.getTitleTextColor());
          }
    }
});

Authentic Motion

Tangible surfaces don’t just appear out of nowhere like a jump-cut in
a movie; they move into place helping to focus attention, establish
spatial relationships and maintain continuity. Materials respond to
touch to confirm your interaction and all changes radiate outward from
your touch point. All motion is meaningful and intimate, aiding the
user’s comprehension.

Activity + Fragment Transitions

By declaring ‘shared elements’ that are common across two screens you can create a smooth transition between the two states.

 

 

album_grid.xml
…
    <ImageView
        …
        android:transitionName="@string/transition_album_cover" />
album_details.xml
…
    <ImageView
        …
        android:transitionName="@string/transition_album_cover" />
AlbumActivity.java
Intent intent = new Intent();
String transitionName = getString(R.string.transition_album_cover);
…
ActivityOptionsCompat options =
ActivityOptionsCompat.makeSceneTransitionAnimation(activity,
    albumCoverImageView,   // The view which starts the transition
    transitionName    // The transitionName of the view we’re transitioning to
    );
ActivityCompat.startActivity(activity, intent, options.toBundle());

Here we define the same transitionName in two screens.
When starting the new Activity and this transition is animated
automatically. In addition to shared elements, you can now also
choreograph entering and exiting elements.

Ripples

Materials respond to users’ touch with an ink ripple surface reaction. Interactive controls such as Buttons exhibit this behaviour by default when you use or inherit from Theme.Material (as will ?android:selectableItemBackground). You can add this feedback to your own drawables by simply wrapping them in a ripple element:

<ripple
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:color="@color/accent_dark">
    <item>
        <shape
            android:shape="oval">
            <solid android:color="?android:colorAccent" />
        </shape>
    </item>
</ripple>

Custom views should propagate touch location down to their drawables in the View#drawableHotspotChanged callback so that the ripple can start from the touch point.

StateListAnimator

Materials also respond to touch by raising up
to meet your finger, like a magnetic attraction. You can achieve this
effect by animating the translationZ attribute which is analogous to
elevation but intended for transient use; such that Z = elevation + translationZ. The new stateListAnimator attribute allows you to easily animate the translationZ on touch (Buttons do this by default):

layout/your_layout.xml
<ImageButton …
    android:stateListAnimator="@anim/raise" />
anim/raise.xml
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_enabled="true" android:state_pressed="true">
        <objectAnimator
            android:duration="@android:integer/config_shortAnimTime"
            android:propertyName="translationZ"
            android:valueTo="@dimen/touch_raise"
            android:valueType="floatType" />
    </item>
    <item>
        <objectAnimator
            android:duration="@android:integer/config_shortAnimTime"
            android:propertyName="translationZ"
            android:valueTo="0dp"
            android:valueType="floatType" />
    </item>
</selector>

Reveal

A hallmark material transition for showing new content is to reveal
it with an expanding circular mask. This helps to reinforce the user’s
touchpoint as the start of all transitions, with its effects radiating outward radially. You can implement this using the following Animator:

Animator reveal = ViewAnimationUtils.createCircularReveal(
                    viewToReveal, // The new View to reveal
                    centerX,      // x co-ordinate to start the mask from
                    centerY,      // y co-ordinate to start the mask from
                    startRadius,  // radius of the starting mask
                    endRadius);   // radius of the final mask
reveal.start();

Interpolators

Motion should be deliberate, swift and precise. Unlike typical
ease-in-ease-out transitions, in Material Design, objects tend to start
quickly and ease into their final position. Over the course of the
animation, the object spends more time near its final destination. As a
result, the user isn’t left waiting for the animation to finish, and the
negative effects of motion are minimized. A new fast-in-slow-out interpolator has been added to achieve this motion.

 

 

For elements entering and exiting the screen (which should do so at peak velocity), check out the linear-out-slow-in and fast-out-linear-in interpolators respectively.

Adaptive design

Our final core concept of material is creating a single adaptive
design that works across devices of all sizes and shapes, from watches
to giant TVs. Adaptive design techniques help us realize the vision
that each device reflects a different view of the same underlying
system. Each view is tailored to the size and interaction appropriate
for that device. Colors, iconography, hierarchy, and spatial
relationships remain constant. The material design system provides
flexible components and patterns to help you build a design that scales.

Toolbar

The toolbar is a generalization of the action bar pattern, providing
similar functionality, but much more flexibility. Unlike the standard
action bar, toolbar is a view in your hierarchy just like any other, so
you can place instances wherever you like, interleave them with the rest
of your views, animate, react to scroll events and so on. You can make
the Toolbar act as your Activity’s Action Bar by calling
Activity.setActionBar().

 

 

In this example, the blue toolbar is an extended height, overlaid by
the screen content and provides the navigation button. Note that two
further toolbars are used in the list and detail views.

For details of implementing toolbars, see this post.

Go Forth and Materialize

Material Design helps you to build understandable, beautiful and
adaptive apps, which are alive with motion. Hopefully, this post has
inspired you to apply these principles to your app and signposted some
of the new (and compatibility) APIs to achieve this.

Read More