Unity Upgrade Guide

See what changed between your current SDK version and the latest, with the exact steps to migrate.

查看你目前的 SDK 版本與最新版本之間的變更，以及確切的遷移步驟。

查看你当前的 SDK 版本与最新版本之间的变更，以及确切的迁移步骤。

1.2.0 renames the embedded Unity package from com.vng.passsdk to com.vnggames.sdk. Importing the new package adds a second folder under Packages/ instead of replacing the old one, so the old folder has to go first.

1.2.0 將內嵌的 Unity 套件由 com.vng.passsdk 更名為 com.vnggames.sdk。匯入新套件會在 Packages/ 下新增另一個資料夾，而不會取代舊的，因此必須先移除舊資料夾。

1.2.0 将内嵌的 Unity 包由 com.vng.passsdk 更名为 com.vnggames.sdk。导入新包会在 Packages/ 下新增另一个文件夹，而不会取代旧的，因此必须先移除旧文件夹。

1. Delete the Packages/com.vng.passsdk folder from your Unity project.
2. Import the new package so the SDK lands at Packages/com.vnggames.sdk.

1. 從 Unity 專案刪除 Packages/com.vng.passsdk 資料夾。
2. 匯入新套件，使 SDK 落在 Packages/com.vnggames.sdk。

1. 从 Unity 工程删除 Packages/com.vng.passsdk 文件夹。
2. 导入新包，使 SDK 落在 Packages/com.vnggames.sdk。

Keeping the old folder leaves two copies of every SDK type under Packages/, and the Unity Editor stops compiling with duplicate-definition errors.

若保留舊資料夾，Packages/ 下會有兩份相同的 SDK 型別，Unity 編輯器將因重複定義錯誤而無法編譯。

若保留旧文件夹，Packages/ 下会有两份相同的 SDK 类型，Unity 编辑器将因重复定义错误而无法编译。

The mediation networks you pass to PassSDK.Instance.AppsFlyerAdRevenue were re-cased, and customMediation became Custom. The method signature itself is unchanged, so only the case names have to move.

傳入 PassSDK.Instance.AppsFlyerAdRevenue 的中介聯播網列舉值調整了大小寫，customMediation 也改為 Custom。方法簽名本身未變，因此只需更新列舉值名稱。

传入 PassSDK.Instance.AppsFlyerAdRevenue 的聚合网络枚举值调整了大小写，customMediation 也改为 Custom。方法签名本身未变，因此只需更新枚举值名称。

↪ Also changed in 1.6.0, see: New unified VGSDKAnalytics event API

↪ 於 1.6.0 亦有變更，請參見： 全新統一的 VGSDKAnalytics 事件 API

↪ 于 1.6.0 亦有变更，请参见： 全新统一的 VGSDKAnalytics 事件 API

Switch each call to the replacement shown in the table above.

將每個呼叫改為上表所示的替代項目。

将每个调用改为上表所示的替代项。

The old API no longer exists, so your project stops compiling until you migrate.

舊 API 已不存在，未完成遷移前你的專案將無法編譯。

旧 API 已不存在，未完成迁移前你的工程将无法编译。

The user model’s login-type string now follows the LoginChannel naming the rest of the SDK already used. The value it carries is unchanged.

使用者模型的登入類型字串改為沿用 SDK 其他地方既有的 LoginChannel 命名，欄位所帶的值並未改變。

用户模型的登录类型字符串改为沿用 SDK 其他地方既有的 LoginChannel 命名，字段所带的值并未改变。

Switch each call to the replacement shown in the table above.

將每個呼叫改為上表所示的替代項目。

将每个调用改为上表所示的替代项。

The old API no longer exists, so your project stops compiling until you migrate.

舊 API 已不存在，未完成遷移前你的專案將無法編譯。

旧 API 已不存在，未完成迁移前你的工程将无法编译。

The Data Platform event name is now a separate, required parameter instead of being carried inside the data dictionary, matching the other per-provider custom-event calls.

Data Platform 事件名稱現在是獨立的必填參數，不再放在資料字典中，與其他平台專屬的自訂事件呼叫一致。

Data Platform 事件名称现在是独立的必填参数，不再放在数据字典中，与其他提供商专属的自定义事件调用一致。

Pass the event name as the new first argument of every PassSDK.Instance.DataPlatformCustomEvent call.

在每個 PassSDK.Instance.DataPlatformCustomEvent 呼叫中，將事件名稱作為新的第一個參數傳入。

在每个 PassSDK.Instance.DataPlatformCustomEvent 调用中，将事件名称作为新的第一个参数传入。

The old API no longer exists, so your project stops compiling until you migrate.

舊 API 已不存在，未完成遷移前你的專案將無法編譯。

旧 API 已不存在，未完成迁移前你的工程将无法编译。

1.3.0 adds CleverTap in-app messaging. The custom extras of the button a player taps reach the game only through the callback you register, so registering it is what makes an in-app message actionable in-game.

1.3.0 新增 CleverTap 應用內訊息。玩家點擊按鈕所帶的 custom extras 只會透過你註冊的回呼傳給遊戲，因此註冊回呼才能讓應用內訊息在遊戲中產生後續動作。

1.3.0 新增 CleverTap 应用内消息。玩家点击按钮所带的 custom extras 只会通过你注册的回调传给游戏，因此注册回调才能让应用内消息在游戏中产生后续动作。

Register a callback with PassSDK.Instance.OnCleverTapInAppButtonClick and route the custom extras it delivers.

以 PassSDK.Instance.OnCleverTapInAppButtonClick 註冊回呼，並依其傳回的 custom extras 在遊戲內導頁。

以 PassSDK.Instance.OnCleverTapInAppButtonClick 注册回调，并依其返回的 custom extras 在游戏内跳转。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

This addition is opt-in. Nothing breaks if you skip it: your existing integration keeps working, you just don’t gain this capability.

此新增功能為選用。略過不會造成任何問題：你現有的整合仍可正常運作，只是不會獲得此功能。

此新增功能为可选。跳过不会造成任何问题：你现有的集成仍可正常运行，只是不会获得此功能。

1.5.0 adds a dedicated Quick Login entry point, separate from the standard ShowFormLogin flow. It signs a returning VGA player in with no interaction.

1.5.0 新增獨立於標準 ShowFormLogin 流程的專用快速登入進入點，讓回訪的 VGA 玩家零互動完成登入。

1.5.0 新增独立于标准 ShowFormLogin 流程的专用快速登录入口，让回访的 VGA 玩家零交互完成登录。

1. Call PassSDK.Instance.QuickLogin to start the VGA Quick Login flow.
2. Read the signed-in PassUserInfo or the error from its result callback.

1. 呼叫 PassSDK.Instance.QuickLogin 以啟動 VGA 快速登入流程。
2. 從其結果回呼取得登入後的 PassUserInfo 或錯誤。

1. 调用 PassSDK.Instance.QuickLogin 以启动 VGA 快速登录流程。
2. 从其结果回调取得登录后的 PassUserInfo 或错误。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

This addition is opt-in. Nothing breaks if you skip it: your existing integration keeps working, you just don’t gain this capability.

