标签：#androidtv

Live Project: tv.cadnative.com What Is FireViston TV? FireViston TV is a full-stack streaming solution designed for the modern living room. It consists of two parts that work in tight coordination: FireViston TV Android App — a native Android/Android TV application that delivers a polished, remote-friendly viewing experience. https://github.com/akshaynikhare/FireVisionIPTV/releases FireViston TV Server — the backend streaming infrastructure that powers content delivery, user management, and playback control hosted at tv.cadnative.com Together, they form a complete, self-contained streaming platform. The Android App Built for the 10-Foot Experience The FireViston Android app is designed for television screens — large fonts, d-pad navigation, and a layout that works from across the room. No pinching, no scrolling hunts, no mobile-style UI crammed onto a 55-inch display. Smooth Playback Video streaming requires more than just playing a file. FireViston handles adaptive bitrate streaming, buffer management, and codec compatibility to ensure smooth playback across the broadest range of Android TV devices — from budget sticks to high-end smart TVs. Content Discovery A clean, browsable content grid lets users find what they want quickly. Categories, search, and a "continue watching" row reduce friction from intent to playback. The Server Backend Reliable Infrastructure The FireViston server at tv.cadnative.com manages content ingestion, transcoding pipelines, and delivery. It's built to handle concurrent streams without degrading quality for any individual viewer. API-Driven Architecture The Android app communicates with the server through a REST API, making the backend flexible enough to support additional clients — web players, other mobile platforms — without rewriting core logic. User & Session Management Account creation, authentication, playback progress sync, and device management all happen server-side. Users can pick up on any device exactly where they left off. W

The bug report was simple: long-pressing the d-pad center button on a channel card should toggle the favorite — it wasn't working reliably. On some devices it fired once and stopped. On others it didn't fire at all on long-press. The fix was changing onKeyEvent to onPreviewKeyEvent in one Composable. The reason why is worth understanding. Background: Two Event Handlers in Compose Jetpack Compose exposes two modifier-level hooks for key input: Modifier . onKeyEvent { keyEvent -> .. . } Modifier . onPreviewKeyEvent { keyEvent -> .. . } They sound equivalent. They're not. The difference is where they sit in the event propagation chain . How Android TV Routes D-Pad Events When a user presses a key on a TV remote, Android routes the event through a dispatch tree: Activity └─ ViewGroup (root) └─ FocusedComposable └─ Child Composables The event travels down first (capture phase), then up (bubble phase): Capture (top → focused node): onPreviewKeyEvent handlers fire here, outermost first. Bubble (focused node → top): onKeyEvent handlers fire here, innermost first. onPreviewKeyEvent is the capture phase. onKeyEvent is the bubble phase. Why This Matters for Long-Press Android TV handles long-press recognition at the framework level. When you hold the d-pad center button: A KeyEvent.ACTION_DOWN fires immediately. If the key is held, the framework generates repeated ACTION_DOWN events at the key repeat rate. ACTION_UP fires when the button is released. The long-press callback that Compose's focus system uses for "confirm" actions (select, activate) consumes ACTION_DOWN during the bubble phase — specifically to prevent the holding action from also triggering the tap action. When the ChannelCard had a click handler wired for the primary action and onKeyEvent for the long-press toggle, the click handler's bubble-phase consumption of ACTION_DOWN was racing with the long-press handler. On some devices the click handler won, swallowing the event before the long-press code ran. The Fix