Android Upgrade Guide

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

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

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

Before 3.0.0 the game listed every VNGGames SDK third-party dependency and every extra Maven repository by hand. 3.0.0 ships a Gradle plugin that reads pass-services.json and wires those dependencies and repositories up for you, so the hand-written block is now duplicated and can drift out of sync with the SDK.

3.0.0 之前，遊戲必須自行列出 VNGGames SDK 的每個第三方相依套件與額外的 Maven repository。3.0.0 改為隨附一個 Gradle plugin，它會讀取 pass-services.json 並為你接上這些相依套件與 repository，因此手寫的區塊變成重複設定，且可能與 SDK 不同步。

3.0.0 之前，游戏必须自行列出 VNGGames SDK 的每个第三方依赖与额外的 Maven 仓库。3.0.0 改为随附一个 Gradle plugin，它会读取 pass-services.json 并为你接上这些依赖与仓库，因此手写的区块变成重复配置，且可能与 SDK 不同步。

1. Apply the PassPlugin Gradle plugin in your app-level build.gradle.
2. Delete the hand-written VNGGames SDK third-party dependencies from your app-level build.gradle.
3. Delete the extra SDK Maven repositories from your project-level build.gradle.
4. Copy the pass-services.json you were given into your app module.

1. 在 app 層級的 build.gradle 套用 PassPlugin Gradle plugin。
2. 從 app 層級的 build.gradle 刪除手寫的 VNGGames SDK 第三方相依套件。
3. 從專案層級的 build.gradle 刪除額外的 SDK Maven repository。
4. 把你收到的 pass-services.json 複製到 app 模組中。

1. 在 app 层级的 build.gradle 应用 PassPlugin Gradle plugin。
2. 从 app 层级的 build.gradle 删除手写的 VNGGames SDK 第三方依赖。
3. 从工程层级的 build.gradle 删除额外的 SDK Maven 仓库。
4. 把你收到的 pass-services.json 复制到 app 模块中。

Without the plugin the SDK’s dependencies are never added, so the build fails to resolve the VNGGames SDK classes. Leaving the old hand-written block in place pins third-party versions the SDK no longer expects.

未套用 plugin 時，SDK 的相依套件不會被加入，建置將無法解析 VNGGames SDK 的類別。若保留舊的手寫區塊，則會把第三方版本鎖在 SDK 已不再預期的版本上。

未应用 plugin 时，SDK 的依赖不会被加入，构建将无法解析 VNGGames SDK 的类。若保留旧的手写区块，则会把第三方版本锁在 SDK 已不再预期的版本上。

The SDK library now declares minSdkVersion 21 (was 18), so the game’s own minimum must be at least as high before the manifests can merge.

SDK library 現在宣告 minSdkVersion 21（原為 18），因此遊戲自身的最低版本必須不低於此值，manifest 才能合併成功。

SDK library 现在声明 minSdkVersion 21（原为 18），因此游戏自身的最低版本必须不低于此值，manifest 才能合并成功。

Raise minSdkVersion to 21 or higher in your app-level build.gradle before upgrading to 3.0.0.

升級到 3.0.0 前，將 app 層級 build.gradle 的 minSdkVersion 提升至 21 或以上。

升级到 3.0.0 前，将 app 层级 build.gradle 的 minSdkVersion 提升至 21 或以上。

An app still declaring API 18, 19, or 20 fails the manifest merge against the SDK library and does not build. Android 4.4 and older are no longer supported.

仍宣告 API 18、19 或 20 的 App 會在與 SDK library 合併 manifest 時失敗，無法建置。Android 4.4 及更舊版本不再受支援。

仍声明 API 18、19 或 20 的 App 会在与 SDK library 合并 manifest 时失败，无法构建。Android 4.4 及更旧版本不再受支持。

3.0.0 opens up the device and region values the SDK already resolves, so the game can read the same device id, country code, and SDK language the SDK reports instead of computing its own. Each getter blocks the calling thread until the value is ready.

3.0.0 開放 SDK 本來就已解析的裝置與地區資訊，讓遊戲可以讀取與 SDK 回報一致的 device id、國家代碼與 SDK 語言，不必自行推算。每個取值方法都會阻塞呼叫端執行緒，直到取得值為止。

3.0.0 开放 SDK 本来就已解析的设备与地区信息，让游戏可以读取与 SDK 上报一致的 device id、国家代码与 SDK 语言，不必自行推算。每个取值方法都会阻塞调用线程，直到取得值为止。

1. Read the SDK’s device id, country code, and language through these getters instead of your own copies.
2. Call them from a background thread, never from the main thread.

1. 改用這些方法讀取 SDK 的 device id、國家代碼與語言，不要再自行維護副本。
2. 請在背景執行緒呼叫，切勿在主執行緒呼叫。

1. 改用这些方法读取 SDK 的 device id、国家代码与语言，不要再自行维护副本。
2. 请在后台线程调用，切勿在主线程调用。

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.

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

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