此新增功能為選用。略過不會造成任何問題：你現有的整合仍可正常運作，只是不會獲得此功能。

此新增功能为可选。跳过不会造成任何问题：你现有的集成仍可正常运行，只是不会获得此功能。

1.5.0 adds VGA account management (bind, switch, delete, close), surfaced through the new VGSDKManageAccount result and its VGSDKManageAccountAction enum.

1.5.0 新增 VGA 帳號管理（綁定、切換、刪除、關閉），透過新的 VGSDKManageAccount 結果與其 VGSDKManageAccountAction 列舉提供。

1.5.0 新增 VGA 账号管理（绑定、切换、删除、关闭），通过新的 VGSDKManageAccount 结果与其 VGSDKManageAccountAction 枚举提供。

1. Call PassSDK.Instance.ManageAccount to present VGA account management.
2. Branch on the returned VGSDKManageAccountAction and refresh your session from the updated PassUserInfo.

1. 呼叫 PassSDK.Instance.ManageAccount 以顯示 VGA 帳號管理介面。
2. 依回傳的 VGSDKManageAccountAction 分支處理，並以更新後的 PassUserInfo 刷新你的工作階段。

1. 调用 PassSDK.Instance.ManageAccount 以显示 VGA 账号管理界面。
2. 根据返回的 VGSDKManageAccountAction 分支处理，并以更新后的 PassUserInfo 刷新你的会话。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

This addition is opt-in. Nothing breaks if you skip it: your existing integration keeps working, you just don’t gain this capability.

此新增功能為選用。略過不會造成任何問題：你現有的整合仍可正常運作，只是不會獲得此功能。

此新增功能为可选。跳过不会造成任何问题：你现有的集成仍可正常运行，只是不会获得此功能。

The four payment methods left PassSDK for the static VGSDKPayment facade, and the product model was re-typed. Products now arrive as VGSDKPaymentProduct, whose Price is a number and which also carries DisplayPrice and PriceMicros, instead of the string-only PassProductInfo.

四個付款方法已從 PassSDK 移至靜態的 VGSDKPayment 門面，商品模型也重新定型。商品現在以 VGSDKPaymentProduct 回傳，其 Price 為數值，並額外提供 DisplayPrice 與 PriceMicros，取代僅有字串欄位的 PassProductInfo。

四个支付方法已从 PassSDK 移至静态的 VGSDKPayment 门面，商品模型也重新定型。商品现在以 VGSDKPaymentProduct 返回，其 Price 为数值，并额外提供 DisplayPrice 与 PriceMicros，取代仅有字符串字段的 PassProductInfo。

1. Move every payment call from PassSDK.Instance to the static VGSDKPayment facade.
2. Pass a string array of product ids to VGSDKPayment.GetProducts in place of the old list.
3. Read products from VGSDKPaymentProducts.Products as VGSDKPaymentProduct, taking Price as a number rather than a string.

1. 將每個付款呼叫從 PassSDK.Instance 改為靜態的 VGSDKPayment 門面。
2. 改以商品 id 的字串陣列傳入 VGSDKPayment.GetProducts，取代原本的清單。
3. 從 VGSDKPaymentProducts.Products 以 VGSDKPaymentProduct 讀取商品，並將 Price 視為數值而非字串。

1. 将每个支付调用从 PassSDK.Instance 改为静态的 VGSDKPayment 门面。
2. 改以商品 id 的字符串数组传入 VGSDKPayment.GetProducts，取代原本的列表。
3. 从 VGSDKPaymentProducts.Products 以 VGSDKPaymentProduct 读取商品，并将 Price 视为数值而非字符串。

The old API no longer exists, so your project stops compiling until you migrate.

舊 API 已不存在，未完成遷移前你的專案將無法編譯。

旧 API 已不存在，未完成迁移前你的工程将无法编译。

1.6.0 adds VGSDKAnalytics, a typed game-event facade: one call reports a game event to every analytics provider your game has configured, instead of wiring the same event up per provider. It covers the conversion-rate, role-config and ad-revenue calls listed below, which keep working but are no longer the way to report those events.

1.6.0 新增 VGSDKAnalytics，一個型別化的遊戲事件門面：單一呼叫即可將遊戲事件回報給遊戲已設定的所有分析平台，不必再為每個平台分別接上同一個事件。它涵蓋下表所列的轉換率、角色設定與廣告收益呼叫。這些舊呼叫仍可運作，但已不再是回報這些事件的方式。

1.6.0 新增 VGSDKAnalytics，一个类型化的游戏事件门面：单一调用即可将游戏事件上报给游戏已配置的所有分析提供商，不必再为每个提供商分别接上同一个事件。它涵盖下表所列的转化率、角色配置与广告收入调用。这些旧调用仍可使用，但已不再是上报这些事件的方式。

Switch each call to the replacement shown in the table above.

將每個呼叫改為上表所示的替代項目。

将每个调用改为上表所示的替代项。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

Nothing breaks and your existing PassSDK.Instance analytics calls keep working, but you keep a separate call site per provider and your game events never reach the other providers VGSDKAnalytics fans them out to.

不會有任何中斷，你現有的 PassSDK.Instance 分析呼叫仍可運作，但你仍須為每個平台維護獨立的呼叫點，且遊戲事件不會送達 VGSDKAnalytics 會一併分發的其他平台。

不会有任何中断，你现有的 PassSDK.Instance 分析调用仍可使用，但你仍须为每个提供商维护独立的调用点，且游戏事件不会送达 VGSDKAnalytics 会一并分发的其他提供商。

1.7.0 adds VGSDKMetaAds alongside IronSource, so a game can run its in-app advertising on either network. It covers interstitial, rewarded-video, and rewarded-interstitial formats, each reporting progress through its own status enum.

1.7.0 在 IronSource 之外新增 VGSDKMetaAds，讓遊戲可選擇任一聯播網投放應用內廣告。支援插頁廣告、獎勵影片與獎勵插頁廣告，各自透過專屬的狀態列舉回報進度。

1.7.0 在 IronSource 之外新增 VGSDKMetaAds，让游戏可选择任一网络投放应用内广告。支持插页广告、激励视频与激励插页广告，各自通过专属的状态枚举回报进度。

1. Show each ad format through the matching VGSDKMetaAds call.
2. Branch on the Status of the listener each call returns to grant or withhold the reward.

1. 透過對應的 VGSDKMetaAds 方法顯示各種廣告格式。
2. 依各呼叫回傳監聽器的 Status 分支處理，決定是否發放獎勵。

1. 通过对应的 VGSDKMetaAds 方法展示各种广告格式。
2. 根据各调用返回监听器的 Status 分支处理，决定是否发放奖励。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

This addition is opt-in. Nothing breaks if you skip it: your existing integration keeps working, you just don’t gain this capability.

此新增功能為選用。略過不會造成任何問題：你現有的整合仍可正常運作，只是不會獲得此功能。

此新增功能为可选。跳过不会造成任何问题：你现有的集成仍可正常运行，只是不会获得此功能。

1.8.0 adds VGSDKAnalytics.SendCustomEvent, which takes the providers as data (a VGSDKAnalyticsPlatform per VGSDKAnalyticsProvider you target) rather than making you pick a different method name per provider, and delivers one call to every provider you list. Each platform also carries its own prefix, so you decide the event-name prefix instead of inheriting a default.

