Yuzi download

Building TV Channels

Channel surfing is a popular way of watching TV. You pick up the remote, lean back, and flip through channels to see what’s on. On Android TV, app developers can create their own channel-like experiences using the TV Input Framework.

To the user, the channels you create look and feel just like regular TV channel. But behind the scenes, they stream video over the internet. For example, you can create a channel from a video playlist.

Watch this DevByte for an overview of how to build to a channel, and see the sample app and developer training for more info. The sample shows how to work with a variety of media formats, including HLS, MPEG-Dash, and HTTP Progressive.

If you already have an app that streams video, consider also making your content available as a channel. It’s a great opportunity to increase engagement. We’re excited to see what you develop, and look forward to seeing your content on the big screen!

Available link for download

Building better apps with Runtime Permissions

Posted by Ian Lake, Developer Advocate

Android devices do a lot, whether it is taking pictures, getting directions or making phone calls. With all of this functionality comes a large amount of very sensitive user data including contacts, calendar appointments, current location, and more. This sensitive information is protected by permissions, which each app must have before being able to access the data. Android 6.0 Marshmallow introduces one of the largest changes to the permissions model with the addition of runtime permissions, a new permission model that replaces the existing install time permissions model when you target API 23 and the app is running on an Android 6.0+ device.

Runtime permissions give your app the ability to control when and with what context you’ll ask for permissions. This means that users installing your app from Google Play will not be required to accept a list of permissions before installing your app, making it easy for users to get directly into your app. It also means that if your app adds new permissions, app updates will not be blocked until the user accepts the new permissions. Instead, your app can ask for the newly added runtime permissions as needed.

Finding the right time to ask for runtime permissions has an important impact on your app’s user experience. We’ve gathered a number of design patterns in our new Permission design guidelines including best practices around when to request permissions, how to explain why permissions are needed, and how to handle permissions being denied.

In many cases, you can avoid permissions altogether by using the existing intents system to utilize other existing specialized apps rather than building a full experience within your app. An example of this is using ACTION_IMAGE_CAPTURE to start an existing camera app the user is familiar with rather than building your own camera experience. Learn more about permissions versus intents.

However, if you do need a runtime permission, there’s a number of tools to help you. Checking for whether your app has a permission is possible with ContextCompat.checkSelfPermission() (available as part of revision 23 of the support-v4 library for backward compatibility) and requesting permissions can be done with requestPermissions(), bringing up the system controlled permissions dialog to allow the user to grant you the requested permission(s) if you don’t already have them. Keep in mind that users can revoke permissions at any time through the system settings so you should always check permissions every time.

A special note should be made around shouldShowRequestPermissionRationale(). This method returns true if the user has denied your permission request at least once yet have not selected the ‘Don’t ask again’ option (which appears the second or later time the permission dialog appears). This gives you an opportunity to provide additional education around the feature and why you need the given permission. Learn more about explaining why the app needs permissions.

Read through the design guidelines and our developer guide for all of the details in getting your app ready for Android 6.0 and runtime permissions. Making it easy to install your app and providing context around accessing user’s sensitive data are key changes you can make to build better apps.

Join the discussion on

+Android Developers

Available link for download

Fragments 101 building better user interfaces

Android is an exciting platform to develop for, but it does have one major limitation: you can only display a single Activity onscreen at any one time (true, the upcoming Multi-Window mode does seem set to shake things up a bit, but well get to that shortly).

Thats where fragments come in.

Ever since Android 3.0, fragments have given developers a way of dividing their apps user interface into multiple, self-contained blocks, and then displaying these blocks in the way that makes sense for the users current screen configuration.

When you include fragments in your application, your app can either display these fragments:

• One at a time in separate activities, in whats known as single-pane mode.
• Side-by-side in a single Activity, in whats known as multi-pane mode.

For example, if you use fragments your app may choose to display a single fragment on a handset thats held in portrait mode, and then display two fragments side-by-side on a tablet-sized device – or, it may even switch to multi-pane mode when the user tilts that aforementioned handset from portrait mode, into landscape mode.

This is where the real value of fragments lie: they give you a way of designing a single UI thats flexible enough to adapt to a wide range of different screen configurations. Thanks to the magic of fragments, you can sleep soundly at night knowing that your app is providing a good user experience, regardless of the kind of device it winds up on.

So what is a fragment, exactly?

Lets look at an example. Imagine you have a single Activity (the imaginatively-titled Activity A) and two fragments (Fragment 1 and Fragment 2).

Fragment 1 displays a list of nearby tourist attractions the user might want to visit. When the user selects an item from this list, Fragment B displays information about the currently-selected attraction.

Depending on the current screen configuration, your app may display these fragments in the following ways:

• If the users screen is large enough, Activity A will display Fragment 1 and Fragment 2 side-by-side, in a multi-pane layout.
• If there isnt enough room to accommodate both fragments, the app displays each fragment separately. In this scenario, Activity A displays Fragment 1 only. When the user selects an item from Fragment 1, the app creates a new Activity (lets call it Activity B) whose sole purpose in life is to host Fragment B.

