Google Play မှာ အက်ပ်ထုတ်ဝေနည်း: Play Console ၏ အမှန်တကယ် အဆင့်များ

Google Play မှာ အက်ပ်ထုတ်ဝေဖို့ Google Play developer account (၂၀၂၆ နိုဝင်ဘာလအထိ တစ်ကြိမ်တည်း USD 25) ကို မှတ်ပုံတင်ပါ၊ Play Console မှာ အက်ပ်ကို ဖန်တီးပါ၊ store listing နဲ့ App content ပုံစံများကို ဖြည့်ပါ၊ Android App Bundle (.aab) ကို testing track သို့ upload လုပ်ပါ၊ ပြီးရင် Google က ပြန်စစ်ပြီးနောက် production သို့ release လုပ်ပါ။ ကိုယ်ပိုင် အကောင့်အသစ်ရှိရင် အပို အဆင့်တစ်ခုရှိပါတယ်: production access မတောင်းခင် tester အနည်းဆုံး ၁၂ ယောက်နဲ့ closed test ကို ၁၄ ရက်ဆက်တိုက် လုပ်ရပါမယ်။ ဤလမ်းညွှန်က စခရင်တစ်ခုချင်းစီကို အစီအစဉ်အတိုင်း၊ နှောင့်နှေးစေတတ်တဲ့ အသေးစိတ်များနဲ့ ရှင်းပြပါတယ်။

အက်ပ်ကို မတည်ဆောက်ရသေးရင် Android app ဖန်တီးနည်း ကနေ စပါ။

စတင်မီ: ဘာလိုအပ်သလဲ

• Android App Bundle (.aab) အဖြစ် အက်ပ်။ Google Play က အက်ပ်အသစ်များအတွက် ဤဖော်မတ်ကို လိုအပ်ပါတယ်။
• လက်ရှိ target API level။ ၂၀၂၆ နိုဝင်ဘာလအထိ အက်ပ်အသစ်များနဲ့ update များက Android 16 (API level 36) ကို target လုပ်ရပါမယ်။
• ပုဂ္ဂလိက မူဝါဒ (privacy policy) ကို အများပြည်သူ ဝဘ်လိပ်စာတွင်။ ပုံမှန် ဝဘ်စာမျက်နှာ ဖြစ်ရမယ်၊ PDF မဟုတ်ဘဲ login နောက်ကွယ်မှာလည်း မဟုတ်ရပါဘူး။
• အိုင်ကွန်၊ screenshot များနဲ့ feature graphic။ လက်ရှိ အရွယ်အစား လိုအပ်ချက်များကို Play Console မှာ စစ်ပါ; ရေးသားချိန်တွင် အိုင်ကွန်က 512 × 512 pixel၊ feature graphic က 1024 × 500 ဖြစ်ပါတယ်။
• Support email လိပ်စာ။
• မှတ်ပုံတင်ရန် အစိုးရ ID နဲ့ သင့်ဥပဒေကြောင်းနာမည်ဖြင့် ကတ်။ Prepaid ကတ်ကို မလက်ခံပါ။

အဆင့် ၁: developer account ဖန်တီးပါ

Play Console သို့ သွားပြီး စာရင်းသွင်းပါ။ Account အမျိုးအစား နှစ်မျိုးမှ ရွေးပါ:

• ကိုယ်ပိုင်။ တစ်ဦးချင်းအတွက်။ သင့်ဝန်ခံချက်ကို အတည်ပြုပြီး Play Console mobile app ဖြင့် Android စက်ကို ဝင်ရောက်ခွင့် အတည်ပြုရပါမယ်၊ အဆင့် ၆ မှာ ဖော်ပြထားတဲ့ testing လိုအပ်ချက်ကို ပြည့်စုံစေရပါမယ်။
• Organisation။ မှတ်ပုံတင်ထားသော စီးပွားရေးအဖွဲ့အစည်းများအတွက်။ အတည်ပြုခြင်းက စီးပွားရေးအချက်အလက် တောင်းပြီး ပိုကြာပါတယ်၊ သို့သော် tester ၁၂ ယောက် စည်းမျဉ်း မရှိပါ။