1.8.0 新增 VGSDKAnalytics.SendCustomEvent，改以資料形式指定平台（為每個目標 VGSDKAnalyticsProvider 各建立一個 VGSDKAnalyticsPlatform），不必再依平台選用不同的方法名稱，單一呼叫即可送達你列出的所有平台。每個 platform 也自帶 prefix，因此事件名稱前綴由你決定，而非沿用預設值。

1.8.0 新增 VGSDKAnalytics.SendCustomEvent，改以数据形式指定提供商（为每个目标 VGSDKAnalyticsProvider 各构建一个 VGSDKAnalyticsPlatform），不必再按提供商选用不同的方法名，单一调用即可送达你列出的所有提供商。每个 platform 也自带 prefix，因此事件名称前缀由你决定，而非沿用默认值。

Switch each call to the replacement shown in the table above.

將每個呼叫改為上表所示的替代項目。

将每个调用改为上表所示的替代项。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

Nothing breaks and your existing per-provider custom-event calls keep working, but you keep a separate call site for every provider and you cannot choose the prefix your event names are sent with.

不會有任何中斷，你現有的各平台自訂事件呼叫仍可運作，但你仍須為每個平台維護獨立的呼叫點，且無法自行決定事件名稱送出時所帶的 prefix。

不会有任何中断，你现有的各提供商自定义事件调用仍可使用，但你仍须为每个提供商维护独立的调用点，且无法自行决定事件名称发送时所带的 prefix。

The minimum supported iOS version is now 13.0 (was 12.0), and the SDK stamps that floor onto the iOS project it exports. The public C# API is unchanged in this release.

最低支援的 iOS 版本現為 13.0（原為 12.0），SDK 也會將此下限寫入其匯出的 iOS 專案。本次發佈的公開 C# API 並未變更。

最低支持的 iOS 版本现为 13.0（原为 12.0），SDK 也会将此下限写入其导出的 iOS 工程。本次发布的公开 C# API 并未变更。

Set Target minimum iOS Version to 13.0 or later in Unity Player Settings before you export the iOS project.

在匯出 iOS 專案前，於 Unity Player Settings 將 Target minimum iOS Version 設為 13.0 或以上。

在导出 iOS 工程前，于 Unity Player Settings 将 Target minimum iOS Version 设为 13.0 或以上。

An exported project still targeting iOS 12 mixes a 12.0 app target with 13.0 SDK dependencies and fails to build, and iOS 12 devices are no longer supported.

仍以 iOS 12 為目標的匯出專案，會讓 12.0 的 App target 與 13.0 的 SDK 相依套件並存而無法建置，且不再支援 iOS 12 裝置。

仍以 iOS 12 为目标的导出工程，会让 12.0 的 App target 与 13.0 的 SDK 依赖并存而无法构建，且不再支持 iOS 12 设备。

1.10.0 adds a dedicated Quick Auth facade that splits the entry point into three flows, so a returning player can jump straight in, play as a guest, or pick a login channel first. It replaces nothing. PassSDK.Instance.QuickLogin is unchanged and both generations stay available.

1.10.0 新增專用的 Quick Auth 門面，將進入點拆為三種流程，讓回訪玩家可直接進入遊戲、以訪客身分遊玩，或先選擇登入管道。它不取代任何既有 API：PassSDK.Instance.QuickLogin 未變更，兩代 API 皆持續可用。

1.10.0 新增专用的 Quick Auth 门面，将入口拆为三种流程，让回访玩家可直接进入游戏、以访客身份游玩，或先选择登录渠道。它不取代任何既有 API：PassSDK.Instance.QuickLogin 未变更，两代 API 均持续可用。

1. Start each Quick Auth flow through the matching VGSDKQuickAuth call.
2. Read the signed-in PassUserInfo or the error from its result callback.

1. 透過對應的 VGSDKQuickAuth 方法啟動各項 Quick Auth 流程。
2. 從其結果回呼取得登入後的 PassUserInfo 或錯誤。

1. 通过对应的 VGSDKQuickAuth 方法启动各项 Quick Auth 流程。
2. 从其结果回调取得登录后的 PassUserInfo 或错误。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

This addition is opt-in. Nothing breaks if you skip it: your existing integration keeps working, you just don’t gain this capability.

此新增功能為選用。略過不會造成任何問題：你現有的整合仍可正常運作，只是不會獲得此功能。

此新增功能为可选。跳过不会造成任何问题：你现有的集成仍可正常运行，只是不会获得此功能。

1.11.0 adds an in-app message inbox the game opens on demand, with a styleable UI (VGSDKAppInboxCleverTapStyle covers the title, the tab items, and the colors). Messages a player missed stay reachable there.

1.11.0 新增可由遊戲隨時開啟的應用內訊息收件匣，介面樣式可自訂（VGSDKAppInboxCleverTapStyle 涵蓋標題、分頁項目與顏色），玩家錯過的訊息仍可在此取得。

1.11.0 新增可由游戏随时打开的应用内消息收件箱，界面样式可自定义（VGSDKAppInboxCleverTapStyle 涵盖标题、标签项与颜色），玩家错过的消息仍可在此取得。

1. Open the inbox with VGSDKAppInbox.Open, passing a styled VGSDKAppInboxCleverTapProvider.
2. Handle the tapped item on the VGSDKAppInboxListener the call returns.

1. 以 VGSDKAppInbox.Open 開啟收件匣，並傳入已設定樣式的 VGSDKAppInboxCleverTapProvider。
2. 於呼叫回傳的 VGSDKAppInboxListener 處理被點擊的項目。

1. 以 VGSDKAppInbox.Open 打开收件箱，并传入已设置样式的 VGSDKAppInboxCleverTapProvider。
2. 在调用返回的 VGSDKAppInboxListener 上处理被点击的项目。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

This addition is opt-in. Nothing breaks if you skip it: your existing integration keeps working, you just don’t gain this capability.

此新增功能為選用。略過不會造成任何問題：你現有的整合仍可正常運作，只是不會獲得此功能。

此新增功能为可选。跳过不会造成任何问题：你现有的集成仍可正常运行，只是不会获得此功能。

1.12.0 drops AIHelp from the SDK. Both public entry points were deleted from PassSDK, so any call site that still references them no longer resolves.

1.12.0 自 SDK 移除 AIHelp，兩個公開進入點已從 PassSDK 刪除，任何仍引用它們的呼叫點都將無法解析。

1.12.0 自 SDK 移除 AIHelp，两个公开入口已从 PassSDK 删除，任何仍引用它们的调用点都将无法解析。

1. Remove every PassSDK.Instance.AIHelpShowWithConfig call from your game.
2. Remove every PassSDK.Instance.AIHelpSetUser call from your game.

1. 從遊戲中移除所有 PassSDK.Instance.AIHelpShowWithConfig 呼叫。
2. 從遊戲中移除所有 PassSDK.Instance.AIHelpSetUser 呼叫。

1. 从游戏中移除所有 PassSDK.Instance.AIHelpShowWithConfig 调用。
2. 从游戏中移除所有 PassSDK.Instance.AIHelpSetUser 调用。