3.0.0 adds the four conversion-rate events for the pre-login download funnel, so the loading stage of the game reports through the SDK instead of only through the game’s own pipeline.

3.0.0 新增登入前下載漏斗的四個轉換率事件，讓遊戲載入階段可透過 SDK 回報，而不再只依賴遊戲自己的管線。

3.0.0 新增登录前下载漏斗的四个转化率事件，让游戏加载阶段可通过 SDK 上报，而不再只依赖游戏自己的管线。

1. Report the start and the end of the CDN download with the two cdnDownload calls.
2. Report the start and the end of resource extraction with the two resourceExtract calls.

1. 以兩個 cdnDownload 方法回報 CDN 下載的開始與結束。
2. 以兩個 resourceExtract 方法回報資源解壓縮的開始與結束。

1. 以两个 cdnDownload 方法上报 CDN 下载的开始与结束。
2. 以两个 resourceExtract 方法上报资源解压的开始与结束。

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.

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

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

3.1.0 adds CleverTap analytics, available once CleverTap is enabled for your game in its SDK configuration.

3.1.0 加入 CleverTap 分析。只要在遊戲的 SDK 設定中啟用 CleverTap 即可使用。

3.1.0 加入 CleverTap 分析。只要在游戏的 SDK 配置中启用 CleverTap 即可使用。

Record custom CleverTap events with this call once CleverTap is enabled for the game.

在遊戲已啟用 CleverTap 後，以此方法記錄自訂 CleverTap 事件。

在游戏已启用 CleverTap 后，以此方法记录自定义 CleverTap 事件。

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 tapped button’s payload map is delivered to the listener you register, so the game can act on a CleverTap in-app message. Nothing reaches the game until the listener is registered.

被點擊按鈕的 payload map 會傳給你註冊的監聽器，讓遊戲可以回應 CleverTap 應用內訊息。未註冊監聽器前，遊戲不會收到任何內容。

被点击按钮的 payload map 会传给你注册的监听器，让游戏可以响应 CleverTap 应用内消息。未注册监听器前，游戏不会收到任何内容。

Register a CleverTapInAppNotificationButtonListener through PASS.setCleverTapInAppNotificationButtonListener so your callback runs when a CleverTap in-app notification button is tapped.

透過 PASS.setCleverTapInAppNotificationButtonListener 註冊 CleverTapInAppNotificationButtonListener，使用者點擊 CleverTap 應用內通知按鈕時即會執行你的回呼。

通过 PASS.setCleverTapInAppNotificationButtonListener 注册 CleverTapInAppNotificationButtonListener，用户点击 CleverTap 应用内通知按钮时即会执行你的回调。

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.

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

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

For privacy compliance the SDK manifest drops READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, and READ_MEDIA_AUDIO, so those permissions no longer reach your app through manifest merging. Google Play flags apps that request them without a declared use.

為符合隱私合規，SDK manifest 移除了 READ_MEDIA_IMAGES、READ_MEDIA_VIDEO 與 READ_MEDIA_AUDIO，這些權限不再透過 manifest 合併進入你的 App。Google Play 會對未宣告用途卻申請這些權限的 App 提出警示。

为符合隐私合规，SDK manifest 移除了 READ_MEDIA_IMAGES、READ_MEDIA_VIDEO 与 READ_MEDIA_AUDIO，这些权限不再通过 manifest 合并进入你的 App。Google Play 会对未声明用途却申请这些权限的 App 提出警示。

1. Build the app and open the merged manifest to see which permissions your APK still declares.
2. Declare READ_MEDIA_IMAGES and READ_MEDIA_VIDEO in your own manifest when your game reads device photos or videos.

1. 建置 App 並開啟合併後的 manifest，確認 APK 目前仍宣告哪些權限。
2. 若你的遊戲會讀取裝置上的相片或影片，請在自己的 manifest 中宣告 READ_MEDIA_IMAGES 與 READ_MEDIA_VIDEO。

1. 构建 App 并打开合并后的 manifest，确认 APK 目前仍声明哪些权限。
2. 若你的游戏会读取设备上的照片或视频，请在自己的 manifest 中声明 READ_MEDIA_IMAGES 与 READ_MEDIA_VIDEO。

A game that inherited these permissions from the SDK manifest loses them after the upgrade. The build still succeeds, but media reads that used to work now fail at runtime with a SecurityException on Android 13 and newer.

原本從 SDK manifest 繼承這些權限的遊戲，升級後將不再擁有它們。建置仍會成功，但在 Android 13 以上，原本可用的媒體讀取會在執行期以 SecurityException 失敗。

原本从 SDK manifest 继承这些权限的游戏，升级后将不再拥有它们。构建仍会成功，但在 Android 13 及以上，原本可用的媒体读取会在运行期以 SecurityException 失败。

3.3.0 adds a dedicated Quick Login entry point, separate from the standard showLogin flow. It takes the same LoginListener every other login entry point takes.

