Amazon Developer

as

Settings
Sign out
Notifications
Alexa
Amazon Appstore
Ring
AWS
Documentation
Support
Contact Us
My Cases
Devices
Build
Test
Publish
Connect
Documentation
Skip to main content
App Porting is an AI-assisted workflow that migrates your existing Fire OS app to a Vega app. It uses Amazon Devices Builder Tools for AI to analyze your source code, generate a migration plan, and produce a working Vega app. Use it when you want to bring an existing Fire OS app to Vega without doing a manual, screen-by-screen rewrite. This page explains what App Porting supports, how it works, and how to run it.

What App Porting does

App Porting automates the conversion of Fire OS apps to Vega apps. It handles four migration paths. You don’t need to determine the app type yourself. App Porting inspects your project structure, detects which supported type it is, and follows the matching path. You can name your app type in your prompt to speed up detection, but App Porting still validates it against your project structure. If it isn’t sure, it asks you before continuing.

How it works

App Porting runs through six phases.
  • Phase 1: Validation - App Porting detects your app type, collects metadata (package name and app name), and validates the project structure.
  • Phase 2: Planning - App Porting scans your source code file by file, maps Fire OS APIs and patterns to their Vega equivalents, and generates a migration guide.
  • Phase 3: Execution - App Porting scaffolds a Vega project from the appropriate template and applies the migration guide to produce your app’s code.
  • Phase 4: Build and verification - App Porting builds the Vega app, runs migration validation tests, installs it on a connected device, and launches it.
  • Phase 5: Guided AI review - App Porting opens an interactive session where you test the app on-device and report issues for the AI agent to diagnose and fix.
  • Phase 6: Performance comparison (optional) - App Porting benchmarks app launch time, UI fluidity, and memory usage against guideline thresholds or your original Fire OS app.
Throughout the process, App Porting documents anything it can’t migrate automatically in a NextSteps.md file in your generated project.

Prerequisites

Before you start App Porting, make sure you have the following.
  • Amazon Devices Builder Tools installed and configured for your AI agent.
  • Vega SDK v0.22 or later. See Install the Vega SDK.
  • A Vega device for Phase 4 onward. If no physical device is connected, App Porting starts a Vega Virtual Device (VVD) so the flow isn’t blocked. A physical device is recommended, because screenshot support and performance tooling analysis aren’t available on a VVD.
  • Your Fire OS app source code, or a web URL to wrap.
  • A Fire OS device (optional, enables a Fire OS vs. Vega performance comparison in Phase 6).

Start App Porting

To start App Porting, use one of the following prompts in your AI agent’s chat.
To be more specific about your app type, use one of the following prompts.
The agent asks what you want to convert and where to create the output. Provide one of the following.
  • A path to your Fire OS app source code, which lets the agent auto-detect the app type.
  • A web URL, which the agent uses to create a Vega WebView app that wraps the URL.
The agent then runs through the six phases. You interact during Phase 5 (guided review) to verify functionality and report issues.

Supported migration paths

App Porting supports the following migration paths.

Fire OS WebView app to Vega WebView app

App Porting converts a WebView-based (HTML5 hybrid) app, where the UI runs as web content inside a WebView, into a Vega WebView app. Detection looks for a JavaScript-to-native bridge, a bundled web app that gets loaded, or a <WebView> as the main screen surface. An app that uses a WebView on only a screen or two counts as native, not WebView. The agent extracts the loaded URL, settings, and JavaScript interfaces from your source code.

Web URL to Vega WebView app

App Porting creates a new Vega WebView app that loads a specified URL. You don’t need existing source code. You can also point to a reference codebase (your existing Fire OS app or non-Fire OS wrapper) so the agent scans it for integration details such as deep links, authentication, or ad SDKs.

Fire OS React Native app to React Native for Vega app

App Porting converts a React Native app built for Fire OS (including Expo-based TV apps) into a React Native for Vega app. The agent maps your React Native components and third-party libraries to their Vega equivalents.

Fire OS native app (Java or Kotlin) to React Native for Vega app

App Porting converts a native Android app (Activities, Fragments, and ViewModels) into a React Native for Vega app. This path is a full rewrite from Java or Kotlin to React Native, so it requires the most manual review after generation. The agent maps Android UI components and APIs to React Native equivalents and documents any APIs without Vega equivalents in NextSteps.md.

Understand the output

After App Porting completes, your generated Vega app directory contains the following.
  • App source code. A buildable Vega project based on the appropriate template.
  • migration_guide.md. The plan the agent writes during Phase 2, before it generates any code. It maps every screen, feature, and asset in your original app to its Vega equivalent. The app is built from this file, so anything missing here is missing in the app. Review it after Phase 2 (Plan) and before Phase 3 (Execute) to catch gaps early.
  • NextSteps.md. A file that documents gaps that need manual attention, including:
    • APIs or native modules without Vega equivalents.
    • Build errors encountered during Phase 4.
    • Migration validation test results.
    • Performance baseline or regression notes (if you opted into Phase 6).
    • A testing checklist covering all migrated integrations.
Always review NextSteps.md after the workflow completes.

Limitations

App Porting is in Beta and has the following limitations.
  • Custom native modules. App Porting supports custom Turbo Modules. It flags only the native modules it can’t confidently map, or that have no Vega equivalent, in NextSteps.md for manual work.
  • Unsupported third-party libraries. Libraries whose native code has no Vega equivalent can’t be migrated automatically. The workflow checks your dependencies and flags anything unsupported for you to handle manually.
  • Complex custom views. Custom View subclasses that draw with Canvas (custom widgets, charts, drawing or game surfaces) have no direct React Native equivalent and are flagged for manual implementation. Standard layouts, widgets, and lists are converted automatically.
  • Fire OS and Android APIs. Deep integrations with Fire OS or Android APIs outside what the knowledge base covers are flagged for manual resolution.
  • Code quality. Generated code provides a functional starting point but might not match production coding standards. Plan for a code review pass.

Troubleshooting

For more troubleshooting, see App migration workflows don’t produce expected results. Once NextSteps.md has no remaining blocking items, your Vega app is ready for further testing and certification.
Last modified on September 30, 2026