What App Porting does
App Porting automates the conversion of Fire OS apps to Vega apps. It handles four migration paths.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.
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.- 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.
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 inNextSteps.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.
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.mdfor 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
NextSteps.md has no remaining blocking items, your Vega app is ready for further testing and certification.
Related topics
- Get Started with Amazon Devices Builder Tools for AI
- Vega Module Resolver Preset
- Porting Third-Party Libraries to Vega
- Build a New App from a Template
- Troubleshoot Amazon Devices Builder Tools for AI

