25 Ekim 2026 Pazar

Google Play Store-ზე აპლიკაციებისა და თამაშების ნულიდან გამოქვეყნების გზამკვლევი: შეფუთვა, ფორმები, დახურული ტესტირება და გამოქვეყნება




Google Play Store აპლიკაციების გამოქვეყნებისა და განაცხადის გზამკვლევი (ნულიდან გამოქვეყნებამდე)

ეს გზამკვლევი ეტაპობრივად განმარტავს თანამედროვე Android აპლიკაციის (განსაკუთრებით .NET MAUI, MonoGame ან ჰიბრიდული C# პროექტების) ნულიდან შექმნის პროცესს Google Play Console-ში, მის შეფუთვას, ხელმოწერას (signing), კრიტიკული შეცდომების გადაჭრასა და მაღაზიაში განაცხადის წარდგენის ყველა ეტაპის გავლას (აპლიკაციის შექმნა, კონფიდენციალურობის პოლიტიკა, შესვლის ნებართვები, რეკლამები, IARC ასაკობრივი რეიტინგი, მონაცემთა უსაფრთხოება, დახურული ტესტირება და ღია გამოქვეყნება).


სარჩევი

  1. შესავალი და არქიტექტურული მომზადება
  2. Play Console-ში ახალი აპლიკაციის / თამაშის შექმნა ნულიდან (Create App)
  3. Keystore-ის შექმნა და Build/Sign ავტომატიზაცია
  4. Play Console-ში პირველი ნაკრების (Bundle) ატვირთვა და კრიტიკული შეცდომები
  5. კონფიდენციალურობის პოლიტიკის მომზადება (Privacy Policy)
  6. აპლიკაციაზე წვდომა / შესვლის დეტალები (App Access / Sign-in Details)
  7. რეკლამის დეკლარაცია (Ads Declaration)
  8. კონტენტის რეიტინგი (IARC Content Rating Questionnaire)
  9. სამიზნე აუდიტორია და ასაკობრივი ჯგუფის შერჩევა (Target Audience)
  10. აპლიკაციის კონტენტის მართვის პანელი (App Content Dashboard)
  11. მონაცემთა უსაფრთხოების ფორმა (Data Safety Form)
  12. სამართლებრივი და მარეგულირებელი განცხადებები (სამთავრობო, ფინანსური, ჯანმრთელობა)
  13. მაღაზიის პარამეტრები და საკონტაქტო ინფორმაცია (Store Settings)
  14. მაღაზიის მთავარი გვერდი და ვიზუალური აქტივები (Main Store Listing)
  15. დახურული ტესტირების გამართვა და მიმოხილვა (Closed Testing Setup)
  16. სარეკლამო იდენტიფიკატორის დეკლარაცია (Advertising ID Declaration)
  17. საბოლოო წარდგენა განსახილველად (Submission for Review)
  18. განაცხადი წარმოების ნებართვაზე დახურული ტესტირების შემდეგ (Apply for Access to Production)
  19. საბოლოო გამარჯვება: წარმოებაში წვდომის (ღია გამოქვეყნების) დამტკიცება
  20. გამოშვებამდე შესამოწმებელი სია (დასრულებული)
  21. Arar Games და ჩვენი თამაშები

1. შესავალი და არქიტექტურული მომზადება

Google Play Store-ზე ახალი აპლიკაციის გამოქვეყნებისას აუცილებელია Google-ის უახლესი უსაფრთხოებისა და ტექნიკური პოლიტიკის დაცვა:

  • პაკეტის (Bundle) ფორმატი: მიიღება მხოლოდ .aab (Android App Bundle) ფორმატი. APK ფაილები არ არის ვალიდური მაღაზიაში გამოსაშვებად (თუმცა მათი გენერირება შესაძლებელია გვერდითი ჩატვირთვის / sideload ტესტირებისთვის).
  • მინიმალური Target 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" დაჭერით, სადაც ჩამოთვლილია ყველა აპლიკაცია. ეს ფორმა განსაზღვრავს აპლიკაციის ციფრულ ID-ს კონსოლში, მის პაკეტის სახელსა და მაღაზიის ძირითად კლასიფიკაციას.

A. აპლიკაციის დეტალები

Play Console ახალი აპლიკაციის შექმნა - დეტალები

  1. App Name (აპლიკაციის სახელი):
    • ეს არის პირველი ოფიციალური სახელი, რომელიც გამოჩნდება მომხმარებლებისთვის მაღაზიაში.
    • შემოიფარგლება მაქსიმუმ 30 სიმბოლოთი (მაგ.: YourAppName).
    • რეკომენდაცია: მოერიდეთ სათაურში არასაჭირო საკვანძო სიტყვების გადატვირთვას (keyword stuffing) ან შეცდომაში შემყვან/სარეკლამო სიტყვებს ("საუკეთესო", "უფასო", "#1"); წინააღმდეგ შემთხვევაში, მან შესაძლოა მიიღოს უარყოფა Google Play-ის განხილვისას.
  2. Package Name (პაკეტის სახელი):
    • Java/Android პაკეტის იდენტიფიკატორი, რომელიც გლობალურად და უნიკალურად განსაზღვრავს თქვენს აპლიკაციას Android ეკოსისტემაში (უკუ დომენის კონვენცია, მაგ.: com.yourcompany.appname).
    • მაქსიმუმ 150 სიმბოლო.
    • ⚠️ კრიტიკული წესი: მას შემდეგ, რაც ამ ეკრანზე შეიქმნება აპლიკაცია და აიტვირთება პირველი პაკეტი, პაკეტის სახელი ვეღარასოდეს შეიცვლება! პროექტის კოდში Platforms/Android/AndroidManifest.xml და .csproj ფაილებში მითითებული ApplicationId (<ApplicationId>com.yourcompany.appname</ApplicationId>) 100%-ით იდენტური უნდა იყოს კონსოლში მითითებულთან.
    • Check availability (ხელმისაწვდომობის შემოწმება): ღილაკზე დაჭერით მყისიერად მოწმდება, არის თუ არა თქვენ მიერ მითითებული პაკეტის სახელი უკვე დარეგისტრირებული სხვა დეველოპერის მიერ Google Play ეკოსისტემაში.
  3. Default Language (ნაგულისხმევი ენა):
    • აპლიკაციის მაღაზიის პირველადი ენა (მაგ.: English (United States) – en-US).
    • მაღაზიის ინფორმაცია წარმოდგენილი იქნება ამ ნაგულისხმევ ენაზე იმ ქვეყნების მომხმარებლებისთვის, სადაც არ არის განსაზღვრული კონკრეტული ლოკალიზაცია (თარგმანი).

B. აპლიკაციის ტიპი, ფასწარმოქმნა და დეკლარაციები

Play Console ახალი აპლიკაციის შექმნა - დეკლარაციები

  1. App or Game (აპლიკაცია თუ თამაში):
    • განისაზღვრება პროდუქტის ძირითადი ტიპი (App ან Game).
    • კრიტიკული შენიშვნა: ეს არჩევანი განსაზღვრავს მაღაზიის შესაბამის მთავარ კატეგორიას (აპლიკაციების ჩანართი ან თამაშების ჩანართი) და მისი შეცვლა მოგვიანებით შეუძლებელია.
  2. Free or Paid (უფასო თუ ფასიანი):
    • აირჩიეთ, ხელმისაწვდომი იქნება თუ არა აპლიკაცია მაღაზიაში უფასოდ, თუ როგორც ფასიანი შენაძენი.
    • ⚠️ კრიტიკული შეუქცევადი წესი: Google Play-ის პოლიტიკის თანახმად, აპლიკაცია, რომელიც ერთხელ გამოქვეყნდა როგორც "Free", მომავალში ვეღარასოდეს გახდება "Paid"! თუ გსურთ თქვენი პროდუქტის პირდაპირ მაღაზიაში გაყიდვა, თავიდანვე უნდა აირჩიოთ Paid. უფასოდ გამოქვეყნებისა და შემოსავლის მისაღებად უმჯობესია გამოიყენოთ In-App Purchase (აპს-შიდა შესყიდვები) ან AdMob რეკლამები.
  3. Automatic Protection (ავტომატური დაცვა):
    • Google Play თქვენი აპლიკაციის APK/AAB კოდს ამატებს ავტომატურ ინსტალატორის შემოწმებას (installer check). თუ მომხმარებლები თქვენს აპლიკაციას ჩამოტვირთავენ არაავტორიზებული წყაროებიდან Google Play-ის გარეთ, ისინი გაფრთხილებულნი იქნებიან, რომ ჩამოტვირთონ ორიგინალი ვერსია Google Play-დან.
  4. Declarations (სამართლებრივი დეკლარაციები და პოლიტიკა):
    • Developer Program Policies: დასტურდება, რომ აპლიკაცია სრულად შეესაბამება Google Play დეველოპერისა და კონტენტის პოლიტიკას.
    • US Export Laws: პროგრამული უზრუნველყოფა მიჩნეულია აშშ-ის ექსპორტის კანონებთან და ემბარგოს რეგულაციებთან შესაბამისად.
  5. Create App (აპლიკაციის შექმნა):
    • ფორმის დამტკიცების შემდეგ დააჭირეთ ქვედა მარჯვენა კუთხეში არსებულ ლურჯ ღილაკს "Create app". კონსოლი შეიყვანს აპლიკაციას სისტემაში და გადაიყვანს დეველოპერს აპლიკაციის მთავარ მართვის პანელზე (Dashboard).

3. Keystore-ის შექმნა და Build/Sign ავტომატიზაცია

გამოქვეყნების პროცესის უშეცდომო და განმეორებადი განხორციელებისთვის, პროექტის ძირში უნდა შეიქმნას 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-ის batch ფაილებში set /p-ით მომხმარებლისგან პაროლის მიღებისას ფრჩხილებიანი if (...) ბლოკების გამოყენებამ შეიძლება გამოიწვიოს სინტაქსური შეცდომები (: was unexpected at this time). ნაკადის მართვა goto ტეგებით და პაროლის პარამეტრების ბრჭყალებში "%PASS%" ჩასმა უზრუნველყოფს სტაბილურობას.

B. ავტომატური ვერსიონირება და ხელმოწერილი AAB-ის აწყობა (2_BuildAndSign_AAB.bat)

Google Play ყოველი განახლებისას მოითხოვს მკაცრად მზარდ 'versionCode'-ს. ამის ავტომატურად სამართავად გამოიყენება თარიღსა და დროზე დაფუძნებული ფორმულა:

# Yılın son hanesi + Ay + Gün + Saat + Dakika (Örn: 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%

როდესაც პროცესი დასრულდება, დაკომპილირებული ფაილის შემცველი საქაღალდე გაიხსნება პირდაპირ Windows Explorer-ში start "" "%OUTPUT%" ბრძანებით.


4. Play Console-ში პირველი ნაკრების (Bundle) ატვირთვა და კრიტიკული შეცდომები

როდესაც ხელმოწერილი .aab ფაილი აიტვირთება Google Play Console-ის Internal testing ან Production არხში, შეიძლება გამოჩნდეს შემდეგი ეკრანი:

Play Console გამოშვების შეცდომები

შეცდომა 1: Target API Level 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."

გადაწყვეტა:

ეს შეცდომა ბლოკავს გამოშვებას და პროცესი ვერ გაგრძელდება მის მოგვარებამდე.

  1. მკაფიოდ განსაზღვრეთ <uses-sdk> ტეგი Platforms/Android/AndroidManifest.xml ფაილში:
   <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.yourcompany.appname">
       <uses-sdk android:minSdkVersion="24" android:targetSdkVersion="36" />
       ...
   </manifest>
  1. დაამატეთ პროექტის .csproj ფაილში <PropertyGroup> ბლოკში:
   <AndroidTargetSdkVersion>36</AndroidTargetSdkVersion>

შეცდომა 2: ვერსიის კოდის მნიშვნელოვნად მაღალი მნიშვნელობის გაფრთხილება

გაფრთხილების შეტყობინება:
"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"

გადაწყვეტა:

  • Google Play ამ გაფრთხილებას იძლევა მაშინ, როდესაც პროექტის წინა ვერსიის კოდი იყო მცირე რიცხვი (მაგ. 1 ან 8) და თქვენ გადახვალთ დინამიურ თარიღის ფორმატზე (მაგ. 610 მილიონი).
  • ეს არ არის ბლოკირებადი შეცდომა. მისი გვერდის ავლა შესაძლებელია გაფრთხილების ქვემოთ არსებულ ლურჯ ბმულზე Proceed anyway დაჭერით.
  • ვინაიდან ეს რიცხვი გახდება შემდგომი ატვირთვების საფუძველი, დიდი ნახტომის შესახებ გაფრთხილება აღარ გამოჩნდება.

5. კონფიდენციალურობის პოლიტიკის მომზადება (Privacy Policy)

Google Play-ის პოლიტიკის მიხედვით, მაშინაც კი, თუ თქვენი აპლიკაცია არ აგროვებს სენსიტიურ მონაცემებს, სავალდებულოა კონფიდენციალურობის პოლიტიკის ბმულის წარდგენა საჯაროდ ხელმისაწვდომი, სტანდარტული ვებგვერდის (არა PDF) ფორმატში აქტიური SSL-ით.

კონფიდენციალურობის პოლიტიკის URL-ის შეყვანა

უფასო ჰოსტინგი GitHub-ზე

GitHub-ის საცავში განთავსებული markdown ფაილი (blob/main/...) პირდაპირ აღიარებულია Google-ის მიერ როგორც ვალიდური ვებგვერდი.

GitHub საცავის ხედი

პოლიტიკაში შესატანი ძირითადი პუნქტები

  1. რეკლამები (Google AdMob): ბანერული, ინტერსტიციული და დაჯილდოებული რეკლამები; Android სარეკლამო ID-ის (AD_ID), მოწყობილობის ტექნიკური მონაცემებისა და სავარაუდო IP ლოკაციის გამოყენება.
  2. აპს-შიდა შესყიდვები და გამოწერები (Google Play Billing): გადახდები მთლიანად ხორციელდება Google-ის ინფრასტრუქტურის ფარგლებში და დეველოპერს არასოდეს აქვს წვდომა საბანკო ბარათის ან ანგარიშსწორების მონაცემებზე.
  3. ანალიტიკა და ტელემეტრია (Firebase Analytics & Crashlytics): ანონიმური გამოყენების მოვლენები და შეცდომების (crash) ანგარიშები.
  4. თანხმობის მართვა (Google UMP): GDPR და KVKK შესაბამისი დადასტურების ფანჯრები და მომხმარებლის უფლება, შეცვალოს პარამეტრები ნებისმიერ დროს.
  5. სამართლებრივი გამონაკლისები და სპეციალური დეკლარაციები (მაგ. აზარტული თამაშები / პროგნოზირების ხელსაწყოები):
    • აპლიკაცია კატეგორიულად არ წარმოადგენს ფსონების ან აზარტული თამაშების პლატფორმას.
    • ის მხოლოდ გთავაზობთ მათემატიკური კუპონების ოპტიმიზაციას და სტატისტიკურ მხარდაჭერას.
    • ოფიციალურ დილერებთან გადამისამართებისას, ოფიციალური საიტების მომხმარებლის სახელები და პაროლები არასოდეს ინახება, ხოლო 2FA/SMS ვერიფიკაცია ხორციელდება უშუალოდ ოფიციალური დაწესებულების ინტერფეისში.
  6. უსაფრთხოების შენიშვნა: კონფიდენციალურობის პოლიტიკის ტექსტში არ უნდა იყოს მითითებული ისეთი ტექნიკური ბმულები, როგორიცაა დეველოპერის პირადი GitHub პროფილი; მითითებული უნდა იყოს მხოლოდ კორპორატიული ელფოსტა და ოფიციალური ვებგვერდი.

6. აპლიკაციაზე წვდომა / შესვლის დეტალები (App Access / Sign-in Details)

სანამ Google-ის აუდიტორები შეძლებენ აპლიკაციის განხილვას, თქვენ უნდა მიუთითოთ, შეიცავს თუ არა აპლიკაცია შეზღუდულ ზონას:

აპლიკაციაზე წვდომის ეკრანი

  • არჩევანი: No (აპლიკაციის არცერთი ნაწილი არ არის შეზღუდული).
  • განმარტება: თუ აპლიკაციაში არ არის წევრობა, მომხმარებლის ავტორიზაცია, ელფოსტა/პაროლი ან დაბლოკილი ეკრანი, უნდა აირჩიოთ No. თუ აირჩევთ 'Yes'-ს, Google მოგთხოვთ სატესტო მომხმარებლის სახელსა და პაროლს.

7. რეკლამის დეკლარაცია (Ads Declaration)

ეს არის ეტაპი, სადაც აცხადებთ, ჩანს თუ არა რეკლამები თქვენს აპლიკაციაში:

რეკლამის დეკლარაციის ეკრანი

  • არჩევანი: Yes, my app contains ads (დიახ, ჩემი აპლიკაცია შეიცავს რეკლამას).
  • განმარტება: თუ აპლიკაციაში ინტეგრირებულია AdMob ბიბლიოთეკა ან თუ რეკლამების ჩართვა დაგეგმილია მომავალში, უნდა აირჩიოთ 'Yes'. ეს არჩევანი ააქტიურებს "Contains ads" (შეიცავს რეკლამას) იარლიყს Google Play-ის გვერდზე და უზრუნველყოფს პოლიტიკასთან სრულ შესაბამისობას.

8. კონტენტის რეიტინგი (IARC Content Rating Questionnaire)

აპლიკაციის ასაკობრივი ზღვრის დასადგენად, თქვენ უნდა შეავსოთ IARC (International Age Rating Coalition) გამოკითხვა.

A. კატეგორიის შერჩევა და ელფოსტის შეყვანა

კატეგორიის შერჩევა

  • კატეგორია: All Other App Types (ყველა სხვა აპლიკაცია, რომელიც არ არის თამაში, აზარტული თამაში ან სოციალური ქსელი: ხელსაწყოები, კომუნალური აპლიკაციები, კალკულატორები).
  • ელფოსტა: შეიყვანება საკონტაქტო ელფოსტა და დასტურდება IARC-ის პირობები.

B. გამოკითხვის კითხვები (Questionnaire)

თავი 1: ძალადობა და მომხმარებელთა კომუნიკაცია

გამოკითხვა ნაწილი 1

  • ჩამოტვირთული აპლიკაცია (ძალადობა, სექსუალობა, უხამსი ენა): No
  • მომხმარებლის კონტენტის გაზიარება (აუდიო, შეტყობინებები, მედიის გაზიარება მომხმარებლებს შორის): No

თავი 2: კონტენტი და ასაკობრივად შეზღუდული პროდუქტები

გამოკითხვა ნაწილი 2

  • ონლაინ კონტენტი (მუსიკის/ვიდეოს სტრიმინგი ან ელექტრონული კომერციის კატალოგი): No
  • ასაკობრივად შეზღუდული პროდუქტების პოპულარიზაცია (თამბაქო, ალკოჰოლი, აზარტული თამაშები): No (კატეგორიულად No, რადგან აპლიკაცია არ იძლევა ფსონების დადების საშუალებას)
  • სხვადასხვა (ზუსტი GPS მდებარეობის გაზიარება): No

თავი 3: ციფრული პროდუქტები და სხვადასხვა ფუნქციები

გამოკითხვა ნაწილი 3

  • ციფრული საქონელი (ციფრული პროდუქტების გაყიდვა): No (No, თუ მაღაზიის აქტიური ბილინგი არ არის დაკავშირებული; თუ აქტიურია, აირჩიეთ Yes და მიიღეთ Digital Purchases სამკერდე ნიშანი)
  • ფულადი ჯილდოები (ფულადი ჯილდო, სასაჩუქრე ბარათი): No
  • ვებ ბრაუზერი (ინტერნეტ ბრაუზერი / საძიებო სისტემა): No
  • სიახლეები / საგანმანათლებლო (საინფორმაციო ან საგანმანათლებლო პროდუქტი): No

როდესაც ყველა ამ კითხვაზე პასუხია 'No', აპლიკაცია იღებს ასაკობრივ რეიტინგს, რომელიც შესაფერისია მსოფლიოში ყველაზე ფართო აუდიტორიისთვის (PEGI 3, ESRB Everyone).


9. სამიზნე აუდიტორია და ასაკობრივი ჯგუფის შერჩევა

თქვენი აპლიკაციის სამიზნე აუდიტორიის განსაზღვრისას სასიცოცხლოდ მნიშვნელოვანია ზუსტად განაცხადოთ, არის თუ არა ის განკუთვნილი ბავშვებისთვის Google-ის Designed for Families (საოჯახო პოლიტიკა) და COPPA რეგულაციების თვალსაზრისით.

სამიზნე აუდიტორიის ასაკობრივი ჯგუფის არჩევა

სწორი არჩევანი: მხოლოდ 18 and over

  • რატომ მხოლოდ 18+?
    1. სამართლებრივი შესაბამისობა: Spor Toto სტატისტიკა, კოეფიციენტები და კუპონის ანალიზის ხელსაწყოები განკუთვნილია ზრდასრული აუდიტორიისთვის, რადგან ისინი ეფუძნება აზარტული თამაშების ბიულეტენებს.
    2. დაცვა საოჯახო პოლიტიკის შეზღუდვებისგან: თუ არჩეულია 13 წლამდე ან 13-17 წელი, Google მოითხოვს, რომ აპლიკაციის სარეკლამო SDK-ები იყოს სერტიფიცირებული ბავშვებისთვის უსაფრთხოდ, ზღუდავს ტელემეტრიას და იწყებს გაცილებით მკაცრ შემოწმების პროცესს.
    3. შესაბამისობა კონფიდენციალურობის პოლიტიკასთან: ეს 100%-ით ემთხვევა ჩვენს კონფიდენციალურობის პოლიტიკაში არსებულ პუნქტს "აპლიკაცია განკუთვნილია 18 წლის და უფროსი ასაკის აუდიტორიისთვის".
  • მეორე ნაბიჯი (შეიძლება თუ არა თქვენმა აპლიკაციამ უნებლიეთ მიიზიდოს ბავშვები?):
    • ამ კითხვას უნდა გაეცეს პასუხი: No (არა). ვინაიდან აპლიკაციის ინტერფეისში არ არის მულტფილმის პერსონაჟები, სათამაშოების თემები ან საბავშვო ანიმაციები, ის არ წარმოადგენს პროდუქტს, რომელიც შემთხვევით მიიპყრობს ბავშვების ყურადღებას.

10. აპლიკაციის კონტენტის მართვის პანელი

Google Play Console აკონტროლებს თქვენი აპლიკაციის სამართლებრივ და კონტენტის მზადყოფნას ნაბიჯ-ნაბიჯ საკონტროლო სიით მარცხენა მენიუში Policy and programs -> App content ჩანართის ქვეშ.

აპლიკაციის კონტენტის მართვის პანელის საკონტროლო სია
მწვანე მონიშვნის ხატულები (✓) გამოჩნდება კონფიდენციალურობის პოლიტიკის, შესვლის ნებართვების, რეკლამებისა და კონტენტის რეიტინგის დასრულებისთანავე. სიის დარჩენილი სექციები (მონაცემთა უსაფრთხოება, სამთავრობო ორგანოები, ფინანსური ფუნქციები, ჯანმრთელობა) უნდა დასრულდეს თანმიმდევრობით.


11. მონაცემთა უსაფრთხოების ფორმა

ეს არის Google Play-ის ერთ-ერთი ყველაზე მკაცრად კონტროლირებადი სფერო. თქვენ უნდა განაცხადოთ, რა მონაცემებს აგროვებს ან უზიარებს მესამე პირებს აპლიკაცია და მისი ბიბლიოთეკები.

მონაცემთა უსაფრთხოების მიმოხილვა

კითხვა: აგროვებს თუ უზიარებს თქვენი აპლიკაცია მომხმარებლის მოთხოვნილი მონაცემების ტიპებიდან რომელიმეს?

მონაცემთა შეგროვების კითხვა

  • არჩევანი პირველი გამოშვებისთვის: No (არა).
  • ტექნიკური მიზეზი: ვინაიდან AdMob SDK ან Firebase SDK ჯერ არ არის პირდაპირ ინტეგრირებული პირველ ატვირთულ .aab პაკეტში და არ ხდება მომხმარებლის ID-ის / სენსიტიური მონაცემების შეგროვება, ფორმა სუფთად სრულდება No-ს არჩევით.
  • შენიშვნა მომავლისთვის: როდესაც AdMob ან Firebase SDK-ები გააქტიურდება და დაკოდირდება, თქვენ უნდა დაბრუნდეთ ამ ფორმაში და განაახლოთ "სავარაუდო მდებარეობა", "აპლიკაციის წარმადობა" და "მოწყობილობის ან სხვა იდენტიფიკატორები (AD_ID)" პუნქტები Yes სტატუსზე.

მონაცემთა უსაფრთხოების მაღაზიის წინასწარი გადახედვა

წინასწარი გადახედვის შემოწმების შემდეგ ის ინახება.


12. სამართლებრივი და მარეგულირებელი განცხადებები

A. სამთავრობო აპლიკაციები (Government Apps)

სამთავრობო აპლიკაციის დეკლარაცია

  • არჩევანი: No (აპლიკაცია არ წარმოადგენს ოფიციალურ სამთავრობო ორგანოს).

B. ფინანსური ფუნქციები (Financial Features)

ფინანსური ფუნქციები ზედა ნაწილი

ფინანსური ფუნქციები ქვედა ნაწილი

  • არჩევანი: ქვედა ნაწილში My app doesn't provide any financial features.
  • დადასტურება: გახსნილ მოდალურ ფანჯარაში დასტურდება, რომ არ არის საჭირო რაიმე ფინანსური ლიცენზიის ან დოკუმენტის წარდგენა:

ფინანსური დოკუმენტაციის დადასტურება

C. ჯანმრთელობის აპლიკაციები (Health Apps)

ჯანმრთელობის აპლიკაციები ზედა ნაწილი
ჯანმრთელობის აპლიკაციები ქვედა ნაწილი

  • არჩევანი: ქვედა ნაწილში My app does not have any health features.
  • დადასტურება: მოდალურ ფანჯარაში ადასტურებთ, რომ რეგიონალური ჯანდაცვის დოკუმენტაცია არ არის საჭირო:

ჯანმრთელობის დოკუმენტაციის დადასტურება


13. მაღაზიის პარამეტრები და საკონტაქტო ინფორმაცია

კონფიგურირდება კატეგორია მაღაზიაში და საკომუნიკაციო არხები, რომლებითაც მომხმარებლებს შეუძლიათ დაუკავშირდნენ დეველოპერს:

მაღაზიის პარამეტრები და კონტაქტი

  • აპლიკაციის კატეგორია (App Category): Sports ან Utilities / Tools.
  • ტეგები (Tags): შესაძლებელია შესაბამისი საკვანძო სიტყვების შერჩევა (მაგ.: Sports, Utilities).
  • მაღაზიის საკონტაქტო დეტალები (Store Listing Contact Details):
    • ელფოსტის მისამართი: destek@sirketadi.com (კორპორატიული მხარდაჭერის ელფოსტა სავალდებულოა).
    • ვებსაიტი: https://company.com
  • გარე მარკეტინგი (External Marketing): დატოვებულია მონიშნული, რათა Google-ს მიეცეს უფლება გაუწიოს თქვენს აპლიკაციას პოპულარიზაცია Google Play-ის ფარგლებს გარეთ არსებულ პლატფორმებზე:

გარე მარკეტინგის ნებართვა


14. მაღაზიის მთავარი გვერდი და ვიზუალური აქტივები

ვიტრინა არის ყველაზე მნიშვნელოვანი სფერო, რომელიც პირდაპირ გავლენას ახდენს მომხმარებლების მიერ ჩამოტვირთვის გადაწყვეტილებაზე:

A. ტექსტები

  • აპლიკაციის სახელი (App Name): მაქსიმუმ 30 სიმბოლო (მაგ.: 15te15 - Spor Toto Assistant).
  • მოკლე აღწერა (Short Description): მაქსიმუმ 80 სიმბოლო (მაგ.: ფორმულების ოპტიმიზაცია, ალბათობის გამოთვლა და ჭკვიანი Spor Toto კუპონის ასისტენტი.).
  • სრული აღწერა (Full Description): დეტალური აღწერა, მათ შორის ფუნქციები, ალგორითმული უპირატესობები და სამართლებრივი შენიშვნები.

B. ვიზუალური ზომის სტანდარტები

  • აპლიკაციის ხატულა (App Icon): ზუსტად 512 x 512 px, 32-ბიტიანი PNG, მაქსიმუმ 1 მბ.
  • მთავარი გრაფიკა (Feature Graphic): ზუსტად 1024 x 500 px, JPG ან 24-ბიტიანი PNG, მაქსიმუმ 15 მბ.
  • ტელეფონის ეკრანის ანაბეჭდები (Phone Screenshots):
    • მინიმუმ 2, მაქსიმუმ 8 ეკრანის ანაბეჭდი.
    • მინიმალური ზომა: 1080 px (მაგ.: 1080 x 2340 px).
    • ასპექტის თანაფარდობა: 16:9 ან 9:16.

C. გენერაციული ხელოვნური ინტელექტის (AI) კონტენტის დეკლარაცია

AI ვიზუალური დეკლარაცია

  • მაშინაც კი, თუ მაღაზიის სურათების შესაქმნელად გამოყენებულია AI-ზე მომუშავე ხელსაწყოები, ირჩევა Don't label assets, თუ არ არის გენერირებული ფოტორეალისტური ადამიანის/საჯარო სახეები, რომლებიც მომხმარებელს შეცდომაში შეიყვანს.

15. დახურული ტესტირების გამართვა და მიმოხილვა

Google Play Console-ში ახლად შექმნილი პირადი დეველოპერის ანგარიშებისთვის სავალდებულოა დახურული ტესტირების (Closed Testing) პროცესის დასრულება უშუალოდ ღია წარმოებაში გადასვლამდე.

A. ცვლილებების წარდგენა განსახილველად (Publishing Overview)

როდესაც მაღაზიის ყველა პარამეტრი და ფორმა დასრულდება, გამოქვეყნების მიმოხილვაში ჩამოთვლილია მომლოდინე ცვლილებები:

გამოქვეყნების მიმოხილვა

თუმცა, იმისთვის, რომ ზედა მარჯვენა კუთხეში გააქტიურდეს ღილაკი "Send changes for review", აპლიკაცია კონფიგურირებული უნდა იყოს მინიმუმ ერთ სატესტო არხის (Closed Testing) ვერსიაში.

B. დახურული ტესტირების ეტაპები

დახურული ტესტირების დავალებები

დახურული ტესტირების დასასრულებლად საჭიროა 3 სავალდებულო ნაბიჯი:

  1. Select countries and regions (ქვეყნებისა და რეგიონების შერჩევა):

ქვეყნების შერჩევა

  • შეირჩევა ქვეყნები, სადაც აპლიკაცია გამოიცდება (ნაგულისხმევად შესაძლებელია მთელი მსოფლიოს ან თურქეთის/საქართველოს არჩევა) და ინახება ქვედა მარჯვენა ღილაკით Save.
  1. Select testers (ტესტერების შერჩევა):

ტესტერების შერჩევა

  • ჩანართში Testers შეირჩევა ელფოსტის სია (Email List) ან იქმნება ახალი სია.
  • პირად Google Play ანგარიშებზე წარმოების ნებართვის მისაღებად Google მოითხოვს, რომ მინიმუმ 20 სატესტო მომხმარებელი ჩაერთოს ტესტირებაში 14 დღის განმავლობაში. ამიტომ მნიშვნელოვანია ტესტირების სიაში მომხმარებლების საკმარისი რაოდენობის შეყვანა.
  • სიის შერჩევის შემდეგ დააჭირეთ ქვედა მარჯვენა კუთხეში არსებულ ღილაკს Save changes.
  1. Create a new release (ახალი გამოშვების შექმნა):

დახურული ტესტირების მზადყოფნის სტატუსი

  • როდესაც ქვეყნები და ტესტერები დასრულდება, გამოჩნდება "2 of 4 complete", როგორც ზემოთ მოცემულ სურათზეა.
  • დააჭირეთ ზედა მარჯვენა კუთხეში არსებულ ლურჯ ღილაკს Create new release, რათა გადახვიდეთ ვერსიის შექმნის ეტაპზე.

ნაკრების ატვირთვის ეკრანი

  • აიტვირთება ხელმოწერილი .aab პაკეტი. ინსტალაციის დასრულების შემდეგ Google აანალიზებს პაკეტს:

პაკეტი აიტვირთა და API 36 დადასტურდა

  • როგორც სურათზე ჩანს, Target SDK: 36 წარმატებით არის ამოცნობილი, ხოლო Version: 610060410 და არქიტექტურები გადამოწმებულია.
  • Next-ზე დაჭერისას გამოჩნდება გაფრთხილების ეკრანი ვერსიის კოდის ნახტომის გამო:

Proceed Anyway გაფრთხილება

  • გადაწყვეტა: დააჭირეთ ლურჯ ბმულს Proceed anyway გაფრთხილების ქვემოთ: "This release's version code is significantly higher than your previous version code".
  • შეცდომის დადასტურების მოხსნის შემდეგ, ვერსია წარმატებით შეინახება ქვედა მარჯვენა კუთხეში არსებულ ლურჯ ღილაკზე Save დაჭერით.

ამ ნაბიჯების დასრულების შემდეგ შეგიძლიათ დაბრუნდეთ Publishing overview ეკრანზე და დაიწყოთ Google-ის დამტკიცების პროცესი ღილაკით Send changes for review.

C. გავრცელებული სიტუაცია: "App not available" გაფრთხილება სატესტო ბმულზე

ყველაზე გავრცელებული ეკრანი, რომელსაც დეველოპერები ხედავენ დახურული ტესტირების ბმულის (play.google.com/apps/testing/com...) გახსნისას, არის შემდეგი:

App Not Available გაფრთხილება

"App not available - A testing version of this app hasn't been published yet or isn't available for this account."

ამ გაფრთხილების მიზეზები და გადაწყვეტა:

  1. განხილვის პროცესშია (In Review): მაშინაც კი, თუ დახურული ტესტირების ვერსია შეიქმნა და გაიგზავნა განსახილველად, ეს ბმული არ გააქტიურდება მანამ, სანამ Google-ის განხილვის გუნდი არ დაამტკიცებს პაკეტს. ბმული გაიხსნება მაშინ, როდესაც სტატუსი იქნება "Available to testers" Play Console-ში.
  2. Google ანგარიშის შეუსაბამობა: ბრაუზერში აქტიური Google-ის ანგარიში ზუსტად უნდა ემთხვეოდეს Play Console-ში Testers სიაში დამატებულ ელფოსტის მისამართს. განსხვავებული ან ანონიმური Google ანგარიში ვერ შეძლებს ამ ბმულზე წვდომას.
  3. სერვერებზე გავრცელების დრო: მაშინაც კი, თუ Google დაამტკიცებს განხილვას, ჩვეულებრივ შეიძლება დასჭირდეს 1-2 საათი, სანამ დახურული ტესტირების ბმული გავრცელდება მაღაზიის სერვერებზე მთელ მსოფლიოში.

D. ტესტირების პროგრამაში მონაწილეობის მიღება (Become a Tester - Opt-in)

განხილვის დამტკიცებისა და ბმულის გააქტიურების შემდეგ იხსნება შემდეგი ოფიციალური მოწვევის ეკრანი:

Become a Tester ეკრანი

  • გვერდი შეიცავს აპლიკაციის ხატულას, დეველოპერის სახელსა და მოწვევის ტექსტს სატესტო ვერსიაზე.
  • ლურჯ ღილაკზე Become a tester დაჭერისას ანგარიში ჩაერთვება ტესტირებაში.
  • აპლიკაციის ჩამოტვირთვა შესაძლებელია პირდაპირ Google Play Store აპლიკაციიდან Android მოწყობილობაზე შემდეგ ეკრანზე არსებულ ბმულზე "Download it on Google Play" დაჭერით.

16. სარეკლამო იდენტიფიკატორის დეკლარაცია

Android 13 (API 33) და უფრო მაღალი ვერსიებისთვის განკუთვნილი ყველა აპლიკაციისთვის Google Play მოითხოვს სარეკლამო ID-ის (AD_ID) გამოყენების მკაფიო დეკლარაციას.

სარეკლამო ID-ის დეკლარაციის წესები

სარეკლამო ID-ის კითხვაზე პასუხი

კითხვა: Does your app use advertising 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."

  • ვარიანტი 1 (რეკომენდებული): No (არა).
  • ამჟამად დაინსტალირებულ დახურული ტესტირების პაკეტში AdMob SDK ან ჯვარედინი პრომოუშენის ბიბლიოთეკები ჯერ ფაქტობრივად არ არის დაკომპილირებული და AndroidManifest.xml ფაილში არ არის AD_ID ნებართვა. ამიტომ, როდესაც არჩეულია და შენახულია No, მანიფესტის კონფლიქტი არ წარმოიქმნება.
  • ვარიანტი 2 (თუ არჩეულია დიახ):

Advertising ID 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. საბოლოო წარდგენა განსახილველად (Submission for Review)

მას შემდეგ, რაც მაღაზიის ყველა ჩამონათვალი, კონფიდენციალურობის პოლიტიკა, უსაფრთხოების ფორმები, სამართლებრივი დეკლარაციები, სამიზნე აუდიტორია და დახურული ტესტირების ვერსია დასრულდება, თქვენ დაბრუნდებით Publishing overview ეკრანზე:

14 ცვლილების გაგზავნა განსახილველად

  • Submit 14 changes for review: Google Play აგროვებს ყველა განცხადებას და სატესტო ვერსიას ერთ განხილვის პაკეტში (სურათზე ნაჩვენებია 14 ცვლილება, რომლებიც ელოდება დამტკიცებას).
  • ოფიციალური Google-ის დამტკიცების პროცესი იწყება ლურჯ ღილაკზე Submit 14 changes for review დაჭერით.
  • Google-ის ავტომატური ხარისხის შემოწმებები (Quick checks) მუშაობს ფონურ რეჟიმში და შემდეგ აპლიკაცია თავსდება Google Play Review Team-ის შეფასების რიგში. განხილვა ჩვეულებრივ სრულდება 24-72 საათის განმავლობაში პირად ანგარიშებზე.

18. განაცხადი წარმოების ნებართვაზე დახურული ტესტირების შემდეგ (Apply for Access to Production)

როდესაც დასრულდება Google-ის მიერ პირადი დეველოპერის ანგარიშებისთვის მოთხოვნილი დახურული ტესტირების პროცესი (უწყვეტი ტესტირება მინიმუმ 14 დღის განმავლობაში არანაკლებ 20 ტესტერით), Play Console-ის მთავარ პანელში გააქტიურდება ღილაკი "Apply for production". ამ ღილაკზე დაჭერით Google გთავაზობთ ყოვლისმომცველ 3-საფეხურიან სააპლიკაციო ფორმას იმის შესამოწმებლად, რეალურად გამოიცადა თუ არა აპლიკაცია და მზად არის თუ არა ცოცხალი გამოქვეყნებისთვის:

წარმოების ნებართვის განაცხადის ფორმა

ფორმის ეტაპები:

  1. About your closed test: გეკითხებიან, როგორ იპოვეთ სატესტო მომხმარებლები, როგორ შეაგროვეთ უკუკავშირი და რა გაუმჯობესებები შეიტანეთ აპლიკაციაში მიღებული გამოხმაურების საფუძველზე.
  2. About your app: განმარტებულია აპლიკაციის სამიზნე აუდიტორია და ძირითადი სარგებელი, რომელსაც ის აძლევს მომხმარებლებს.
  3. 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?"

როგორ გადაწყვიტეთ, რომ თქვენი აპლიკაცია მზად არის ცოცხალი წარმოებისთვის?

რეკომენდაცია: ხაზი უნდა გაესვას Google-ის ძირითად მეტრიკებს (ნულოვანი კრაში, ნულოვანი 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 დაჭერით.

განაცხადის გაგზავნის ეკრანი (განხილვის პროცესი)

'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."

რა უნდა ვიცოდეთ ამ ეტაპის შესახებ:

  1. განხილვის დრო: მიუხედავად იმისა, რომ Google ეკრანზე ოფიციალურად აცხადებს, რომ ეს არის "7 days or less" (7 დღე ან ნაკლები), თანმიმდევრული ფორმის პასუხებისა და ნულოვანი კრაშის მაჩვენებლის მქონე აპლიკაციებისთვის ეს დამტკიცება ჩვეულებრივ წყდება 24-დან 72 საათამდე ვადაში.
  2. შედეგის შეტყობინება: შეფასების დასრულების შემდეგ ანგარიშის მფლობელის ელფოსტის მისამართზე იგზავნება ოფიციალური მიღების შეტყობინება (იხ. თავი 19).
  3. რა უნდა გავაკეთოთ ლოდინის პროცესში: არ არის საჭირო დამატებითი ქმედებების განხორციელება; დახურული ტესტირების არხი შეიძლება დარჩეს აქტიური, საკმარისია დაელოდოთ Play Console-ის განხილვის გუნდის გადაწყვეტილებას.

19. საბოლოო გამარჯვება: წარმოებაში წვდომის (ღია გამოქვეყნების) დამტკიცება

როდესაც წარმატებით დასრულდება დახურული ტესტირება (14-დღიანი აქტიური ტესტირება მინიმუმ 20 ტესტერით), რაც Google Play Console-ის ყველაზე რთული ეტაპია ახალი პირადი დეველოპერის ანგარიშებისთვის, და წარდგენილია ღია მაღაზიის განაცხადი, Google Play Console-ის გუნდისგან მიიღება შემდეგი ოფიციალური მიღების წერილი:

Google Play Production Access დადასტურების ელფოსტა

"Congratulations! Your app has been granted Google Play production access"
"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."

რას ნიშნავს ეს ელფოსტა?

  1. საჯარო გამოშვება: თქვენი აპლიკაცია ახლა უფლებამოსილია გამოქვეყნდეს მილიარდობით Android მომხმარებლისთვის მთელ მსოფლიოში და არა მხოლოდ მოწვეული დახურული ტესტერებისთვის.
  2. პირადი ანგარიშის ზღვრის გადალახვა: Google-ის 20 ტესტერი / 14-დღიანი ტესტის მოთხოვნა ოფიციალურად დაკმაყოფილდა და დეველოპერის ანგარიში გადავიდა სანდო სტატუსში.
  3. ერთი დაწკაპუნებით გამოქვეყნება: Play Console-ის პანელში Production არხზე გადასვლით, დახურულ ტესტირებაში გამოცდილი პაკეტი შეიძლება პირდაპირ ან ახალი ვერსიით გამოვიდეს მაღაზიის ვიტრინაზე.

20. გამოშვებამდე შესამოწმებელი სია (დასრულებული)

ყველა საკონტროლო პუნქტი განაცხადის ეტაპზე:

  • შექმნილია თუ არა აპლიკაციის ID და უნიკალური პაკეტის სახელი Play Console-ში?
  • არის თუ არა ხელმოწერილი .aab პაკეტი დაკომპილირებული targetSdkVersion 36-ით?
  • არის თუ არა versionCode წინა ვერსიებზე მეტი? (დაეჭირა თუ არა გაფრთხილებაზე Proceed anyway?)
  • არის თუ არა კონფიდენციალურობის პოლიტიკის URL აქტიური და იხსნება თუ არა HTTPS-ით?
  • არის თუ არა აპლიკაციაზე წვდომა ჩაწერილი როგორც No?
  • არის თუ არა რეკლამის დეკლარაცია მონიშნული როგორც Yes?
  • არის თუ არა IARC ასაკობრივი რეიტინგი დასრულებული და სერტიფიცირებული?
  • არის თუ არა სამიზნე აუდიტორია არჩეული როგორც 18 and over?
  • შევსებულია თუ არა მონაცემთა უსაფრთხოების ფორმა?
  • ჩაწერილია თუ არა სამთავრობო, ფინანსური და ჯანდაცვის დეკლარაციები როგორც No?
  • ატვირთულია თუ არა მაღაზიის აქტივები (512x512 ხატულა, 1024x500 მთავარი გრაფიკა, ეკრანის ანაბეჭდები)?
  • დახურული ტესტირება: შერჩეულია და შენახულია ქვეყნები/რეგიონები?
  • დახურული ტესტირება: შერჩეულია და შენახულია ტესტერების სია?
  • დახურული ტესტირება: ატვირთულია და ვერსიონირებულია ხელმოწერილი .aab პაკეტი?
  • სარეკლამო ID: შენახულია როგორც No თავდაპირველი გამოშვებისთვის?
  • გამოქვეყნების მიმოხილვა: გაგზავნილია ცვლილებები Google-ის განსახილველად?
  • მიღებულია თუ არა დახურული ტესტირების პროცესი და წარმოებაში წვდომა (Production Access)?

21. Arar Games და ჩვენი თამაშები

შეგიძლიათ ეწვიოთ ჩვენი მაღაზიის გვერდებს, რათა ცოცხლად გამოსცადოთ ყველა თამაში, თამაშის მექანიკა და განახლებები, რომლებიც შევიმუშავეთ ჩვენს დამოუკიდებელ სტუდიაში:

🎮 ჩვენი თამაშები:

  • 🛡️ Blocked: Pixel Panzer:
    რეტრო პიქსელური ტანკების ბრძოლა, ColorWheel სტიქიური ჭურვები, დინამიური ამინდი, ბოსებთან ბრძოლები, გლობალური ლიდერბორდები და Google Play-ის მიღწევები!
    👉 ჩამოტვირთეთ Google Play-ზე (Android & PC) | Microsoft Store (Windows PC)
  • 🎨 Paint Trek:
    რეფლექსებზე ორიენტირებული არკადული გამოცდილება ფერად პიქსელებსა და კოსმოსურ ატმოსფეროში.
    👉 Google Play | Microsoft Store (PC & Xbox)
  • 🚀 Space Dodger:
    სწრაფი ტემპის რეტრო არკადა დაბრკოლებების არიდებით ღრმა კოსმოსში.
    👉 ჩამოტვირთეთ Google Play-ზე

📢 სოციალური მედია და კომუნიკაცია:

ჩვენი ახალი ტექნიკური გზამკვლევების, დევლოგებისა და თამაშების განახლებების სანახავად:


მომზადებულია: Arar Games Developer Documentation Archive




Hiç yorum yok:

Yorum Gönder