Google Play 商店應用程式發布與上架完整指南（從零到正式發布）
本指南詳細且循序漸進地說明如何在 Google Play Console 上從零建立現代 Android 應用程式（特別是 .NET MAUI、MonoGame 或混合架構 C# 專案）、封裝、簽署、排除遭遇的各項關鍵錯誤，並完整完成商店上架流程（建立應用程式、隱私權政策、存取權限、廣告聲明、IARC 年齡分級、資料安全性、封閉測試以及正式公開發布）。
目錄
- 引言與架構準備
- 在 Play Console 中從零建立新應用程式/遊戲（Create App）
- Keystore 產生與建置/簽署自動化
- Play Console 首次上傳 Bundle 與關鍵錯誤排除
- 隱私權政策（Privacy Policy）準備
- 應用程式存取權 / 登入詳細資訊（App Access / Sign-in Details）
- 廣告聲明（Ads Declaration）
- 內容分級（IARC 內容分級問卷）
- 目標目標目標對象與年齡層選擇（Target Audience）
- 應用程式內容資訊主頁（App Content Dashboard）
- 資料安全性表單（Data Safety Form）
- 法律與法規聲明（政府、金融、健康應用程式）
- 商店設定與聯絡資訊（Store Settings）
- 主要商店資訊與視覺素材（Main Store Listing）
- 封閉測試設定與審查（Closed Testing）
- 廣告 ID 聲明（Advertising ID）
- 提交變更以供審查（Final Submission）
- 封閉測試後申請正式發布權限（Apply for Access to Production）
- 最終勝利：獲得正式發布權限（Production Access）批准
- 上架前檢查清單（已完成）
- Arar Games 與我們的遊戲產品
1. 引言與架構準備
在 Google Play 商店發布新應用程式時，必須嚴格遵守 Google 目前的安全與技術政策規範：
- Bundle 格式： 僅接受
.aab（Android App Bundle）格式。APK 檔案無法再用於商店正式發布（但仍可用於本機側載測試）。 - 最低目標 SDK： Google Play 目前要求新發布或更新的應用程式必須至少以 Android API Level 36 (Android 16) 為目標。
- 安全簽署： 應用程式必須使用與 v2/v3 架構相容的 2048 位元 RSA 金鑰進行數位簽署。
2. 在 Play Console 中從零建立新應用程式/遊戲（Create App）
登入 Google Play Console 管理控制台（play.google.com/console）後，在列出所有應用程式的主畫面右上角點選藍色的 "建立應用程式"（Create app） 按鈕，即可展開發布流程。此表單將確立應用程式在控制台中的數位識別碼、套件名稱以及基礎商店分類。
A. 應用程式詳細資料
- 應用程式名稱（App Name）：
- 商店中向使用者顯示的官方正式名稱。
- 上限最多 30 個字元（例如：
YourAppName）。 - 建議： 避免在標題中填塞不必要的關鍵字（keyword stuffing）或誤導/促銷字眼（如 "Best"、"Free"、"#1"）；否則極可能在 Google Play 審查階段遭到拒絕退件。
- 套件名稱（Package Name）：
- 在 Android 生態系中全域唯一識別您應用程式的 Java/Android 套件識別碼（反向網域名稱慣例，例如
com.yourcompany.appname）。 - 上限最多 150 個字元。
- ⚠️ 關鍵規則： 在此畫面建立應用程式並上傳第一個 Bundle 後，套件名稱將永遠無法再做更改！ 它必須與
Platforms/Android/AndroidManifest.xml或專案檔中的ApplicationId（<ApplicationId>com.yourcompany.appname</ApplicationId>）完全吻合。 檢查可用性（Check availability）： 點選該按鈕可即時查詢您指定的套件名稱是否已被 Google Play 生態中的其他開發者註冊使用。
- 在 Android 生態系中全域唯一識別您應用程式的 Java/Android 套件識別碼（反向網域名稱慣例，例如
- 預設語言（Default Language）：
- 應用程式的主要商店資訊語言（例如：
English (United States) – en-US或中文（台灣）– zh-TW）。 - 在未特別設定當地語言翻譯的國家與地區，商店資訊將預設以此語言呈現給使用者。
- 應用程式的主要商店資訊語言（例如：
B. 應用程式類型、定價與聲明事項
- 應用程式或遊戲（App or Game）：
- 決定產品的基本屬性（
應用程式或遊戲）。 - 重要注意事項： 此項選擇決定了應用程式在商店中的所屬主分頁（應用程式分頁或遊戲分頁），日後無法變更。
- 決定產品的基本屬性（
- 免費或付費（Free or Paid）：
- 選擇應用程式在商店中是以免費形式提供還是付費購買。
- ⚠️ 不可逆關鍵規範： 根據 Google Play 政策，一旦發布為「免費」的應用程式，將來絕無法更改為「付費」！ 若您打算在商店中直接販售該產品，最初就必須選擇
付費。若欲以免費形式發布並獲取營收，建議採用應用程式內購（In-App Purchase）或 AdMob 廣告機制。
- 自動防護（Automatic Protection）：
- Google Play 會在您應用程式的 APK/AAB 程式碼中注入自動安裝程式驗證機制（installer check）。若使用者從 Google Play 以外的未授權管道側載安裝，系統將提示其返回 Google Play 下載正版。
- 聲明事項（政策與法規聲明）：
- 開發人員計畫政策（Developer Program Policies）： 確認應用程式完全符合 Google Play 開發人員與內容政策。
- 美國出口法規（US Export Laws）： 確認本軟體符合美國出口管制法律與禁運規範。
- 建立應用程式（Create App）：
- 表單資料確認無誤後，點選右下角藍色的 "建立應用程式"（Create app） 按鈕。控制台會將應用程式登錄至系統，並將開發者引導至該應用程式的主管理儀表板（Dashboard）。
3. Keystore 產生與建置/簽署自動化
為了使發布流程維持零失誤且具備高可重複性，建議在專案根目錄建立 Deploy/ 資料夾與各項自動化指令碼。
A. Keystore 金鑰產生（1_CreateKeystore.bat）
使用 JDK 中的 keytool 工具產生有效期長達 25 年（10,000 天）的簽署金鑰：
keytool -genkeypair -v ^
-keystore "%KEYSTORE_PATH%" ^
-alias %ALIAS% ^
-keyalg RSA ^
-keysize 2048 ^
-validity 10000 ^
-storepass "%PASS%" ^
-keypass "%PASS%" ^
-dname "CN=SirketAdi, OU=Apps, O=SirketAdi, C=TR"
提示： 在 Windows 批次檔中使用
set /p取得使用者輸入的密碼時，若內部包含括號的if (...)區塊，可能會引發語法剖析錯誤（: was unexpected at this time）。改用goto標籤控制流程，並將密碼參數用雙引號包覆"%PASS%"可確保執行穩定。
B. 自動版本遞增與簽署 AAB 建置（2_BuildAndSign_AAB.bat）
Google Play 要求每次發布更新時 versionCode 必須嚴格持續遞增。為了實現自動化管理，可採用基於日期與時間的計算公式：
# 年份末碼 + 月 + 日 + 時 + 分（例如：2026-10-06 02:42 -> 610060242）
$vc = (Get-Date).ToString('yy').Substring(1) + (Get-Date).ToString('MMddHHmm')
編譯與數位簽署指令：
dotnet build "Proje.Android.csproj" -c Release -f net9.0-android /p:AndroidPackageFormat=aab /p:ApplicationVersion=%VERSION_CODE% /p:ApplicationDisplayVersion=%VERSION_NAME%
jarsigner -sigalg SHA256withRSA -digestalg SHA-256 ^
-keystore "%KEYSTORE%" ^
-storepass "%PASS%" ^
-keypass "%PASS%" ^
-signedjar "%SIGNED_FILE%" ^
"%AAB_INPUT%" ^
%ALIAS%
程序執行完成後，可透過 start "" "%OUTPUT%" 指令直接在 Windows 檔案總管中開啟存放已簽署檔案的目標資料夾。
4. Play Console 首次上傳 Bundle 與關鍵錯誤排除
當已簽署的 .aab 檔案上傳至 Google Play Console 的 內部測試（Internal testing） 或 正式版（Production） 軌道時，畫面可能會出現以下提示訊息：
錯誤 1：必須以 API 級別 36（Android 16）為目標
錯誤訊息：
"Your app currently targets API level 35 and must target at least API level 36 to ensure it is built on the latest APIs optimized for security and performance."（您的應用程式目前以 API 級別 35 為目標，必須至少以 API 級別 36 為目標，以確保採用針對安全性與效能優化的最新 API 所建置。）
解決方案：
此為阻斷性錯誤，排除前無法繼續完成發布。
- 在
Platforms/Android/AndroidManifest.xml檔案中明確設定<uses-sdk>標籤：
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.yourcompany.appname">
<uses-sdk android:minSdkVersion="24" android:targetSdkVersion="36" />
...
</manifest>
- 在專案
.csproj檔案的<PropertyGroup>中新增以下設定：
<AndroidTargetSdkVersion>36</AndroidTargetSdkVersion>
錯誤 2：版本代碼大幅提高警告（Version Code Significantly Higher）
警告訊息：
"This release's version code is significantly higher than your previous version code. Over time, this will result in your app reaching the maximum limit for version codes... Learn more"（此版本的版本代碼明顯高於先前的版本代碼。隨著時間推移，這可能導致您的應用程式達到版本代碼的上限……瞭解詳情）
解決方案：
- 當專案先前的版本代碼為較小的數字（如 1 或 8），而切換為以日期時間動態產生的格式（如 6 億多）時，Google Play 就會發出此項警示。
- 這 並非阻斷性錯誤。只要點選警告訊息下方的藍色
Proceed anyway（仍要繼續） 連結即可略過。 - 由於後續版本將以此數值為基礎繼續遞增，將不會再次出現跨度過大的警示。
5. 隱私權政策（Privacy Policy）準備
根據 Google Play 政策規定，即使您的應用程式未主動蒐集敏感資料，也必須提供一個公開可存取、具備有效 SSL（HTTPS）連線的標準網頁連結（不能是 PDF 格式）。
在 GitHub 上免費託管
GitHub 存放庫中的 Markdown 文件（blob/main/...）可被 Google 系統直接識別為標準合規網頁。
政策文件中應涵蓋的核心條款
- 廣告服務（Google AdMob）： 橫幅廣告、插頁式廣告與獎勵影片廣告；Android 廣告 ID（
AD_ID）、裝置技術參數與大約 IP 位置的使用聲明。 - 應用程式內購與訂閱（Google Play Billing）： 付款交易全程在 Google 官方基礎架構下完成，開發者絕不接觸使用者的信用卡號或個人帳單資訊。
- 分析與遙測工具（Firebase Analytics & Crashlytics）： 匿名使用事件與當機崩潰分析報告。
- 同意聲明管理（Google UMP）： 符合 GDPR 與相關資料保護法規的授權視窗，並賦予使用者隨時在設定中更改個人偏好的權利。
- 法律免責聲明與特殊聲明（例如預測分析工具/賽事競猜）：
- 鄭重聲明本應用程式絕非博弈或賭博平台。
- 僅提供數學演算法最佳化與統計數據分析輔助。
- 跳轉至官方機構網站時，絕不保存使用者在官方網站的帳號密碼，2FA/簡訊認證均在官方介面獨立完成。
- 安全注意事項： 隱私權政策內文中請勿包含開發者的個人 GitHub 等私人連結；僅列出企業官方支援信箱與官方網站。
6. 應用程式存取權 / 登入詳細資訊（App Access / Sign-in Details）
在 Google 審查人員進行實際測試前，您必須宣告應用程式內部是否有受限的存取區域：
- 選項：
No（應用程式所有部分均未受限，可直接存取）。 - 說明： 若應用程式中沒有會員登入、帳號密碼驗證或付費鎖屏，應選擇
No。若選擇Yes，Google 會要求您提供供測試人員專用的示範帳號與密碼。
7. 廣告聲明（Ads Declaration）
在此步驟中宣告應用程式是否會展示廣告：
- 選項：
Yes, my app contains ads（是，我的應用程式包含廣告）。 - 說明： 若應用程式中已引用 AdMob 函式庫或未來規劃加入廣告，必須選擇「是」。此選項會在 Google Play 商店頁面上顯示 "包含廣告" 標籤，確保完全符合政策規定。
8. 內容分級（IARC 內容分級問卷）
為評定應用程式適用的年齡分級標準，您必須填寫 IARC（國際年齡分級聯盟）問卷調查。
A. 類別選擇與電子郵件填寫
- 類別：
All Other App Types（所有其他應用程式類型）（非遊戲、非博弈、非社群媒體的公用工具、實用工具、計算機等應用程式）。 - 電子郵件： 輸入官方聯絡信箱並同意 IARC 條款。
B. 問卷問題（Questionnaire）
第一部分：暴力與使用者互動
- 下載的應用程式（暴力、色情內容、粗俗語言）：
No - 使用者內容分享（使用者之間分享音訊、簡訊、影音相片）：
No
第二部分：內容與年齡限制商品
- 線上串流內容（串流音樂/影片或電商目錄）：
No - 推廣受年齡限制商品（菸草、酒精、博弈）：
No（由於應用程式絕無下注行為，務必選 No） - 其他項目（分享精確 GPS 地理位置）：
No
第三部分：數位商品與其他功能
- 數位商品（販售數位虛擬商品）：
No（若目前尚未啟用官方應用程式內結算請選 No；若已啟用請選 Yes 以取得「應用程式內購」標記） - 現金獎勵（現金獎金、禮品卡）：
No - 網路瀏覽器（網路瀏覽器/搜尋引擎）：
No - 新聞/教育類（新聞或教育產品）：
No
當上述所有題目皆回答「No」時，應用程式將取得全球適用受眾最廣泛的年齡分級（PEGI 3, ESRB Everyone）。
9. 目標目標目標對象與年齡層選擇（Target Audience）
在設定應用程式的目標受眾時，依據 Google 的 家庭政策（Designed for Families / Family Policy） 與 COPPA（兒童線上隱私保護法） 規範，明確聲明是否針對兒童設計極為關鍵。
正確選擇：僅勾選 18 and over（18 歲以上）
- 為何僅限 18+？
- 法規遵循： 運動賽事數據統計、賠率與分析工具基於賽事公報，專門面向成年受眾。
- 免除家庭政策嚴苛限制： 若選擇 13 歲以下或 13-17 歲，Google 會強制要求應用程式內的廣告 SDK 必須通過兒童友善認證，大幅限縮遙測數據，並啟動極為嚴厲的審查機制。
- 與隱私權政策保持一致： 與隱私權政策中載明的 "本應用程式僅供 18 歲及以上對象使用" 條款百分之百吻合。
- 第二步驟（您的應用程式是否會在無意中吸引兒童？）：
- 此問題務必回答
No（否）。應用程式介面中無卡通人物、玩具主題或兒童動畫，因此絕非會在無意間引起兒童注意的產品。
- 此問題務必回答
10. 應用程式內容資訊主頁（App Content Dashboard）
Google Play Console 透過左側選單 政策與計畫 -> 應用程式內容（App content） 分頁中的檢查清單，逐步追蹤您應用程式的法律與內容就緒狀態。
隨著隱私權政策、登入權限、廣告與內容分級依序完成，畫面上會出現綠色勾號（✓）。清單中其餘的項目（資料安全性、政府機關、金融功能、健康應用程式）必須依序逐項填妥。
11. 資料安全性表單（Data Safety Form）
這是 Google Play 審查最為嚴謹的項目之一。您必須誠實宣告應用程式及其引用的第三方第三方程式庫收集了哪些資料，或與第三方共享了哪些資料。
關鍵問題：您的應用程式是否會收集或分享任何必要的使用者資料類型？
- 初次發布建議選擇：
No（否）。 - 技術原因： 在首次上傳的
.aab套件中，若尚未實際編譯並啟動 AdMob SDK 或 Firebase SDK，且未收集任何使用者識別碼或機敏資訊，選擇No即可俐落通過表單。 - 未來注意事項： 當後續版本中實際撰寫程式碼啟動 AdMob 或 Firebase 時，需返回此表單將 "大約位置"、"應用程式效能" 與 "裝置或其他識別碼（AD_ID）" 更新為
Yes。
確認預覽效果後，點選儲存。
12. 法律與法規聲明（政府、金融、健康應用程式）
A. 政府應用程式聲明
- 選擇：
No（本應用程式不代表任何政府官方機關）。
B. 金融功能聲明
- 選擇： 頁面最下方的
My app doesn't provide any financial features（我的應用程式不提供任何金融功能）。 - 確認： 在開啟的確認彈窗中確認無需提交任何金融營運執照或認證文件：
C. 健康應用程式聲明
- 選擇： 頁面最下方的
My app does not have any health features（我的應用程式不具備任何健康相關功能）。 - 確認： 在快顯視窗中確認不需要提交區域醫療健康文件：
13. 商店設定與聯絡資訊（Store Settings）
設定應用程式在商店中的分類以及使用者與開發者取得聯繫的通訊管道：
- 應用程式分類（App Category）：
運動（Sports）或實用工具/工具（Utilities / Tools）。 - 標籤（Tags）： 挑選相應關鍵字標籤（例如：Sports、Tools）。
- 商店資訊聯絡詳細資料（Store Listing Contact Details）：
- 電子郵件地址：
destek@sirketadi.com（官方支援電子郵件為必填欄位）。 - 網站：
https://company.com
- 電子郵件地址：
- 外部行銷推廣（External Marketing）： 保持勾選，允許 Google 在 Google Play 以外的行銷平台推廣推薦您的應用程式：
14. 主要商店資訊與視覺素材（Main Store Listing）
商店首頁門面是直接影響使用者下載決策的最關鍵區塊：
A. 文字內容
- 應用程式名稱（App Name）： 上限 30 個字元（例如：
15te15 - Spor Toto Assistant）。 - 簡短說明（Short Description）： 上限 80 個字元（例如：
Formula optimization, probability calculation and smart Spor Toto coupon assistant.）。 - 完整說明（Full Description）： 詳細闡述功能特性、演算法優勢與法律免責聲明。
B. 視覺素材規格標準
- 應用程式圖示（App Icon）： 嚴格為
512 x 512 px，32 位元 PNG 格式，檔案上限 1 MB。 - 主題特徵圖片（Feature Graphic）： 嚴格為
1024 x 500 px，JPG 或 24 位元 PNG 格式，檔案上限 15 MB。 - 手機螢幕截圖（Phone Screenshots）：
- 最少 2 張，最多 8 張。
- 最小解析度邊長：1080 px（例如：
1080 x 2340 px）。 - 畫面長寬比：16:9 或 9:16。
C. 生成式 AI 內容聲明
- 即使在設計宣傳視覺圖時採用了 AI 輔助生成工具，只要未產生會誤導使用者的擬真人物面孔或公眾人物肖像，皆選擇
Don't label assets（不替素材標記標籤）。
15. 封閉測試設定與審查（Closed Testing）
針對在 Google Play Console 新建立的個人開發者帳戶，在直接上架正式版前，強制必須完整執行 封閉測試（Closed Testing） 程序。
A. 提交變更以供審查（發布總覽）
當所有商店設定與表單填寫完畢後，發布總覽畫面會列出所有待審查的變更項目：
然而，若要讓右上角藍色的 "提交變更以供審查" 按鈕啟用，應用程式必須至少在一個測試管道（Closed Testing）中上傳並配置了版本。
B. 封閉測試流程三步驟
完成封閉測試有 3 個必備步驟：
- 選取國家與地區（Select countries and regions）：
- 選取將開放測試應用程式的國家/地區（預設可選取全球或特定區域），並點選右下角 儲存。
- 選取測試人員（Select testers）：
- 在 測試人員（Testers） 分頁中選取已建置的電子郵件名單（Email List），或直接建立新名單。
- 為了在個人帳戶上取得正式版發布存取權，Google 規範必須有至少 20 名測試人員連續參與測試達 14 天。因此，名單中務必納入足額的真實測試使用者。
- 選取名單後，點選右下角的 儲存變更（Save changes）。
- 建立新版本（Create a new release）：
- 當國家與測試人員設定完成後，上方會顯示 "2 of 4 complete"。
- 點選右上角藍色的
Create new release（建立新版本） 按鈕進入版本發布建置畫面。
- 上傳已數位簽署的
.aab套件。上傳完成後，Google 會自動進行套件深度分析：
- 畫面顯示成功辨識出
Target SDK: 36，版本代碼Version: 610060410與架構指令集皆通過驗證。 - 點選
Next（下一步） 時，由於版本代碼跨度較大會彈出警示訊息：
- 解決方式： 點選 "This release's version code is significantly higher than your previous version code" 警示正下方的藍色
Proceed anyway連結。 - 解除錯誤阻擋後，點選右下角藍色的
Save（儲存） 按鈕即可順利儲存該版本。
完成以上所有步驟後，即可返回 發布總覽（Publishing overview） 畫面，透過 Send changes for review（提交變更以供審查） 按鈕正式展開 Google 的審核程序。
C. 常見狀況：測試連結顯示 "App not available"（應用程式無法使用）
開發者在開啟封閉測試邀請連結（play.google.com/apps/testing/com...）時最常遇到的畫面：
"App not available - A testing version of this app hasn't been published yet or isn't available for this account."（應用程式無法使用 - 此應用程式的測試版本尚未發布，或無法在此帳戶中使用。）
原因與排查方針：
- 審核中（In Review）： 即使封閉測試版本已建立並送審，在 Google 審查團隊正式 核准 該套件前，此連結不會生效。只有在 Play Console 中的狀態變更為 "Available to testers"（可供測試人員使用）時，連結才會對外開放。
- Google 帳戶不一致： 瀏覽器目前登入的 Google 帳戶必須與 Play Console 測試人員名單中輸入的信箱完全相符。未獲授權或無痕帳戶無法開啟該連結。
- 伺服器發布延遲時間： 即使 Google 已審核核准，封閉測試連結同步至全球 CDN 節點通常需要 1 到 2 個小時。
D. 參與測試計畫（Become a Tester - Opt-in）
當審查獲准且連結正式啟用後，將呈現以下官方邀請畫面：
- 頁面包含應用程式圖示、開發者名稱與加入測試的邀請說明。
- 點選藍色的
Become a tester（成為測試人員） 按鈕，該帳戶即正式加入測試計畫。 - 接著點選下一頁的 "Download it on Google Play" 連結，即可直接在 Android 裝置上的 Google Play 商店下載安裝測試版本。
16. 廣告 ID 聲明（Advertising ID）
針對所有以 Android 13（API 33）及以上版本為目標的應用程式，Google Play 要求必須明確宣告廣告 ID（AD_ID）的使用狀態。
關鍵問題：您的應用程式是否使用廣告 ID？
本頁面上 Google 的核心防堵規則如下：
"If you say that your app uses advertising ID, we will block releases that don't include the com.google.android.gms.permission.AD_ID permission in the manifest file when targeting Android 13."（若您宣告應用程式使用廣告 ID，當以 Android 13 為目標但在資訊清單中未包含 com.google.android.gms.permission.AD_ID 權限時，我們將封鎖該版本發布。）
- 選項 1（建議做法）：
No（否）。 - 在目前上傳的封閉測試套件中，AdMob SDK 或交叉推廣套件尚未實際編譯，且
AndroidManifest.xml中未添加AD_ID權限。因此選擇No並儲存，不會產生資訊清單權限衝突。 - 選項 2（若選擇 Yes）：
- 若勾選
Yes，必須在用途中勾選[x] Advertising or marketing（廣告或行銷），並務必勾選頁面底部的 "Turn off release errors"（關閉發布錯誤） 核取方塊（I understand the ramifications of not including the com.google.android.gms.permission.AD_ID permission...），以解除權限未設定的發布阻擋。
無論選擇哪一種，設定完成後點選右下角的 Save（儲存）。
17. 提交變更以供審查（Final Submission）
當商店資訊、隱私權政策、安全表單、法規聲明、目標受眾與封閉測試版本皆準備就緒後，返回 發布總覽（Publishing overview） 畫面：
- Submit 14 changes for review（提交 14 項變更以供審查）： Google Play 會將所有表單聲明與測試版本整合為單一審查封包（如圖所示有 14 項變更待審查）。
- 點選藍色的
Submit 14 changes for review按鈕正式啟動 Google 審核作業。 - Google 的自動化快速品質檢查會在背景執行，隨後應用程式進入 Google Play 審查團隊的人工評估佇列。個人帳戶的初次審查通常在 24 到 72 小時內完成。
18. 封閉測試後申請正式發布權限（Apply for Access to Production）
當個人開發者帳戶完成 Google 規定的封閉測試要求（至少 20 名測試人員持續活躍測試達 14 天）後，Play Console 主控制儀表板上的 "Apply for production"（申請正式發布權限） 按鈕將會被點亮啟用。點選此按鈕後，Google 會提供一份包含 3 個步驟的完整申請表單，詳細審核應用程式是否確實經過充分測試且具備上線水準：
表單三階段步驟：
- 關於您的封閉測試（About your closed test）： 詢問您如何招募測試人員、如何蒐集回饋意見，以及根據收到的意見對應用程式進行了哪些具體改進。
- 關於您的應用程式（About your app）： 說明應用程式的目標受眾以及為使用者創造的核心價值。
- 您的正式發布準備（Your production readiness）： 宣告正式上線後如何追蹤線上錯誤崩潰並管理使用者評論。
核心問題與申請參考範例（英文與中文對照）
1. "How did you recruit users for your closed testing? For example, did you ask friends and family, or use a paid testing provider?"
（您是如何為封閉測試招募使用者的？例如詢問了親友，還是使用了付費測試供應商？）
重要原則： Google 極為排斥機器人或付費虛擬測試農場。最穩妥誠實的回應是表明測試人員皆為真實有機的親友、同事以及相關社群的使用者。
I recruited testers organically through friends, family, and colleagues interested in sports analysis. Additionally, I invited active football prediction fans from targeted social media groups (Reddit & sports communities). No paid services were used; all were real, active users.
2. "How easy was it to recruit testers for your app?"
（為您的應用程式招募測試人員容易程度如何？）
- 建議選項：
Neither difficult or easy（普通）或Easy（容易）。這項選擇表明招募過程順理成章、真實自然，而非仰賴不正常的灌水管道。
3. "Describe the engagement you received from testers during your closed test"
（描述在封閉測試期間測試人員的互動參與情況：）
（Google 審查指南：指出測試人員是否實際使用了所有核心功能，其行為模式是否與真實世界使用者相符）
Testers actively used all core features: match fixtures, filters, and coupon generation. Their engagement matched real user behavior, logging in regularly around weekly match days to create coupons and review predictions. All tester activity closely mirrored real-world football fan usage.
4. "Provide a summary of the feedback that you received from testers. Include how you collected the feedback."
（請提供從測試人員處收到的回饋意見摘要，並說明您蒐集回饋的方式：）
Feedback was collected via Google Play internal feedback, emails, and tester messaging groups. Testers appreciated the fast coupon generator but suggested improving font readability on small screens, adding clearer filter descriptions, and optimizing fixture loading on slow mobile networks.
第 2 步：關於您的應用程式（About your app）
此步驟深入了解應用程式的鎖定受眾、創造的附加價值以及第一年預期的下載次數：
1. "Who is the intended audience of your app?"
（您的應用程式目標受眾是誰？）
The intended audience includes adult football fans, sports enthusiasts, and Toto players seeking analytical tools to plan predictions. It is designed for users aged 18+ who want structured match fixture insights, mathematical coupon filtering, and systematic statistical analysis.
2. "Describe how your app provides value to users"
（描述您的應用程式如何為使用者創造價值：）
The app provides value by automating complex coupon filtering and Toto calculations, saving users substantial time. It offers clean weekly fixture overviews, probability statistics, and intuitive mathematical tools that help sports fans make well-structured, data-informed prediction plans.
3. "How many installs do you expect your app to have in your first year?"
（您預期應用程式在第一年能達到多少次下載安裝？）
- 建議選項：
0 - 10K（獨立開發者腳踏實地且符合常理的預估）。
第 3 步：您的正式發布準備（Your production readiness）
此最後階段探討根據封閉測試經驗所實施的各項優化，以及如何確認應用程式已具備正式公開水準：
1. "What changes did you make to your app based on what you learned during your closed test?"
（根據封閉測試中的收穫，您對應用程式進行了哪些具體修改？）
建議方針： 回答內容應與前面步驟中提及的回饋重點（小螢幕適配、字體大小、篩選標籤清晰度與弱網快取）相互呼應一致。
Based on tester feedback, we adjusted font scaling and spacing for smaller screens, added descriptive labels to filter options, and optimized fixture caching for slower network connections. We also streamlined the coupon generation interface to make navigation smoother and more intuitive.
2. "How did you decide that your app is ready for production?"
（您是如何判定應用程式已經具備正式上線條件的？）
建議方針： 應重點強調 Android Vitals 的官方數據（零當機、零 ANR 無回應）、長達 14 天的測試週期以及在多樣化 Android 機型與版本上的穩定表現。
We confirmed production readiness through 14 days of closed testing with zero crashes and zero ANRs in Android Vitals. All core workflows (fixture browsing, filtering, and coupon generation) executed smoothly across diverse devices, and testers confirmed high stability and complete features.
所有欄位填寫完畢後，點選右下角藍色的 Apply（申請） 按鈕正式送出發布權限申請。
申請已送出畫面（審查作業中）
點選申請按鈕後將返回 Play Console 主儀表板，正式版（Production） 頁面將呈現官方審查進度資訊卡片：
"We have your application for production access"（我們已收到您的正式發布存取權申請）
"We're reviewing your application form. We'll email the account owner with an update. This usually takes 7 days or less, but may occasionally take longer."（我們正在審查您的申請表單。審查進度將透過電子郵件通知帳戶所有人。處理時間通常為 7 天以內，偶爾可能需要更長時間。）
此階段重要須知：
- 審核所需時間： 雖然介面上官方載明為 "7 天或以內"，但對於問卷填寫邏輯嚴密且零崩潰的優良專案，通常在 24 至 72 小時內 即可收到審核結果。
- 結果通知方式： 當評估完成後，官方核准通知信將直接寄達帳戶擁有者的電子郵件信箱（參見第 19 節）。
- 等待期間指引： 無需進行任何額外動作；封閉測試管道可維持現狀運作，只需靜候 Play Console 審查團隊的決定。
19. 最終勝利：獲得正式發布權限（Production Access）批准
當新個人開發者帳戶成功克服了 Google Play Console 最艱難的關卡——封閉測試（至少 20 名測試人員持續活躍測試滿 14 天） 並送出正式申請後，帳戶信箱將收到由 Google Play Console 團隊親自寄發的官方核准信函：
"Congratulations! Your app has been granted Google Play production access"（恭喜！您的應用程式已獲得 Google Play 正式發布存取權）
"You applied for Google Play production access for your app, and this has now been granted. Production is where you make your app available to billions of users on Google Play."（您為應用程式申請了 Google Play 正式發布存取權，該申請現已獲准。透過正式版，您可以將應用程式推廣給 Google Play 上數十億名使用者。）
這封電子郵件代表什麼？
- 公開發布資格： 您的應用程式現在正式具備發布給全球數十億 Android 使用者的資格，不再局限於受邀的封閉測試名單。
- 個人帳戶信任升級： 成功達到 Google 20 位測試者 / 14 天的門檻要求，開發者帳戶正式晉升為受信任狀態。
- 一鍵正式上架： 進入 Play Console 的 正式版（Production） 管道，在封閉測試中已經過充分驗證的套件可直接發布至商店首頁櫥窗，或隨時推送全新更新。
20. 上架前檢查清單（已完成）
上架階段全流程檢驗清單：
- 是否已在 Play Console 中產生應用程式 ID 與全域唯一套件名稱？
- 已簽署的
.aab套件是否以targetSdkVersion 36編譯建置？ - versionCode 是否大於舊版本？（遇到警告時是否已點選 Proceed anyway？）
- 隱私權政策 URL 是否已就緒並支援 HTTPS 正常存取？
- 應用程式存取權是否已標註為
No？ - 廣告聲明是否已如實勾選
Yes？ - IARC 年齡分級問卷是否已填寫完畢並取得分級認證？
- 目標受眾是否已勾選為
18 and over？ - 資料安全性表單（Data Safety）是否已填妥無誤？
- 政府、金融與健康相關聲明是否皆已選取為
No？ - 商店宣傳視覺素材（512x512 圖示、1024x500 主題特徵圖片、手機螢幕截圖）是否皆已上傳完畢？
- 封閉測試：國家與地區是否已選取並儲存？
- 封閉測試：測試人員清單是否已配置並儲存？
- 封閉測試：已簽署的
.aab套件是否已上傳並建立版本？ - 廣告 ID：首發版本是否已勾選
No儲存？ - 發布總覽：是否已將所有變更正式提交 Google 審查？
- 封閉測試週期圓滿完成並已取得正式發布存取權（Production Access）？
21. Arar Games 與我們的遊戲產品
您可以造訪我們的官方商店專頁，親身體驗我們獨立工作室所開發的所有遊戲作品、獨特機制與最新更新：
🎮 精選遊戲作品：
- 🛡️ Blocked: Pixel Panzer:
復古像素坦克戰鬥、ColorWheel 屬性砲彈克制對決、動態天氣系統、魄力 Boss 決戰、全球排行榜與 Google Play 成就系統！
👉 在 Google Play 下載（Android & PC） | Microsoft Store（Windows PC） - 🎨 Paint Trek:
在繽紛像素與廣袤太空格調中展現極致反射神經的街機體驗。
👉 Google Play | Microsoft Store (PC & Xbox) - 🚀 Space Dodger:
在無垠深空中疾速穿梭、靈巧閃避各類障礙的快節奏復古街機遊戲。
👉 在 Google Play 下載
📢 社群媒體與交流管道：
歡迎追蹤我們的官方社群，即時掌握最新技術深度專題、開發者日誌（DevLog）與遊戲最新消息：
- 🎵 TikTok: @arargamesstudio
- 📸 Instagram: @arargamesstudio
- 🐦 X (Twitter): @arargamesstudio
- 📺 YouTube: @koreaaria
- 🧵 Threads: @arargamesstudio
- 📘 Facebook: arargamesstudio
文件編整：Arar Games 開發者技術文檔典藏
Hiç yorum yok:
Yorum Gönder