3.3.0 新增獨立於標準 showLogin 流程的專用快速登入進入點。它接收與其他登入進入點相同的 LoginListener。

3.3.0 新增独立于标准 showLogin 流程的专用快速登录入口。它接收与其他登录入口相同的 LoginListener。

1. Call PASS.quickLogin with a LoginListener to launch the Quick Login flow.
2. Read the UserInfo from onSuccess.

1. 以 LoginListener 呼叫 PASS.quickLogin 來啟動快速登入流程。
2. 從 onSuccess 取得 UserInfo。

1. 以 LoginListener 调用 PASS.quickLogin 来启动快速登录流程。
2. 从 onSuccess 取得 UserInfo。

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.

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

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

3.3.0 adds account management (bind, switch) through a dedicated listener rather than the shared LoginListener. Unlike iOS and Unity, Android has no manage-account action enum: which callback fires IS the outcome.

3.3.0 新增帳號管理（綁定、切換），透過專屬監聽器而非共用的 LoginListener 回傳結果。與 iOS 和 Unity 不同，Android 沒有帳號管理動作列舉：觸發哪個回呼本身就是結果。

3.3.0 新增账号管理（绑定、切换），通过专属监听器而非共用的 LoginListener 返回结果。与 iOS 和 Unity 不同，Android 没有账号管理动作枚举：触发哪个回调本身就是结果。

1. Call PASS.manageAccount with a ManageAccountListener to present account management.
2. Refresh your session from the UserInfo delivered by onBoundAccountSuccess and onSwitchAccountSuccess.
3. Handle onClose for the case where the player dismisses the screen without changing anything.

1. 以 ManageAccountListener 呼叫 PASS.manageAccount 來顯示帳號管理介面。
2. 依 onBoundAccountSuccess 與 onSwitchAccountSuccess 傳回的 UserInfo 更新你的工作階段。
3. 處理 onClose，以因應玩家未做任何變更就關閉畫面的情況。

1. 以 ManageAccountListener 调用 PASS.manageAccount 来显示账号管理界面。
2. 根据 onBoundAccountSuccess 与 onSwitchAccountSuccess 返回的 UserInfo 更新你的会话。
3. 处理 onClose，以应对玩家未做任何更改就关闭界面的情况。

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.

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

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

A successful login always produces a user, so the callback parameter is now non-null. Every login entry point that takes a LoginListener is affected, including showLogin, autoLogin, directLogin, and the new Quick Login calls.

登入成功必定會產生使用者，因此回呼參數改為非 null。所有接收 LoginListener 的登入進入點都受影響，包含 showLogin、autoLogin、directLogin 以及新的快速登入方法。

登录成功必定会产生用户，因此回调参数改为非 null。所有接收 LoginListener 的登录入口都受影响，包含 showLogin、autoLogin、directLogin 以及新的快速登录方法。

1. Drop the ? from the userInfo parameter in every Kotlin LoginListener.onSuccess override.
2. Remove the now-dead null checks and null-safe calls around that parameter.

1. 移除所有 Kotlin LoginListener.onSuccess 覆寫中 userInfo 參數的 ?。
2. 刪除該參數周圍已無作用的 null 檢查與 null-safe 呼叫。

1. 移除所有 Kotlin LoginListener.onSuccess 重写中 userInfo 参数的 ?。
2. 删除该参数周围已无作用的 null 检查与 null-safe 调用。

See the usage and full signature in the Integration guide:

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

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

A Kotlin override that still declares the parameter as nullable no longer overrides anything and the module fails to compile. Java implementations keep building unchanged.

仍將參數宣告為可為 null 的 Kotlin 覆寫將不再覆寫任何方法，模組無法編譯。Java 實作則不受影響，仍可正常建置。

仍将参数声明为可为 null 的 Kotlin 重写将不再重写任何方法，模块无法编译。Java 实现则不受影响，仍可正常构建。

3.3.0 integrates the ThinkingData analytics platform. Its identifiers are read from the game configuration, and the new call binds the current role so every later event carries role context.

3.3.0 整合 ThinkingData 分析平台。其識別資訊由遊戲設定讀取，新方法用於綁定目前角色，讓後續事件都帶有角色情境。

3.3.0 集成 ThinkingData 分析平台。其标识信息从游戏配置读取，新方法用于绑定当前角色，让后续事件都带有角色上下文。

Bind the current role right after login with PASS.setRole.

登入後立即以 PASS.setRole 綁定目前角色。

登录后立即以 PASS.setRole 绑定当前角色。

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.

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

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

3.3.0 adds a public entry point on PASS for ThinkingData custom events, alongside the existing per-provider custom-event calls.

3.3.0 在 PASS 上新增用於 ThinkingData 自訂事件的公開進入點，與既有的各平台自訂事件方法並存。

3.3.0 在 PASS 上新增用于 ThinkingData 自定义事件的公开入口，与既有的各提供商自定义事件方法并存。

Send custom ThinkingData events with this call once ThinkingData is enabled for your game.

