VVD image in SDK 0.24.x is two OS releases behind retail; all react-native-svg components fail to bind on the simulator

# :backhand_index_pointing_right: Bug Description

## 1. Summary

On the Vega Virtual Device bundled with SDK 0.24.9859, every `react-native-svg`

component fails to bind and renders as React Native’s `UnimplementedView`. The

identical app build renders SVG correctly on retail hardware.

The VVD ships OS `RELEASE_ID 21`; our retail device is on `RELEASE_ID 23`.

Retail is unaffected, so this is not a shipping blocker. It does mean the

simulator cannot be used for any screen containing SVG — for us, the QR code on

the login screen.

**App Name**: STARZ (`com.starz.starzplay.firetv`)

**App Link on Amazon Appstore**: `<fill in from Developer Console → Actions → View on Amazon.com>`

**Bug Severity**

Select one that applies [x]

* [ ] Impacts operation of app

* [] Blocks current development *(simulator only — retail unaffected)*

* [ x] Improvement suggestion

* [ ] Issue with documentation (If selected, please share the doc link and describe the issue)

* [ ] Other

## 2. Steps to Reproduce

1. Build a React Native 0.83 app that depends on `@amazon-devices/react-native-svg` (ours arrives via `@amazon-devices/react-native-qrcode-svg`).

2. Install and launch it on the Vega Virtual Device bundled with SDK 0.24.9859.

3. Navigate to any screen that renders an `` element — in our case the login screen’s QR code.

4. Observe the red `Unimplemented component: RNSVGGroup` / `RNSVGPath` placeholder in place of the SVG.

5. Install the same build on a retail device on `RELEASE_ID 23` and open the same screen — the SVG renders correctly.

## 3. Observed Behavior

All react-native-svg components render as React Native’s UnimplementedView

placeholder. The SVG library itself loads successfully, the component name

resolves via OS metadata, and the component initializer is then not found:

[AutoLinkService] Successfully v2 auto-linked libreact-native-svg-stable-3.so.3.0

[AutoLinkService] Successfully linked ‘RNSVGGroup’ from OS metadata

[ComponentViewManager] Expected auto-linked initializer for RNSVGGroup not found.

Identical for RNSVGSvgView, RNSVGPath, RNSVGRect, RNSVGDefs and

RNSVGLinearGradient.

## 4. Expected Behavior

SVG components bind and render on the virtual device, as they already do on

retail hardware running RELEASE_ID 23 with the identical app build.

### 4.a Possible Root Cause & Temporary Workaround

Possible root cause:

/etc/autolink/autolink-metadata.json contains two entries with

publicName “RNSVG”. One names no library at all, and the file’s own

“violations” array rejects it:

{

"package": "amzn-react-native-svg-2.0.9000000000+13.14.0",

"entry": "RNSVG",

"violations": \["Must have either libraryName or uiComponentName"\]

}

The other correctly names libreact-native-svg-stable-3.so.3.0. On RELEASE_ID 21

the OS-first resolver appears to select the malformed entry, leaving no library

to load component initializers from.

Note the same malformed entry is also present on RELEASE_ID 23, where SVG

works. So the entry alone is not sufficient to cause the failure — the resolver

behaviour differs between the two releases.

Workaround: verify all SVG-backed screens on physical hardware. There is no

app-side fix, since the component names (RNSVGGroup, RNSVGPath, …) are fixed

by the JS package and cannot avoid the OS-first lookup.

Already in place on our side: a postinstall patch that renames our autolink

entry from “RNSVG” to “RNSVGStarz” so the library resolves from app metadata

rather than the OS registry. This correctly links

libreact-native-svg-stable-3.so.3.0, but does not affect the per-component

lookups, which still resolve OS-first.

Tried and ruled out: rendering a hidden at app startup to force the link

earlier. Verified this moved the link from 253 ms after the screen rendered to

1.09 s before first paint, and the components still failed to bind — so this is

not a lazy-autolink timing issue.

Requests:

1. Please ship a VVD image at parity with retail OS (RELEASE_ID 23+). Updating

the SDK is not a workaround: 0.24.9914 carries a byte-identical VVD image to

0.24.9859 (boot.img, vendor.ext4 and misc.img all match by MD5).

2. Please confirm which OS release fixed the RNSVG resolution, so we know what

is affected in the field.

## 5. Logs or crash report

No crash — the app runs normally, only the SVG subtree renders as a placeholder.

Device log excerpt captured via `vega device start-log-stream`, from the render

of the affected screen on the VVD:

[AutoLinkService] Successfully v2 auto-linked libreact-native-svg-stable-3.so.3.0

[AutoLinkService] Successfully linked ‘RNSVGLinearGradient’ from OS metadata

[ComponentViewManager] Expected auto-linked initializer for RNSVGLinearGradient not found.

[AutoLinkService] Successfully v2 auto-linked libreact-native-svg-stable-3.so.3.0

[AutoLinkService] Successfully linked ‘RNSVGDefs’ from OS metadata

