Before you continue
Before submitting a bug report, please review our troubleshooting documentation at Redirect | /docs/vega/0.24/troubleshoot-overview.html
If you still want to file a bug report, please make sure to fill in all the details below and provide the necessary information.
NOTE: PLEASE ONLY REPORT A SINGLE BUG USING THIS TEMPLATE.
If you’re experiencing multiple issues, please file a separate report for each.
Bug Description
1. Summary
Any attempt to start a `[[components.service]]` component on React Native 0.83 / Vega
SDK 0.24 deadlocks inside `libkeplerscript-runtime-loader-4`. The service’s START
lifecycle callback never completes: the OS kills the app with `AppNotResponding`
(ANR reason: `Lifecycle Callback`), or — if the caller’s timeout fires first — the app
survives and the call into the service fails with
`transaction failed, with error: client disconnected.`
Our player server (`@amazon-devices/kepler-player-server` + Shaka) runs in that service
component, as the Vega media architecture prescribes, so **all media playback is
non-functional on RN 0.83**. We instrumented the service entry path and proved the
deadlock occurs **before the service’s JS bundle is ever evaluated** (Evidence in §5 /
attachments), so no application-side workaround exists.
The identical application code plays video correctly on RN 0.72 under **both**
SDK 0.22.5875 and SDK 0.24.9859. Only RN 0.83 fails. Reproduced on two independently
developed migration branches, two physical devices, and all three published 0.24 SDKs
(0.24.9785 / 0.24.9859 / 0.24.9914).
App Name: STARZ
App Link on Amazon Appstore (found through Developer Console → Actions column in App List → View on Amazon.com): Amazon.com
Bug Severity
Select one that applies
- Impacts operation of app
- Blocks current development
- Improvement suggestion
- Issue with documentation (If selected, please share the doc link and describe the issue)
- Other
2. Steps to Reproduce
-
Take an app with one `[[components.interactive]]` and at least one
`[[components.service]]` in `manifest.toml`, migrated from RN 0.72 to RN 0.83 per the
official migration guide (all components on
`/com.amazon.kepler.runtime.react_native_kepler_4@IReactNativeKepler_0` — the
headless runtime module cannot be used, see Additional Context, Defect 2).
-
Build Release for armv7, install on a Fire TV Stick running OS 1.2
(`OsBuildNumber 2101020054720`), launch. The interactive component runs normally.
-
Trigger anything that starts the service component. In our app: press play on any
title/trailer — the player client (`@amazon-devices/kepler-player-client`) requests
the player server hosted in `com.starz.starzplay.firetv.service`, which makes the OS
issue a START transition for that component.
-
The START transition never completes. Within the ANR deadline the OS kills the app;
if the player client’s timeout fires first, the app instead shows
`transaction failed, with error: client disconnected.`
**Specific trigger:** any `IComponentInstance` START of a `[[components.service]]` under
the kepler-4 runtime. In React Native terms, the JS-side trigger in our app is the
player client requesting its server, but note the deadlock happens **before any service
JavaScript executes** — `HeadlessEntryPointRegistry` entry points are never invoked
(see §4.a).
3. Observed Behavior
Explain what actually happened, noting any discrepancies or malfunctions.
- The service component's process never appears (`vega device running-apps` never lists
`com.starz.starzplay.firetv.service` on RN 0.83; it always appears on RN 0.72).
- ACR shows the app killed with:
- `CrashReason: AppNotResponding`, `LCM_ANR_REASON: Lifecycle Callback`
- `LCM_APP_TRANSITION: appInst[115](com.starz.starzplay.firetv.service): START transition`
- Thread 0 blocked: `libc futex → std::condition_variable::wait → libkeplerscript-runtime-loader-4.so.4.0 + 0x7d2b7`
- Both JS threads: `No JavaScript code is currently being executed.`
- Resource pressure was not a factor (`memory_pressure some avg10=0.19`,
`MemAvailable: 318480 kB`).
- On the runs where the ANR kill did not win the race, the player client surfaced
`transaction failed, with error: client disconnected.` and
`MediaPlayer: Invalid State. Media Element not initialized`.4. Expected Behavior
Describe what you expected the SDK to do under normal operation.
The kepler-4 runtime loads the service component's JS bundle, invokes the entry point
registered via `HeadlessEntryPointRegistry`, and the START transition completes — as the
kepler-2 runtime (`keplerscript.runtime.loader_2`) does for the same code on RN 0.72,
where the same press-play flow starts the service and plays video on both SDK 0.22.5875
and SDK 0.24.9859.
4.a Possible Root Cause & Temporary Workaround
Fill out anything you have tried. If you don’t know, N/A is acceptable
**Root cause (as far as we could isolate):** deadlock inside
`libkeplerscript-runtime-loader-4` while servicing a `[[components.service]]` START —
Thread 0 parks on a condition variable that is never signalled, before the service JS
bundle is evaluated.
Proof that application JS is never reached: we placed 8 `console.error` probes in the
service entry path (one at module scope in `service.js`, seven through
`onStartService`). Across a continuous 10-minute device-log capture (84,650 lines)
containing three reproductions, **zero probes fired**, while the app's own
`console.error` output routed normally via `Volta:console.error` in the same capture
(attachment `logs/probe-evidence-excerpt.txt`).
**Workarounds attempted — none viable:**
- Moving service components to `react_native_kepler_headless_4@IReactNativeKeplerHeadless_0`
per the migration guide → **rejected by `vpt validate`** on all three 0.24 SDKs
("Inconsistent runtime module versions"); see Additional Context, Defect 2.
- Isolating the service in its own `[[processes.group]]` vs sharing the interactive
component's group → deadlock in both topologies.
- SDK 0.24.9785 / 0.24.9859 / 0.24.9914 → identical on all three.
- Upgrading to the RN 0.83 player packages (`kepler-player-server/client@2.3.0-rn-83`)
→ cannot be used: unsatisfiable npm dependency (`ETARGET`) and requires
`IKeplerPlayerServer_3`, which OS `2101020054720` does not provide
(`INSTALL_FAILED_MODULE_DEPENDENCY_NOT_FOUND`); see Additional Context, Defects 3–4.
- `headless-task-manager@1.2.8-rn-83.1`, `react-native-w3cmedia@2.3.4-rn-83` → no change.
- Ruled out with evidence: RNSVG dual-runtime SIGSEGV (only the 0.83 stack loads),
the known `__DEV_RUNTIME__` headless issue (string absent from all dumps), memory
pressure, JS deadlock, backend/entitlement (play-auth returns 200/202 immediately
before the failure).
**Current state: no workaround exists.** The failure is in platform code before any
application code runs.
5. Logs or crash report
Attached:
| File | Contents |
|—|—|
| `acr/anr-branchA-repro1.acr`, `acr/anr-branchA-repro2.acr` | Full ANR crash reports (two reproductions, migration branch A) |
| `acr/anr-branchB-independent-migration.acr` | Same signature from an independently developed migration branch of the same app |
| `logs/probe-evidence-excerpt.txt` | Probe experiment summary — zero probe lines across 3 repros with a verified-working console channel |
| `logs/device-log-10min-3-repros-full.log.gz` | The full 10-minute device log capture (84,650 lines) |
| `logs/build-rejecting-mixed-manifest.log` | Build failing on the migration-guide manifest (Defect 2) |
| `logs/npm-etarget-player-2.3.0-rn-83.log` | `ETARGET` for `kepler-player-server@^2.3.0` (Defect 3) |
| `logs/kepler-compatibility-errors-excerpt.log` | `-rn-83` packages failing their own compatibility validation (Defect 5) |
| `validate/vpt-validate-sdk-0.24.{9785,9859,9914}.txt` | `vpt validate` rejection of the guide’s manifest on each SDK |
| `manifest/manifest-all-interactive-BUILDS-OK.toml` | Manifest that builds (all components on the interactive runtime) |
| `manifest/manifest-per-migration-guide-REJECTED.toml` | Manifest exactly per migration guide Step 3 — rejected |
6. Environment
Please fill out the fields related to your bug below:
-
SDK Version: `Active SDK Version: 0.24.9859` / `Vega CLI Version: 1.2.22`
(reproduced identically on 0.24.9785 and 0.24.9914)
-
React Native Version: RN 0.83 (`react-native@0.83.0`, `react@19.2.0`,
`@amazon-devices/react-native-kepler@4.0.1+rn0.83.0`)
-
App State: Foreground (`LCM_APP_IN_FOREGROUND: true` in the ACRs)
-
OS Information: Fire TV Stick, product `callie`, `armv7l`, profile `tv`.
Output of `cat /etc/os-release` (same device the attached ACRs were captured on):
```
NAME=“OS”
OE_VERSION=“4.0.0”
OS_MAJOR_VERSION=“1”
OS_MINOR_VERSION=“2”
RELEASE_ID=“21”
OS_VERSION=“1.2”
BRANCH_CODE=“TV Ship”
BUILD_DESC=“OS 1.2 (TV Ship/547)”
BUILD_FINGERPRINT=“4.0.378951.0(3072cab629675a74)/547N:user/release-keys”
BUILD_VARIANT=“user”
BUILD_TAGS=“release-keys”
BUILD_DATE=“Tue Jul 14 08:13:13 UTC 2026”
BUILD_TIMESTAMP=“1784016793”
VERSION_NUMBER=“2101020054720”
```
7. Example Code Snippet / Screenshots / Screengrabs
Include any relevant code or component setup in React Native that can help reproduce the bug.
`manifest.toml` (full files attached — this is the configuration that builds; the
migration guide's headless variant is rejected by the validator, see Defect 2):
```toml
[[components.interactive]]
id = "com.starz.starzplay.firetv.main"
runtime-module = "/com.amazon.kepler.runtime.react_native_kepler_4@IReactNativeKepler_0"
launch-type = "singleton"
[[components.service]]
id = "com.starz.starzplay.firetv.service" # hosts the player server
runtime-module = "/com.amazon.kepler.runtime.react_native_kepler_4@IReactNativeKepler_0"
launch-type = "singleton"
```
`service.js` (service bundle entry — none of this is ever executed on RN 0.83; a
`console.error` at module scope of this file never fires):
```js
import { HeadlessEntryPointRegistry } from '@amazon-devices/headless-task-manager';
import { onStartService, onStopService } from './src/services/player/runtime/headlessEntry';
HeadlessEntryPointRegistry.registerHeadlessEntryPoint(
'com.starz.starzplay.firetv.service::onStartService',
() => onStartService,
);
```
`onStartService` (never invoked on RN 0.83):
```ts
export async function onStartService(): Promise<void> {
playerServerFactory = new PlayerServerFactory(); // kepler-player-server
const playerServer = playerServerFactory.getOrMakeServer();
playerService = new HeadlessShakaCore({ /* ... */ }); // Shaka wrapper
playerServerHandler = new HeadlessPlayerHandler(playerService);
await playerService.start(playerServer, playerServerHandler);
}
```
Playback Issues
If this is a playback issue, please provide your content URL, any pre-conditions (like geo-location), and let us know if it’s x86 or arm7.
The user-visible symptom is a playback failure, but **the failure occurs before any
media/manifest request is issued** — the player server component never starts, so the
player client's GIPC connection fails (`client disconnected`) and no content URL is
ever fetched. It reproduces with **all** content, on **armv7** hardware. The same
content plays on RN 0.72 (both SDK 0.22 and 0.24) on the same device.
Please share the following details in addition:_
-
Player SDK: Shaka (app-vendored, served through
`@amazon-devices/kepler-player-server` 2.2.14 / `react-native-w3cmedia`)
-
Player SDK Version: Shaka 4.8.5 (`shaka.Player.version = “4.8.5-npm-dirty”`)
-
Audio Codecs: AAC *(immaterial — no media request is ever issued)*
-
Video Codecs: H.264 *(immaterial — as above)*
-
Manifest Types: DASH (`application/dash+xml`), Widevine/PlayReady DRM
*(immaterial — as above)*
-
Q: If applicable, please provide your media/content url
If this is created dynamically, tokenized, etc please provide a way for us to access it
N/A — URLs are tokenized via our play-auth service, but the
failure precedes content resolution entirely; the play-auth calls themselves succeed
(HTTP 200/202) immediately before the failure. Any service-hosted player reproduces it.
Q: Are there any special headers required to reproduce the issue you are facing?
N/A — reproduces before any media HTTP request exists.
Additionally please provide the following if possible
Provide Screenshots / Screengrabs / Logs. Please include as much information as you can that will help debug.
<!-- Answer here if applicable -->
Additional Context
Any Additional Context you would like to provide?
Add any other relevant information, such as recent updates to the SDK, dependencies, or device OS that may affect the bug.
Four additional defects encountered while isolating this, all reproducible (evidenceattached):
**Defect 2 — migration guide contradicts the manifest validator.**The RN 0.83 migration guide ("Step 3: Vega Configuration Updates",https://developer.amazon.com/docs/vega/0.24/rn-migration-vega-config.html) instructsinteractive components onto `react_native_kepler_4@IReactNativeKepler_0` and headlesscomponents onto `react_native_kepler_headless_4@IReactNativeKeplerHeadless_0`. Anymanifest containing both is rejected by `vpt validate`:
```error: [components.runtime-module] Inconsistent runtime module versions found: 'IReactNativeKepler_0' (…main), 'IReactNativeKeplerHeadless_0' (…service, …providers) help: All runtime modules declared must use the same version```
Identical on 0.24.9785 / 0.24.9859 / 0.24.9914 (attached). The message says "version"but both modules are version `_4` — the check appears to compare interface names. Aswritten, **no app with both interactive and headless components can follow the guide.**
**Defect 3 — `-rn-83` player packages have an unsatisfiable npm dependency.**`@amazon-devices/kepler-player-client@2.3.0-rn-83` depends on`kepler-player-server@^2.3.0`; no non-prerelease 2.3.0 exists (only `2.3.0-rn-83`), andnpm ranges exclude prereleases → `ETARGET` (attached). Requires a package.json`overrides` entry to install at all.
**Defect 4 — `-rn-83` player packages target an OS interface the shipping OS lacks.**`kepler-player-server@2.3.0-rn-83` declares`/com.amazon.kepler.kepler_player_server_2@IKeplerPlayerServer_3`; installing on`OsBuildNumber 2101020054720` (the OS version SDK 0.24 itself requires) fails with`INSTALL_FAILED_MODULE_DEPENDENCY_NOT_FOUND` — that OS provides only `_2`. Combinedwith the deadlock: the RN 0.72 player packages install but their service deadlocksunder kepler-4, and the RN 0.83 player packages match the runtime but cannot beinstalled. **A media app currently has no working configuration on RN 0.83.**
**Defect 5 — `-rn-83` packages fail their own compatibility validation.**`headless-task-manager@1.2.8-rn-83.1` and `react-native-w3cmedia@2.3.4-rn-83` areflagged during build: "The version is set to X but that value is not part of it's'kepler-compatibility.json' file" (attached excerpt). Non-fatal, but emitted as `ERROR`,which buries real failures in build logs.
Related detail: on RN 0.83 builds, KMMB regenerates `[[needs.module]]` entries into thesource `manifest.toml` and **appends without removing superseded interfaces** — aftertesting `2.3.0-rn-83` and reverting, the stale `IKeplerPlayerClient_3/_Server_3` entriesremained and every subsequent install failed until removed by hand. Worth checking as asecondary tooling issue.
Timeline note: the app was recently migrated SDK 0.22.5875 → 0.24.9859 (RN 0.72 —everything works, including playback) and then RN 0.72 → 0.83, where this blockerappears. The `__DEV_RUNTIME__` known issue from the 0.24 release notes does **not**reproduce for us — the string appears in no crash dump.