What I learned building a browser for Android TV and why everything I assumed was wrong.
When I started working on a browser for Android TV, I thought: How different can it be? It runs Android. We have WebView. We know web tech.
That assumption aged poorly.
Android TV development is not just Android development on a bigger screen. It's a fundamentally different platform with different input models, different hardware realities, and a fragmentation problem that makes the regular Android ecosystem look tame. Here's what I ran into and what I wish someone had warned me about.
D-pad Focus Is Harder Than Touch UX
Normal Android apps assume touch. Gestures. Scrolling. Users tap what they want, swipe to explore, and pinch to zoom. The system knows exactly where the user's finger is pointing.
TV UX works on none of those assumptions.
With a remote control, you navigate with four directional buttons. That's it. There is no cursor (usually). There is no hover. There is no "tap anywhere." Every interaction is routed through focus states and a movement graph that the developer (not the user) defines.
That means:
- Manually managing focus order, because Android's default focus traversal makes sense for form fields, not arbitrary UI layouts
- Preventing focus traps, where the user presses right infinitely and nothing happens
- Handling invisible focus states, where the focused element has no visible ring and the user has no idea where they are
- Making every interactive element reachable via remote only, with no fallback to "just tap it" The movement graph has to be predictable. Users on TV develop a mental model of where focus will go when they press a direction. Break that model once, and the experience feels broken forever.
Websites Are Not Designed for 10-Foot Viewing
This sounds obvious until you try it.
A site that works fine on desktop (readable, usable, functional) can become genuinely painful on TV because:
- Text that looks normal at arm's length becomes tiny at 10 feet
- Hover interactions (dropdown menus, tooltips, navigation reveals) simply don't exist on TV
- Menus designed for mouse precision require pixel-perfect targeting that a D-pad can't provide
- Dialogs that are carefully sized for 1080p monitors overflow on TV viewports with different scaling
Spacing that feels generous on a monitor feels cramped when you're looking at it across a room
To make arbitrary web content usable, we had to:Increase clickable areas well beyond what the original site intended
Force zoom and scaling to make text legible at distance
Override viewport behavior to prevent sites from making layout decisions we didn't want
Inject CSS and JS fixes as a layer between the user and the original content
You're basically shim-ing bad assumptions at runtime. It's messy, but it's necessary.
WebView Fragmentation Is Brutal on TVs
On phones, Android System WebView is updated regularly through the Play Store. Not so on TVs.
TV vendors rarely push:
- Android System WebView updates
- Chromium engine updates
- Security patches What that means in practice: Android version became a meaningless signal.
Two TVs, both reporting Android 12. One has Chromium 66. Another has Chromium 102. That's a four-year gap in browser engine capability. Both TVs will pass any OS version check you write. Neither will behave the same.
The consequence is a class of bugs that are genuinely hard to reproduce and reason about:
- Missing JavaScript APIs that the spec added years ago
- CSS features that silently fail or render incorrectly
- Video playback inconsistencies in how codecs are handled
- Modern frameworks that partially work, just enough to be confusing We learned to detect capabilities, not versions. Don't ask "is this Android 11?" Ask "does this device support this specific API?" It's more work upfront, but it's the only thing that gives you accurate information.
Fake Android Versions from OEMs
Related, but worse.
Cheap and regional OEM TVs often:
- Spoof Android version strings entirely
- Heavily customize firmware in ways that break standard behaviors
- Remove Google components (no Play Services, no certified WebView)
- Ship uncertified builds that passed no compatibility testing So you'd see a device claiming Android 13 that behaved like a heavily stripped Android 9. Or a "certified Android TV" that was actually a modified AOSP box with a launcher slapped on.
This is where capability detection stopped being a best practice and became a survival strategy. You simply cannot trust what the device tells you about itself.
Pointer Simulation Is Deceptive
Some TVs support a simulated cursor, a virtual pointer you can move around with the remote, mimicking mouse behavior. This sounds like it solves the D-pad problem. It doesn't.
The issue is that TVs don't have real pointer semantics. The cursor is a visual overlay, not an actual input device the OS understands as a pointer. That creates a cascade of problems:
- Focus-based and touch-based systems conflict with each other when both exist simultaneously
- Coordinate mapping becomes inconsistent: what does "cursor position" mean if there's no real pointer device?
- Hitbox mismatch: the visual cursor appears over a button, but the actual registered click coordinate is offset, often by however the DPI or scaling is miscalculated The most concrete example: we had a bug where we treated the center of the cursor image as the click point. Seemed reasonable. It was wrong. The actual registered input coordinate was different, and elements that appeared to be under the cursor weren't being activated. Tracking that down was not fun.
DPI inconsistencies and density miscalculations made it worse. A UI that looked correct on one TV would have systematically shifted hitboxes on another.
Hardware Acceleration Inconsistencies
TVs have GPUs, but the drivers for those GPUs on cheap hardware are often poor.
We saw:
- Animations that dropped frames dramatically even when the content was simple
- WebView rendering that lagged visibly on transitions
- Video overlays that conflicted with composited UI layers
- Hardware acceleration that caused more problems than it solved on specific chipsets The workaround was often the opposite of what you'd do on a performance-focused mobile app: disable effects, reduce transparency, simplify rendering, lower repaint frequency. You're optimizing for correctness over aesthetics.
Overscan Still Exists
Overscan is a legacy TV behavior where the display crops the edges of the image slightly, a leftover from CRT broadcasting. You'd think it's gone by now.
It's not.
A UI that fits perfectly in the Android emulator or on your test monitor can, on a real TV:
- Clip the edges of buttons so they're partially off-screen
- Hide navigation elements
- Cut subtitles or action labels TV-safe margins (keeping all meaningful content away from the outer 5-10% of the screen) aren't just a guideline. They're a requirement if you want to ship something that works everywhere.
Remote Latency Matters More Than Expected
On mobile, a 100ms UI response feels fine. Acceptable. Maybe even snappy.
On TV, with a D-pad, 100ms delay on focus movement feels terrible. The navigation feels sluggish and unresponsive, even when the actual delay is imperceptible on other platforms.
This is partly perceptual. TV UX is used from a couch, passively, and the threshold for "this feels broken" is lower. But it's also because D-pad navigation is sequential and modal. You press right, wait for focus to move, then press again. If each press introduces latency, it compounds.
Focus movement needs to feel instant. Not fast. Instant.
APK Behavior Varies Wildly by Manufacturer
Beyond WebView, the underlying APK behavior differed meaningfully across:
- Keycodes: what keycode does "back" send? Depends on the manufacturer.
- Launcher behavior: how does the system handle app lifecycle when the user goes home?
- Background restrictions: some TVs killed background processes aggressively; others didn't
-
Fullscreen APIs:
WindowInsets,systemUiVisibility, the behavior of immersive mode all differed - Permissions: some TVs prompted for permissions differently or blocked them silently
- Autoplay support: video autoplay policies varied dramatically This was especially pronounced on Mi TV, Realme TV, generic AOSP TV boxes, and uncertified Android TVs from regional manufacturers. Each had its own quirks, and none of them were documented.
Debugging Is Painful
Many TVs:
- Lack proper developer tools
- Have ADB support that's broken, disabled, or intermittent
- Disconnect randomly during sessions
- Hide or truncate logs This makes iteration significantly slower than standard Android development. The feedback loop is longer, crashes are harder to inspect, and reproducing bugs in a controlled way often requires having the exact physical device in hand.
We developed a habit of logging aggressively to in-app overlays: visible debug panels that showed state, errors, and event sequences without relying on ADB. Inelegant, but effective.
Memory Limitations on Cheap Hardware
Premium TVs have reasonable RAM. Cheap TVs, which are often the majority of units in certain markets, have:
- 1-2GB RAM, sometimes less
- Slow eMMC storage
- Weak CPUs with thermal throttling Heavy web apps that run fine on mid-range phones become noticeably sluggish on these devices. Memory pressure causes WebView to drop cached resources. Page loads take longer. Complex layouts trigger more GC pauses.
This pushed us toward lighter rendering, aggressive caching strategy, and simplified page structures for TV-specific views.
The Core Insight
After all of this, the biggest architectural realization was this:
The browser wasn't the problem. The assumptions browsers make about input methods and responsive behavior were.
Browsers are built for a world of mouse pointers, touch surfaces, and responsive viewports. That world doesn't exist on TV. The moment you try to present web content on a TV, you're in a gap between two systems that weren't designed to meet.
Building a good TV browser isn't about shipping Chromium on a bigger screen. It's about mediating between the web's assumptions and the TV's reality, at every layer of the stack, from input handling to rendering to hardware capability detection.
It's more work than it looks. But it's genuinely interesting work.
If you've shipped something for Android TV and ran into similar (or completely different) problems, I'd love to hear about it in the comments.
Top comments (0)