Android Video Player SDK — Outsourced Development

Client: GliaCloud Project: Android Video Player SDK Engagement: Fixed scope milestone based contract Working language: English/Chinese (design notes, PR descriptions, reports) 1. Project Overview GliaCloud delivers a WebView-hosted video player ("web player") that publishers embed in their native Android apps. We are hardening this into a production-grade Android SDK that hosts the web player and gives it reliable native capabilities: layout placement, floating playback, accurate visibility/lifecycle signals, and a secure bidirectional JavaScript bridge. **This is not a greenfield project.** A working proof-of-concept already exists and the engagement is to extend and harden it, not to build from zero. The vendor will inherit, among other things: - Kotlin/Gradle library modules (core SDK + impression/visibility tracking) and a demo app exercising the library. - A reference JavaScript bridge with a modern path and a legacy fallback path. - Visibility/impression primitives (geometry, hidden/occlusion detection, impression state machine) with unit-test coverage. - Instrumented stress tests, including a multi-WebView concurrent bridge load test. - Architecture and design documents defining the component model, the WebView state model, and the visibility-signal definitions with a scenario matrix. The vendor builds on this baseline. Estimates should reflect *extension and hardening of existing code*, not from-scratch development. **Fixed architectural principle (non-negotiable):** the SDK is a **signal emitter and command executor**; the web player makes all product decisions. The SDK continuously reports visibility/lifecycle signals to the web player and executes commands (float, unfloat, pause, etc.) the web player sends back. Technical Requirements • Kotlin 2.x • Android API 24–36 • Android View System and Jetpack Compose support • AndroidX WebKit • Secure JavaScript Bridge • Google Mobile Ads SDK integration • JUnit, Robolectric, Espresso testing --- 2. Scope of Work The following are the major requirements; final scope is detailed per milestone at kickoff and is not limited to these items. 2.1 Layout 1. **SDK layout initialization** - **Static (inline) view** — a slot/placeholder component the integrator places in their UI, provided in two forms sharing one host: an Android View (usable from XML) and a Jetpack Compose composable. - **Floating view** — a view that stays visible on screen, rendered in a floating anchor container (with a sensible default and an integrator override for z-order control). - **WebView persistence** — the WebView must remain alive and available at all times on the same page. When the slot is recycled by a `RecyclerView` or Compose `LazyColumn` and scrolled offscreen, the WebView must not be destroyed or paused; playback and JS execution must continue (see the offscreen requirement in §2.2). 2. **Dynamic sizing from backend / web-player settings** — width and height accepting both relative (percentage) and absolute (dp/px) values, plus aspect-ratio-driven sizing. Sizes must re-resolve correctly on configuration changes (rotation, multi-window, screen-size changes). 3. **Floating view positioning from backend / web-player settings** — corner/edge anchoring and margins, configurable at runtime. 2.2 Float 1. Switch the player into a floating position that stays visible, and back to inline. 2. **Float timing is decided by the web player**, not the SDK. The SDK exposes a float/unfloat command API on the bridge; it must not hard-code float triggers. 3. Implement a small WebView state model (inline / floating / offscreen / released). Of particular note is the **offscreen** state: the WebView stays attached and is translated fully out of the viewport **without** altering `visibility`, `alpha`, or scale, and **without** pausing the WebView — so the web player's playback and ad measurement continue. This must comply with IAB/MRC viewability rules: shrinking to sub-pixel size, alpha-0, or `INVISIBLE`-while-claiming-viewable are ad-fraud patterns and are **prohibited**. 4. Distinguish detach causes correctly (list recycling and in-app navigation vs. Activity destruction / back-stack pop) so the WebView is preserved when it should be and released when it should be, without context leaks. 5. **Stress-test the provided scenarios and report robustness**, including rapid float/unfloat and attach/detach cycling (fast feed scrolling), rotation and multi-window transitions while floating. 6. **R&D component (outcome not guaranteed):** verify that a WebView translated fully offscreen keeps producing video frames, audio, and `requestAnimationFrame` ticks, and that ad (VPAID/VAST) playback state stays normal, across the device and API matrix in §5. This is a research task — the deliverable is an honest, evidence-backed report of what works and what does not; estimates should account for its uncertainty. 7. **Provide a demo** exercising inline, floating, and offscreen behavior in both XML (RecyclerView) and Compose (LazyColumn, Pager, Navigation) integrations. 2.3 Native states (signals) 1. Compute and expose the following, emitted to the web player over the bridge on change (precise definitions and a full edge-case matrix are provided after NDA and must be followed): - **Target view (slot):** - On-screen area percentage (pure geometry, reacting to scroll/layout). - Whether the element is on the currently active page — "page" meaning reachable by scrolling alone, not navigation. - Whether the element is deliberately hidden by the integrator (visibility/alpha/scale/clip across ancestors). - Visible percentage after subtracting IME and system-bar insets, and detection of the element being covered/occluded. - **Whether the app is active** (process in foreground). - **Activity lifecycle state**, including correct behavior for edge cases (picture-in-picture, multi-window focus loss, translucent overlays, system dialogs). 2. **Validate the values against the provided scenario matrix** with automated tests — Robolectric unit tests for geometry/hidden detection, instrumented tests for lifecycle-dependent cases. 3. **Provide a demo** that displays live signal values across the provided scenarios (a debug panel over feed/matrix screens). 2.4 Bridge 1. Implement a secure, robust bidirectional native↔JS bridge: a primary path (modern WebView messaging with a strict origin allow-list), a fallback path for devices where the modern feature is unavailable, native→web event emission with proper JSON serialization and main-thread safety, and defensive message parsing that yields typed errors rather than crashes. 2. **Stress-test the provided scenarios and report robustness** — sustained bidirectional bursts and multiple concurrent WebViews (modern, fallback, and mixed), measuring delivery counts, latency, message loss, and timeouts, with machine-readable reports. The baseline contains reference load tests to extend. 3. **Provide a demo** of bridge round-trips and the command/signal contract. 2.5 SDK interface 1. Validate that the integrator-facing interface (one-call install per Activity, slot placement, optional floating-anchor override) is sufficient for the SDK to obtain everything it needs, with no hidden integrator obligations. Cover both View (XML) and Compose paths, and configuration-change handling. Report any gaps with proposed API changes before implementation. --- 3. Deliverables 1. **SDK source code** — Kotlin Gradle modules, buildable as AARs, with the public API documented (KDoc). 2. **Demo application** — exercising every scenario in §2 (layout modes, float/offscreen, signal debug panel, bridge), in both XML and Compose variants. 3. **Automated test suite** — unit tests (JUnit + Robolectric) and instrumented tests (Espresso/AndroidX), at a depth consistent with the existing baseline. 4. **Stress-test reports** — written robustness reports for the float and bridge scenarios with raw data (latency distributions, loss/timeout counts) across the agreed device/API matrix. 5. **Validation report** — signal values vs. the scenario matrix, with any documented deviations and their justification. 6. **Integration documentation** — integrator setup guide and the bridge message contract. All work is delivered via pull requests to our repository, reviewed and approved by our team. --- 4. Engagement Shape & Effort Proposed milestone structure (vendor may propose an alternative): 1. Bridge + SDK interface validation (§2.4, §2.5) 2. Layout + signal implementation with scenario validation (§2.1, §2.3) 3. Float + offscreen state model + offscreen-continuity R&D (§2.2) 4. Stress testing, hardening, demos, and documentation Indicative effort: 1 engineer-months Vendors should propose a milestone timeline, effort estimate, and pricing model based on the scope above. We expect a weekly sync and written progress notes. --- 5. Device & API Test Matrix Stress tests, the offscreen-continuity R&D, and lifecycle validation must cover (at minimum): - **API levels:** 26, 29, 33, 34 (SDK supports 24–36). - **OEMs:** Pixel, Samsung, Xiaomi. The breadth of this matrix is a deliberate cost driver and should be reflected in estimates. --- 6. Required Qualifications Must have - Senior-level production Android development in Kotlin (typically ~3 years, but the depth below matters more than tenure — a candidate who demonstrably has the WebView and lifecycle knowledge qualifies regardless of exact years). Deep familiarity with the View system **and** Jetpack Compose, including interop (`AndroidView`, `LazyColumn` recycling semantics, `DisposableEffect`). - Demonstrated deep WebView expertise: `androidx.webkit`, modern messaging vs. `addJavascriptInterface` trade-offs, renderer-process lifecycle (`onRenderProcessGone`), Chromium page-visibility behavior, and the pitfalls of WebView reparenting and context handling. - Strong command of Android lifecycle internals: Activity/Fragment edge cases (PiP, multi-window, translucent overlays, configuration changes), `LifecycleOwner` / `ProcessLifecycleOwner`, `findViewTreeLifecycleOwner`. - Experience designing public SDK APIs consumed by third-party integrators (API stability, minimal integration surface, defensive error handling). - Solid testing practice: Robolectric, instrumented tests, and building load/stress harnesses with measurable reports. - Kotlin coroutines and disciplined main-thread handling in UI-adjacent and bridge code. - Familiarity with integrating the Google Mobile Ads SDK into a WebView (initialization and `registerWebView` ordering). Strongly preferred - Deeper ad-tech experience: VAST/VPAID, IAB/MRC viewability, Open Measurement. - Prior work on video player SDKs, floating/PiP-style players, or visibility/impression measurement. - Testing across OEM variations (Pixel, Samsung, Xiaomi) and API levels 24–36. --- 7. How to Respond Please include: 1. Relevant prior work — ideally a shipped SDK, player, or WebView-heavy product (links or case studies). 2. A short technical note (≤1 page) on how you would verify that a WebView translated fully offscreen keeps producing video frames. This is a real problem in scope, and your approach will be weighed heavily. 3. Proposed team composition, milestone timeline, and pricing model. --- 8. Provided After NDA To keep commercially sensitive details out of public circulation, the following are shared once an NDA is in place and the engagement is confirmed: - Repository access and full source history. - Internal architecture documents (component model, full state model, visibility signal definitions and scenario matrix, lifecycle-behavior references). - Complete acceptance thresholds and the formal Statement of Work.