Where does Multi-Window mode fit into all of this?

At this point you may be wondering: whats the difference between fragments and Nougats Multi-Window mode?

Android 7.0 seems set to address some of the platforms one-Activity-at-a-time limitations, but theres a crucial difference between fragments and Multi-Window:

• Multi-Window will allow Android users to view Activities from different applications side-by-side.
• Fragments give developers a way of displaying different content within a single application, depending on the users current screen configuration.

What you need to know before using fragments

When used correctly, fragments are a powerful tool in the Android developers arsenal, but if youre going to get the most out of fragments theres a couple of things you need to bear in mind:

1. A fragment is closely tied to its host Activity

A fragment may have its own behaviour, user interface and (to a certain extent) its own lifecycle, but it can only ever exist inside a host Activity. In fact, let me clarify that point about a fragments lifecycle: you can only add and remove fragments when the host Activity is in its resumed state. This means that even though a fragment does have a distinct lifecycle, that lifecycle is dependent on the lifecycle of its host Activity.

For the sake of keeping this tutorial (relatively) punchy, Im only going to look at how to add a fragment to an Activity declaratively, as this is the quickest and easiest way of getting started with fragments. The downside to this particular method, is that you wont be able to add and remove this fragment at runtime – if this is your end goal, then youll need to delve into your applications code (and the official Android docs has lots of useful info on this).

2. Backwards compatibility

If you want your app to connect with the largest possible audience (and who wouldnt want that?) then it has to be compatible with as many different versions of the Android operating system as possible. The good news is that, even though fragments didnt find their way into Android until Honeycomb, you can use fragments in your project while remaining backwards compatible with Android 1.6 and higher, thanks to the Android Support Library v4.

To add this Support Library to your project, launch the Android SDK Manager, select the SDK Tools tab and download the Android Support Repository.

Next, add the library to your project by opening its module-level build.gradle file and adding the following to its dependencies section:

 dependencies { ……… ……… ……… compile com.android.support:appcompat-v7:24.0.0 } 

This is all you need to do for now, but just be aware that when you come to create your host Activity youll need to do the following:

• Extend FragmentActivity, instead of the usual Activity class.
• Import the android.support.v4.app.Fragment class.

Ill come back to both of these points when were looking at how to create your first Android fragment – which conveniently, just-so-happens to be the subject of our next section.

Creating a Fragment

Although you can create invisible fragments that contribute background behaviour but dont contribute a UI component, most fragments do have a user interface, so Im going to kick things off by defining my fragments UI.

In Android Studio, create a new layout file by opening your projects app/res folder, and then right-clicking the layout folder and selecting New, followed by Layout resource file.

Give your layout resource file a name (Im going to use list_fragment) and select the root element you want to use, such as LinearLayout or RelativeLayout.

Click OK and Android Studio will go ahead and create your layout resource file. At this point you can add whatever UI elements you want to include in your fragment. Im going to use the following:

 <?xml version="1.0" encoding="utf-8"?> <LinearLayout  android_orientation="vertical" android_layout_width="match_parent" android_layout_height="wrap_content" android_background="#CCCCCC"> <TextView android_layout_width="wrap_content" android_layout_height="wrap_content" android_textSize="30sp" android_textStyle="bold" android_textColor="#ffffff" android_text="This is the contents of my list_fragment.xml" android_id="@+id/textView2" android_layout_gravity="center_horizontal" /> </LinearLayout> 

As well as a UI component, you need to have a class associated with your fragment. To create a new class, open your projects app/Java folder, right-click its package name and select New, followed by Java Class.

Give your new class a name (Im going to use ListFragment), then open your new class file and make the following changes:

 import android.os.Bundle; //If you want your app to be compatible with devices running Android 1.6 and earlier, //you need to import the fragment class from the v4 support library// import android.support.v4.app.Fragment; import android.view.LayoutInflater; import android.view.View; import android.view.ViewGroup; //Since Im targeting devices running Android 1.6 and higher, //Im going to extend FragmentActivity, rather than the usual Activity class// public class ListFragment extends FragmentActivity { @Override //onCreateView() must return a View, which is the root of your fragments layout// public View onCreateView(LayoutInflater inflater, ViewGroup container, //If the fragment is being resumed, savedInstanceState will pass data //about the previous instance of the fragment// Bundle savedInstanceState) { //Inflate the fragments layout resource file// return inflater.inflate(R.layout.list_fragment, container, false); } } 

The final step is adding this fragment to your Activity. As already mentioned, there are two ways of doing this, but in this article Im only going to look at adding the fragment declaratively by embedding it in the host Activitys layout resource file.