在遊戲已啟用 ThinkingData 後，以此方法送出自訂 ThinkingData 事件。

在游戏已启用 ThinkingData 后，以此方法发送自定义 ThinkingData 事件。

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.

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

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

3.4.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 on PASS. The old per-provider calls still work in this release, but they are deprecated by the same version.

3.4.0 新增 VGSDKAnalytics，一個型別化的遊戲事件門面。單一呼叫即可將遊戲事件回報給遊戲已設定的所有分析平台，不必再於 PASS 上為每個平台分別接上同一個事件。舊的各平台方法在本版仍可運作，但同一版本已將其標記為棄用。

3.4.0 新增 VGSDKAnalytics，一个类型化的游戏事件门面。单一调用即可将游戏事件上报给游戏已配置的所有分析提供商，不必再在 PASS 上为每个提供商分别接上同一个事件。旧的各提供商方法在本版仍可使用，但同一版本已将其标记为弃用。

Report game events through the typed VGSDKAnalytics static events, which cover the reg, nru, iap, mda, sc, and misc families.

改用 VGSDKAnalytics 的型別化靜態事件回報遊戲事件，涵蓋 reg、nru、iap、mda、sc 與 misc 系列。

改用 VGSDKAnalytics 的类型化静态事件上报游戏事件，涵盖 reg、nru、iap、mda、sc 与 misc 系列。

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.

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

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

Every AppsFlyer, Facebook, Firebase, CleverTap, and ThinkingData event method on PASS, together with the CDN and resource-extraction tracking calls and the role and ad-revenue helpers, is now deprecated in favour of the VGSDKAnalytics equivalent. They still work, and they are scheduled for removal.

PASS 上所有 AppsFlyer、Facebook、Firebase、CleverTap 與 ThinkingData 的事件方法，連同 CDN 與資源解壓縮追蹤方法、角色與廣告收益輔助方法，皆已標記為棄用，改用 VGSDKAnalytics 的對應方法。它們目前仍可運作，並已列入移除計畫。

PASS 上所有 AppsFlyer、Facebook、Firebase、CleverTap 与 ThinkingData 的事件方法，连同 CDN 与资源解压跟踪方法、角色与广告收益辅助方法，均已标记为弃用，改用 VGSDKAnalytics 的对应方法。它们目前仍可使用，并已列入移除计划。

↪ Also changed in 3.6.0, see: One custom-event API for every analytics provider

↪ 於 3.6.0 亦有變更，請參見： 單一自訂事件 API 適用所有分析平台

↪ 于 3.6.0 亦有变更，请参见： 单一自定义事件 API 适用所有提供商

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

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

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

It still works today, but is scheduled for removal. Your build breaks once a later release deletes it.

目前仍可運作，但已列入移除計畫。待日後版本刪除後，你的建置將失敗。

目前仍可运行，但已列入移除计划。待日后版本删除后，你的构建将失败。

3.5.0 introduces the VGSDKMetaAds facade as a second in-app advertising option alongside ironSource. It supports interstitial, rewarded-video, and rewarded-interstitial ads, and the module is only wired up when the game configuration enables Meta Ads.

3.5.0 新增 VGSDKMetaAds 門面，作為 ironSource 之外的第二個應用內廣告選項。支援插頁廣告、獎勵影片與獎勵插頁廣告。只有在遊戲設定啟用 Meta Ads 時才會載入該模組。

3.5.0 新增 VGSDKMetaAds 门面，作为 ironSource 之外的第二个应用内广告选项。支持插页广告、激励视频与激励插页广告。只有在游戏配置启用 Meta Ads 时才会加载该模块。

Show each ad format through VGSDKMetaAds and handle the result on its matching listener.

透過 VGSDKMetaAds 顯示各種廣告格式，並以對應的 listener 處理結果。

通过 VGSDKMetaAds 展示各种广告格式，并以对应的 listener 处理结果。

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.

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

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

3.6.0 adds VGSDKAnalytics.sendCustomEvent, which takes the providers as data (one VGSDKAnalyticsPlatform per provider, each with the prefix you choose). It does not replace miscCustomEvent, which is still supported.

3.6.0 新增 VGSDKAnalytics.sendCustomEvent，改以資料形式指定平台（每個平台一個 VGSDKAnalyticsPlatform，前綴由你決定）。它並未取代 miscCustomEvent，後者仍受支援。

3.6.0 新增 VGSDKAnalytics.sendCustomEvent，改以数据形式指定提供商（每个提供商一个 VGSDKAnalyticsPlatform，前缀由你决定）。它并未取代 miscCustomEvent，后者仍受支持。

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 custom-event calls keep working, but you keep a separate call site for every provider and every event name keeps the SDK’s default prefix instead of the one you choose.

不會有任何中斷，你現有的自訂事件呼叫仍可運作，但你仍需為每個平台維護獨立的呼叫點，且每個事件名稱都會沿用 SDK 的預設前綴，而非你指定的前綴。

