Amazon Developer

Console

as

Settings
Sign out
Notifications
Alexa
Amazonアプリストア
Ring
AWS
ドキュメント
Support
Contact Us
My Cases

Console

as

開発
設計と開発
公開
リファレンス
サポート
メインコンテンツへスキップ
The [os.version] section declares the range of device OS versions your app supports. Vega validates this section at build time, and the Vega Packaging Tool (VPT) validates it again for packaged apps. The [os.version] section is required. Your build fails if the section is missing. If your app was built with SDK 0.23 or earlier, see Migrate from SDK 0.23 or earlier.
Set target to the newest OS version you build against, which is 2.0 for Vega SDK 2.0. Set min to the oldest OS version you support. For SDK 2.0, set min to 2.0, because all Vega devices in the field run OS 2.0. To also support OS 1.2, set min to 1.2. For help choosing, see Choose min.

​
Fields

The following table describes the fields in the [os.version] section. Both values must be quoted "M.n" strings that name officially minted OS versions. Vega rejects a value that isn’t minted, even when the value is numerically well-formed.

​
Validation rules

Vega applies the following rules to the [os.version] section:
  • Both min and target must be OS versions known to the SDK compatibility manifest.
  • min must be less than or equal to target.
  • In the validation, staged, and packaged manifests that the build generates, every [[needs.module]] entry must be available at min.
  • Your code must guard APIs added after min. The build records the OS versions after min as [[wants.module]] entries in the generated manifests, not in your source manifest.toml. For details, see Guard newer APIs with isPresentOnOS.

​
Example manifest

The [os.version] section sits alongside your other manifest sections. A source manifest.toml that targets OS 2.0 and still supports OS 1.2 looks like the following example.
The [os.version] section is yours to set. At build time, the tooling generates the matching OS version module entries into the validation, staged, and packaged manifests. For the source manifest in the previous example, the generated manifests contain the following entries.
Each OS version module id is the OS version with its dot replaced by an underscore, so 2.0 becomes /com.amazon.vega.os@IVega_2_0. The tooling emits a [[needs.module]] entry for min, and a [[wants.module]] entry for each minted OS version above min, up to and including target. When min and target are both 2.0, the generated manifests have a single [[needs.module]] entry for /com.amazon.vega.os@IVega_2_0 and no [[wants.module]] entry.

​
OS version module entries are tool-owned

The OS version module entries, meaning the [[needs.module]] and [[wants.module]] IDs in the reserved /com.amazon.vega.os@IVega_* family, belong to the tooling. Starting with Vega SDK 2.0, they aren’t kept in your source manifest.toml. The tooling removes any copy it finds there:
  • vega project update-manifest removes them on every run. It also removes versioned @amzn/<pkg>@<version> and @amazon-devices/<pkg>@<version> module IDs. With --dry-run, it reports what it would remove and changes nothing.
  • vega project update removes them when it syncs [os.version].
  • Building an application project removes the reserved-family entries.
Other module entries in your source manifest are preserved. The tooling doesn’t strip the [[needs.module]] and [[wants.module]] entries that you declare for other system modules, such as /com.amazon.kepler.media@IContentLauncher1. For details, see Manifest [needs] Section and Manifest [wants] Section.

​
Upgrade from an earlier SDK

If your project was created with an earlier SDK, its source manifest.toml might contain OS version module entries. The first time you run vega project update-manifest, vega project update, or a build after you upgrade, the tooling deletes those lines from your source-controlled manifest. This diff is expected. Commit it, and don’t restore the entries by hand.

​
Add the [os.version] section

You can add the section in three ways. For a project that has no [os.version] section yet, use one of the first two methods. Both are built for authoring the section. The third method is a convenience during migration, and it’s narrower than it looks. Pass both --os-min and --os-version. install resolves your OS target before it writes anything. On a project that has no [os.version] section and no --os-version value, it fails with Missing OS Version and writes nothing. With both flags, it creates the section, sets min, seeds target, and confirms with 📝 Set [os.version] min = "<v>" in manifest.toml. Three more limits apply to the third method:
  • --os-min takes effect only together with --fix. Neither a bare vega project install --fix nor an install <package> run adds the section.
  • --dry-run previews the change without writing it.
  • When [os.version] already exists, this form writes min only and leaves your target unchanged. A legacy [os] section counts as an existing section for this purpose. To change target, use vega project update-manifest.
vega project install --fix writes only the [os.version] values. It doesn’t add module entries. To validate your manifest’s OS version configuration from the command line, run vega project doctor. doctor checks the [os.version] values. It doesn’t inspect the module entries in your source manifest.
最終更新日 2026年10月30日