The old API no longer exists, so your project stops compiling until you migrate.

舊 API 已不存在，未完成遷移前你的專案將無法編譯。

旧 API 已不存在，未完成迁移前你的工程将无法编译。

1.12.0 adds the VGSDK facade with SetGameContext and the VGSDKGameContext model. Engagement campaigns target players by role and server, so the SDK only knows which player it is talking to once the game hands it that context.

1.12.0 新增 VGSDK 門面的 SetGameContext 與 VGSDKGameContext 模型。互動經營活動以角色與伺服器鎖定玩家，因此只有在遊戲提供此情境後，SDK 才知道目前對象是哪位玩家。

1.12.0 新增 VGSDK 门面的 SetGameContext 与 VGSDKGameContext 模型。互动运营活动以角色与服务器锁定玩家，因此只有在游戏提供该上下文后，SDK 才知道当前对象是哪位玩家。

Call VGSDK.SetGameContext with a VGSDKGameContext once the player has picked a role and a server.

在玩家選好角色與伺服器後，以 VGSDKGameContext 呼叫 VGSDK.SetGameContext。

在玩家选好角色与服务器后，以 VGSDKGameContext 调用 VGSDK.SetGameContext。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

This addition is opt-in. Nothing breaks if you skip it: your existing integration keeps working, you just don’t gain this capability.

此新增功能為選用。略過不會造成任何問題：你現有的整合仍可正常運作，只是不會獲得此功能。

此新增功能为可选。跳过不会造成任何问题：你现有的集成仍可正常运行，只是不会获得此功能。

1.15.0 adds VGSDKSupport, whose callback returns a VGSDKSupportCenterListener carrying a Type and a Data payload instead of the plain string PassSDK.Instance.ShowCustomerSupport returns. That lets the game tell an in-portal action apart from a dismissal, and act on the payload.

1.15.0 新增 VGSDKSupport，其回呼回傳帶有 Type 與 Data 內容的 VGSDKSupportCenterListener，取代 PassSDK.Instance.ShowCustomerSupport 回傳的純字串，讓遊戲能區分 Portal 內的動作與關閉行為，並依內容處理。

1.15.0 新增 VGSDKSupport，其回调返回带有 Type 与 Data 内容的 VGSDKSupportCenterListener，取代 PassSDK.Instance.ShowCustomerSupport 返回的纯字符串，让游戏能区分 Portal 内的动作与关闭行为，并依内容处理。

1. Move every PassSDK.Instance.ShowCustomerSupport call to VGSDKSupport.OpenSupportCenter.
2. Branch on the listener’s Type and read its Data payload instead of parsing the old string result.

1. 將每個 PassSDK.Instance.ShowCustomerSupport 呼叫改為 VGSDKSupport.OpenSupportCenter。
2. 依監聽器的 Type 分支處理並讀取其 Data 內容，取代解析舊有的字串結果。

1. 将每个 PassSDK.Instance.ShowCustomerSupport 调用改为 VGSDKSupport.OpenSupportCenter。
2. 根据监听器的 Type 分支处理并读取其 Data 内容，取代解析旧有的字符串结果。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

Nothing breaks and PassSDK.Instance.ShowCustomerSupport keeps working, but its callback still returns a plain string, so the game cannot tell an in-portal action from a dismissal and never receives the action’s payload.

不會有任何損壞，PassSDK.Instance.ShowCustomerSupport 仍可運作，但其回呼仍只回傳純字串，因此遊戲無法區分 Portal 內的動作與關閉行為，也收不到該動作的內容。

不会有任何损坏，PassSDK.Instance.ShowCustomerSupport 仍可使用，但其回调仍只返回纯字符串，因此游戏无法区分 Portal 内的动作与关闭行为，也收不到该动作的内容。

1.17.0 lets a game ship its own notification sound. There is no API to call: the build post-processor picks up whatever you place in the package’s notification sound folder and wires it into both the iOS and the Android export.

1.17.0 讓遊戲可提供自訂的通知音效。無需呼叫任何 API：建置後處理器會取用你放在套件通知音效資料夾中的檔案，並自動接入 iOS 與 Android 的匯出結果。

1.17.0 让游戏可提供自定义的通知声音。无需调用任何 API：构建后处理器会取用你放在包通知声音文件夹中的文件，并自动接入 iOS 与 Android 的导出结果。

1. Copy your sound file into Packages/com.vnggames.sdk/Editor/ProcessBuild/Resources/Notification/sound/.
2. Export the native project as usual, with no script changes.
3. Reference the sound in your push payload by resource name on Android and by full filename on iOS.

1. 將音效檔案複製到 Packages/com.vnggames.sdk/Editor/ProcessBuild/Resources/Notification/sound/。
2. 照常匯出原生專案，無需修改任何指令碼。
3. 在推播負載中引用該音效，Android 使用資源名稱，iOS 使用完整檔名。

1. 将声音文件复制到 Packages/com.vnggames.sdk/Editor/ProcessBuild/Resources/Notification/sound/。
2. 照常导出原生工程，无需修改任何脚本。
3. 在推送负载中引用该声音，Android 使用资源名，iOS 使用完整文件名。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

This addition is opt-in. Nothing breaks if you skip it: your existing integration keeps working, you just don’t gain this capability.

此新增功能為選用。略過不會造成任何問題：你現有的整合仍可正常運作，只是不會獲得此功能。

此新增功能为可选。跳过不会造成任何问题：你现有的集成仍可正常运行，只是不会获得此功能。

1.17.0 adds the deep-link listener the integrator must register to receive deep links from native in-app messages. Without it, a deep link carried by an in-app message is not delivered to the game.

1.17.0 新增了整合方必須註冊的 deep-link 監聽器，用以接收原生應用內訊息的 deep link。若未註冊，應用內訊息所攜帶的 deep link 不會傳遞給遊戲。

1.17.0 新增了接入方必须注册的 deep-link 监听器，用以接收原生应用内消息的 deep link。若未注册，应用内消息所携带的 deep link 不会传递给游戏。

1. Register a listener with VGSDKAppInbox.SetInAppMessageDeepLinkListener.
2. Route the deep-link string it delivers to the matching screen in your game.

1. 於啟動階段以 VGSDKAppInbox.SetInAppMessageDeepLinkListener 註冊監聽器。
2. 將它傳回的 deep link 字串導向遊戲中對應的畫面。

1. 在启动阶段以 VGSDKAppInbox.SetInAppMessageDeepLinkListener 注册监听器。
2. 将它返回的 deep link 字符串导向游戏中对应的界面。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

This addition is opt-in. Nothing breaks if you skip it: your existing integration keeps working, you just don’t gain this capability.

此新增功能為選用。略過不會造成任何問題：你現有的整合仍可正常運作，只是不會獲得此功能。

此新增功能为可选。跳过不会造成任何问题：你现有的集成仍可正常运行，只是不会获得此功能。

The SDK stamps the compile and target API level onto the Android project it exports, and that floor is now 36 (was 35). The public C# API is unchanged in this release.

SDK 會將 compile 與 target API level 寫入其匯出的 Android 專案，該下限現為 36（原為 35）。本次發佈的公開 C# API 並未變更。