不会有任何中断，你现有的自定义事件调用仍可使用，但你仍需为每个提供商维护独立的调用点，且每个事件名称都会沿用 SDK 的默认前缀，而非你指定的前缀。

3.7.0 publishes the SDK library and its Gradle plugin to the VNGGames Nexus Maven repository, so the plugin is resolved as a normal buildscript dependency instead of being included as a local project from the SDK zip. The plugin id changed with the move.

3.7.0 將 SDK library 與其 Gradle plugin 發佈到 VNGGames 的 Nexus Maven repository，因此 plugin 改以一般的 buildscript 相依套件解析，不再從 SDK zip 以本機專案方式引入。plugin id 也隨之更名。

3.7.0 将 SDK library 与其 Gradle plugin 发布到 VNGGames 的 Nexus Maven 仓库，因此 plugin 改以普通的 buildscript 依赖解析，不再从 SDK zip 以本地工程方式引入。plugin id 也随之更名。

1. Add the Nexus Maven repository and the vnggames:vgsdk-service classpath entry to your project-level build.gradle buildscript block.
2. Change the applied plugin id in your app-level build.gradle from PassPlugin to vnggames.vgsdk-service.
3. Delete the bundled plugin project and its includeBuild or buildSrc wiring from settings.gradle.

1. 在專案層級 build.gradle 的 buildscript 區塊加入 Nexus Maven repository 與 vnggames:vgsdk-service classpath 項目。
2. 把 app 層級 build.gradle 套用的 plugin id 由 PassPlugin 改為 vnggames.vgsdk-service。
3. 從 settings.gradle 刪除隨附的 plugin 專案及其 includeBuild 或 buildSrc 設定。

1. 在工程层级 build.gradle 的 buildscript 区块加入 Nexus Maven 仓库与 vnggames:vgsdk-service classpath 条目。
2. 把 app 层级 build.gradle 应用的 plugin id 由 PassPlugin 改为 vnggames.vgsdk-service。
3. 从 settings.gradle 删除随附的 plugin 工程及其 includeBuild 或 buildSrc 配置。

A project still applying PassPlugin fails at configuration time with an unknown-plugin error, so Gradle never syncs and nothing builds.

仍套用 PassPlugin 的專案會在設定階段因找不到該 plugin 而失敗，Gradle 無法同步，任何項目都無法建置。

仍应用 PassPlugin 的工程会在配置阶段因找不到该 plugin 而失败，Gradle 无法同步，任何项目都无法构建。

The SDK library is now compiled with Java 17 source and target compatibility, built with Android Gradle Plugin 8.5.0 on Gradle 8.7, and compiles and targets API level 35. A consuming app must move to the same toolchain floor.

SDK library 現在以 Java 17 的 source 與 target 相容性編譯，使用 Android Gradle Plugin 8.5.0 搭配 Gradle 8.7 建置，並以 API level 35 編譯與作為目標。使用它的 App 必須同步提升到相同的工具鏈下限。

SDK library 现在以 Java 17 的 source 与 target 兼容性编译，使用 Android Gradle Plugin 8.5.0 搭配 Gradle 8.7 构建，并以 API level 35 编译与作为目标。使用它的 App 必须同步提升到相同的工具链下限。

1. Set sourceCompatibility and targetCompatibility to JavaVersion.VERSION_17 in your app-level build.gradle.
2. Raise compileSdk and targetSdkVersion to 35.
3. Upgrade the Android Gradle Plugin to 8.5.0 or later and the Gradle wrapper to 8.7 or later.

1. 在 app 層級 build.gradle 將 sourceCompatibility 與 targetCompatibility 設為 JavaVersion.VERSION_17。
2. 將 compileSdk 與 targetSdkVersion 提升至 35。
3. 將 Android Gradle Plugin 升級至 8.5.0 以上，Gradle wrapper 升級至 8.7 以上。

1. 在 app 层级 build.gradle 将 sourceCompatibility 与 targetCompatibility 设为 JavaVersion.VERSION_17。
2. 将 compileSdk 与 targetSdkVersion 提升至 35。
3. 将 Android Gradle Plugin 升级至 8.5.0 以上，Gradle wrapper 升级至 8.7 以上。

An app still on Java 8 compatibility or Android Gradle Plugin 7 cannot consume the SDK’s class files and the build fails with an unsupported class-file version. Google Play also rejects uploads below the required target API level.

仍使用 Java 8 相容性或 Android Gradle Plugin 7 的 App 無法讀取 SDK 的 class 檔，建置會因不支援的 class 檔版本而失敗。低於所需 target API level 的上傳也會被 Google Play 拒絕。

仍使用 Java 8 兼容性或 Android Gradle Plugin 7 的 App 无法读取 SDK 的 class 文件，构建会因不支持的 class 文件版本而失败。低于所需 target API level 的上传也会被 Google Play 拒绝。

Both methods already took a SocialType, but the parameter was still called loginType. It is now named after the type it accepts, so named-argument call sites have to follow.