သင်အသက် ၁၈ နှစ်ပြည့်ရပါမယ်။ USD 25 ကို တစ်ကြိမ်သာ ပေးရပြီး Google က သင့်အချက်အလက် မမှန်ဟု ဆုံးဖြတ်ရင် ပြန်မရပါ၊ ထို့ကြောင့် ID ပေါ်ရှိ ဥပဒေနာမည်ကို အတိအကျ ရိုက်ပါ။

အဆင့် ၂: အက်ပ်ကို ဖန်တီးပါ

Play Console မှာ Create app ကို နှိပ်ပြီး ဖြည့်ပါ:

• App name — အသုံးပြုသူ မြင်ရမယ့်အတိုင်း။
• Default language။
• App or game။
• Free or paid။ Paid app ကို နောက်မှ free သို့ ပြောင်းလို့ရပေမဲ့ free ကို paid သို့ မပြောင်းနိုင်ပါ။
• Declarations — Developer Program Policies၊ US export ဥပဒေနဲ့ Play App Signing စည်းကမ်းများကို လက်ခံပါ။

Package name (ဥပမာ com.yourcompany.yourapp) ကို ပထမ upload မှ သတ်မှတ်ပြီး ဘယ်တော့မှ ပြောင်းလို့ မရ၊ ပြန်သုံးလို့မရပါ၊ ထို့ကြောင့် အက်ပ်ကို ကိုယ်တိုင်တည်ဆောက်ရင် ဂရုတစိုက် ရွေးပါ။

အဆင့် ၃: Store listing ရေးပါ

ဘယ်ဘက်မီနူးရဲ့ Store presence အောက်က Main store listing စာမျက်နှာကို ဖွင့်ပြီး ထည့်ပါ:

• App name၊ စာလုံး ၃၀ အထိ။
• Short description၊ စာလုံး ၈၀ အထိ။ ဒါက မကြာခဏ လူတွေ ဖတ်တဲ့ အရာဖြစ်လို့ အက်ပ်က ဘာလုပ်သလဲ အရင်ပြောပါ။
• Full description၊ စာလုံး ၄,၀၀၀ အထိ။ ဘယ်သူ့အတွက်လဲ၊ အဓိက feature များနဲ့ သိသင့်တာတွေကို ရိုးရိုးစကားဖြင့် ရှင်းပြပါ။ Keyword ထည့်ပြွမ်းမထည့်ပါနဲ့; Google ရဲ့ မူဝါဒက တားမြစ်ပါတယ်။
• ဂရပ်ဖစ်များ — အိုင်ကွန်၊ feature graphic နဲ့ ဖုန်း screenshot များ။ အက်ပ်ရဲ့ အမှန်တကယ် စခရင်များ၊ မရှိသော feature များကို mock-up မဟုတ်ပါ။
• Category နဲ့ contact အချက်အလက်။

အဆင့် ၄: App content ပုံစံများ ဖြည့်ပါ

ဘယ်ဘက်မီနူးရဲ့ Policy အောက်က App content စာမျက်နှာကို ဖွင့်ပါ။ Release မလုပ်ခင် တစ်ခုချင်းစီကို အဖြေပေးရပါမယ်:

• Privacy policy URL။
• App access — အက်ပ်ရဲ့ အစိတ်အပိုင်းတစ်ခုက login လိုရင် reviewer များအတွက် အလုပ်လုပ်သော အထောက်အထားပေးပါ။ Login မရှိခြင်းက ငြင်းပယ်ခံရတဲ့ အဖြစ်များဆုံး အကြောင်းတစ်ခုပါ။
• Ads — အက်ပ်က ကြော်ငြာပြသလား ပြောပါ၊ third-party ကုဒ်မှတဆင့်ပါ။
• Content rating — ဒေသအလိုက် အသက်အရွယ် rating ထုတ်ပေးသော မေးခွန်းလွှာ။ ကျော်ထားရင် အက်ပ်က "Unrated" ဖြစ်ပြီး release ကို ပိတ်ပါတယ်။
• Target audience နဲ့ content — အက်ပ်ရည်ရွယ်သော အသက်အုပ်စုများ။ ကလေးများ ပါဝင်ရင် Families မူဝါဒ၏ တင်းကြပ်သော လိုအပ်ချက်များ လာပါလိမ့်မယ်။
• Data safety — အက်ပ်က ဘယ်ဒေတာကို စုဆောင်းသလဲ၊ မျှဝေသလဲ၊ ဘာကြောင့်၊ encrypt လုပ်သလား၊ ဖျက်လို့ရလား။ Analytics နဲ့ login provider များအပါအဝင် အက်ပ်ထဲရှိ အရာအားလုံးအတွက် ဖြေပါ။
• အခြားကြေညာချက်များ — ပြောတဲ့အတိုင်း၊ ဥပမာ သတင်း၊ ကျန်းမာရေး၊ ငွေကြေး သို့မဟုတ် အစိုးရအက်ပ်များ၊ သို့မဟုတ် SMS ကဲ့သို့ အထိခိုက်မခံနိုင်သော ခွင့်ပြုချက်များ။

တိကျစွာ ဖြေပါ။ Google က သင့်အဖြေများကို အက်ပ်ဘာလုပ်သလဲနဲ့ နှိုင်းယှဉ်ပါလိမ့်မယ်။

အဆင့် ၅: ပထမ build ကို Internal testing သို့ upload လုပ်ပါ

ဘယ်ဘက်မီနူးရဲ့ Testing အောက်က Internal testing ကို ဖွင့်ပြီး release တစ်ခု ဖန်တီးကာ .aab ကို upload လုပ်ပါ။ ဒီပထမ release မှာ Play App Signing ကို သတ်မှတ်ပါ: သင့်ကိုယ်တိုင် signing key ကို စီမံစရာအကြောင်းမရှိရင် Google ကို ထုတ်ပြီး ထိန်းထားခွင့်ပေးပါ။ သင့်ကိုယ်တိုင်နဲ့ အဖွဲ့သား အနည်းငယ်ကို အီးမေးလ်ဖြင့် internal tester အဖြစ် ထည့်ပါ၊ ပြီးရင် release ကို rollout လုပ်ပါ။ Tester များက opt-in လင့်ခ်ကို ဖွင့်ပြီး Play Store မှ အက်ပ်ကို ထည့်သွင်းပါမယ်။

နောက်ထပ် upload တိုင်း မတိုင်ခင်ရှိသော versionCode ထက် ပိုမြင့်ရပါမယ်။

Mythex နဲ့ တည်ဆောက်ထားရင်

Pro plan မှာ Mythex က သင့် published အက်ပ်မှ AAB ကို သင့်အတွက် ပြုလုပ်ပေးပါတယ်။ နည်းလမ်းနှစ်မျိုးမှ လုပ်နိုင်ပါတယ်:

1. ကိုယ်တိုင် upload လုပ်ပါ။ Agent ကို Android အတွက် build လုပ်ရန် တောင်းဆိုပြီး ကတ်က Ready to upload ပြသတဲ့အခါ Download ကို နှိပ်ပြီး Play Console မှာ ဖိုင်ကို upload လုပ်ပါ။ ဖိုင်ကို Project settings ထဲမှာ ၃၀ ရက်ခန့် ပြန် download လုပ်လို့ရပါတယ်။
2. သင့်ကိုယ်ပိုင် Google Play service account ကို ချိတ်ပါ။ Google Cloud မှာ service account နဲ့ JSON key ဖန်တီးပါ၊ Play Console ရဲ့ Users and permissions အောက်မှာ အဲဒီ email ကို ဒီအက်ပ်အတွက် အခွင့်အရေးနဲ့ ဖိတ်ပါ၊ ပြီးရင် key ကို Mythex ထဲ ထည့်ပါ။ နောက်ပိုင်း Android build တိုင်းက internal testing သို့ အလိုအလျောက် ရောက်ပြီး version code ကို Google Play ပေါ်ရှိပြီးသား အရာထက် မြင့်အောင် သတ်မှတ်ပါမယ်။ Agent က store listing ကိုလည်း ပြင်နိုင်ပြီး production release ကဲ့သို့ အများသူငှာ ဖြစ်မလာခင် သင့်ကို မေးပါလိမ့်မယ်။

အဆင့် ၂ ရဲ့ အက်ပ်ဖန်တီးခြင်း၊ Data safety ပုံစံနဲ့ content rating တို့ကတော့ Play Console မှာပဲ ကျန်ပါတယ်; ပျောက်နေတာတစ်ခုရှိရင် agent က ပြောပြပါလိမ့်မယ်။ Mythex Android app builder စာမျက်နှာမှာ ပိုဖတ်နိုင်ပါတယ်။

အဆင့် ၆: Closed test ပြုလုပ်ပါ (ကိုယ်ပိုင် အကောင့်သစ်များ)

သင့်ကိုယ်ပိုင် အကောင့်ကို ၂၀၂၃ နိုဝင်ဘာ ၁၃ ရက်နောက်ပိုင်း ဖန်တီးထားရင် production access တောင်းခင် tester အနည်းဆုံး ၁၂ ယောက် နဲ့ ၁၄ ရက်ဆက်တိုက် opt-in ထားတဲ့ closed test ကို လုပ်ရပါမယ်။ ထွက်ပြီး ပြန်ဝင်သူက ၁၄ ရက် အသစ် စတင်ပါတယ်။

လက်တွေ့အကြံပြုချက်များ:

• ၁၂ ယောက်ထက် ပိုခေါ်ပါ။ လူတွေ ထွက်သွားတတ်တယ်။ ၁၅ မှ ၂၀ ရည်ရွယ်ပါ။
• Google Group သို့မဟုတ် အီးမေးလ်စာရင်း သုံးပြီး tester တွေကို စီမံပါ။
• အမှန်တကယ် အသုံးပြုဖို့ တောင်းဆိုပါ၊ install သာမဟုတ်ပါ။ Google က production access တောင်းတဲ့အခါ သင့် testing အကြောင်း မေးပြီး သင်ပိုသိရပါလိမ့်မယ်။
• Test ကာလအတွင်း update တစ်ခု ထုတ်ပါ feedback မှ ပြင်ဆင်ချက်တွေနဲ့။

Beta test လမ်းညွှန် က tester ရှာခြင်းနဲ့ feedback စုဆောင်းခြင်းကို ဖုံးလွှမ်းပါတယ်။ ၁၄ ရက် ပြီးရင် Dashboard မှ production access ကို လျှောက်ပြီး သင့် test အကြောင်း မေးခွန်းတွေကို ဖြေပါ။

အဆင့် ၇: Production သို့ release လုပ်ပါ

Production access ရနိုင်တဲ့အခါ ဘယ်ဘက်မီနူးရှိ Production ကို ဖွင့်ပါ:

1. နိုင်ငံနှင့် ဒေသများ ရွေးပါ အက်ပ်ရရှိမည့်နေရာများ။
2. Release အသစ် ဖန်တီးပြီး testing မှ bundle ကို ထည့်ပါ၊ ဒါမှမဟုတ် အသစ်တစ်ခု upload လုပ်ပါ။
3. Release notes ရေးပါ ရိုးရိုးစကားနဲ့: ဘာအသစ်ဖြစ်သလဲ၊ ဘာပြင်ထားသလဲ။
4. ပြန်စစ်ပြီး review ပို့ပါ။ ပြောင်းလဲမှုများက Publishing overview အောက်မှာ ပို့တဲ့အထိ စုဆောင်းထားပါမယ်။