SDK 会将 compile 与 target API level 写入其导出的 Android 工程，该下限现为 36（原为 35）。本次发布的公开 C# API 并未变更。

1. Install Android SDK Platform 36 in the Android SDK your Unity build uses.
2. Re-test your Android build, because the exported launcher module now compiles and targets API 36.

1. 在 Unity 建置所使用的 Android SDK 中安裝 Android SDK Platform 36。
2. 重新測試 Android 建置，因為匯出的 launcher 模組現在會以 API 36 進行 compile 與 target。

1. 在 Unity 构建所使用的 Android SDK 中安装 Android SDK Platform 36。
2. 重新测试 Android 构建，因为导出的 launcher 模块现在会以 API 36 进行 compile 与 target。

A build machine without Android SDK Platform 36 stops in Gradle when it cannot find that compile SDK, and once it builds, your app declares target API 36 to the Play Store.

未安裝 Android SDK Platform 36 的建置機器會在 Gradle 找不到該 compile SDK 時中斷，而建置成功後，你的 App 會向 Play Store 宣告 target API 36。

未安装 Android SDK Platform 36 的构建机器会在 Gradle 找不到该 compile SDK 时中断，而构建成功后，你的 App 会向 Play Store 声明 target API 36。

On builds with managed code stripping enabled, every failure callback used to be dropped before it reached your handler, so a failed call simply never came back. Failures now always arrive, and a native payload that cannot be parsed comes through as an Error with Code -1 and StringCode sdk_malformed_error.

在啟用 managed code stripping 的建置中，所有失敗回呼都會在抵達你的處理程式前被丟棄，因此失敗的呼叫根本不會回來。現在失敗一定會送達，且無法解析的原生內容會以 Code 為 -1、StringCode 為 sdk_malformed_error 的 Error 回傳。

在启用 managed code stripping 的构建中，所有失败回调都会在抵达你的处理程序前被丢弃，因此失败的调用根本不会回来。现在失败一定会送达，且无法解析的原生内容会以 Code 为 -1、StringCode 为 sdk_malformed_error 的 Error 返回。

1. Implement the error branch of every SDK call, because failures that were silently dropped now reach your callback.
2. Treat an Error with Code -1 and StringCode sdk_malformed_error as an unexpected SDK failure, and read Error.Message for the raw payload.
3. Re-test your failure paths on an IL2CPP build with managed stripping enabled.

1. 為每個 SDK 呼叫實作錯誤分支，因為原本被靜默丟棄的失敗現在會送達你的回呼。
2. 將 Code 為 -1、StringCode 為 sdk_malformed_error 的 Error 視為非預期的 SDK 失敗，並從 Error.Message 讀取原始內容。
3. 在啟用 managed stripping 的 IL2CPP 建置上重新測試失敗路徑。

1. 为每个 SDK 调用实现错误分支，因为原本被静默丢弃的失败现在会送达你的回调。
2. 将 Code 为 -1、StringCode 为 sdk_malformed_error 的 Error 视为非预期的 SDK 失败，并从 Error.Message 读取原始内容。
3. 在启用 managed stripping 的 IL2CPP 构建上重新测试失败路径。

If your callbacks only implement the success branch, the failures that now surface (previously the call never came back at all) are ignored, so a failed call produces no reaction in your game.

若你的回呼只實作成功分支，現在會浮現的失敗（先前呼叫根本不會回來）將被忽略，導致呼叫失敗時你的遊戲毫無反應。

若你的回调只实现成功分支，现在会浮现的失败（此前调用根本不会回来）将被忽略，导致调用失败时你的游戏毫无反应。

1.19.0 hands the App Inbox floating button over to the game, so it can be taken off a cutscene or a full-screen shop and put back in the lobby. The first call in either direction takes control for the rest of the session, and the SDK stops showing or hiding the button on its own.

1.19.0 將 App Inbox 浮動按鈕交由遊戲控制，可在過場動畫或全螢幕商店中移除，並在大廳重新顯示。任一方向的第一次呼叫即會取得本次工作階段的控制權，SDK 不再自行顯示或隱藏該按鈕。

1.19.0 将 App Inbox 浮动按钮交由游戏控制，可在过场动画或全屏商店中移除，并在大厅重新显示。任一方向的第一次调用即会取得本次会话的控制权，SDK 不再自行显示或隐藏该按钮。

1. Call VGSDKAppInbox.HideFloatingButton when your game enters a scene the button must stay off.
2. Call VGSDKAppInbox.ShowFloatingButton when the player reaches a scene where it may appear again.
3. Re-issue the call your scene needs after a logout, because the next session starts with the SDK deciding again.
4. Read the Unity console for the outcome of each call, because neither method returns a value.

1. 在遊戲進入不應顯示按鈕的場景時呼叫 VGSDKAppInbox.HideFloatingButton。
2. 在玩家回到允許顯示按鈕的場景時呼叫 VGSDKAppInbox.ShowFloatingButton。
3. 登出後重新發出該場景所需的呼叫，因為下一個工作階段會交回 SDK 決定。
4. 從 Unity console 確認每次呼叫的結果，因為兩個方法都不會回傳值。

1. 在游戏进入不应显示按钮的场景时调用 VGSDKAppInbox.HideFloatingButton。
2. 在玩家回到允许显示按钮的场景时调用 VGSDKAppInbox.ShowFloatingButton。
3. 登出后重新发出该场景所需的调用，因为下一个会话会交回 SDK 决定。
4. 从 Unity console 确认每次调用的结果，因为两个方法都不会返回值。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

Nothing breaks and the App Inbox keeps working, but the SDK alone decides when the floating button is on screen, so it can sit over a cutscene or a full-screen shop with no way for your game to move it out of the way.

不會有任何中斷，App Inbox 仍照常運作，但浮動按鈕何時出現完全由 SDK 決定，因此它可能疊在過場動畫或全螢幕商店上，而遊戲無法將它移開。

不会有任何中断，App Inbox 仍照常运作，但浮动按钮何时出现完全由 SDK 决定，因此它可能叠在过场动画或全屏商店上，而游戏无法将它移开。

The same two App Inbox visibility calls now also decide whether in-app messages may appear, so a hide keeps banners and modals off a match screen with no second API to call. Content that becomes eligible while hidden is kept and released one at a time after the next show call, in its existing priority order.

同樣的兩個 App Inbox 顯示與隱藏呼叫，現在也決定 In-App Message 是否能出現，因此隱藏即可讓橫幅與彈窗不出現在戰鬥畫面，不需要另一個 API。隱藏期間符合條件的內容會被保留，並在下一次顯示呼叫後依原本的優先順序逐一釋出。

同样的两个 App Inbox 显示与隐藏调用，现在也决定 In-App Message 是否能出现，因此隐藏即可让横幅与弹窗不出现在战斗界面，不需要另一个 API。隐藏期间符合条件的内容会被保留，并在下一次显示调用后按原本的优先顺序逐一释出。

1. Review every VGSDKAppInbox.HideFloatingButton call site, because each one now also stops in-app messages from appearing.
2. Keep the hide calls only on scenes where holding back banners and modals is also what you want.
3. Call VGSDKAppInbox.ShowFloatingButton as soon as the player reaches a safe scene, so held content is released one at a time.
4. Re-test your in-app message flow across a hide and show round trip, including content that arrives while hidden.