這兩個方法本來就接收 SocialType，但參數名稱仍是 loginType。現在參數已依其型別更名，因此使用具名參數的呼叫點必須跟著調整。

这两个方法本来就接收 SocialType，但参数名仍是 loginType。现在参数已按其类型更名，因此使用具名参数的调用点必须跟着调整。

Rename the loginType named argument to socialType in every Kotlin PASS.directLogin and PASS.getProfileSocial call.

將所有 Kotlin PASS.directLogin 與 PASS.getProfileSocial 呼叫中的具名參數 loginType 改為 socialType。

将所有 Kotlin PASS.directLogin 与 PASS.getProfileSocial 调用中的具名参数 loginType 改为 socialType。

See the usage and full signature in the Integration guide:

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

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

A Kotlin call that passes loginType = no longer resolves and the module fails to compile. Positional Kotlin calls and all Java calls are unaffected.

以 loginType = 傳入的 Kotlin 呼叫將無法解析，模組無法編譯。使用位置參數的 Kotlin 呼叫與所有 Java 呼叫都不受影響。

以 loginType = 传入的 Kotlin 调用将无法解析，模块无法编译。使用位置参数的 Kotlin 调用与所有 Java 调用都不受影响。

3.9.0 adds a dedicated Quick Auth facade covering sign-in, play-as-guest, and channel selection behind one VGSDKAuthenticationListener. This is the entry point the Integration guide documents from here on. The older PASS quick-login methods it delegates to are not deprecated and keep working unchanged.

3.9.0 新增專屬的 Quick Auth 門面，以單一 VGSDKAuthenticationListener 涵蓋登入、以訪客身分遊玩與頻道選擇。自此之後，整合指南記載的即是這個進入點。它所委派的舊 PASS 快速登入方法並未棄用，仍可照常運作。

3.9.0 新增专属的 Quick Auth 门面，以单一 VGSDKAuthenticationListener 涵盖登录、以访客身份游玩与渠道选择。自此之后，集成指南记载的即是这个入口。它所委派的旧 PASS 快速登录方法并未弃用，仍可照常使用。

1. Start each Quick Auth flow through VGSDKQuickAuth.
2. Pass a VGSDKAuthenticationListener to receive the signed-in UserInfo or the failure.

1. 透過 VGSDKQuickAuth 啟動各項 Quick Auth 流程。
2. 傳入 VGSDKAuthenticationListener 以接收登入後的 UserInfo 或失敗結果。

1. 通过 VGSDKQuickAuth 启动各项 Quick Auth 流程。
2. 传入 VGSDKAuthenticationListener 以接收登录后的 UserInfo 或失败结果。

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.

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

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

For PII compliance, 3.9.0 stops returning the player’s email address in the user model delivered by the login, quick-login, and account-management callbacks. The field is still there and still compiles, but it no longer carries a value.

為符合 PII 合規，3.9.0 不再於登入、快速登入與帳號管理回呼所傳回的使用者模型中提供玩家的電子郵件。該欄位仍存在、仍可編譯，但不再帶有值。

为符合 PII 合规，3.9.0 不再于登录、快速登录与账号管理回调所返回的用户模型中提供玩家的邮箱。该字段仍存在、仍可编译，但不再带有值。

1. Stop depending on UserInfo.email anywhere in the game.
2. Retrieve the email from your own backend if you still need it.

1. 請勿再於遊戲中的任何位置依賴 UserInfo.email。
2. 若仍需要電子郵件，請改由自家後端取得。

1. 请勿再在游戏中的任何位置依赖 UserInfo.email。
2. 若仍需要邮箱，请改由自家后端获取。

Code that reads UserInfo.email keeps compiling but now receives an empty value for every login type, so account linking, support forms, or receipts keyed on the email silently break.

讀取 UserInfo.email 的程式碼仍可編譯，但現在不論何種登入類型都會取得空值，因此以電子郵件為鍵的帳號綁定、客服表單或收據會悄悄失效。

读取 UserInfo.email 的代码仍可编译，但现在无论何种登录类型都会得到空值，因此以邮箱为键的账号绑定、客服表单或收据会悄悄失效。

The SDK library now declares minSdkVersion 23 (was 21). No public API changed in this release.

SDK library 現在宣告 minSdkVersion 23（原為 21）。本次發佈未變更任何公開 API。

SDK library 现在声明 minSdkVersion 23（原为 21）。本次发布未变更任何公开 API。

Raise minSdkVersion to 23 or higher in your app-level build.gradle before upgrading to 3.10.0.

升級到 3.10.0 前，將 app 層級 build.gradle 的 minSdkVersion 提升至 23 或以上。

升级到 3.10.0 前，将 app 层级 build.gradle 的 minSdkVersion 提升至 23 或以上。

An app still declaring API 21 or 22 fails the manifest merge against the SDK library and does not build. Android 5.x is no longer supported.

仍宣告 API 21 或 22 的 App 會在與 SDK library 合併 manifest 時失敗，無法建置。不再支援 Android 5.x。

