Video
-DevBytes: Design for Large Displays - Part 1
-- Smart TVs powered by Android bring your favorite Android apps to the best screen in your house. - Thousands of apps in the Google Play Store are already optimized for TVs. This class shows how - you can optimize your Android app for TVs, including how to build a layout that - works great when the user is ten feet away and navigating with a remote control. -
- -Lessons
- --
-
- Optimizing Layouts for TV -
- Shows you how to optimize app layouts for TV screens, which have some unique characteristics such as:
-
-
-
- permanent "landscape" mode -
- high-resolution displays -
- "10 foot UI" environment. -
-
- - Optimizing Navigation for TV -
- Shows you how to design navigation for TVs, including:
-
-
-
- handling D-pad navigation -
- providing navigational feedback -
- providing easily-accessible controls on the screen. -
-
- - Handling features not supported on TV -
- Lists the hardware features that are usually not available on TVs. This lesson also shows you how to - provide alternatives for missing features or check for missing features and disable code at run time. -
These classes teach you how to build apps for TV devices.
\ No newline at end of file diff --git a/docs/html/training/tv/optimizing-layouts-tv.jd b/docs/html/training/tv/optimizing-layouts-tv.jd deleted file mode 100644 index a6db05212fd1b..0000000000000 --- a/docs/html/training/tv/optimizing-layouts-tv.jd +++ /dev/null @@ -1,246 +0,0 @@ -page.title=Optimizing Layouts for TV -parent.title=Designing for TV -parent.link=index.html - -trainingnavtop=true -next.title=Optimizing Navigation for TV -next.link=optimizing-navigation-tv.html - -@jd:body - -This lesson teaches you to
--
-
- Design Landscape Layouts -
- Make Text and Controls Easy to See -
- Design for High-Density Large Screens -
- Design to Handle Large Bitmaps -
You should also read
- - --When your application is running on a television set, you should assume that the user is sitting about -ten feet away from the screen. This user environment is referred to as the -10-foot UI. To provide your -users with a usable and enjoyable experience, you should style and lay out your UI accordingly.. -
--This lesson shows you how to optimize layouts for TV by: -
--
-
- Providing appropriate layout resources for landscape mode. -
- Ensuring that text and controls are large enough to be visible from a distance. -
- Providing high resolution bitmaps and icons for HD TV screens. -
Design Landscape Layouts
- --TV screens are always in landscape orientation. Follow these tips to build landscape layouts optimized for TV screens: -
--
-
- Put on-screen navigational controls on the left or right side of the screen and save the - vertical space for content. -
- Create UIs that are divided into sections, by using Fragments - and use view groups like {@link android.widget.GridView} instead - of {@link android.widget.ListView} to make better use of the - horizontal screen space. -
- Use view groups such as {@link android.widget.RelativeLayout} - or {@link android.widget.LinearLayout} to arrange views. - This allows the Android system to adjust the position of the views to the size, alignment, - aspect ratio, and pixel density of the TV screen. -
- Add sufficient margins between layout controls to avoid a cluttered UI. -
-For example, the following layout is optimized for TV: -
- -
-
--In this layout, the controls are on the lefthand side. The UI is displayed within a -{@link android.widget.GridView}, which is well-suited to landscape orientation. -In this layout both GridView and Fragment have the width and height set -dynamically, so they can adjust to the screen resolution. Controls are added to the left side Fragment programatically at runtime. -The layout file for this UI is {@code res/layout-land-large/photogrid_tv.xml}. -(This layout file is placed in {@code layout-land-large} because TVs have large screens with landscape orientation. For details refer to -Supporting Multiple Screens.)
- -res/layout-land-large/photogrid_tv.xml --<RelativeLayout - android:layout_width="fill_parent" - android:layout_height="fill_parent" > - - <fragment - android:id="@+id/leftsidecontrols" - android:layout_width="0dip" - android:layout_marginLeft="5dip" - android:layout_height="match_parent" /> - - <GridView - android:id="@+id/gridview" - android:layout_width="wrap_content" - android:layout_height="wrap_content" /> - -</RelativeLayout> -- -
-To set up action bar items on the left side of the screen, you can also include the -Left navigation bar library in your application to set up action items on the left side -of the screen, instead of creating a custom Fragment to add controls: -
- --LeftNavBar bar = (LeftNavBarService.instance()).getLeftNavBar(this); -- -
-When you have an activity in which the content scrolls vertically, always use a left navigation bar; -otherwise, your users have to scroll to the top of the content to switch between the content view and -the ActionBar. Look at the - -Left navigation bar sample app to see how to simple it is to include the left navigation bar in your app. -
- -Make Text and Controls Easy to See
--The text and controls in a TV application's UI should be easily visible and navigable from a distance. -Follow these tips to make them easier to see from a distance : -
- --
-
- Break text into small chunks that users can quickly scan. -
- Use light text on a dark background. This style is easier to read on a TV. -
- Avoid lightweight fonts or fonts that have both very narrow and very broad strokes. Use simple sans-serif - fonts and use anti-aliasing to increase readability. -
- Use Android's standard font sizes:
-
- <TextView - android:id="@+id/atext" - android:layout_width="wrap_content" - android:layout_height="wrap_content" - android:gravity="center_vertical" - android:singleLine="true" - android:textAppearance="?android:attr/textAppearanceMedium"/> -
- - Ensure that all your view widgets are large enough to be clearly visible to someone sitting 10 feet away - from the screen (this distance is greater for very large screens). The best way to do this is to use - layout-relative sizing rather than absolute sizing, and density-independent pixel units instead of absolute - pixel units. For example, to set the width of a widget, use wrap_content instead of a pixel measurement, - and to set the margin for a widget, use dip instead of px values. - -
- -
- -Design for High-Density Large Screens
- --The common HDTV display resolutions are 720p, 1080i, and 1080p. Design your UI for 1080p, and then -allow the Android system to downscale your UI to 720p if necessary. In general, downscaling (removing pixels) -does not degrade the UI (Notice that the converse is not true; you should avoid upscaling because it degrades -UI quality). -
- --To get the best scaling results for images, provide them as -9-patch image elements if possible. -If you provide low quality or small images in your layouts, they will appear pixelated, fuzzy, or grainy. This -is not a good experience for the user. Instead, use high-quality images. -
- --For more information on optimizing apps for large screens see -Designing for multiple screens. -
- -Design to Handle Large Bitmaps
- --The Android system has a limited amount of memory, so downloading and storing high-resolution images can often -cause out-of-memory errors in your app. To avoid this, follow these tips: -
- --
-
- Load images only when they're displayed on the screen. For example, when displaying multiple images in - a {@link android.widget.GridView} or - {@link android.widget.Gallery}, only load an image when - {@link android.widget.Adapter#getView(int, View, ViewGroup) getView()} - is called on the View's {@link android.widget.Adapter}. - -
- Call {@link android.graphics.Bitmap#recycle()} on - {@link android.graphics.Bitmap} views that are no longer needed. - -
- Use {@link java.lang.ref.WeakReference} for storing references - to {@link android.graphics.Bitmap} objects in an in-memory - {@link java.util.Collection}. -
- If you fetch images from the network, use {@link android.os.AsyncTask} - to fetch them and store them on the SD card for faster access. - Never do network transactions on the application's UI thread. - -
- Scale down really large images to a more appropriate size as you download them; otherwise, downloading the image
- itself may cause an "Out of Memory" exception. Here is sample code that scales down images while downloading:
-
-
- // Get the source image's dimensions - BitmapFactory.Options options = new BitmapFactory.Options(); - // This does not download the actual image, just downloads headers. - options.inJustDecodeBounds = true; - BitmapFactory.decodeFile(IMAGE_FILE_URL, options); - // The actual width of the image. - int srcWidth = options.outWidth; - // The actual height of the image. - int srcHeight = options.outHeight; - - // Only scale if the source is bigger than the width of the destination view. - if(desiredWidth > srcWidth) - desiredWidth = srcWidth; - - // Calculate the correct inSampleSize/scale value. This helps reduce memory use. It should be a power of 2. - int inSampleSize = 1; - while(srcWidth / 2 > desiredWidth){ - srcWidth /= 2; - srcHeight /= 2; - inSampleSize *= 2; - } - - float desiredScale = (float) desiredWidth / srcWidth; - - // Decode with inSampleSize - options.inJustDecodeBounds = false; - options.inDither = false; - options.inSampleSize = inSampleSize; - options.inScaled = false; - // Ensures the image stays as a 32-bit ARGB_8888 image. - // This preserves image quality. - options.inPreferredConfig = Bitmap.Config.ARGB_8888; - - Bitmap sampledSrcBitmap = BitmapFactory.decodeFile(IMAGE_FILE_URL, options); - - // Resize - Matrix matrix = new Matrix(); - matrix.postScale(desiredScale, desiredScale); - Bitmap scaledBitmap = Bitmap.createBitmap(sampledSrcBitmap, 0, 0, - sampledSrcBitmap.getWidth(), sampledSrcBitmap.getHeight(), matrix, true); - sampledSrcBitmap = null; - - // Save - FileOutputStream out = new FileOutputStream(LOCAL_PATH_TO_STORE_IMAGE); - scaledBitmap.compress(Bitmap.CompressFormat.JPEG, 100, out); - scaledBitmap = null; --
This lesson teaches you to
--
-
- Handle D-pad Navigation -
- Provide Clear Visual Indication for Focus and Selection -
- Design for Easy Navigation -
You should also read
- - --An important aspect of the user experience when operating a TV is the direct human interface: a remote control. -As you optimize your Android application for TVs, you should pay special attention to how the user actually navigates -around your application when using a remote control instead of a touchscreen. -
--This lesson shows you how to optimize navigation for TV by: -
- --
-
- Ensuring all layout controls are D-pad navigable. -
- Providing highly obvious feedback for UI navigation. -
- Placing layout controls for easy access. -
Handle D-pad Navigation
- --On a TV, users navigate with controls on a TV remote, using either a D-pad or arrow keys. -This limits movement to up, down, left, and right. -To build a great TV-optimized app, you must provide a navigation scheme in which the user can -quickly learn how to navigate your app using the remote. -
- --When you design navigation for D-pad, follow these guidelines: -
- --
-
- Ensure that the D-pad can navigate to all the visible controls on the screen. -
- For scrolling lists with focus, D-pad up/down keys scroll the list and Enter key selects an item in the list. Ensure that users can - select an element in the list and that the list still scrolls when an element is selected. -
- Ensure that movement between controls is straightforward and predictable. -
-Android usually handles navigation order between layout elements automatically, so you don't need to do anything extra. If the screen layout -makes navigation difficult, or if you want users to move through the layout in a specific way, you can set up explicit navigation for your -controls. -For example, for an {@code android.widget.EditText}, to define the next control to receive focus, use: -
-<EditText android:id="@+id/LastNameField" android:nextFocusDown="@+id/FirstNameField"\> --The following table lists all of the available navigation attributes: - - -
| Attribute | -Function | -
|---|---|
| {@link android.R.attr#nextFocusDown} | -Defines the next view to receive focus when the user navigates down. | -
| {@link android.R.attr#nextFocusLeft} | -Defines the next view to receive focus when the user navigates left. | -
| {@link android.R.attr#nextFocusRight} | -Defines the next view to receive focus when the user navigates right. | -
| {@link android.R.attr#nextFocusUp} | -Defines the next view to receive focus when the user navigates up. | -
-To use one of these explicit navigation attributes, set the value to the ID (android:id value) of another widget in the layout. You should set -up the navigation order as a loop, so that the last control directs focus back to the first one. -
- --Note: You should only use these attributes to modify the navigation order if the default order that the system applies does not work well. -
- -Provide Clear Visual Indication for Focus and Selection
- --Use appropriate color highlights for all navigable and selectable elements in the UI. This makes it easy for users to know whether the control -is currently focused or selected when they navigate with a D-pad. Also, use uniform highlight scheme across your application. -
- --Android provides Drawable State List Resources to implement highlights -for selected and focused controls. For example: -
- -res/drawable/button.xml: --<?xml version="1.0" encoding="utf-8"?> -<selector xmlns:android="http://schemas.android.com/apk/res/android"> - <item android:state_pressed="true" - android:drawable="@drawable/button_pressed" /> <!-- pressed --> - <item android:state_focused="true" - android:drawable="@drawable/button_focused" /> <!-- focused --> - <item android:state_hovered="true" - android:drawable="@drawable/button_focused" /> <!-- hovered --> - <item android:drawable="@drawable/button_normal" /> <!-- default --> -</selector> -- -
-This layout XML applies the above state list drawable to a {@link android.widget.Button}: -
--<Button - android:layout_height="wrap_content" - android:layout_width="wrap_content" - android:background="@drawable/button" /> -- -
-Provide sufficient padding within the focusable and selectable controls so that the highlights around them are clearly visible. -
- -Design for Easy Navigation
- --Users should be able to navigate to any UI control with a couple of D-pad clicks. Navigation should be easy and intuitive to -understand. For any non-intuitive actions, provide users with written help, using a dialog triggered by a help button or action bar icon. -
- --Predict the next screen that the user will want to navigate to and provide one click navigation to it. If the current screen UI is very sparse, -consider making it a multi pane screen. Use fragments for making multi-pane screens. For example, consider the multi-pane UI below with continent names -on the left and list of cool places in each continent on the right. -
- -
-
-
-The above UI consists of three Fragments - left_side_action_controls, continents and
-places - as shown in its layout
-xml file below. Such multi-pane UIs make D-pad navigation easier and make good use of the horizontal screen space for
-TVs.
-
-<LinearLayout - android:layout_width="match_parent" - android:layout_height="match_parent" - android:orientation="horizontal" - > - <fragment - android:id="@+id/left_side_action_controls" - android:layout_width="0px" - android:layout_height="match_parent" - android:layout_marginLeft="10dip" - android:layout_weight="0.2"/> - <fragment - android:id="@+id/continents" - android:layout_width="0px" - android:layout_height="match_parent" - android:layout_marginLeft="10dip" - android:layout_weight="0.2"/> - - <fragment - android:id="@+id/places" - android:layout_width="0px" - android:layout_height="match_parent" - android:layout_marginLeft="10dip" - android:layout_weight="0.6"/> - -</LinearLayout> -- -
-Also, notice in the UI layout above action controls are on the left hand side of a vertically scrolling list to make -them easily accessible using D-pad. -In general, for layouts with horizontally scrolling components, place action controls on left or right hand side and -vice versa for vertically scrolling components. -
- diff --git a/docs/html/training/tv/start/hardware.jd b/docs/html/training/tv/start/hardware.jd new file mode 100644 index 0000000000000..33d396b7a8e82 --- /dev/null +++ b/docs/html/training/tv/start/hardware.jd @@ -0,0 +1,361 @@ +page.title=Handling TV Hardware +page.tags="unsupported" +trainingnavtop=true + +@jd:body + +This lesson teaches you how to
+ ++ TV hardware is substantially different from other Android devices. TVs do not + include some of the hardware features found on other Android devices, such as touch screens, + cameras, and GPS receivers. TVs are also completely dependent on secondary hardware devices. + In order for users to interact with TV apps, they must use a remote control or game pad. When + you build an app for TV, you must carefully consider the hardware limitations and requirements of + operating on TV hardware. +
+ ++ This lesson discusses how to check if your app is running on a TV, how to handle unsupported + hardware features, and discusses the requirements for handling controllers for TV devices. +
+ + +Check for a TV Device
+ ++ If you are building an app that operates both on TV devices and other devices, you may need to + check what kind of device your app is running on and adjust the operation of your app. For + instance, if you have an app that can be started through an {@link android.content.Intent}, your + application should check the device properties to determine if it should start a TV-oriented + activity or a phone activity. +
+ ++ The recommended way to determine if your app is running on a TV device is to use the {@link + android.app.UiModeManager#getCurrentModeType UiModeManager.getCurrentModeType()} method to check + if the device is running in television mode. The following example code shows you how to check if + your app is running on a TV device: +
+ +
+public static final String TAG = "DeviceTypeRuntimeCheck";
+
+UiModeManager uiModeManager = (UiModeManager) getSystemService(UI_MODE_SERVICE);
+if (uiModeManager.getCurrentModeType() == Configuration.UI_MODE_TYPE_TELEVISION) {
+ Log.d(TAG, "Running on a TV Device")
+} else {
+ Log.d(TAG, "Running on a non-TV Device")
+}
+
+
+
+Handle Unsupported Hardware Features
+ ++ Depending on the design and functionality of your app, you may be able to work around certain + hardware features being unavailable. This section discusses what hardware features are typically + not available for TV, how to detect missing hardware features, and suggests alternatives to + using these features. +
+ + +Unsupported TV hardware features
+ ++ TVs have a different purpose from other devices, and so they do not have hardware features that + other Android-powered devices often have. For this reason, the Android system does not support + the following features for a TV device: +
+ +| Hardware | +Android feature descriptor | +
|---|---|
| Touchscreen | +android.hardware.touchscreen | +
| Telephony | +android.hardware.telephony | +
| Camera | +android.hardware.camera | +
| Near Field Communications (NFC) | +android.hardware.nfc | +
| GPS | +android.hardware.location.gps | +
| Microphone | +android.hardware.microphone | +
Declaring hardware requirements for TV
+ ++ Android apps can declare hardware feature requirements in the app manifest to ensure that they do + not get installed on devices that do not provide those features. If you are extending an existing + app for use on TV, closely review your app's manifest for any hardware requirement + declarations that might prevent it from being installed on a TV device. +
+ ++ If your app uses hardware features (such as a touchscreen or camera) that are not available on + TV, but can operate without the use of those features, modify your app's manifest to + indicate that these features are not required by your app. The following manifest code snippet + demonstrates how to declare that your app does not require hardware features which are unavailable + on TV devices, even though your app may use these features on non-TV devices: +
+ ++<uses-feature android:name="android.hardware.touchscreen" + android:required="false"/> +<uses-feature android:name="android.hardware.telephony" + android:required="false"/> +<uses-feature android:name="android.hardware.camera" + android:required="false"/> +<uses-feature android:name="android.hardware.nfc" + android:required="false"/> +<uses-feature android:name="android.hardware.gps" + android:required="false"/> +<uses-feature android:name="android.hardware.microphone" + android:required="false"/> ++ +
+ Caution: Declaring an unavailable hardware feature as required by setting its + value to {@code true} in your app manifest prevents your app from being installed on TV + devices or appearing in the Android TV home screen launcher. +
+ ++ Caution: Some {@code uses-permission} manifest declarations imply hardware use, which can also + prevent your app from being installed and used on TV devices. For example, requesting the + {@link android.Manifest.permission#RECORD_AUDIO} permission in your app implies the + {@code android.hardware.microphone} hardware feature requirement. In which case, you must declare + the microphone feature as not required ({@code android:required="false"}) in your app manifest. + For a list of permission requests that imply a hardware feature requirement, see + {@code uses-feature} guide. +
+ ++ Once you decide to make hardware features optional for your app, you must check for the + availability of those features at runtime and then adjust your app's behavior. The next section + discusses how to check for hardware features and suggests some approaches for changing the + behavior of your app. +
+ ++ For more information on filtering and declaring features in the manifest, see the + {@code uses-feature} + guide. +
+ + +Checking for hardware features + +
+ The Android framework can tell you if hardware features are not available on the device where + your app is running. Use the {@link android.content.pm.PackageManager#hasSystemFeature(String)} + method to check for specific features at runtime. This method takes a single string argument that + specifies the feature you want to check. +
+ +The following code example demonstrates how to detect the availability of hardware features + at runtime:
+ +
+// Check if the telephony hardware feature is available.
+if (getPackageManager().hasSystemFeature("android.hardware.telephony")) {
+ Log.d("HardwareFeatureTest", "Device can make phone calls");
+}
+
+// Check if android.hardware.touchscreen feature is available.
+if (getPackageManager().hasSystemFeature("android.hardware.touchscreen")) {
+ Log.d("HardwareFeatureTest", "Device has a touch screen.");
+}
+
+
+
+Touch screen
+ ++ Since most TVs do not have touch screens, Android does not support touch screen interaction for + TV devices. Furthermore, using a touch screen is not consistent with a viewing environment where + the user is seated 10 feet away from the display. +
+ ++ On TV devices, you should design your app to work with this interaction model by supporting + navigation using a directional pad (D-pad) on a TV remote control. For more information on + properly supporting navigation using TV-friendly controls, see + Creating TV Navigation. +
+ + +Camera
+ ++ Although a TV typically does not have a camera, you can still provide a photography-related + app on a TV. For example, if you have an app that takes, views, and edits photos, you can + disable its picture-taking functionality for TVs and still allow users to view and even edit + photos. If you decide to enable your camera-related app to work on a TV, add the + following feature declaration your app manifest: +
+ ++<uses-feature android:name="android.hardware.camera" android:required="false" /> ++ +
+ If you enable your app to run without a camera, add code to your app + that detects if the camera feature is available and makes adjustments to the operation of your + app. The following code example demonstrates how to detect the presence of a camera: +
+ +
+// Check if the camera hardware feature is available.
+if (getPackageManager().hasSystemFeature("android.hardware.camera")) {
+ Log.d("Camera test", "Camera available!");
+} else {
+ Log.d("Camera test", "No camera available. View and edit features only.");
+}
+
+
+
+GPS
+ ++ TVs are stationary, indoor devices, and do not have built-in global positioning system (GPS) + receivers. If your app uses location information, you can still allow users to search for + a location, or use a static location provider such as a zip code configured during the TV device + setup. +
+ +
+// Request a static location from the location manager
+LocationManager locationManager = (LocationManager) this.getSystemService(
+ Context.LOCATION_SERVICE);
+Location location = locationManager.getLastKnownLocation("static");
+
+// Attempt to get postal or zip code from the static location object
+Geocoder geocoder = new Geocoder(this);
+Address address = null;
+try {
+ address = geocoder.getFromLocation(location.getLatitude(),
+ location.getLongitude(), 1).get(0);
+ Log.d("Zip code", address.getPostalCode());
+
+} catch (IOException e) {
+ Log.e(TAG, "Geocoder error", e);
+}
+
+
+
+Handling Controllers
+ ++ TV devices require a secondary hardware device for interacting with apps, in the form of a basic + remote controller or game controller. This means that your app must support D-pad input. It also + means that your app may need to handle controllers going offline and input from more than one + type of controller. +
+ + +D-pad minimum controls
+ ++ The default controller for a TV device is a D-pad. In general, your app should be operable from a + remote controller that only has up, down, left, right, select, Back, and Home buttons. If your app + is a game that typically requires a game controller with additional controls, your app should + attempt to allow gameplay with these D-pad controls. In this case, your app should also warn the + user that + a controller is required and allow them to exit your game gracefully using the D-pad controller. + For more information about handling navigation with D-pad controller for TV devices, see + Creating TV Navigation. +
+ + +Handle controller disconnects
+ ++ Controllers for TV are frequently Bluetooth devices which may attempt to save power by periodically + going into sleep mode and disconnecting from the TV device. This means that an app might be + interrupted or restarted if it is not configured to handle these reconnect events. These events + can happen in any of the following circumstances: +
+ +-
+
- While watching a video which is several minutes long, a D-Pad or game controller goes into + sleep mode, disconnects from the TV device and then reconnects later on. + +
- During gameplay, a new player joins the game using a game controller that is not currently + connected. + +
- During gameplay, a player leaves the game and disconnects a game controller. + +
+ Any TV app activity that is subject to disconnect and reconnect events must be configured to + handle reconnection events in the app manifest. The following code sample demonstrates how to + enable an activity to handle configuration changes, including a keyboard or navigation device + connecting, disconnecting, or reconnecting: +
+ ++<activity + android:name="com.example.android.TvActivity" + android:label="@string/app_name" + android:configChanges="keyboard|keyboardHidden|navigation" + android:theme="@style/Theme.Leanback"> + + <intent-filter> + <action android:name="android.intent.action.MAIN" /> + <category android:name="android.intent.category.LEANBACK_LAUNCHER" /> + </intent-filter> + ... +</activity> ++ +
+ This configuration change allows the app to continue running through a reconnection event, rather + than being restarted by the Android framework, which is not a good user experience. +
+ + +Handle D-pad input variations
+ ++ TV device users may have more than one type of controller that they use with their TV. For + example, a user might have both a basic D-pad controller and a game controller. The key codes + provided by a game controller when it is being used for D-pad functions may vary from the key + codes sent by a physical D-pad. +
+ ++ Your app should handle the variations of D-pad input from a game controller, so the user does not + have to physically switch controllers to operate your app. For more information on handling these + input variations, see + Handling Controller Actions. +
diff --git a/docs/html/training/tv/start/index.jd b/docs/html/training/tv/start/index.jd new file mode 100644 index 0000000000000..ceefea1ac23f7 --- /dev/null +++ b/docs/html/training/tv/start/index.jd @@ -0,0 +1,63 @@ +page.title=Building TV Apps +startpage=true + +@jd:body + +Dependencies and Prerequisites
+-
+
- Android 5.0 (API level 21) or higher +
- Android Studio 0.8 or later and Gradle 0.12 or later +
+ Android offers a rich user experience that's optimized for apps running on large screen devices, + such as high-definition televisions. Apps on TV offer new opportunities to delight your users + from the comfort of their couch. +
+ ++ TV apps use the same structure as those for phones and tablets. This approach means you can + create new TV apps based on what you already know about building apps for Android, or extend your + existing apps to also run on TV devices. However, the user interaction model for TV is + substantially different from phone and tablet devices. In order to make your app successful on TV + devices, you must design new layouts that can be easily understood from 10 feet away, and provide + navigation that works with just a directional pad and a select button. +
+ ++ This class describes how to start building apps for TV, including setting up your development + environment, basic requirements for layouts and navigation, as well as guidance on how to handle + hardware features that are not typically available on TV devices. +
+ ++ Note: You are encouraged to use Android Studio for building TV apps, because it + provides project setup, library inclusion, and packaging conveniences. This training assumes you + are using Android Studio. +
+ + +Lessons
+ +-
+
- + Getting Started with TV Apps +
- Learn how to create a new Android Studio project for TV apps or modify your existing + app project to run on TV devices. +
- + Building TV Layouts +
- Learn the minimum requirements for TV layouts and how to implement them. +
- + Creating TV Navigation +
- Learn the requirements for TV navigation and how to implement TV-compatible + navigation. +
- + Handling TV Hardware +
- Learn how to check if your app is running on TV hardware, handle unsupported hardware + features, and manage controller devices. +
This lesson teaches you how to
+-
+
- Use Layout Themes for TV +
- Build Basic TV Layouts +
- Build Useable Text and Controls +
- Manage Layout Resources for TV +
- Avoid Layout Anti-Patterns +
- Handle Large Bitmaps +
You should also read
+ ++ A TV screen is typically viewed from about 10 feet away, and while it is much larger than most + other Android device displays, this type of screen does not provide the same level of precise + detail and color as a smaller device. These factors require you to create app layouts with TV + devices in mind in order to create a useful and enjoyable user experience. +
+ ++ This lesson describes the minimum requirements and implementation details for building effective + layouts in TV apps. +
+ +Use Layout Themes for TV
+ ++ Android Themes can provide a basis for + layouts in your TV apps. You should use a theme to modify the display of your app activities that + are meant to run on a TV device. This section explains which themes you should use. +
+ +Leanback theme
+ ++ A support library for TV user interfaces called the v17 leanback library provides a + standard theme for TV activities, called {@code Theme.Leanback}. This theme establishes a + consistent visual style for TV apps. Use of this theme is recommended for most TV apps. This + theme is strongly recommended for any TV app that uses v17 leanback classes. The following code + sample shows how to apply this theme to a given activity within an app: +
+ ++<activity + android:name="com.example.android.TvActivity" + android:label="@string/app_name" + android:theme="@style/Theme.Leanback"> ++ + +
NoTitleBar theme
+ ++ The title bar is a standard user interface element for Android apps on phones and tablets, but it + is not appropriate for TV apps. If you are not using v17 leanback classes, you should apply this + theme to your TV activities to suppress the display of a title bar. The following code example + from a TV app manifest demonstrates how to apply this theme to remove the display of a title bar: +
+ ++<application> + ... + + <activity + android:name="com.example.android.TvActivity" + android:label="@string/app_name" + android:theme="@android:style/Theme.NoTitleBar"> + ... + + </activity> +</application> ++ + +
Build Basic TV Layouts
+ +Layouts for TV devices should follow some basic guidelines to ensure they are usable and + effective on large screens. Follow these tips to build landscape layouts optimized for TV screens: +
+ +-
+
- Build layouts with a landscape orientation. TV screens always display in landscape mode. +
- Put on-screen navigation controls on the left or right side of the screen and save the + vertical space for content. +
- Create UIs that are divided into sections, using Fragments, and use view groups like {@link android.widget.GridView} instead of {@link + android.widget.ListView} to make better use of the horizontal screen space. + +
- Use view groups such as {@link android.widget.RelativeLayout} or {@link + android.widget.LinearLayout} to arrange views. This approach allows the system to adjust the + position of the views to the size, alignment, aspect ratio, and pixel density of a TV screen. +
- Add sufficient margins between layout controls to avoid a cluttered UI. +
Overscan
+ +Layouts for TV have some unique requirements due to the evolution of TV standards and the + desire to always present a full screen picture to viewers. For this reason, TV devices may + clip the outside edge of an app layout in order to ensure that the entire display is filled. + This behavior is generally referred to as overscan. +
+ ++ Avoid screen elements being clipped due to overscan and by incorporating a 10% margin + on all sides of your layout. This translates into a 27dp margin on the left and right edges and + a 48dp margin on the top and bottom of your base layouts for activities. The following + example layout demonstrates how to set these margins in the root layout for a TV app: +
+ ++<?xml version="1.0" encoding="utf-8"?> +<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" + android:id="@+id/base_layout" + android:layout_width="match_parent" + android:layout_height="match_parent" + android:orientation="vertical" + android:layout_marginTop="27dp" + android:layout_marginLeft="48dp" + android:layout_marginRight="48dp" + android:layout_marginBottom="27dp" > +</LinearLayout> ++ +
+ Caution: Do not apply overscan margins to your layout if you are using the + v17 leanback classes, such as {@link android.support.v17.leanback.app.BrowseFragment} or related + widgets, as those layouts already incorporate overscan-safe margins. +
+ +Build Useable Text and Controls
+ ++ The text and controls in a TV app layout should be easily visible and navigable from a distance. + Follow these tips to make your user interface elements easier to see from a distance: +
+ +-
+
- Break text into small chunks that users can quickly scan. +
- Use light text on a dark background. This style is easier to read on a TV. +
- Avoid lightweight fonts or fonts that have both very narrow and very broad strokes. + Use simple sans-serif fonts and anti-aliasing to increase readability. +
- Use Android's standard font sizes:
+
+<TextView + android:id="@+id/atext" + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:gravity="center_vertical" + android:singleLine="true" + android:textAppearance="?android:attr/textAppearanceMedium"/> +
+
+ - Ensure that all your view widgets are large enough to be clearly visible to someone + sitting 10 feet away from the screen (this distance is greater for very large screens). The + best way to do this is to use layout-relative sizing rather than absolute sizing, and + density-independent pixel (dip) units instead of absolute pixel units. For example, to set the + width of a widget, use {@code wrap_content} instead of a pixel measurement, and to set the + margin for a widget, use dip values instead of px values. +
+ For more information about density-independent pixels and building layouts to handle larger + screen sizes, see Supporting Multiple + Screens. +
+ +Manage Layout Resources for TV
+ +The common high-definition TV display resolutions are 720p, 1080i, and 1080p. + Your TV layout should target a screen size of 1920 x 1080 pixels, and then allow the Android + system to downscale your layout elements to 720p if necessary. In general, downscaling + (removing pixels) does not degrade your layout presentation quality. However, upscaling can + cause display artifacts that degrade the quality of your layout and have a negative impact on + the user experience of your app.
+ ++ To get the best scaling results for images, provide them as + 9-patch image elements if possible. If you + provide low quality or small images in your layouts, they will appear pixelated, fuzzy, or + grainy, which is not a good experience for the user. Use high-quality images instead. +
+ ++ For more information on optimizing layouts and resources for large screens see + Designing for multiple screens. +
+ + +Avoid Layout Anti-Patterns
+ ++ There are a few approaches to building layouts that you should avoid because they do not work + well on TV devices and lead to bad user experiences. Here are some user interface approaches you + should specifically not use when developing a layout for TV. +
+ +-
+
- Re-using phone or tablet layouts - Do not reuse layouts from a phone or + tablet app without modification. Layouts built for other Android device form factors are not + well suited for TV devices and should be simplified for operation on a TV. +
- ActionBar - While this user interface convention is recommended for use + on phones and tablets, it is not appropriate for a TV interface. In particular, using an + action bar options menu (or any pull-down menu for that matter) is strongly discouraged, due + to the difficulty in navigating such a menu with a remote control. +
- ViewPager - Sliding between screens can work great on a phone or tablet, + but don't try this on a TV! +
For more information on designing layouts that are appropriate to TV, see the + TV Design guide.
+ + +Handle Large Bitmaps
+ +TV devices, like any other Android device, have a limited amount of memory. If you build your + app layout with very high-resolution images or use many high-resolution images in the operation + of your app, it can quickly run into memory limits and cause out of memory errors. + To avoid these types of problems, follow these tips:
+ +-
+
- Load images only when they are displayed on the screen. For example, when displaying multiple + images in a {@link android.widget.GridView} or {@link android.widget.Gallery}, only load an image + when {@link android.widget.Adapter#getView getView()} is called on the + view's {@link android.widget.Adapter}. + +
- Call {@link android.graphics.Bitmap#recycle()} on {@link android.graphics.Bitmap} views that + are no longer needed. + +
- Use {@link java.lang.ref.WeakReference} for storing references to {@link + android.graphics.Bitmap} objects in an in-memory {@link java.util.Collection}. + +
- If you fetch images from the network, use {@link android.os.AsyncTask} to fetch and store + them on the device for faster access. Never do network transactions on the application's main + user interface thread. + +
- Scale down large images to a more appropriate size as you download them; otherwise, + downloading the image itself may cause an out of memory exception. + +
+ For more information on getting the best performance when working with images, see + Displaying Bitmaps Efficiently. +
diff --git a/docs/html/training/tv/start/navigation.jd b/docs/html/training/tv/start/navigation.jd new file mode 100644 index 0000000000000..1c9faca238e02 --- /dev/null +++ b/docs/html/training/tv/start/navigation.jd @@ -0,0 +1,180 @@ +page.title=Creating TV Navigation +page.tags="focus","selection","d-pad" +trainingnavtop=true + +@jd:body + +This lesson teaches you how to
+ + ++ TV devices provide a limited set of navigation controls for apps. Creating an effective + navigation scheme for your TV app depends on understanding these limited controls and the limits + of users' perception while operating your app. As you build your Android app for TVs, + pay special attention to how the user actually navigates around your app when using remote + control buttons instead of a touch screen. +
+ ++ This lesson explains the minimum requirements for creating effective TV app navigation scheme and + how to apply those requirements to your app. +
+ + +Enable D-pad Navigation
+ ++ On a TV device, users navigate with controls on a remote control device, using either a + directional pad (D-pad) or arrow keys. This type of control limits movement to up, down, left, + and right. To build a great TV-optimized app, you must provide a navigation scheme where the user + can quickly learn how to navigate your app using these limited controls. +
+ ++ The Android framework handles directional navigation between layout elements automatically, so + you typically do not need to do anything extra for your app. However, you should thoroughly test + navigation with a D-pad controller to discover any navigation problems. Follow these guidelines to + test that your app's navigation system works well with a D-pad on a TV device: +
+ +-
+
- Ensure that a user with a D-pad controller can navigate to all visible controls on the + screen. + +
- For scrolling lists with focus, make sure that the D-pad up and down keys scroll the list, + and the Enter key selects an item in the list. Verify that users can select an element in the + list and that the list still scrolls when an element is selected. + +
- Ensure that switching between controls between controls is straightforward and predictable. + +
Modifying directional navigation
+ ++ The Android framework automatically applies a directional navigation scheme based on the + relative position of focusable elements in your layouts. You should test the generated + navigation scheme in your app using a D-pad controller. After testing, if you decide you want + users to move through your layouts in a specific way, you can set up explicit directional + navigation for your controls. +
+ ++ Note: You should only use these attributes to modify the navigation order if the + default order that the system applies does not work well. +
+ ++ The following code sample shows how to define the next control to receive focus for a {@link + android.widget.TextView} layout object: +
+ ++<TextView android:id="@+id/Category1" + android:nextFocusDown="@+id/Category2"\> ++ +
+ The following table lists all of the available navigation attributes for Android user interface + widgets: +
+ +| Attribute | +Function | +
|---|---|
| {@link android.R.attr#nextFocusDown} | +Defines the next view to receive focus when the user navigates down. | +
| {@link android.R.attr#nextFocusLeft} | +Defines the next view to receive focus when the user navigates left. | +
| {@link android.R.attr#nextFocusRight} | +Defines the next view to receive focus when the user navigates right. | +
| {@link android.R.attr#nextFocusUp} | +Defines the next view to receive focus when the user navigates up. | +
+ To use one of these explicit navigation attributes, set the value to the ID ({@code android:id} + value) of another widget in the layout. You should set up the navigation order as a loop, so that + the last control directs focus back to the first one. +
+ + + +Provide Clear Focus and Selection
+ ++ The success of an app's navigation scheme on TV devices is depends on how easy it is for + a user to determine what user interface element is in focus on screen. If you do not provide + clear indications of focused items (and therefore what item a user can take action on), they can + quickly become frustrated and exit your app. For the same reason, it is important to always have + an item in focus that a user can take action on immediately after your app starts, or any time + it is idle. +
+ ++ Your app layout and implementation should use color, size, animation, or a combination of these + attributes to help users easily determine what actions they can take next. Use a uniform scheme + for indicating focus across your application. +
+ ++ Android provides + Drawable State List Resources to implement highlights for focused and selected controls. The + following code example demonstrates how to enable visual behavior for a button to indicate that a + user has navigated to the control and then selected it: +
+ ++<!-- res/drawable/button.xml --> +<?xml version="1.0" encoding="utf-8"?> +<selector xmlns:android="http://schemas.android.com/apk/res/android"> + <item android:state_pressed="true" + android:drawable="@drawable/button_pressed" /> <!-- pressed --> + <item android:state_focused="true" + android:drawable="@drawable/button_focused" /> <!-- focused --> + <item android:state_hovered="true" + android:drawable="@drawable/button_focused" /> <!-- hovered --> + <item android:drawable="@drawable/button_normal" /> <!-- default --> +</selector> ++ +
+ The following layout XML sample code applies the previous state list drawable to a + {@link android.widget.Button}: +
+ ++<Button + android:layout_height="wrap_content" + android:layout_width="wrap_content" + android:background="@drawable/button" /> ++ +
+ Make sure to provide sufficient padding within the focusable and selectable controls so that the + highlights around them are clearly visible. +
+ ++ For more recommendations on designing effective selection and focus for your TV app, see + Patterns for TV. +
diff --git a/docs/html/training/tv/start/start.jd b/docs/html/training/tv/start/start.jd new file mode 100644 index 0000000000000..b50bc3325689c --- /dev/null +++ b/docs/html/training/tv/start/start.jd @@ -0,0 +1,259 @@ +page.title=Get Started with TV Apps +page.tags="leanback","recyclerview","launcher" + +trainingnavtop=true +startpage=true + +@jd:body + +This lesson teaches you how to
+ +You should also read
+ ++ TV apps use the same structure as those for phones and tablets. This similarity means you can + modify your existing apps to also run on TV devices or create new apps based on what you already + know about building apps for Android. +
+ ++ Important: There are specific requirements your app must meet in order to + qualify as an Android TV app on Google Play. For more information, see the requirements listed + in TV App Quality. +
+ ++ This lesson describes how to prepare your development environment for building TV apps, and the + minimum required changes to enable an app to run on TV devices. +
+ + +Set up a TV Project
+ ++ This section discusses how to modify an existing app to run on TV devices, or create a new one. + These are the main components you must use to create an app that runs on TV devices: +
+ +-
+
- Activity for TV (Required) - In your application manifest, + declare an activity that is intended to run on TV devices. +
- TV Support Libraries (Optional) - There are several + Support Libraries + available for TV devices that provide widgets for building user interfaces. +
Prerequisites
+ +Before you begin building apps for TV, you must:
+ +-
+
-
+ Update your SDK tools to version 24.0.0 or higher
+
+ The updated SDK tools enable you to build and test apps for TV. +
+ -
+ Update your SDK with Android 5.0 (API 21) or higher
+
+ The updated platform version provides new APIs for TV apps. +
+ -
+ Create or update your app project
+
+ In order to access new APIs for TV devices, you must create a project or modify an existing + project that targets Android 5.0 (API level 21) or higher. +
+
Declare a TV Activity
+ +An application intended to run on TV devices must declare a launcher activity for TV + in its manifest using a {@link android.content.Intent#CATEGORY_LEANBACK_LAUNCHER} intent filter. + This filter identifies your app as being enabled for TV, allowing it to be considered a TV app + in Google Play. Declaring this intent also identifies which activity + in your app to launch when a user selects its icon on the TV home screen.
+ ++ Caution: If you do not include the {@link android.content.Intent#CATEGORY_LEANBACK_LAUNCHER} intent filter in + your app, it is not visible to users running the Google Play store on TV devices. Also, if your + app does not have this filter when you load it onto a TV device using developer tools, the app + does not appear in the TV user interface. +
+ +The following code snippet shows how to include this intent filter in your manifest:
+ ++<application> + ... + <activity + android:name="com.example.android.MainActivity" + android:label="@string/app_name" > + + <intent-filter> + <action android:name="android.intent.action.MAIN" /> + <category android:name="android.intent.category.LAUNCHER" /> + </intent-filter> + </activity> + + <activity + android:name="com.example.android.TvActivity" + android:label="@string/app_name" + android:theme="@style/Theme.Leanback"> + + <intent-filter> + <action android:name="android.intent.action.MAIN" /> + <category android:name="android.intent.category.LEANBACK_LAUNCHER" /> + </intent-filter> + + </activity> +</application> ++ +
+ The second activity manifest entry in this example specifies that activity as the one to + launch on a TV device. +
+ ++ If you are modifying an existing app for use on TV, your app should not use the same + activity layout for TV that it does for phones and tablets. The user interface of your TV app (or + TV portion of your existing app) should provide a simpler interface that can be easily navigated + using a remote control from a couch. For guidelines on designing an app for TV, see the TV Design guide. For more information on the minimum + implementation requirements for interface layouts on TV, see Building TV Layouts. +
+ + +Add TV support libraries
+ ++ The Android SDK includes support libraries that are intended for use with TV apps. These + libraries provide APIs and user interface widgets for use on TV devices. The libraries are + located in the {@code <sdk>/extras/android/support/} directory. Here is a list of the + libraries and their general purpose: +
+ +-
+
- + v17 leanback library - Provides user interface widgets for TV apps, + particularly for apps that do media playback. + +
- + v7 recyclerview library - Provides classes for managing display of long + lists in a memory efficient manner. Several classes in the v17 leanback library depend on the + classes in this library. + +
- + v7 cardview library - Provides user interface widgets for displaying + information cards, such as media item pictures and descriptions. + +
+ Note: You are not required to use these support libraries for your TV app. + However, we strongly recommend using them, particularly for apps that provide a media catalog + browsing interface. +
+ ++ If you decide to use the v17 leanback library for your app, you should note that it is dependent + on the v4 support library. This + means that apps that use the leanback support library should include all of these support + libraries: +
+ +-
+
- v4 support library +
- v7 recyclerview support library +
- v17 leanback support library +
+ The v17 leanback library contains resources, which require you to take specific steps to include + it in app projects. For instructions on importing a support library with resources, see + Support Library Setup. +
+ + +Build TV Apps
+ +After you have completed the steps described above, it's time to start building apps for + the big screen! Check out these additional topics to help you build your app for TV: + +
-
+
- + Building TV Playback Apps - TVs are + built to entertain, so Android provides a set of user interface tools and widgets for building + TV apps that play videos and music, and let users browse for the content they want. + +
- + Surfacing Content on TV - With all the + content choices at users' fingertips, helping them find content they enjoy is almost as important + as providing that content. This training discusses how to surface your content on TV devices. + +
- + Games for TV - TV devices are a great + platform for games. See this topic for information on building great game experiences for TV. + +
Run TV Apps
+ ++ Running your app is an important part of the development process. The AVD Manager in the Android + SDK provides the device definitions that allow you to create virtual TV devices for running and + testing your applications. +
+ +To create an virtual TV device:
+ +-
+
- Start the AVD Manager. For more information, see the + AVD Manager help. +
- In the AVD Manager dialog, click the Device Definitions tab. +
- Select one of the Android TV device definitions and click Create AVD. +
- Select the emulator options and click OK to create the AVD.
+
+ Note: For best performance of the TV emulator device, enable the Use + Host GPU option and, where supported, use virtual device acceleration. For + more information on hardware acceleration of the emulator, see + Using the Emulator. +
+
+
To test your application on the virtual TV device:
+ +-
+
- Compile your TV application in your development environment. +
- Run the application from your development environment and choose the TV virtual device as + the target. +
+ For more information about using emulators see, + Using the Emulator. For more information on deploying apps from Android Studio to virtual + devices, see Debugging with Android + Studio. For more information about deploying apps to emulators from Eclipse with ADT, see + Building and Running from Eclipse with + ADT. +
diff --git a/docs/html/training/tv/unsupported-features-tv.jd b/docs/html/training/tv/unsupported-features-tv.jd deleted file mode 100644 index a9f090bfe1e23..0000000000000 --- a/docs/html/training/tv/unsupported-features-tv.jd +++ /dev/null @@ -1,157 +0,0 @@ -page.title=Handling Features Not Supported on TV -parent.title=Designing for TV -parent.link=index.html - -trainingnavtop=true -previous.title=Optimizing Navigation for TV -previous.link=optimizing-navigation-tv.html - -@jd:body - -This lesson teaches you to
- - --TVs are much different from other Android-powered devices: -
--
-
- They're not mobile. -
- Out of habit, people use them for watching media with little or no interaction. -
- People interact with them from a distance. -
-Because TVs have a different purpose from other devices, they usually don't have hardware features -that other Android-powered devices often have. For this reason, the Android system does not -support the following features for a TV device: -
| Hardware | -Android feature descriptor | -
|---|---|
| Camera | -android.hardware.camera | -
| GPS | -android.hardware.location.gps | -
| Microphone | -android.hardware.microphone | -
| Near Field Communications (NFC) | -android.hardware.nfc | -
| Telephony | -android.hardware.telephony | -
| Touchscreen | -android.hardware.touchscreen | -
-This lesson shows you how to work around features that are not available on TV by: -
-
-
- Providing work arounds for some non-supported features. -
- Checking for available features at runtime and conditionally activating/deactivating certain code - paths based on availability of those features. -
Work Around Features Not Supported on TV
- --Android doesn't support touchscreen interaction for TV devices, most TVs don't have touch screens, -and interacting with a TV using a touchscreen is not consistent with the 10 foot environment. For -these reasons, users interact with Android-powered TVs using a remote. In consideration of this, -ensure that every control in your app can be accessed with the D-pad. Refer back to the previous two lessons -Optimizing Layouts for TV and -Optimize Navigation for TV for -more details -on this topic. The Android system assumes that a device has a touchscreen, so if you want your application -to run on a TV, you must explicitly disable the touchscreen requirement in your manifest file: -
-<uses-feature android:name="android.hardware.touchscreen" android:required="false"/> -- - -
-Although a TV doesn't have a camera, you can still provide a photography-related application on a TV. -For example, if you have an app that takes, views and edits photos, you can disable its picture-taking -functionality for TVs and still allow users to view and even edit photos. The next section talks about how to -deactivate or activate specific functions in the application based on runtime device type detection. -
- --Because TVs are stationary, indoor devices, they don't have built-in GPS. If your application uses location -information, allow users to search for a location or use a "static" location provider to get -a location from the zip code configured during the TV setup. -
-LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE);
-Location location = locationManager.getLastKnownLocation("static");
-Geocoder geocoder = new Geocoder(this);
-Address address = null;
-
-try {
- address = geocoder.getFromLocation(location.getLatitude(), location.getLongitude(), 1).get(0);
- Log.d("Zip code", address.getPostalCode());
-
-} catch (IOException e) {
- Log.e(TAG, "Geocoder error", e);
-}
-
-
-
--TVs usually don't support microphones, but if you have an application that uses voice control, -you can create a mobile device app that takes voice input and then acts as a remote control for a TV. -
- -Check for Available Features at Runtime
- --To check if a feature is available at runtime, call -{@link android.content.pm.PackageManager#hasSystemFeature(String)}. - This method takes a single argument : a string corresponding to the -feature you want to check. For example, to check for touchscreen, use -{@link android.content.pm.PackageManager#hasSystemFeature(String)} with the argument -{@link android.content.pm.PackageManager#FEATURE_TOUCHSCREEN}. -
- --The following code snippet demonstrates how to detect device type at runtime based on supported features: - -
-// Check if android.hardware.telephony feature is available.
-if (getPackageManager().hasSystemFeature("android.hardware.telephony")) {
- Log.d("Mobile Test", "Running on phone");
-// Check if android.hardware.touchscreen feature is available.
-} else if (getPackageManager().hasSystemFeature("android.hardware.touchscreen")) {
- Log.d("Tablet Test", "Running on devices that don't support telphony but have a touchscreen.");
-} else {
- Log.d("TV Test", "Running on a TV!");
-}
-
-
-
--This is just one example of using runtime checks to deactivate app functionality that depends on features -that aren't available on TVs. -
\ No newline at end of file