1. 檢視每一處 VGSDKAppInbox.HideFloatingButton 呼叫，因為現在每一次都會同時讓 In-App Message 不再出現。
2. 只在同時希望暫停橫幅與彈窗的場景保留隱藏呼叫。
3. 玩家一回到安全場景就呼叫 VGSDKAppInbox.ShowFloatingButton，讓保留的內容逐一釋出。
4. 重新測試隱藏與顯示往返的 In-App Message 流程，包含隱藏期間送達的內容。

1. 检视每一处 VGSDKAppInbox.HideFloatingButton 调用，因为现在每一次都会同时让 In-App Message 不再出现。
2. 只在同时希望暂停横幅与弹窗的场景保留隐藏调用。
3. 玩家一回到安全场景就调用 VGSDKAppInbox.ShowFloatingButton，让保留的内容逐一释出。
4. 重新测试隐藏与显示往返的 In-App Message 流程，包含隐藏期间送达的内容。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

Your existing calls keep compiling and the button still hides, but any scene where you hid it purely for layout now also holds back in-app messages, so content piles up until you call show again and anything whose own validity window closes while hidden is never seen.

現有呼叫仍可正常編譯，按鈕也照樣隱藏，但凡是僅為版面而隱藏的場景，現在也會一併暫停 In-App Message，內容會持續累積到再次呼叫顯示為止，而在隱藏期間就過期的內容將永遠不會被看到。

现有调用仍可正常编译，按钮也照样隐藏，但凡是仅为版面而隐藏的场景，现在也会一并暂停 In-App Message，内容会持续累积到再次调用显示为止，而在隐藏期间就过期的内容将永远不会被看到。

On Android, in-app messages now draw as an overlay on the game’s own Activity instead of opening a separate SDK screen, so Unity no longer auto-pauses while a banner or a modal is on screen. iOS already behaved this way, so the two platforms now match.

在 Android 上，In-App Message 現在改以疊層方式繪製在遊戲自己的 Activity 上，不再開啟獨立的 SDK 畫面，因此橫幅或彈窗顯示期間 Unity 不再自動暫停。iOS 原本就是這個行為，兩個平台現已一致。

在 Android 上，In-App Message 现在改以叠层方式绘制在游戏自己的 Activity 上，不再打开独立的 SDK 界面，因此横幅或弹窗显示期间 Unity 不再自动暂停。iOS 原本就是这个行为，两个平台现已一致。

1. Pause your own gameplay on scenes where a banner or a modal must not play over live action, because the SDK no longer stops it for you.
2. Review any OnApplicationPause work you tied to in-app messages, because Unity no longer pauses the player while one is on screen.
3. Re-test timed and real-time gameplay on an Android build with a banner and with a modal on screen, covering animations, timers and input.

1. 在不允許橫幅或彈窗蓋住即時操作的場景，自行暫停遊戲流程，因為 SDK 不再代為停止。
2. 檢視任何綁在 In-App Message 上的 OnApplicationPause 處理，因為訊息顯示期間 Unity 不再暫停播放器。
3. 在 Android 版本上重新測試計時與即時玩法在橫幅與彈窗顯示時的表現，涵蓋動畫、計時器與輸入。

1. 在不允许横幅或弹窗盖住实时操作的场景，自行暂停游戏流程，因为 SDK 不再代为停止。
2. 检视任何绑在 In-App Message 上的 OnApplicationPause 处理，因为消息显示期间 Unity 不再暂停播放器。
3. 在 Android 版本上重新测试计时与实时玩法在横幅与弹窗显示时的表现，涵盖动画、计时器与输入。

Your code keeps compiling, but Android gameplay that used to freeze behind a banner or a modal now keeps running, so timers keep counting, real-time matches keep advancing, and anything you hung off OnApplicationPause never fires while a message is on screen.

程式碼仍可正常編譯，但過去會在橫幅或彈窗後方凍結的 Android 遊戲流程現在會持續執行，因此計時器繼續計算，即時對戰繼續推進，任何掛在 OnApplicationPause 上的處理在訊息顯示期間都不會觸發。

代码仍可正常编译，但过去会在横幅或弹窗后方冻结的 Android 游戏流程现在会持续运行，因此计时器继续计算，实时对战继续推进，任何挂在 OnApplicationPause 上的处理在消息显示期间都不会触发。

On iOS builds, share dialogs now open in the native Facebook app instead of the iOS share sheet, which is what makes them work again on Facebook SDK 18.1.0. Sharing a link now fails with error 9027 when the Facebook app is missing, and Android builds are unchanged.

在 iOS 版本中，分享對話框現在改為在原生 Facebook 應用程式中開啟，不再使用 iOS 分享表單，這正是它們在 Facebook SDK 18.1.0 上恢復運作的原因。當裝置未安裝 Facebook 應用程式時，分享連結現在會回傳錯誤 9027，Android 版本則維持不變。

在 iOS 版本中，分享对话框现在改为在原生 Facebook 应用中打开，不再使用 iOS 分享表单，这正是它们在 Facebook SDK 18.1.0 上恢复运作的原因。当设备未安装 Facebook 应用时，分享链接现在会返回错误 9027，Android 版本则维持不变。

1. Handle error 9027 on your Facebook share callback and tell the player the Facebook app is required.
2. Drop any assumption that sharing falls back to the iOS share sheet, because the dialog now opens only in the Facebook app.
3. Re-test Facebook photo and link sharing on an iOS build with the Facebook app removed.

1. 在 Facebook 分享的回呼中處理錯誤 9027，並告知玩家需要安裝 Facebook 應用程式。
2. 不要再假設分享會退回 iOS 分享表單，因為對話框現在只會在 Facebook 應用程式中開啟。
3. 在已移除 Facebook 應用程式的 iOS 版本上，重新測試 Facebook 相片與連結分享。

1. 在 Facebook 分享的回调中处理错误 9027，并告知玩家需要安装 Facebook 应用。
2. 不要再假设分享会退回 iOS 分享表单，因为对话框现在只会在 Facebook 应用中打开。
3. 在已移除 Facebook 应用的 iOS 版本上，重新测试 Facebook 照片与链接分享。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

Your code keeps compiling and sharing still works for players who have the Facebook app, but an iOS player without it now gets error 9027 where the iOS share sheet used to open, so an unhandled callback leaves the share doing nothing.

程式碼仍可正常編譯，對有安裝 Facebook 應用程式的玩家分享也照常運作，但未安裝的 iOS 玩家現在會在原本開啟 iOS 分享表單的位置收到錯誤 9027，因此未處理的回呼會讓分享毫無反應。

代码仍可正常编译，对已安装 Facebook 应用的玩家分享也照常运作，但未安装的 iOS 玩家现在会在原本打开 iOS 分享表单的位置收到错误 9027，因此未处理的回调会让分享毫无反应。

1.19.2 adds RecoveryAccount = 20 to LoginChannel, so a game that builds its own login UI can send a player to Guest account recovery through the DirectLogin it already calls. Unity forwards the value to the native SDK, and the channel is Legacy only.