仍声明 API 21 或 22 的 App 会在与 SDK library 合并 manifest 时失败，无法构建。不再支持 Android 5.x。

3.11.0 adds an in-app message inbox with a styleable UI. VGSDKAppInboxCleverTapStyle covers the title, tabs, and colours, and the listener you pass receives the tapped message together with the CTA payload.

3.11.0 新增可自訂樣式的應用程式內訊息收件匣。VGSDKAppInboxCleverTapStyle 可設定標題、分頁與顏色，你傳入的監聽器會收到被點擊的訊息與 CTA payload。

3.11.0 新增可自定义样式的应用内消息收件箱。VGSDKAppInboxCleverTapStyle 可设置标题、标签页与颜色，你传入的监听器会收到被点击的消息与 CTA payload。

Open the inbox with VGSDKAppInbox.open, passing a styled VGSDKAppInboxCleverTapProvider and a VGSDKCleverTapInboxListener that handles the tapped item.

使用 VGSDKAppInbox.open 開啟收件匣，傳入已設定樣式的 VGSDKAppInboxCleverTapProvider 與處理點擊項目的 VGSDKCleverTapInboxListener。

使用 VGSDKAppInbox.open 打开收件箱，传入已设置样式的 VGSDKAppInboxCleverTapProvider 与处理点击项目的 VGSDKCleverTapInboxListener。

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.

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

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

3.11.0 adds the VGSDK facade with setGameContext and the VGSDKGameContext(roleId, serverId) model. Engagement campaigns target players by role and server, so they only reach the right audience once the game reports the current context.

3.11.0 新增 VGSDK 門面的 setGameContext 與 VGSDKGameContext(roleId, serverId) 模型。互動活動會依角色與伺服器鎖定玩家，因此只有在遊戲回報目前情境後，才能觸及正確的受眾。

3.11.0 新增 VGSDK 门面的 setGameContext 与 VGSDKGameContext(roleId, serverId) 模型。互动活动会按角色与服务器定位玩家，因此只有在游戏上报当前上下文后，才能触达正确的受众。

Call VGSDK.setGameContext with a VGSDKGameContext once the player has picked a role and server, and again whenever either changes.

在玩家選好角色與伺服器後，以 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.

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

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

The entire GVoice voice-chat surface was removed from PASS in 3.12.0 and should not be used in current or future integrations.

整個 GVoice 語音聊天介面已於 3.12.0 從 PASS 移除，現有與未來的整合都不應再使用。

整个 GVoice 语音聊天接口已于 3.12.0 从 PASS 移除，现有与未来的集成都不应再使用。

1. Remove every GVoice call listed below from your code.
2. Remove your VoiceChatNotify and VoiceMessageNotify implementations and the UI that drove them.

1. 從程式碼移除下列所有 GVoice 呼叫。
2. 移除你的 VoiceChatNotify 與 VoiceMessageNotify 實作，以及驅動它們的 UI。

1. 从代码移除下列所有 GVoice 调用。
2. 移除你的 VoiceChatNotify 与 VoiceMessageNotify 实现，以及驱动它们的 UI。

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

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

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

The AIHelp entry points were removed from PASS in 3.12.0 and should not be used in current or future integrations.

AIHelp 的進入點已於 3.12.0 從 PASS 移除，現有與未來的整合都不應再使用。

AIHelp 的入口已于 3.12.0 从 PASS 移除，现有与未来的集成都不应再使用。

1. Remove every PASS.setAIHelpUser and PASS.showAIHelpConfig call from your code.
2. Remove the AIHelpUserInfo and AIHelpApiConfig values you built for them.

1. 從程式碼移除所有 PASS.setAIHelpUser 與 PASS.showAIHelpConfig 呼叫。
2. 移除你為它們建立的 AIHelpUserInfo 與 AIHelpApiConfig 值。

1. 从代码移除所有 PASS.setAIHelpUser 与 PASS.showAIHelpConfig 调用。
2. 移除你为它们构建的 AIHelpUserInfo 与 AIHelpApiConfig 值。

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

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

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

In 3.15.0 PASS.showCustomerSupport is deprecated and the new VGSDKSupport module takes over. It carries the player’s in-game journey through VGSDKSupportInfo and reports back through a listener with separate action, closed, and error callbacks.

3.15.0 將 PASS.showCustomerSupport 標記為棄用，改由新的 VGSDKSupport 模組接手。它以 VGSDKSupportInfo 帶入玩家的遊戲歷程，並透過具備 action、closed 與 error 三種回呼的 listener 回報結果。

3.15.0 将 PASS.showCustomerSupport 标记为弃用，改由新的 VGSDKSupport 模块接手。它以 VGSDKSupportInfo 带入玩家的游戏历程，并通过具备 action、closed 与 error 三种回调的 listener 回报结果。

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

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

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

See the usage and full signature in the Integration guide:

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

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

