Android TV development: where remote navigation breaks
There is no touchscreen on a TV — the only input is the remote, and all Android TV remote navigation rests on focus.
If the highlight gets lost when moving between rows of cards, the person stops understanding where they are: the screen looks alive, but no element is highlighted, and presses go nowhere.
On a large screen this is more noticeable than on a phone: there are more elements, the distances between them are wider, and there are fewer hints.
Interface focus on a large screen is not inherited by itself.
You have to explicitly describe where the highlight will go when pressing up, down, left, and right, what happens at the boundary of the list, and how to restore the position after data is redrawn — otherwise rows get stuck and stop scrolling.
A separate class of failures is returning the app after it has been minimized: the activity is recreated, the player loses its position, and the user ends up at the wrong minute from the one they were watching.
Compatibility adds to this: the app does not launch on a TV because of different firmware bitness, a reduced set of system modules, and old platform versions on budget models.
Support for remotes and gamepads adds another layer: some manufacturers send hold repeats, others send their own key codes, and gamepads behave differently from infrared remotes.
This breaks not in individual pieces of code but at the seams: navigation, the player, and the app lifecycle pull on each other, and fixing one breaks another. How this is closed at the level of the TV build architecture — we analyze further.
What changes after launch: responsiveness, stability, support
After the rework, the app on Android TV starts in a matter of seconds, and the interface response to a remote button press feels instantaneous: focus moves between tiles without delay, and poster loading does not block navigation.
This is the result of heavy operations being moved off the main thread and startup data being cached on the device.
Interface smoothness on a TV is maintained by a layout designed for remote control: large focus areas, row scrolling, preloading of the next screen. On weak set-top box hardware, this scheme removes stutters during fast catalog scrolling.
When the network is weak, the player switches quality adaptively, so a drop in the channel reduces picture sharpness rather than stopping playback.
Buffering is configured so that short connection interruptions remain unnoticeable, and the share of successfully started viewing sessions grows.
Updates are released without downtime: the build first goes to a limited group, then to everyone, and the previous version remains available for rollback.
Previously, a crash at startup after release would take down the app on some devices — this class of failures has been eliminated.
Support requests become fewer: failures are recorded in crash reports before the user picks up the remote and calls. We look at the share of successful launches, viewing depth, and failure frequency by device model — these are the metrics that show the effect of the rework.
TV build options: comparison of approaches
A TV is not a phone with a large screen: control is only via remote, focus moves via the D-pad, the player lives in a separate lifecycle, and bringing the app to the foreground is structured differently.
That is why the choice comes down not to design but to how much code you are ready to keep separate and how you plan to pass publication in the TV catalog.
Below are four schemes that are realistically chosen between at the start: all of them pass moderation in the TV catalog, but they behave differently as the product evolves and on weak set-top boxes.
| Option | When it fits | Limitations |
|---|---|---|
| Native TV build | Your own TV direction: proprietary player, complex screens, strict requirements for remote responsiveness | Two products are developed and tested separately, releases become out of sync |
| Unified codebase for phone and TV | A content service where logic and data are the same, only the presentation layer differs | Compromises in the interface; focus and remote handling are still written separately |
| Shell on top of a ready-made app | You need to cover TV quickly, with minimal unique interface | Player and navigation are limited by the wrapper's capabilities, delays are noticeable on weak set-top boxes |
| Storefront with external playback | Catalog and content selection are more important than the player, playback is delegated to the system | No control over playback and advertising, part of analytics is lost |
In practice, the choice is almost always hybrid: we move shared logic and data handling into one module, while navigation, focus, and the player are kept as separate implementations for TV. This preserves a unified version release cycle and does not lose remote responsiveness.
Work stages: from interface audit to build handover
The stages follow a strict sequence: first we record what exactly breaks for the viewer, then we design the interface behavior, and only after that we test it on real set-top boxes and TVs.
The order cannot be changed — the navigation scheme and focus rules determine how the player will behave, not the other way around. That is why each step ends with an artifact that becomes the input for the next.
- TV interface audit. We go through the current app or prototype using the remote: where focus is lost, how many steps it takes to start content, what happens on minimize and return. The output is a prioritized list of bottlenecks and target viewer scenarios.
- Screen navigation scheme. We build a transition map: start screen, catalog, card, player, search, settings. For each transition, we define focus rules, Back button behavior, and return to exactly the place the viewer left.
- Player and buffering setup. We select the buffer size for an unstable network, behavior during quality changes, transitions between videos, and additional loading. We configure startup separately: how long the viewer waits for the first frame and what they see during that time.
- Testing on real devices. We run the build on weak set-top boxes and TVs from previous years, not only on the emulator: long sessions, input switching, memory shortage, remotes from different manufacturers.
- Acceptance by scenarios. A checklist of navigation and playback walkthroughs, measurements of startup and switching times, and checks of behavior during a network outage. Anything that does not pass goes back to work before handover.
- Build and documentation handover. We hand over the signed build, navigation map, update release regulations, and instructions for your team so that the next version can be built without us.
Deliverables: build, screen maps, regulations
Deliverables are what remains with the customer after project handover and does not require us for day-to-day work.
We hand over not only a working app but also knowledge of how it is structured: where focus travels between interface blocks, how the player behaves during a network outage, and what to do if publication fails. Below is the full list with an explanation of why each element is needed in operation.
- Assembled package for publication — a signed release artifact ready for upload to the developer console, a separate debug build for test devices, and scripts that build both versions without manual edits.
- Screen and state map — a transition map with focus logic for remote control, including dead-end and error scenarios: empty catalog, long loading, connection loss, inability to play.
- List of tested devices — which TV and TV set-top box models passed manual testing, on which system versions and remote types, what is covered by navigation autotests, and what remains under manual acceptance.
- Build documentation — how to set up the environment from scratch, where signing keys are stored, which parameters change for different environments, and which commands release a new build.
- Update publication regulations — the release procedure with staged rollout to a share of the audience, criteria for stopping the rollout when failures increase, and a step-by-step rollback to the previous release.
- Support instructions — typical requests and what to do for each, where to look at logs, and how to switch app behavior remotely without releasing a new version.
- Error behavior rules — an agreed policy for retries, placeholder screens, and notifications so that the app does not "fall into a black screen" in front of the viewer.
Each document is written so that your engineer can use it, not only the code author: without references to chat threads and verbal agreements. Describe the task — we will come back with an estimate and plan, including the composition of such a package for your project.
Case study: navigation and player for a TV service
A movie and series service launched on Google TV with a catalog of several thousand items.
Focus was lost when returning from the player: the interface opened on the first row instead of the card the user had left, and horizontal movement across the row boundary took the highlight off-screen.
The share of successful launches stayed around 88% — some crashes occurred at stream start, and some on re-entering the app.
The second problem appeared during long viewing. After two hours of playback, the response delay to remote presses grew, and on weak set-top boxes the stream dropped and did not recover on its own. Support requests for these two scenarios accounted for a noticeable share of app-related requests.
What we changed
We rewrote the focus model: card state is saved in the navigation stack, transitions between rows are described by explicit rules, and catalog scrolling happens with preloading of the next screen.
The player was moved to the current Android media stack branch with a separate startup buffer and position recovery after a network outage; the catalog and covers are cached to disk, so a cold start does not wait for the network.
Interface response time decreased from 0.7 to 0.15 s, and the share of successful launches grew to 99.2%. During three-hour viewing, playback ran without interruptions or drops, and support requests for navigation and playback became more than halved.
How does Android TV development differ from a phone app?
A TV build is not a stretched phone interface. There are no touches here: the user moves with the remote's D-pad, and all logic is built around focus — what is highlighted now and where it will go when pressing left or down.
Losing focus after a dialog or exiting the player means a screen that the remote no longer listens to.
The physics of perception also changes. The screen is viewed from three meters, so elements are noticeably larger, the spacing between them is greater, and the edges of the picture go into the safe zones of panels.
A ten-column grid turns into a horizontal row of five or six posters: otherwise captions are unreadable, and hitting the right card becomes difficult.
The background also behaves differently. The TV goes into standby mode, the app loses focus and goes to the background, and it is expected to pause while preserving the playback position.
Returning should restore state without restarting — the user expects continuation from the same second, not a repeated loading of the catalog.
Playback relies on the hardware decoder and media session: audio must be routed correctly to an external receiver, and the picture must survive input switching. Updates come less often than on a phone, so compatibility with previous system versions is tested separately.
The product remains one: shared code, data, and backend, but two entry points and two builds with different navigation, manifests, and store rules. It is precisely at this junction that the TV version most often breaks.
Common technical questions before project start
A TV build is a separate interface branch: the remote provides only directions, selection, and back, so navigation is built on focus, not touches. Below are the doubts we most often discuss before starting.
How is the app controlled with a single remote?
The focus position is restored after the list loads, holding a button speeds up scrolling, and every scenario is completed in a finite number of presses. We separately test behavior on remotes from different manufacturers and during text input.
What will happen to the already released phone app?
Shared authorization and data layer, separate interface branches. The TV build is released on its own cycle and does not shift mobile releases.
Can the interface be changed without re-reviewing the build?
Yes: the home screen and sections are described by managed configuration that the app fetches at startup. The order of blocks, texts, and selections change without a new publication — only the build goes through review.
What happens on a weak network?
The catalog and latest states are cached locally, and navigation remains responsive. During a drop, playback switches to a lower quality profile, and requests are retried with increasing delay.
How is the app maintained after a system update?
We maintain a test matrix on current firmware branches and target builds for different device families. If the platform changes behavior, we release a compatible update.
Let's discuss the task and come back with an estimate and plan
To make the estimate for Android TV app build timelines realistic rather than "plus or minus a quarter," we need a minimum of input data.
The more specific the initial description, the fewer assumptions in the work plan for the TV app and the more accurately we name the team composition.
- Viewing scenarios. Live broadcast, archive, subscriptions, resume from where stopped, multiple profiles in one apartment — each scenario changes the player architecture and state storage logic.
- List of target devices. TV and set-top box models, system versions, remotes with and without voice search. Navigation that works on one device breaks on another — we build this into testing in advance.
- Access to the current build. Repository, signing keys, developer console, test accounts. Starting from working code is faster than reconstructing context from stories.
- Launch deadline constraints. Tying to a content release or a partner requirement sets the order of stages: first the skeleton and navigation, then the player, then refinements.
- Acceptance owner. Who accepts the result, in what form they record comments, and by what criteria they consider the task closed.
- Current feedback. What already breaks for viewers: freezes during switching, position loss, slow start — the first candidates for the plan.
After that, we come back with an estimate of build timelines, team composition, and a work plan for the TV app, and separately discuss project handover: documentation, access, and the support procedure after launch. Describe the task in free form — that is enough to discuss it substantively.