1.19.2 於 LoginChannel 新增 RecoveryAccount = 20，因此自行製作登入介面的遊戲可以透過原本就會呼叫的 DirectLogin，將玩家帶往訪客帳號尋回。Unity 只是把這個值轉交給原生 SDK，這個頻道也僅在 Legacy 登入平台上提供。

1.19.2 在 LoginChannel 新增 RecoveryAccount = 20，因此自行制作登录界面的游戏可以通过原本就会调用的 DirectLogin，将玩家带往访客账号寻回。Unity 只是把这个值转交给原生 SDK，这个渠道也仅在 Legacy 登录平台上提供。

1. Call PassSDK.Instance.DirectLogin(LoginChannel.RecoveryAccount, result => …) from your own recovery entry point, on a Legacy game only.
2. Keep the callback you already pass, and read the PassUserInfo it returns as a Guest session, because the SDK maps recovery onto Guest before it reports anything.
3. Handle the cancel-login error your callback already receives, because closing the screen cancels the call, and so do the back action and dismissing the confirmation the SDK shows when the device already holds a Guest account.
4. Handle error 9050 on the same callback. It arrives when the native SDK cannot read the recovery entry in your support configuration.

1. 在你自己的尋回入口呼叫 PassSDK.Instance.DirectLogin(LoginChannel.RecoveryAccount, result => …)，且僅限 Legacy 遊戲。
2. 沿用原本傳入的回呼，並將它回傳的 PassUserInfo 視為 Guest 工作階段，因為 SDK 會先把尋回對應成 Guest 才回報。
3. 處理回呼原本就會收到的取消登入錯誤，因為關閉畫面會取消這次呼叫，返回動作以及關閉裝置上已有訪客帳號時顯示的確認對話框也一樣。
4. 在同一個回呼上處理錯誤 9050。當原生 SDK 無法讀取支援設定中的尋回項目時就會收到它。

1. 在你自己的寻回入口调用 PassSDK.Instance.DirectLogin(LoginChannel.RecoveryAccount, result => …)，且仅限 Legacy 游戏。
2. 沿用原本传入的回调，并将它返回的 PassUserInfo 视为 Guest 会话，因为 SDK 会先把寻回映射成 Guest 才报告。
3. 处理回调原本就会收到的取消登录错误，因为关闭界面会取消这次调用，返回动作以及关闭设备上已有访客账号时显示的确认对话框也一样。
4. 在同一个回调上处理错误 9050。当原生 SDK 无法读取支持配置中的寻回条目时就会收到它。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

Nothing breaks if you skip the channel, and an existing switch over LoginChannel keeps compiling untouched. Adopt it on a VGA game and the native SDK raises a fatal error carrying This feature is available only in Legacy. instead of answering your callback.

略過這個頻道不會造成任何損壞，現有對 LoginChannel 進行的 switch 也能照常編譯。若在 VGA 遊戲上採用，原生 SDK 會引發帶有 This feature is available only in Legacy. 的致命錯誤，而不是回應你的回呼。

跳过这个渠道不会造成任何损坏，现有对 LoginChannel 进行的 switch 也能照常编译。若在 VGA 游戏上采用，原生 SDK 会引发带有 This feature is available only in Legacy. 的致命错误，而不是响应你的回调。

Adds one call that returns the store’s age band for the signed in account, in a single result shape that is identical on every platform. It replaces nothing, and no existing call changes.

新增一個呼叫，回傳商店針對已登入帳號的年齡區間，並以在各平台完全一致的單一結果結構呈現。它沒有取代任何東西，既有的呼叫也都沒有變動。

新增一个调用，返回商店针对已登录账号的年龄区间，并以在各平台完全一致的单一结果结构呈现。它没有取代任何东西，既有的调用也都没有变动。

1. Ask VNGGames to add the AgeAssurance feature key to your build before you ship the call, because without it the native SDK halts your application instead of answering.
2. Add the com.apple.developer.declared-age-range entitlement as a capability on your exported iOS target, and ship the Android build through Google Play, because without either the call answers UNAVAILABLE with DEVICE_NOT_ELIGIBLE on that target.
3. Call VGSDKCompliance.RequestAgeSignals and read access on the result before any other field.
4. Branch on access for its five states, and read reason when you need the cause behind a state.
5. Expect reason DISABLED_BY_CONFIG until the feature is switched on for your game, because it ships off on every platform.
6. Read range only when access is SHARED, because it is absent on every other outcome, and treat both of its bounds as optional.
7. Re-test below iOS 26 on the iOS target, and with the Play Store or Play services missing or out of date on the Android target, which are the conditions that answer UNAVAILABLE with DEVICE_NOT_ELIGIBLE. The Android SDK is already API 23+, so no supported Android build sits below this call’s own OS floor.

1. 在正式推出這個呼叫之前，請向 VNGGames 申請為你的版本加上 AgeAssurance 功能金鑰，否則原生 SDK 會讓應用程式中止，而不是回應你。
2. 請在匯出的 iOS target 上加入 com.apple.developer.declared-age-range entitlement 作為 capability，並透過 Google Play 發佈 Android 版本，否則在該目標上呼叫都會以 DEVICE_NOT_ELIGIBLE 回傳 UNAVAILABLE。
3. 呼叫 VGSDKCompliance.RequestAgeSignals，並在讀取其他欄位之前先讀取結果的 access。
4. 針對 access 的五種狀態分支處理，需要知道狀態背後的原因時再讀取 reason。
5. 在此功能為你的遊戲開啟之前，請預期 reason 會是 DISABLED_BY_CONFIG，因為它在每個平台上都以關閉狀態出貨。
6. 僅在 access 為 SHARED 時讀取 range，因為其他結果都不會帶有它，並且要把它的上下限都當成可能不存在。
7. 請在 iOS 目標上以低於 iOS 26 的裝置重新測試，並在 Android 目標上以缺少或版本過舊的 Play 商店或 Play 服務重新測試，這些才是會以 DEVICE_NOT_ELIGIBLE 回傳 UNAVAILABLE 的情況。Android SDK 本身已是 API 23+，因此沒有任何受支援的 Android 版本會低於這個呼叫自己的 OS 門檻。

1. 在正式推出这个调用之前，请向 VNGGames 申请为你的版本加上 AgeAssurance 功能密钥，否则原生 SDK 会让应用程序中止，而不是响应你。
2. 请在导出的 iOS target 上加入 com.apple.developer.declared-age-range entitlement 作为 capability，并通过 Google Play 发布 Android 版本，否则在该目标上调用都会以 DEVICE_NOT_ELIGIBLE 返回 UNAVAILABLE。
3. 调用 VGSDKCompliance.RequestAgeSignals，并在读取其他字段之前先读取结果的 access。
4. 针对 access 的五种状态分支处理，需要知道状态背后的原因时再读取 reason。
5. 在此功能为你的游戏开启之前，请预期 reason 会是 DISABLED_BY_CONFIG，因为它在每个平台上都以关闭状态发布。
6. 仅在 access 为 SHARED 时读取 range，因为其他结果都不会带有它，并且要把它的上下限都当成可能不存在。
7. 请在 iOS 目标上以低于 iOS 26 的设备重新测试，并在 Android 目标上以缺失或版本过旧的 Play 商店或 Play 服务重新测试，这些才是会以 DEVICE_NOT_ELIGIBLE 返回 UNAVAILABLE 的情况。Android SDK 本身已是 API 23+，因此没有任何受支持的 Android 版本会低于这个调用自己的 OS 门槛。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