PASS.showCustomerSupport still works today, but it is deprecated and scheduled for removal. Your build breaks once a later release deletes it, and you keep the old two-callback contract instead of the richer listener.

PASS.showCustomerSupport 目前仍可運作，但已棄用並列入移除計畫。待日後版本刪除後你的建置將失敗，而且你仍停留在舊的雙回呼契約，而非功能更完整的 listener。

PASS.showCustomerSupport 目前仍可使用，但已弃用并列入移除计划。待日后版本删除后你的构建将失败，而且你仍停留在旧的双回调约定，而非功能更完整的 listener。

3.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 never delivered to the game.

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

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

1. Register a VGSDKInAppMessageDeepLinkListener with VGSDKAppInbox.setInAppMessageDeepLinkListener.
2. Route the deep link your onDeepLink callback receives to the matching in-game destination.

1. 以 VGSDKAppInbox.setInAppMessageDeepLinkListener 註冊 VGSDKInAppMessageDeepLinkListener。
2. 將 onDeepLink 回呼收到的 deep link 導向對應的遊戲內頁面。

1. 以 VGSDKAppInbox.setInAppMessageDeepLinkListener 注册 VGSDKInAppMessageDeepLinkListener。
2. 将 onDeepLink 回调收到的 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 library now compiles and targets API level 36, and the bundled Google Play Billing Library moves to 8.3.0. A consuming app has to compile against the same API level, so the floor set in 3.8.0 moves from 35 to 36.

SDK library 現在以 API level 36 編譯與作為目標，內建的 Google Play Billing Library 也升級到 8.3.0。使用它的 App 必須以相同的 API level 編譯，因此 3.8.0 設下的下限由 35 提升為 36。

SDK library 现在以 API level 36 编译与作为目标，内置的 Google Play Billing Library 也升级到 8.3.0。使用它的 App 必须以相同的 API level 编译，因此 3.8.0 设下的下限由 35 提升为 36。

1. Raise compileSdk and targetSdkVersion to 36 in your app-level build.gradle.
2. Install the Android 36 SDK platform in Android Studio if you do not have it yet.
3. Re-test your purchase flow, since the bundled Google Play Billing Library moves to 8.3.0.

1. 在 app 層級 build.gradle 將 compileSdk 與 targetSdkVersion 提升至 36。
2. 若尚未安裝，請在 Android Studio 安裝 Android 36 SDK platform。
3. 由於內建的 Google Play Billing Library 升級至 8.3.0，請重新測試你的購買流程。

1. 在 app 层级 build.gradle 将 compileSdk 与 targetSdkVersion 提升至 36。
2. 若尚未安装，请在 Android Studio 安装 Android 36 SDK platform。
3. 由于内置的 Google Play Billing Library 升级至 8.3.0，请重新测试你的购买流程。

An app still compiling against API level 35 cannot resolve the SDK’s manifest and resource requirements, and the build fails. Google Play also rejects uploads below the required target API level.

仍以 API level 35 編譯的 App 無法解析 SDK 的 manifest 與資源需求，建置將失敗。低於所需 target API level 的上傳也會被 Google Play 拒絕。

仍以 API level 35 编译的 App 无法解析 SDK 的 manifest 与资源需求，构建将失败。低于所需 target API level 的上传也会被 Google Play 拒绝。

The ad-revenue call no longer exposes AppsFlyer’s own mediation-network enum. It takes the SDK’s VGSDKAdRevenueMediationNetwork instead, so game code no longer depends on an AppsFlyer type whose package moved. VGSDKAnalytics.miscAdRevenue already took the SDK enum and is unchanged.

廣告收益方法不再直接暴露 AppsFlyer 自有的 mediation network 列舉，改為接收 SDK 的 VGSDKAdRevenueMediationNetwork，讓遊戲程式碼不再相依於已變更套件路徑的 AppsFlyer 型別。VGSDKAnalytics.miscAdRevenue 本來就接收 SDK 列舉，並未變動。

广告收益方法不再直接暴露 AppsFlyer 自有的 mediation network 枚举，改为接收 SDK 的 VGSDKAdRevenueMediationNetwork，让游戏代码不再依赖已变更包路径的 AppsFlyer 类型。VGSDKAnalytics.miscAdRevenue 本来就接收 SDK 枚举，并未变动。

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

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

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

See the usage and full signature in the Integration guide:

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

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

A call still passing the AppsFlyer enum no longer matches the signature and the module fails to compile in both Java and Kotlin.

仍傳入 AppsFlyer 列舉的呼叫將不符合新簽章，Java 與 Kotlin 模組都無法編譯。

仍传入 AppsFlyer 枚举的调用将不符合新签名，Java 与 Kotlin 模块都无法编译。

3.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.

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

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

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

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

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

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 screens where holding back banners and modals is also what you want.
3. Call VGSDKAppInbox.showFloatingButton() as soon as the player reaches a safe screen, 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 screen 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，内容会持续累积到再次调用显示为止，而在隐藏期间就过期的内容将永远不会被看到。