Review အချိန်က ကွဲပြားပါတယ်။ Update များက မကြာခဏ မြန်ပေမဲ့ ပထမ release များက ရက်အတော်ကြာနိုင်ပါတယ်။ အတည်ပြုပြီးသော release ကို ဘယ်အချိန် live ဖြစ်မလဲ သင်ကိုယ်တိုင် အတည်ပြုချင်ရင် managed publishing ကို ရွေးနိုင်ပါတယ်။

အဆင့် ၈: ထုတ်ဝေပြီးနောက်

• Android vitals ကို ကြည့်ပါ၊ crash နဲ့ "app not responding" အစီရင်ခံစာများအတွက်။
• Review များကို ပြန်ဖြေပါ၊ အစောပိုင်းမှာ အထူးသဖြင့်။
• Target API level ကို လက်ရှိအောင် ထားပါ။ Google က နှစ်စဉ် မြှင့်ပြီး နောက်ကျကျန်ရစ်သော အက်ပ်တွေက စမတ်ဖုန်းအသစ်တွေ သုံးသူသစ်တွေ ဆီ ပို့မပေးတော့ပါ။
• Data safety ပုံစံကို ဒေတာစုဆောင်းမှု အသစ် ထည့်တိုင်း update လုပ်ပါ။

Web-wrapped အက်ပ် တစ်ခု၊ ဥပမာ Mythex နဲ့ တည်ဆောက်ထားတာ၊ အတွက် ပြောင်းလဲမှု အများစုက သင် web app ကို ထုတ်ဝေတဲ့အခါ Android သုံးစွဲသူတွေ ရောက်ပါတယ်၊ ဘာလို့လဲဆိုတော့ ဖုန်းအက်ပ်က သင့် published အက်ပ်ကို ဖွင့်တာပါ။ အိုင်ကွန်၊ အမည်၊ ခွင့်ပြုချက် သို့မဟုတ် target level အသစ်လို အရာတွေအတွက်သာ store release အသစ် လိုအပ်ပါတယ်။

ငြင်းပယ်ခံရခြင်း သို့မဟုတ် နှောင့်နှေးခြင်း၏ အဖြစ်များသော အကြောင်းများ

• Reviewer အတွက် အလုပ်လုပ်သော login မရှိခြင်း။
• Privacy policy မရှိခြင်း၊ PDF ဖြစ်နေခြင်း၊ သို့မဟုတ် Data safety အဖြေများနဲ့ မကိုက်ညီခြင်း။
• အက်ပ်မှာ မရှိသော feature များကို ကတိပြုထားသော screenshot သို့မဟုတ် ဖော်ပြချက်များ။
• အက်ပ်က သိသိသာသာ မလိုအပ်သော အထိခိုက်မခံနိုင်သော ခွင့်ပြုချက်များ တောင်းခြင်း။
• ပျက်ပြယ်သော သို့မဟုတ် ဗလာ အက်ပ်: placeholder စာသားများ၊ အလုပ်မလုပ်သော ခလုတ်များ။

iPhone မှာလည်း ထုတ်ဝေမှာလား?

Apple ရဲ့ လုပ်ငန်းစဉ်က ကွဲပြားပါတယ်: နှစ်စဉ် အဖွဲ့ဝင်ခ၊ TestFlight၊ release တိုင်းကို လူတစ်ဦး စစ်ဆေးခြင်း။ ထိုအဆင့်များအတွက် App Store မှာ အက်ပ်ထုတ်ဝေနည်း ကို ဖတ်ပါ။

မေးခွန်းများ