Skipping the call breaks nothing and no existing call changes, but your game then has no store backed age band and keeps asking players for a date of birth. Adopt it and the native SDK raises a fatal carrying Age Assurance feature not requested in any build without the AgeAssurance key, and the wrapper converts none of that into a result of its own, so your callback never fires. A build that reads access and ignores reason also cannot tell a player who declined from a device that was never asked.

跳過這個呼叫不會造成任何損壞，既有的呼叫也不會改變，但你的遊戲就沒有來自商店的年齡區間，只能繼續自行向玩家詢問出生日期。若要採用，在任何沒有 AgeAssurance 金鑰的版本上，原生 SDK 會引發帶有 Age Assurance feature not requested 的致命錯誤，wrapper 不會把它轉成自己的結果，你的 callback 因此永遠不會被呼叫。只讀取 access 而忽略 reason 的版本，也無法分辨是玩家拒絕分享，還是裝置根本沒有被詢問。

跳过这个调用不会造成任何损坏，既有的调用也不会改变，但你的游戏就没有来自商店的年龄区间，只能继续自行向玩家询问出生日期。若要采用，在任何没有 AgeAssurance 密钥的版本上，原生 SDK 会引发带有 Age Assurance feature not requested 的致命错误，wrapper 不会把它转成自己的结果，你的回调因此永远不会被调用。只读取 access 而忽略 reason 的版本，也无法分辨是玩家拒绝分享，还是设备根本没有被询问。

Adds a second purchase entry point for a game that declares the item at purchase time instead of registering every item as its own store product. It replaces nothing, and the existing purchase call and the model it takes are unchanged.

為在購買當下宣告商品、而非將每個商品都註冊成獨立商店產品的遊戲，新增第二個購買進入點。它沒有取代任何東西，既有的購買呼叫與它所接受的模型都維持不變。

为在购买当下声明商品、而非将每个商品都注册成独立商店产品的游戏，新增第二个购买入口。它没有取代任何东西，既有的购买调用与它所接受的模型都维持不变。

1. Ask VNGGames to add the AdvancedCommerce feature key to your build, because without it every purchase is refused. Unity refuses it through your callback with a message naming the missing key rather than halting, which is the opposite of what the iOS native call does.
2. Call IsAdvancedCommerceSupported() before you show a shop that sells declared items. On Unity it answers false both below iOS 15 and when the build lacks the AdvancedCommerce key, so it is the one check that covers everything.
3. Build the purchase map with itemId, serverId, amount, currency and genericProductId, and add an optional key only when you have a value for it.
4. Call the Advanced Commerce purchase with it and keep the purchase listener you already pass, because the outcome arrives on that same shape.
5. Handle this flow’s own error codes, because it reuses none of the existing IAP codes.
6. Leave your existing purchase calls exactly as they are, because they still reach the existing flow.
7. Skip this call on an Android build, because Advanced Commerce runs on the iOS target alone.

1. 請向 VNGGames 申請為你的版本加上 AdvancedCommerce 功能金鑰，否則每次購買都會被拒絕。Unity 會透過你的 callback 回報一則指出金鑰缺少的訊息，而不是讓應用程式中止，這和 iOS 原生呼叫的行為正好相反。
2. 在顯示販售宣告式商品的商店之前先呼叫 IsAdvancedCommerceSupported()。在 Unity 上，低於 iOS 15 和版本缺少 AdvancedCommerce 金鑰時它都會回傳 false，因此這一個檢查就涵蓋了所有情況。
3. 建立購買用的 map，帶入 itemId、serverId、amount、currency 與 genericProductId，選填的鍵只在你確實有值時才加入。
4. 以它呼叫 Advanced Commerce 購買，並沿用你原本傳入的購買 listener，因為結果會以同樣的形式回傳。
5. 處理此流程自有的錯誤碼，因為它沒有沿用任何既有的 IAP 錯誤碼。
6. 既有的購買呼叫請原封不動保留，因為它們仍然走既有的流程。
7. 在 Android 版本請略過這個呼叫，因為 Advanced Commerce 僅在 iOS 目標上執行。

1. 请向 VNGGames 申请为你的版本加上 AdvancedCommerce 功能密钥，否则每次购买都会被拒绝。Unity 会通过你的回调报告一条指出密钥缺失的消息，而不是让应用程序中止，这和 iOS 原生调用的行为正好相反。
2. 在显示销售声明式商品的商店之前先调用 IsAdvancedCommerceSupported()。在 Unity 上，低于 iOS 15 和版本缺少 AdvancedCommerce 密钥时它都会返回 false，因此这一个检查就涵盖了所有情况。
3. 构建购买用的 map，带入 itemId、serverId、amount、currency 与 genericProductId，可选的键只在你确实有值时才加入。
4. 以它调用 Advanced Commerce 购买，并沿用你原本传入的购买 listener，因为结果会以同样的形式返回。
5. 处理此流程自有的错误码，因为它没有沿用任何既有的 IAP 错误码。
6. 既有的购买调用请原封不动保留，因为它们仍然走既有的流程。
7. 在 Android 版本请跳过这个调用，因为 Advanced Commerce 仅在 iOS 目标上运行。

See the usage and full signature in the Integration guide:

請在整合指南中查看用法與完整簽名：

请在集成指南中查看用法与完整签名：

Nothing breaks and your existing purchase calls keep working. Unity is the one platform where a missing AdvancedCommerce key is recoverable: the wrapper reads the key itself and answers your callback on its error arm, naming the key, rather than letting the native fatal kill the game. IsAdvancedCommerceSupported() folds the same check in, so a build that cannot purchase can hide its shop instead of finding out from a refusal. On an Android export the call reports code 404 and the device check is always false.

不會有任何損壞，既有的購買呼叫也照常運作。Unity 是唯一能從缺少 AdvancedCommerce 金鑰中恢復的平台：wrapper 會自行讀取金鑰，並透過你的 callback 錯誤分支回報，明確指出缺少的金鑰，而不是讓原生的致命錯誤終止遊戲。IsAdvancedCommerceSupported() 也納入了同樣的檢查，因此無法購買的版本可以先隱藏商店，而不是等到被拒絕才知道。在 Android 匯出版本上，這個呼叫會回報代碼 404，裝置檢查則固定為 false。

不会有任何损坏，既有的购买调用也照常运作。Unity 是唯一能从缺少 AdvancedCommerce 密钥中恢复的平台：wrapper 会自行读取密钥，并通过你的回调错误分支报告，明确指出缺失的密钥，而不是让原生的致命错误终止游戏。IsAdvancedCommerceSupported() 也纳入了同样的检查，因此无法购买的版本可以先隐藏商店，而不是等到被拒绝才知道。在 Android 导出版本上，这个调用会报告代码 404，设备检查则固定为 false。