Google not only offers the Chromecast, but also offers Android TV as a way to get content “into the living room”. Android TV devices — whether they be set-top boxes or are integrated into televisions directly — run Android apps directly, unlike Chromecast. Android TV, therefore, is a competitor to devices like Amazon’s Fire TV.
Understanding this chapter requires that you have read the core chapters of this book. Having read the chapter on “ten-foot” user experiences is also a good idea.
You can be forgiven for any confusion over the names.
Google TV was Google’s initial attempt to get content onto televisions. Debuting in 2011, Google TV has some of the same characteristics as does Android TV:
However, Google TV did not prove all that popular.
In 2014, Google announced that they were no longer supporting app development for Google TV, much to the consternation of the ~17 people still using Google TV devices.
That being said, designing an app for Android TV resembles designing an app for Google TV or for any other “ten-foot” user experience. Hence, design guidance that you may run across for Google TV may have some tips that are still relevant for Android TV and other TV-centric Android environments.
Android TV debuted in 2014. However, as of the end of 2014, there were a total of two Android TV device models… both available from Google. While other manufacturers had announced plans regarding Android TV, none were available at the time of this writing.
When Google TV was announced, there was a similar lack of hardware. To help ensure that there were TV-capable apps at the time of a wider Google TV rollout, Google offered free developer devices to various firms and solo developers.
Google did the same thing with Android TV, where they offered a free ADT-1 device to qualified registrants. While deliveries of the ADT-1 were spread out over a few months, they generally arrived significantly in advance of production Android TV hardware.
Figure 1099: ADT-1 Developer Android TV Device
The first production-grade Android TV device is Google’s own Nexus Player. As with the ADT-1, the Nexus Player has an HDMI port for connecting to a TV (or projector, monitor, etc.). It also has its own remote control and power adapter.
Figure 1100: Nexus Player Android TV Device
Both the ADT-1 and the Nexus Player are presently running Android 5.0.
Android has built into the SDK a fair bit of device flexibility. Most of this comes in the form of configurations (things that affect resources) and features (other stuff). If your application can handle a range of configurations and features, or can advertise that they need certain configurations or features, they can handle Android TV or arrange to not be available for Android TV on the Play Store.
Android TV devices are always categorized as xlarge
screen size.
Densities, however, are a bit more complicated.
Android TV is for use with HDTV, whether Android TV is integrated into
the television or it comes as an external set-top box. There are two
predominant HDTV resolutions, known as 720p (1280x720) and 1080p
(1920x1080). A 1080p television will be categorized as an xhdpi
density device. A 720p television will be categorized as a tvdpi
device. tvdpi
is for devices around 213dpi, in between mdpi
and
hdpi
. In practice, you might elect to skip tvdpi
for your
drawable resources, allowing Android to resample your mdpi
, hdpi
,
or xhdpi
drawables as needed.
Android TV will not normally be navigated using a touchscreen. Instead, the normal form of input will be a D-pad remote. Developers will need to ensure that their apps are navigable this way.
Android TV has no sensors, no camera, no microphone, and no telephony features. As such, any application requiring such features will not run on Android TV and will not even show up in the Play Store for such devices.
Bear in mind that some of these will be driven by permissions. If you
ask for the SEND_SMS
permission, Android will assume you need
android.hardware.telephony unless you specifically state otherwise,
via a <uses-feature>
element for android.hardware.telephony
with
android:required="false"
.
Beyond the features and configurations, there are other things about Android TV that will depart from what you might expect for an Android environment, due to the nature of the TV set-top box platform and the Android implementation upon it.
Since Android TV typically uses a television for its primary output, overscan can be an issue. Addressing overscan is covered as part of the chapter on the “10 foot UI”.
While Android TV devices will generally be connected to the Internet, it may not be via WiFi. Since Android TV devices generally are not portable, some will have Ethernet jacks, and hence some users will elect to wire in their Android TV as opposed to using WiFi.
The upshot is that you should not assume that WifiManager
will
necessarily give you useful results. Also, ConnectivityManager
should report wired Ethernet as TYPE_ETHERNET
, added in API Level
13, when you call methods like getActiveNetworkInfo()
.
Generally speaking, Android TV devices will tend not to move, earthquakes and large dogs notwithstanding.
As such, Android TV devices do not have GPS receivers. Rather, location is determined in an approximate fashion via address-based lookups, using a postal code. Hence, asking Android for a GPS fix on a Android TV device will be ineffective.
However, since users of Android TV devices tend not to be moving much at the time, it is a bit more likely than normal that they will want information about some location other than where they are. If your app is exclusively tied to providing information about their current location, you may wish to consider how you could extend your app to help users get information about other places that they may be interested in.
Android TV devices are usually manipulated by remote controls. Some of these remotes will have lots of buttons, such as media-specific buttons for play, pause, etc.
The KeyEvent
class has had support for some media buttons since API
Level 3, mostly for use with wired headsets. API Level 11 added a
bunch more media buttons. Your Android TV application may wish to
respond to these, via onKeyDown()
in a View
or Activity
.
In particular, an Android TV application should not be using on-screen controls for play, pause, etc., as they take up screen space that probably could be put to better use. Rather, use layouts that offer such controls for touchscreen devices (e.g., phones and tablets) but rely on the media buttons for non-touchscreen devices.
Android TV emulator images are available in the SDK Manager for Android 5.0 and above:
Figure 1101: Android TV Emulator Images in SDK Manager
Your AVD Manager can then help you set up TV emulator images, for rather large theoretical screen sizes:
Figure 1102: Android TV Hardware Profiles in AVD Manager
The rest of the emulator setup is the same as you would have for phone or tablet emulators.
The emulator even has “leanback” UI characteristics, rather than a standard Android emulator home screen:
Figure 1103: Android TV 1080p Emulator, As Initially Launched
The ADT-1 and Nexus Player have micro-USB ports for debugging purposes. This, though, requires that your player and your development machine be within USB cable reach of one another. The author of this book uses a pico projector to be able to work with TV-native devices (Android TV, Fire TV, etc.) or external displays (HDMI, MHL, etc.).
To enable an Android TV for debugging, you will need to enable developer options, much like you do for a mobile device (click on the build number 7 times in the Setting’s About screen). Then, in the “Developer Options” screen, you can go into Debugging and elect to enable “USB debugging”.
Your app probably falls in one of three buckets: you want it on Android TV (along with other devices), it only supports Android TV, or it will not work on Android TV. Whichever of those buckets best fits your device will determine the manifest settings you will want to ensure that the Play Store (and perhaps other third-party markets in the future) will honor your request.
The first criterion for getting your app visible to Android TV devices
on the Play Store is to add a <uses-feature>
element to your
manifest, indicating that you do not require the
android.hardware.touchscreen
feature:
<uses-feature android:name="android.hardware.touchscreen" android:required="false"/>
By default, Android assumes that you need a touchscreen, and so without this clarification in your manifest, you will not appear in the Play Store.
Also, add similar <uses-feature>
elements for any hardware that you
might like to use where available but do not absolutely need,
particularly hardware that Android TV may lack. The
documentation
outlines the features that Android TV devices will likely lack.
You need to have an activity that has an <intent-filter>
for
ACTION_MAIN
and CATEGORY_LEANBACK_LAUNCHER
. This will be your
launcher activity on Android TV devices, instead of your
ACTION_MAIN
/CATEGORY_HOME
activity. Of course, you are welcome to
have one activity serving as the launcher for both types of devices,
if you can come up with one with a solid presentation for both mobile
devices and TVs.
In addition, do not have any activities with android:screenOrientation
set to
portrait
, as Android TV devices always display in landscape
If your app only supports Android TV, in addition to the above
requirements, you should also add one more <uses-feature>
element to
your manifest:
<uses-feature android:name="android.hardware.type.television" android:required="true"/>
This will filter you out of the Market for all non-TV environments.
If your app specifically is untested on Android TV, you need to have something in the manifest that will keep you off Android TV devices’ views of the Play Store. The easiest is to say that you need a touchscreen:
<uses-feature android:name="android.hardware.touchscreen" android:required="true"/>
Note that true
is the default setting for this particular feature, though
putting it in your manifest to remind you that you do require a touchscreen
is a good idea.