To add a fragment to an Activity, simply open that Activitys corresponding layout resource file and declare the fragment you want to use, in exactly the same way youd declare a View. So you have no problems distinguishing between the portion of the finished UI thats contributed by the activity_main.xml file, and the portion thats contributed by the fragment, Im going to set activity_main to display an image:

 <?xml version="1.0" encoding="utf-8"?> <RelativeLayout   android_layout_width="match_parent" android_layout_height="match_parent" android_background="@drawable/background" tools_context="com.fragmentsexample.jessicathornsby.myapplication.MainActivity"> //Add your fragment// <fragment android_name="com.fragmentsexample.jessicathornsby.myapplication.ListFragment" android_id="@+id/list_fragment" android_layout_width="match_parent" android_layout_height="wrap_content" /> </RelativeLayoutLayout> 

Wrap-up

And thats it! The full source code for the demo app can be found on GitHub. How have you used fragments in your own Android app projects? Let us know in the comments.

Available link for download

Building better mobile apps for work

Last year, we introduced Android for Work, a program designed to pair the strength of the Android platform with support from the rich ecosystem of OEMs (device manufacturers like Samsung), EMMs (Enterprise Mobility Managers) and carriers with the goal of transforming the workplace. This means that developers get the support they need to develop apps that configure to meet business needs without customization.

With Android for Work, developers have been able to build apps for business and make them available via Google Play for Work to all types of industries. No matter the place or use case, Android for Work has helped lead businesses to foster employee productivity and creativity through increased mobility.

Today we are announcing the Android for Work DevHub, a place for developers to keep up with Android in the workplace and engage fellow business app developers in an open forum. Android for Work DevHub members will receive access to Google Play for Work and Android for Work product betas and developer events and will have the opportunity to learn from Google experts on topics like how to:

• leverage tools and resources provided by the AppConfig Community, which established a standard that provides Android developers a simple way set up app configurations,
• improve app security by integrating with Android for Work APIs,
• get an app featured on Google Play for Work,
• and more…

Among the early members of the Android for Work DevHub is Keeper, a mobile-first company committed to securing corporate credentials and sensitive information. Darren Guccione, Keeper’s CEO and co-founder, said: “Having our team be able to talk with Google experts as a part of the Android for Work DevHub has been very helpful in optimizing Keeper, as an essential product, for the workplace.” In addition to Keeper, select developers across an array of industries are already represented in the Android for Work DevHub, and—starting today—any business developer can apply to become a member, too.

To learn more about Android for Work, join us at Google I/O Thursday, May 19th at 2pm on Stage 10 Cassiopeia. I’ll be joined live on stage with James Kelly, product manager in Android for Work and Rich Hyndman, and Android developer advocate, to walk through the latest developments in Android for Work that will help you make awesome apps for businesses and to meet the Android for Work team in-person at our shop to see the Android for Work retail experience.

Available link for download

Building for Billions

‘TOP-UP WARNING.’ ‘NO CONNECTION.’ ‘INSUFFICIENT BANDWIDTH TO PLAY THIS RESOURCE.’

These are common warnings for many smartphone users around the world.

To build products that work for billions of users, developers must address key challenges: limited or intermittent connectivity, device compatibility, varying screen sizes, high data costs, short-lived batteries. We first presented developers.google.com/billions and related Android and Web resources at Google I/O last month, and today you can watch the video presentations about Android or the Web.

These best practices can help developers reach billions by delivering exceptional performance across a range of connections, data plans, and devices. g.co/dev/billions will help you:

Seamlessly transition between slow, intermediate, and offline environments

Your users move from place to place, from speedy wireless to patchy or expensive data. Manage these transitions by storing data, queueing requests, optimizing image handling, and performing core functions entirely offline.

Provide the right content for the right context

Keep context in mind - how and where do your users consume your content? Selecting text and media that works well across different viewport sizes, keeping text short (for scrolling on the go), providing a simple UI that doesn’t distract from content, and removing redundant content can all increase perception of your app’s quality while giving real performance gains like reduced data transfer. Once these practices are in place, localization options can grow audience reach and increase engagement.

Optimize for mobile hardware

Ensure your app or Web content is served and runs well for your widest possible addressable market, covering all actively used OS versions, while still following best practices, by testing on virtual or actual devices in target markets. Native Android apps should set minimum and target SDKs. Also, remember low cost phones have smaller amounts of RAM; apps should therefore adjust usage accordingly and minimize background running. For in-depth information on minimizing APK size, check out this series of Medium posts. On the Web, optimize JavaScript CPU usage, avoid raster image rendering, and minimize resource requests. Find out more here.

Reduce battery consumption

Low cost phones usually have shorter battery life. Users are sensitive to battery consumption levels and excessive consumption can lead to a high uninstall rate or avoidance of your site. Benchmark your battery usage against sessions on other pages or apps, or using tools such as Battery Historian, and avoid long-running processes which drain batteries.

Conserve data usage

Whatever you’re building, conserve data usage in three simple steps: understand loading requirements, reduce the amount of data required for interaction, and streamline navigation so users get what they want quickly. Conserving data on behalf of your users (and with native apps, offering configurable network usage) helps retain data-sensitive users -- especially those on prepaid plans or contracts with limited data -- as even “unlimited” plans can become expensive when roaming or if unexpected fees are applied.

Have another insight, or a success launching in low-connectivity conditions or on low-cost devices? Let us know on our G+ post.

Available link for download