Guide til udgivelse af apps og spil fra bunden i Google Play Butik: Pakning, formularer, lukket test og live-lancering

Guide til udgivelse og ansøgning i Google Play Butik (Fra bunden til lancering)

Denne guide forklarer trin for trin processerne ved at oprette en moderne Android-applikation (især .NET MAUI-, MonoGame- eller hybride C#-projekter) fra bunden på Google Play Console, pakke den, signere den, løse kritiske fejl og fuldføre alle trin i butiksansøgningen (oprettelse af app, privatlivspolitik, login-tilladelser, annoncer, IARC-aldersmærkning, datasikkerhed, lukket test og offentlig lancering).

---

Indhold

1. Introduktion og arkitektonisk forberedelse
2. Oprettelse af en ny app/et nyt spil fra bunden i Play Console (Create App)
   • A. Appoplysninger (App Details)
   • B. Apptype, prissætning og erklæringer
3. Keystore-oprettelse og automatisering af build/signering
4. Play Console første bundle-installation og kritiske fejl
   • Fejl 1: Krav om Target API Level 36 (Android 16)
   • Fejl 2: Advarsel om væsentligt højere versionskode
5. Udarbejdelse af privatlivspolitik (Privacy Policy)
6. Appadgang / loginoplysninger (App Access / Sign-in Details)
7. Annonceerklæring (Ads Declaration)
8. Indholdsklassificering (IARC-spørgeskema om indholdsklassificering)
9. Valg af målgruppe og aldersgruppe (Target Audience)
10. Dashboard for appindhold (App Content Dashboard)
11. Formular om datasikkerhed (Data Safety Form)
12. Juridiske og lovgivningsmæssige erklæringer (Offentlige, finansielle og sundhedsapps)
13. Butiksindstillinger og kontaktoplysninger (Store Settings)
14. Hovedbutiksfortegnelse og visuelle aktiver (Main Store Listing)
15. Opsætning og gennemgang af lukket test (Closed Testing)
16. Erklæring om annoncerings-id (Advertising ID)
17. Indsendelse til gennemgang (Endelig indsendelse)
18. Ansøgning om produktionstilladelse efter lukket test (Apply for Access to Production)
19. Den endelige sejr: Godkendelse af produktionsadgang (Production Access)
20. Tjekliste før udgivelse (Fuldført)
21. Arar Games og vores spil

---

1. Introduktion og arkitektonisk forberedelse

Ved udgivelse af en ny applikation i Google Play Butik skal Googles aktuelle sikkerhedsmæssige og tekniske retningslinjer følges nøje:

• Bundle-format: Kun .aab (Android App Bundle)-formatet accepteres. APK-filer er ikke gyldige til officiel butiksudgivelse (men kan stadig genereres til lokal sideloading-test).
• Minimum Target SDK: Google Play kræver nu, at nyudgivne eller opdaterede apps som minimum har Android API Level 36 (Android 16) som mål.
• Sikker signering: Appen skal signeres med en 2048-bit RSA-nøgle, der er kompatibel med v2/v3-skemaet.

---

2. Oprettelse af en ny app/et nyt spil fra bunden i Play Console (Create App)

Efter login på Google Play Console-panelet (play.google.com/console) påbegyndes udgivelsesprocessen ved at klikke på den blå knap "Opret app" (Create app) øverst til højre på hovedskærmen, hvor alle applikationer er listet. Denne formular fastlægger appens digitale id på konsollen, dens pakkenavn og grundlæggende butiksklassifikation.

A. Appoplysninger

1. Appnavn (App Name):
   • Det officielle navn, der vil blive vist for brugerne i butikken.
   • Begrænset til højst 30 tegn (f.eks.: YourAppName).
   • Anbefaling: Undgå unødvendig ophobning af søgeord (keyword stuffing) eller vildledende/promoverende ord ("Best", "Free", "#1"); ellers kan appen blive afvist under Google Play-gennemgangen.
2. Pakkenavn (Package Name):
   • Java/Android-pakkeidentifikator, der unikt identificerer din applikation globalt i Android-økosystemet (omvendt domænekonvention, f.eks. com.yourcompany.appname).
   • Højst 150 tegn.
   • ⚠️ Kritisk regel: Efter applikationen er oprettet på denne skærm, og den første bundle er uploadet, kan pakkenavnet aldrig ændres igen! Det skal stemme 100 % overens med ApplicationId (<ApplicationId>com.yourcompany.appname</ApplicationId>) i AndroidManifest.xml eller .csproj-filen.
   • Tjek tilgængelighed (Check availability): Ved at trykke på knappen undersøges det øjeblikkeligt, om det angivne pakkenavn allerede er registreret af en anden udvikler i Google Play-økosystemet.
3. Standardsprog (Default Language):
   • Det primære butiksnoteringssprog for appen (f.eks.: English (United States) – en-US eller Dansk – da-DK).
   • Butiksinformation vil blive præsenteret på dette standardsprog for brugere i alle lande, hvor der ikke er defineret en specifik oversættelse.

---

B. Apptype, prissætning og erklæringer

1. App eller spil (App or Game):
   • Produktets grundlæggende type fastlægges (App eller Game).
   • Vigtig bemærkning: Dette valg bestemmer appens primære fane i butikken (fanen Apps eller Spil) og kan ikke ændres senere.
2. Gratis eller betalt (Free or Paid):
   • Vælg, om applikationen skal være tilgængelig i butikken gratis eller som et betalt køb.
   • ⚠️ Kritisk irreversibel regel: I henhold til Google Play-politikker kan en app, der én gang er udgivet som "Gratis", aldrig gøres "Betalt" i fremtiden! Hvis du vil sælge dit produkt direkte i butikken, skal du vælge Betalt fra starten. For at udgive gratis og tjene penge bør In-App Purchase (køb i appen) eller AdMob-annoncer foretrækkes.
3. Automatisk beskyttelse (Automatic Protection):
   • Google Play tilføjer automatisk installationskontrol (installer check) til din apps APK/AAB-kode. Hvis brugere sideloads din app fra uautoriserede kilder uden for Google Play, vil de blive advaret om at downloade den originale version fra Google Play.
4. Erklæringer (Juridiske erklæringer og politikker):
   • Politikker for udviklerprogrammet (Developer Program Policies): Det bekræftes, at applikationen fuldt ud overholder Google Plays udvikler- og indholdspolitikker.
   • USA's eksportlovgivning (US Export Laws): Softwaren bekræftes at overholde amerikansk eksportlovgivning og embargoregler.
5. Opret app (Create App):
   • Når formularen er godkendt, klikkes på den blå knap "Opret app" (Create app) nederst til højre. Konsollen registrerer appen i systemet og overfører udvikleren til appens hovedkontrolpanel (Dashboard).

---

3. Keystore-oprettelse og automatisering af build/signering

For at gøre udrulningsprocessen fejlfri og gentagelig bør der oprettes en Deploy/-mappe og automatiseringsscripts i projektroden.

A. Keystore-generering (1_CreateKeystore.bat)

Ved hjælp af keytool i JDK genereres en nøgle, der er gyldig i 25 år (10.000 dage):

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"

Tip: Brug af parentesbestemte if (...)-blokke ved indlæsning af adgangskoden fra brugeren med set /p i Windows-batchfiler kan forårsage syntaksfejl (: was unexpected at this time). Styring af flowet med goto-mærker og indkapsling af adgangskodeparametre i anførselstegn "%PASS%" sikrer stabilitet.

B. Automatisk versionsstyring og signeret AAB-build (2_BuildAndSign_AAB.bat)

Google Play forventer en strengt stigende versionCode ved hver opdatering. For at administrere dette automatisk bruges en formel baseret på dato og klokkeslæt:

# Årets sidste ciffer + måned + dag + time + minut (F.eks.: 2026-10-06 02:42 -> 610060242)
$vc = (Get-Date).ToString('yy').Substring(1) + (Get-Date).ToString('MMddHHmm')

Kompilerings- og signeringskommandoer:

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%

Når processen er afsluttet, åbnes mappen med den kompilerede fil direkte i Windows Stifinder med kommandoen start "" "%OUTPUT%".

---

4. Play Console første bundle-installation og kritiske fejl

Når den signerede .aab-fil uploades til kanalen Intern test (Internal testing) eller Produktion (Production) i Google Play Console, kan følgende skærmbillede blive vist:

Fejl 1: Krav om Target API Level 36 (Android 16)

Fejlmeddelelse:
"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." (Din app er i øjeblikket målrettet API-niveau 35 og skal som minimum være målrettet API-niveau 36 for at sikre, at den er bygget på de nyeste API'er, der er optimeret til sikkerhed og ydeevne.)

Løsning:

Dette er en blokerende fejl og kan ikke udgives, før den er løst.

1. Definer eksplicit <uses-sdk>-tagget i filen 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>

2. Tilføj det til <PropertyGroup> i projektets .csproj-fil:

   <AndroidTargetSdkVersion>36</AndroidTargetSdkVersion>

Fejl 2: Advarsel om væsentligt højere versionskode

Advarselsmeddelelse:
"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" (Denne udgivelses versionskode er væsentligt højere end din tidligere versionskode. Over tid vil dette resultere i, at din app når den maksimale grænse for versionskoder... Få flere oplysninger)

Løsning:

• Google Play viser denne advarsel, når projektets tidligere versionskode var et lille tal (f.eks. 1 eller 8), og du skifter til dynamisk datoformat (f.eks. over 600 millioner).
• Dette er ikke en blokerende fejl. Den kan omgås ved at klikke på det blå link Proceed anyway (Fortsæt alligevel) lige under advarslen.
• Da dette tal vil blive brugt som grundlag for efterfølgende uploads, vil advarslen om det store spring ikke blive vist igen.

---

5. Udarbejdelse af privatlivspolitik (Privacy Policy)

I henhold til Google Play-politikker kræves der et link til en privatlivspolitik i et offentligt tilgængeligt, standard websideformat (ikke PDF) med aktiv SSL (HTTPS), selvom din app ikke indsamler følsomme data.

Gratis hosting på GitHub

En markdown-fil (blob/main/...) i et GitHub-lager anerkendes direkte af Google som en gyldig webside.

Grundlæggende punkter, der bør inkluderes i politikken

1. Annoncer (Google AdMob): Banner-, mellemliggende og belønnede annoncer; brug af Android-annoncerings-id (AD_ID), tekniske enhedsdata og omtrentlig IP-placering.
2. Køb og abonnementer i appen (Google Play Billing): Betalinger foretages udelukkende inden for Googles infrastruktur, og udvikleren får aldrig adgang til kort- eller faktureringsoplysninger.
3. Analyse og telemetri (Firebase Analytics & Crashlytics): Anonyme brugshændelser og nedbrudsrapporter.
4. Samtykkestyring (Google UMP): GDPR-kompatible bekræftelsesvinduer og brugerens ret til at ændre præferencer via indstillingerne.
5. Juridiske ansvarsfraskrivelser og særlige erklæringer (f.eks. væddemål/forudsigelsesværktøjer):
   • Applikationen er absolut ikke en platform for væddemål eller hasardspil.
   • Den tilbyder udelukkende matematisk kuponoptimering og statistisk support.
   • Ved omdirigering til officielle udbydere gemmes brugernavne og adgangskoder til officielle sider aldrig, og 2FA/SMS-verifikationer foretages direkte på den officielle institutions grænseflade.
6. Sikkerhedsbemærkning: Tekniske links såsom udviklerens personlige GitHub-profil bør ikke inkluderes i privatlivspolitikken; kun virksomhedens support-e-mail og officielle hjemmeside bør fremgå.

---

6. Appadgang / loginoplysninger (App Access / Sign-in Details)

Før Googles kontrollører kan gennemgå appen, skal du angive, om appen indeholder et begrænset område:

• Valg: No (Ingen dele af applikationen er begrænset).
• Forklaring: Hvis der ikke er medlemskab, brugerlogin, e-mail/adgangskode eller en låst skærm i appen, skal No vælges. Hvis 'Yes' vælges, vil Google bede om testbrugernavn og adgangskode.

---

7. Annonceerklæring (Ads Declaration)

Dette er trinnet, hvor du erklærer, om der vises annoncer i din app:

• Valg: Yes, my app contains ads (Ja, min app indeholder annoncer).
• Forklaring: Hvis applikationen indeholder AdMob-biblioteket, eller hvis der vil blive åbnet for annoncer i fremtiden, skal 'Ja' vælges. Dette valg aktiverer mærkatet "Indeholder annoncer" på Google Play-siden og sikrer fuld overensstemmelse med retningslinjerne.

---

8. Indholdsklassificering (IARC-spørgeskema om indholdsklassificering)

For at bestemme aldersgrænsen for applikationen skal du udfylde IARC-undersøgelsen (International Age Rating Coalition).

A. Kategorivalg og e-mailadresse

• Kategori: All Other App Types (Alle andre apptyper) (Alle andre applikationer, der ikke er spil, væddemålsspil eller sociale medier: Værktøjer, hjælpeprogrammer, regnemaskiner).
• E-mail: Kontakt-e-mail indtastes, og IARC-betingelser bekræftes.

B. Spørgeskema (Questionnaire)

Afsnit 1: Vold og brugerkommunikation

• Downloadet app (Vold, seksualitet, groft sprog): No
• Deling af brugerindhold (Lyd, beskeder, mediedeling mellem brugere): No

Afsnit 2: Indhold og produkter med aldersbegrænsning

• Onlineindhold (Musik-/videostreaming eller e-handelskatalog): No
• Markedsføring af produkter med aldersbegrænsning (Tobak, alkohol, gambling): No (Absolut Nej, da applikationen ikke tillader væddemål)
• Diverse (Præcis deling af GPS-placering): No

Afsnit 3: Digitale produkter og diverse funktioner

• Digitale varer (Salg af digitale produkter): No (Nej, hvis aktiv butiksfakturering ikke er tilsluttet; hvis aktiv, vælg Ja og få mærket Digitale køb)
• Kontante belønninger (Kontant belønning, gavekort): No
• Webbrowser (Internetbrowser / søgemaskine): No
• Nyheder / uddannelse (Nyheds- eller uddannelsesprodukt): No

Når alle disse spørgsmål besvares med 'Nej', modtager applikationen den aldersklassificering, der passer til det bredeste publikum i verden (PEGI 3, ESRB Everyone).

---

9. Valg af målgruppe og aldersgruppe (Target Audience)

Ved fastlæggelse af din applikations målgruppe er det afgørende nøjagtigt at erklære, om den er beregnet til børn eller ej i forhold til Googles regler for Designed for Families (Familiepolitik) og COPPA.

Rigtigt valg: Kun 18 and over (18 år og derover)

• Hvorfor kun 18+?
  1. Lovoverholdelse: Sportsstatistikker, odds og kuponanalyseværktøjer er rettet mod et voksent publikum, da de er baseret på sportsvæddemålsbulletiner.
  2. Beskyttelse mod restriktioner i familiepolitikken: Hvis under 13 eller 13-17 vælges, kræver Google, at appens annonce-SDK'er er certificeret børnevenlige, begrænser telemetri og indleder en langt mere omfattende undersøgelsesproces.
  3. Overensstemmelse med privatlivspolitikken: Det er 100 % i overensstemmelse med punktet "Appen er beregnet til målgrupper på 18 år og ældre" i vores privatlivspolitik.
• Andet trin (Kan din app utilsigtet appellere til børn?):
  • Dette spørgsmål skal besvares med No (Nej). Da der ikke er tegneseriefigurer, legetøjstemaer eller børneanimationer i brugerfladen, er det ikke et produkt, der utilsigtet vil tiltrække børns opmærksomhed.

---

10. Dashboard for appindhold (App Content Dashboard)

Google Play Console sporer den juridiske og indholdsmæssige parathed af din app med en tjekliste under fanen Politik og programmer -> Appindhold (App content) i menuen til venstre.

Grønne flueben (✓) vises, efterhånden som privatlivspolitik, login-tilladelser, annoncer og indholdsklassificering fuldføres. De resterende sektioner på listen (Datasikkerhed, Statslige myndigheder, Finansielle funktioner, Sundhed) skal udfyldes i rækkefølge.

---

11. Formular om datasikkerhed (Data Safety Form)

Dette er et af de mest strengt kontrollerede områder på Google Play. Du skal angive, hvilke data applikationen og dens biblioteker indsamler eller deler med tredjeparter.

Spørgsmål: Indsamler eller deler din app nogen af de påkrævede brugerdatatyper?

• Valg for første udgivelse: No (Nej).
• Teknisk årsag: Da AdMob SDK eller Firebase SDK endnu ikke er direkte integreret i den først uploadede .aab-pakke, og bruger-id / følsomme data ikke indsamles, udfyldes formularen rent ved at vælge No.
• Bemærkning for fremtiden: Når AdMob- eller Firebase-SDK'er aktiveres og kodes, skal du vende tilbage til denne formular og opdatere punkterne "Omtrentlig placering", "Appens ydeevne" og "Enheds- eller andre id'er (AD_ID)" til Yes.

Efter kontrol af forhåndsvisningen gemmes formularen.

---

12. Juridiske og lovgivningsmæssige erklæringer (Offentlige, finansielle og sundhedsapps)

A. Statslige apps (Government Apps)

• Valg: No (Applikationen repræsenterer ikke en officiel statslig myndighed).

B. Finansielle funktioner (Financial Features)

• Valg: My app doesn't provide any financial features (Min app leverer ingen finansielle funktioner) nederst.
• Bekræftelse: I pop op-vinduet, der åbnes, bekræftes det, at der ikke er behov for at indsende finansielle licenser eller dokumenter:

C. Sundhedsapps (Health Apps)

• Valg: My app does not have any health features (Min app har ingen sundhedsfunktioner) nederst.
• Bekræftelse: I pop op-vinduet bekræfter du, at regional sundhedsdokumentation ikke er påkrævet:

---

13. Butiksindstillinger og kontaktoplysninger (Store Settings)

Kategorien i butikken og de kommunikationskanaler, hvorigennem brugerne kan nå udvikleren, konfigureres:

• Appkategori: Sport eller Værktøjer / Hjælpeprogrammer.
• Tags: Relevante søgeord kan vælges (f.eks.: Sport, Værktøjer).
• Kontaktoplysninger for butiksfortegnelse:
  • E-mailadresse: destek@sirketadi.com (Virksomhedens support-e-mail er obligatorisk).
  • Hjemmeside: https://company.com
• Ekstern markedsføring: Forbliver markeret for at tillade Google at promovere din app på platforme uden for Google Play:

---

14. Hovedbutiksfortegnelse og visuelle aktiver (Main Store Listing)

Butiksfacaden er det vigtigste område, der direkte påvirker brugernes downloadbeslutning:

A. Tekster

• Appnavn: Maksimalt 30 tegn (f.eks.: 15te15 - Spor Toto Assistant).
• Kort beskrivelse: Maksimalt 80 tegn (f.eks.: Formula optimization, probability calculation and smart Spor Toto coupon assistant.).
• Fuld beskrivelse: Detaljeret beskrivelse inklusive funktioner, algoritmiske fordele og juridiske meddelelser.

B. Standarder for visuelle størrelser

• Appikon: Præcis 512 x 512 px, 32-bit PNG, maksimalt 1 MB.
• Fremhævet grafik (Feature Graphic): Præcis 1024 x 500 px, JPG eller 24-bit PNG, maksimalt 15 MB.
• Skærmbilleder til telefon:
  • Minimum 2, maksimalt 8 skærmbilleder.
  • Minimumsstørrelse: 1080 px (f.eks.: 1080 x 2340 px).
  • Billedformat: 16:9 eller 9:16.

C. Erklæring om generativt AI-indhold

• Selvom der anvendes AI-drevne værktøjer til at skabe butiksbilleder, vælges Don't label assets (Mærk ikke aktiver), så længe der ikke produceres fotorealistiske menneske-/offentlige ansigter, der vildleder brugeren.

---

15. Opsætning og gennemgang af lukket test (Closed Testing)

For nyoprettede personlige udviklerkonti i Google Play Console er det obligatorisk at gennemføre processen for Lukket test (Closed Testing), før der kan gås direkte til produktion.

A. Indsendelse af ændringer til gennemgang (Udgivelsesoversigt)

Når alle butiksindstillinger og formularer er udfyldt, lister udgivelsesoversigten ventende ændringer:

For at knappen "Send ændringer til gennemgang" øverst til højre kan aktiveres, skal applikationen dog være konfigureret i mindst én testkanalversion (Closed Testing).

B. Trin i lukket test

Der er 3 obligatoriske trin for at fuldføre lukket test:

1. Vælg lande og områder (Select countries and regions):

• De lande, hvor applikationen skal testes, vælges (som standard kan hele verden eller et specifikt land vælges), og der klikkes på Gem nederst til højre.

2. Vælg testere (Select testers):

• På fanen Testere (Testers) vælges en e-mailliste (Email List), eller der oprettes en ny liste.
• For at opnå produktionstilladelse på personlige Google Play-konti kræver Google, at mindst 20 testbrugere deltager aktivt i testen i 14 dage. Derfor er det vigtigt at have et tilstrækkeligt antal brugere inkluderet på listen.
• Efter valg af listen klikkes på Gem ændringer (Save changes) nederst til højre.

3. Opret en ny udgivelse (Create a new release):

• Når lande og testere er konfigureret, vises "2 of 4 complete" som ovenfor.
• Klik på den blå knap Create new release (Opret ny udgivelse) øverst til højre for at gå videre til versionsoprettelsesfasen.

• Den signerede .aab-pakke uploades. Når installationen er fuldført, analyserer Google pakken:

• Som vist på billedet registreres Target SDK: 36 korrekt, Version: 610060410 og arkitekturer bekræftes.
• Når der klikkes på Next (Næste), vises en advarselsskærm på grund af versionskodespringet:

• Løsning: Klik på det blå link Proceed anyway lige under advarslen "This release's version code is significantly higher than your previous version code".
• Efter at fejlblokeringen er fjernet, gemmes versionen ved at klikke på den blå knap Save (Gem) nederst til højre.

Når disse trin er fuldført, kan du vende tilbage til skærmen Udgivelsesoversigt (Publishing overview) og starte Googles godkendelsesproces med knappen Send changes for review (Send ændringer til gennemgang).

C. Almindelig situation: "App not available" (Appen er ikke tilgængelig) ved testforbindelse

Den mest almindelige skærm, som udviklere ser, når de åbner et tilmeldingslink til lukket test (play.google.com/apps/testing/com...), er denne:

"App not available - A testing version of this app hasn't been published yet or isn't available for this account." (Appen er ikke tilgængelig – En testversion af denne app er endnu ikke blevet udgivet eller er ikke tilgængelig for denne konto.)

Årsager og løsning på denne advarsel:

1. Under gennemgang (In Review): Selvom den lukkede testversion er oprettet og sendt til gennemgang, vil dette link ikke blive aktiveret, før Googles gennemgangsteam godkender pakken. Linket åbnes, når status er "Available to testers" i Play Console.
2. Google-konto uoverensstemmelse: Den Google-konto, der er aktiv i browseren, skal være nøjagtig den samme som den e-mailadresse, der er tilføjet til listen over Testere i Play Console. En anden eller anonym Google-konto kan ikke få adgang til dette link.
3. Serverudbredelsestid: Selvom Google godkender gennemgangen, kan det normalt tage 1-2 timer, før linket til den lukkede test udbreder sig til butiksservere over hele verden.

D. Deltagelse i testprogrammet (Become a Tester - Opt-in)

Når gennemgangen er godkendt, og linket er aktiveret, åbnes den officielle invitationsskærm:

• Siden indeholder applikationens ikon, udviklernavn og invitationstekst til testversionen.
• Når der klikkes på den blå knap Become a tester (Bliv tester), inkluderes kontoen i testen.
• Applikationen kan derefter downloades direkte fra Google Play Butik på Android-enheden ved at klikke på linket "Download it on Google Play" på den næste skærm.

---

16. Erklæring om annoncerings-id (Advertising ID)

For alle apps, der er målrettet Android 13 (API 33) og nyere, kræver Google Play en eksplicit erklæring om brug af annoncerings-id (AD_ID).

Spørgsmål: Bruger din app annoncerings-id?

Googles kritiske regel på denne side er følgende:

"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." (Hvis du angiver, at din app bruger annoncerings-id, blokerer vi udgivelser, der ikke inkluderer tilladelsen com.google.android.gms.permission.AD_ID i manifestfilen, når der er målrettet mod Android 13.)

• Mulighed 1 (Anbefales): No (Nej).
• I den lukkede testpakke, vi i øjeblikket har installeret, er AdMob SDK eller krydskampagnebiblioteker endnu ikke kompileret, og der er ingen AD_ID-tilladelse i AndroidManifest.xml-filen. Derfor vil der ikke være nogen manifestkonflikt, når der vælges No og gemmes.
• Mulighed 2 (Hvis der vælges Ja):

• Hvis der vælges Yes, skal [x] Advertising or marketing (Annoncering eller markedsføring) vælges som det tilsigtede formål, og feltet "Turn off release errors" (Deaktiver udgivelsesfejl) nederst på siden (I understand the ramifications of not including the com.google.android.gms.permission.AD_ID permission...) skal markeres, da tilladelsen endnu ikke er tilføjet til manifestet.

I begge tilfælde klikkes der på Save (Gem) nederst til højre efter foretaget valg.

---

17. Indsendelse til gennemgang (Endelig indsendelse)

Når alle butiksfortegnelser, privatlivspolitik, sikkerhedsformularer, juridiske erklæringer, målgruppe og lukket testversion er fuldført, vender du tilbage til skærmen Udgivelsesoversigt (Publishing overview):

• Submit 14 changes for review (Indsend 14 ændringer til gennemgang): Google Play samler alle erklæringer og testversionen i en enkelt gennemgangspakke (14 ændringer afventer godkendelse som set på billedet).
• Den officielle Google-godkendelsesproces startes ved at klikke på den blå knap Submit 14 changes for review.
• Googles automatiske kvalitetskontrol kører i baggrunden, og derefter placeres applikationen i evalueringskøen hos Google Play Review Team. Gennemgangen afsluttes normalt inden for 24-72 timer på personlige konti.

---

18. Ansøgning om produktionstilladelse efter lukket test (Apply for Access to Production)

Når den lukkede testproces (uafbrudt test i mindst 14 dage med mindst 20 testere), som kræves af Google for personlige udviklerkonti, er fuldført, vil knappen "Ansøg om produktion" (Apply for production) blive aktiveret i Play Consoles hovedkontrolpanel. Ved at klikke på denne knap tilbyder Google en omfattende 3-trins ansøgningsformular for at kontrollere, om applikationen faktisk er blevet testet og er klar til at gå live:

Formulartrin:

1. Om din lukkede test (About your closed test): Du bliver spurgt, hvordan du fandt testbrugere, hvordan du indsamlede feedback, og hvilke forbedringer du foretog i applikationen baseret på den modtagne feedback.
2. Om din app (About your app): Målgruppen for applikationen og de vigtigste fordele, den giver brugerne, forklares.
3. Din produktionsparathed (Your production readiness): Det erklæres, hvordan du vil spore fejl og administrere brugerkommentarer, når appen går live.

Kritiske spørgsmål og eksempler på ansøgningssvar (engelsk og dansk forklaring)

1. "How did you recruit users for your closed testing? For example, did you ask friends and family, or use a paid testing provider?"

(Hvordan rekrutterede du brugere til din lukkede test? F.eks. spurgte du venner og familie, eller brugte du en betalt testudbyder?)

Vigtig regel: Google bryder sig ikke om bots eller betalte kunstige testfarme. Det er sikrest at angive, at testerne er rigtige organiske brugere, nære kredse og relevante sociale mediefællesskaber.

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?"

(Hvor let var det at rekruttere testere til din app?)

• Anbefalet valg: Neither difficult or easy (Hverken svært eller let) eller Easy (Let). Denne mulighed indikerer, at processen udføres organisk og afbalanceret, og at der ikke anvendes kunstige botnetværk.

3. "Describe the engagement you received from testers during your closed test"

(Beskriv det engagement, du modtog fra testere under din lukkede test:)
(Googles tip: Angiv, om brugerne bruger alle funktioner, og om brugen stemmer overens med en rigtig brugers adfærd)

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

(Giv en sammenfatning af den feedback, du modtog fra testere. Inkluder, hvordan du indsamlede feedbacken:)

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.

---

Trin 2: Om din app (About your app)

Dette trin spørger om applikationens målgruppe, den merværdi den tilbyder, og det forventede antal downloads for det første år:

1. "Who is the intended audience of your app?"

(Hvem er den tilsigtede målgruppe for din 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"

(Beskriv, hvordan din app giver værdi til brugerne:)

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?"

(Hvor mange downloads forventer du, at din app når i det første år?)

• Anbefalet valg: 0 - 10K (Et organisk og realistisk mål for en indie-udvikler).

---

Trin 3: Din produktionsparathed (Your production readiness)

Dette sidste trin i ansøgningen spørger om forbedringer foretaget baseret på erfaringer fra den lukkede test, og hvordan applikationen anses for klar til live produktion:

1. "What changes did you make to your app based on what you learned during your closed test?"

(Hvilke ændringer foretog du i din app baseret på, hvad du lærte under din lukkede test?)

Anbefaling: Svaret bør være fuldt ud i overensstemmelse med den feedback, du angav i de foregående trin (kompatibilitet med små skærme, skriftstørrelse, filtermærkater og datacache).

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?"

(Hvordan besluttede du, at din app er klar til live produktion?)

Anbefaling: Google vitals-målinger (nul nedbrud, nul ANR), 14-dages testperiode og stabilitet på tværs af forskellige Android-versioner bør fremhæves.

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.

Når alle felter er udfyldt, fuldføres den officielle ansøgning om produktionstilladelse ved at klikke på den blå knap Apply (Ansøg) nederst til højre.

Skærmbillede for indsendt ansøgning (Gennemgangsproces)

Ved at trykke på knappen 'Apply' vender du tilbage til Play Consoles hovedkontrolpanel, og følgende officielle gennemgangskort vises på siden Produktion (Production):

"We have your application for production access" (Vi har modtaget din ansøgning om produktionsadgang)
"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." (Vi gennemgår din ansøgningsformular. Vi sender en e-mail til kontoejeren med en opdatering. Dette tager normalt 7 dage eller mindre, men kan lejlighedsvis tage længere tid.)

Ting at vide om denne fase:

1. Gennemgangstid: Selvom Google officielt angiver på skærmen, at det er "7 dage eller mindre", resulterer denne godkendelse normalt inden for 24 til 72 timer for apps med konsistente formularsvar og en nedbrudsrate på nul.
2. Meddelelse om resultat: Når evalueringen er afsluttet, sendes en officiel acceptmeddelelse til kontohaverens e-mailadresse (se kapitel 19).
3. Hvad skal man gøre i ventetiden: Der er ingen grund til at foretage yderligere handlinger; den lukkede testkanal kan forblive aktiv, det er nok at afvente afgørelsen fra Play Console-gennemgangsteamet.

---

19. Den endelige sejr: Godkendelse af produktionsadgang (Production Access)

Når processen for Lukket test (14 dages aktiv test med mindst 20 testbrugere), som er den mest udfordrende fase i Google Play Console for nye personlige udviklerkonti, er fuldført, og den åbne butiksansøgning er indsendt, modtages følgende officielle godkendelses-e-mail fra Google Play Console-teamet:

"Congratulations! Your app has been granted Google Play production access" (Tillykke! Din app har fået tildelt produktionsadgang til 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." (Du har ansøgt om produktionsadgang til Google Play for din app, og dette er nu blevet bevilget. Produktion er stedet, hvor du gør din app tilgængelig for milliarder af brugere på Google Play.)

Hvad betyder denne e-mail?

1. Offentlig udgivelse: Din app er nu kvalificeret til at blive udgivet til milliarder af Android-brugere over hele verden, ikke kun til inviterede lukkede testere.
2. Overskridelse af personlig kontotærskel: Googles krav om 20 testere / 14 dages test er officielt opfyldt, og udviklerkontoen er flyttet til betroet status.
3. Gå live med ét klik: Ved at gå til kanalen Produktion (Production) i Play Console-panelet kan den gennemtestede pakke fra den lukkede test gå live direkte på butiksfacaden eller med en ny version.

---

20. Tjekliste før udgivelse (Fuldført)

Alle kontrolpunkter i ansøgningsfasen:

• Er app-id og unikt pakkenavn blevet genereret i Play Console?
• Er den signerede .aab-pakke kompileret med targetSdkVersion 36?
• Er versionCode større end tidligere versioner? (Blev der klikket på Proceed anyway ved advarslen?)
• Er URL'en til privatlivspolitikken aktiv og åbnet med HTTPS?
• Er appadgang registreret som No?
• Er annonceerklæringen markeret som Yes?
• Er IARC-aldersklassificering fuldført og certificeret?
• Er målgruppen valgt som 18 and over?
• Er formularen om datasikkerhed (Data Safety) blevet udfyldt?
• Er statslige, finansielle og sundhedsmæssige erklæringer registreret som No?
• Er butiksaktiver (512x512-ikon, 1024x500-funktionsgrafik, skærmbilleder) uploadet?
• Lukket test: Er lande/regioner blevet valgt og gemt?
• Lukket test: Er testerlisten blevet valgt og gemt?
• Lukket test: Er den signerede .aab-pakke uploadet og versioneret?
• Annoncerings-id: Gemt som No for første udgivelse?
• Udgivelsesoversigt: Er ændringerne indsendt til Google-gennemgang?
• Er den lukkede testproces fuldført, og produktionsadgang modtaget?

---

21. Arar Games og vores spil

Du kan besøge vores butikssider for at opleve alle de spil, spilmekanikker og opdateringer, vi har udviklet i vores uafhængige studie:

🎮 Vores spil:

• 🛡️ Blocked: Pixel Panzer:
  Retro pixel tank-action, ColorWheel elementære projektiler, dynamisk vejr, Boss-kampe, globale ranglister og Google Play-præstationer!
  👉 Download på Google Play (Android & PC) | Microsoft Store (Windows PC)
• 🎨 Paint Trek:
  Refleksfokuseret arkadeoplevelse i farverige pixels og rumatmosfære.
  👉 Google Play | Microsoft Store (PC & Xbox)
• 🚀 Space Dodger:
  Hurtig retro-arkade med forhindringsundvigelse i det dybe rum.
  👉 Download på Google Play

📢 Sociale medier og kommunikation:

Følg vores nye tekniske guides, devlogs og spilopdateringer:

• 🎵 TikTok: @arargamesstudio
• 📸 Instagram: @arargamesstudio
• 🐦 X (Twitter): @arargamesstudio
• 📺 YouTube: @koreaaria
• 🧵 Threads: @arargamesstudio
• 📘 Facebook: arargamesstudio

---

Udarbejdet af: Arar Games Developer Documentation Archive