[ComponentViewManager] Expected auto-linked initializer for RNSVGDefs not found.

[AutoLinkService] Successfully v2 auto-linked libreact-native-svg-stable-3.so.3.0

[AutoLinkService] Successfully linked ‘RNSVGRect’ from OS metadata

[ComponentViewManager] Expected auto-linked initializer for RNSVGRect not found.

[AutoLinkService] Successfully v2 auto-linked libreact-native-svg-stable-3.so.3.0

[AutoLinkService] Successfully linked ‘RNSVGGroup’ from OS metadata

[ComponentViewManager] Expected auto-linked initializer for RNSVGGroup not found.

[AutoLinkService] Successfully v2 auto-linked libreact-native-svg-stable-3.so.3.0

[AutoLinkService] Successfully linked ‘RNSVGPath’ from OS metadata

[ComponentViewManager] Expected auto-linked initializer for RNSVGPath not found.

Full log and the device’s autolink-metadata.json attached.

## 6. Environment

* **SDK Version:** 0.24.9859 (Vega CLI 1.2.22)

* **React Native Version:** RN 0.83.0 (`@amazon-devices/react-native-kepler` 4.0.1+rn0.83.0, React 19.2.0)

* **App State:** `Foreground`

* **OS Information:**

Vega Virtual Device (affected) — aarch64:

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/101520710)”

Retail device (works correctly) — armv7l:

OE_VERSION=“4.0.0”

OS_MAJOR_VERSION=“1”

OS_MINOR_VERSION=“2”

RELEASE_ID=“23”

OS_VERSION=“1.2”

BRANCH_CODE=“TV Ship”

BUILD_DESC=“OS 1.2 (TV Ship/44)”

## 7. Example Code Snippet / Screenshots / Screengrabs

Any SVG reproduces it. Minimal case:

import Svg, { Path } from ‘@amazon-devices/react-native-svg’;

Our original report came from a QR code, which renders through the same components:

import QRCode from ‘@amazon-devices/react-native-qrcode-svg’;

Screenshots attached: the affected screen on the VVD (placeholder) and the same

build on retail hardware (renders correctly).

## :backhand_index_pointing_right: Playback Issues

N/A — not a playback issue.

## :backhand_index_pointing_right: Additional Context

The two devices differ in architecture as well as OS release — the VVD is

aarch64, our retail device is armv7l — and we have no aarch64 retail hardware to

isolate that variable. We believe OS release is the relevant one, since the

failure is in autolink resolution rather than anything architecture-specific,

but please confirm on an aarch64 retail device.

The malformed RNSVG registry entry is long-standing and we already work around

the svg_2 / svg_3 publicName collision in our build (see 4.a). This report is

specifically about the bundled VVD image being two OS releases behind retail,

which is what makes that collision fatal in the simulator but not on device.

Hi @Phi_Huynh,

Thanks for the exceptionally detailed report - you’ve done most of the diagnostic work for us, and your analysis holds up.

@amazon-devices/react-native-svg is system-deployed and resolved through OS autolinking at runtime - it isn’t bundled in your app ( react-native-svg - Amazon Vega Docs ). So the per-component initializer lookups (RNSVGGroup, RNSVGPath, RNSVGRect, etc.) depend on the OS image’s autolink resolver, which is consistent with everything you found:

  • Your RNSVG → RNSVGStarz postinstall rename fixes library resolution but not the per-component OS-first lookup (the component names are fixed by the JS package and can’t avoid it).
  • You ruled out lazy-autolink timing by moving the link to 1.09 s before first paint - still failed.
  • The malformed duplicate publicName "RNSVG" entry exists on both RELEASE_ID 21 and 23, yet SVG binds on 23 and fails on 21 - which points to a resolver behavior difference between the two OS releases rather than the metadata entry alone.

The VVD in SDK 0.24.x ships OS 1.2 / RELEASE_ID 21, while your retail Fire TV is on RELEASE_ID 23. A gap between the VVD and retail OS is expected in general, and our guidance is to test on physical hardware for the most accurate results ( Notice: Virtual Device tests must be run on the latest SDK ). In this case the gap appears large enough that the behavior you’re seeing shows up in the simulator but not on retail.

A couple of things to help us confirm this

  1. Your post references an attached full log and autolink-metadata.json, but they don’t appear to have uploaded - could you re-attach them?
  2. You noted the VVD is aarch64 and your retail device is armv7l. We agree OS release is the likely variable since the failure is in autolink resolution, but if you have access to any aarch64 retail device, confirming SVG binds there would rule architecture out entirely.

Our team is investigating this issue and will provide an update as soon as we have more information.

In the meantime

Your workaround is the right one: verify SVG-backed screens (the login QR code) on physical retail hardware on RELEASE_ID 23+. Since retail is unaffected, this isn’t a shipping blocker, and there’s no app-side fix available given the OS-first component lookup.

Thanks for helping us improve the Vega platform.

Warm Regards,
Aishwarya