Kako poslati aplikaciju za pozive na Google Play 2026. i ne poludeti

U julu 2026. poslali smo Android verziju aplikacije ID Caller, naše aplikacije za privatne audio i video pozive bez broja telefona, na pregled za production na Google Play-u. AAB je bio potpisan, listing spreman, a interni trek je već imao ispravno izdanje, ali je dugme za slanje i dalje bilo zaključano. Držala su ga dva upitnika: deklaracija foreground servisa i Data safety. Oba postoje samo u Play Console: Play Developer API, preko kojeg vodimo listinge, kontakt podatke, trekove i otpremanje AAB-a, ne daje pristup njima.

Ovo je vodič koji nam je tog dana nedostajao. Snimaka ekrana nema: konzola se često menja, a naša je bila na ruskom, pa opisujemo šta svaka forma traži umesto da citiramo svaku oznaku. Tamo gde nas je konzola uhvatila, stoji upozorenje.

Šta blokira slanje

Za aplikaciju za pozive ovi App content upitnici morali su biti popunjeni pre nego što je Play prihvatio izdanje na pregled:

• ✦Data safety.
• ✦Deklaracija foreground servisa, za koju je potreban link ka demo videu.
• ✦Deklaracija full-screen intent-a.
• ✦Kategorija aplikacije.
• ✦Kontakt email.

Poslednja tri traju po nekoliko minuta; koraci ispod uglavnom se tiču prva dva. Radite ovim redom: manifest, zatim video, zatim pisani odgovori za Data safety, i tek onda forme.

Korak 1: popišite šta manifest deklariše

Na Androidu 14+ deklaracija foreground servisa prati dozvole FOREGROUND_SERVICE_* iz manifesta, pa krenite od njega. Tokom poziva ID Caller drži foreground servis živim dok je aplikacija u pozadini: microphone za zvuk, camera za video i phoneCall jer dolazni pozivi idu kroz self-managed Telecom ConnectionService.

<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.CAMERA" />

<!-- Dolazni pozivi kroz Telecom (self-managed) + FCM, full-screen UI na zaključanom ekranu,
     foreground servis aktivnog poziva -->
<uses-permission android:name="android.permission.MANAGE_OWN_CALLS" />
<uses-permission android:name="android.permission.USE_FULL_SCREEN_INTENT" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MICROPHONE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_CAMERA" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_PHONE_CALL" />

<!-- ... -->

<!-- Foreground servis aktivnog poziva: microphone + camera (video) + phoneCall (Telecom) -->
<service
  android:name=".call.CallForegroundService"
  android:exported="false"
  android:foregroundServiceType="phoneCall|microphone|camera" />

Tri tipizovane dozvole znače tri stavke koje treba obrazložiti u deklaraciji; USE_FULL_SCREEN_INTENT ima sopstvenu deklaraciju (korak 5). Zapišite spisak: to je ujedno i ček-lista za video.

Runtime polovina istih tipova

To što su tri tipa deklarisana u manifestu ne znači da servis uvek može da se pokrene sa sva tri. Android 14+ proverava runtime dozvolu iza svakog tipa, pa masku tipova gradimo od onoga što je korisnik zaista odobrio:

// Android 14+ proverava runtime dozvole za deklarisane tipove:
// microphone bez RECORD_AUDIO i camera bez CAMERA bacaju SecurityException.
// phoneCall (MANAGE_OWN_CALLS je normal dozvola) je uvek dozvoljen.
private fun foregroundServiceTypes(): Int {
    var types = ServiceInfo.FOREGROUND_SERVICE_TYPE_PHONE_CALL
    if (granted(Manifest.permission.RECORD_AUDIO)) {
        types = types or ServiceInfo.FOREGROUND_SERVICE_TYPE_MICROPHONE
    }
    if (granted(Manifest.permission.CAMERA)) {
        types = types or ServiceInfo.FOREGROUND_SERVICE_TYPE_CAMERA
    }
    return types
}

Pregled ovo nije uhvatio. Uhvatili su ga izveštaji o padovima u Play-u, posle izdavanja: 8 padova kod 3 korisnika, tačno sa ovim SecurityException.

Korak 2: prvo demo video, pa deklaracija

Deklaracija izgleda lako: nekoliko polja za označavanje i opisa. Kvaka je u tome što Google traži link ka videu za svaku dozvolu foreground servisa. Zato video ide prvi.

1. 01Izaberite test uređaj koji dozvoljava snimanje ekrana preko adb-a (adb shell screenrecord) i proverite da se dobijeni fajl zaista reprodukuje.
2. 02Napišite scenario tako da video pokazuje servise dok rade svoj posao u pozadini. Naš: dolazni video poziv, prihvatanje, Home (aplikacija odlazi u pozadinu, poziv ostaje živ), spuštanje panela sa obaveštenjem o pozivu u toku, povratak u aplikaciju, prekid.
3. 03Neka bude kratak. Naš traje 50 sekundi.
4. 04Postavite video na URL koji recenzent može da otvori.
5. 05U deklaraciji označite dozvole za kameru, mikrofon i telefonski poziv i opišite upotrebu: prenos kamere i zvuka dok je aplikacija u pozadini, plus VoIP pozivi.
6. 06Nalepite isti link za svaku dozvolu. Jedan video sa celim tokom poziva pokriva sve tri.
7. 07Sačuvajte formu.

Korak 3: zapišite Data safety odgovore pre nego što otvorite formu

Ovo je upitnik koji nas je potpuno blokirao. U njemu je stajalo da aplikacija ne prikuplja podatke, i forma je to prihvatila bez prigovora. Problem je isplivao tek na Google-ovoj prethodnoj proveri pre pregleda, koja je Data safety deklaraciju proglasila nevažećom i zaključala dugme za slanje. U stvarnosti aplikacija ima identity ID, push token i AppMetrica analitiku.

Ne znamo na koji signal se provera oslanja, i to nije važno: deklaracija je bila pogrešna. Ako vaša aplikacija za pozive ima push token ili SDK za analitiku, tvrdnja „ne prikupljaju se podaci” nije tačna.

Rešenje je bilo da formu popunjavamo po dokumentu, a ne po sećanju. Odgovore držimo u repozitorijumu (docs/store/google-data-safety.md), izvedene iz politike privatnosti i iz onoga što server zaista čuva. Za ID Caller to su:

• ✦Prikuplja korisničke podatke: da. Deli ih: ne.
• ✦Šifrovano u prenosu: da. REST i WebSocket idu samo preko TLS-a, mediji preko DTLS-SRTP.
• ✦Brisanje na zahtev: da. Brisanje ID-a u aplikaciji (Settings → Account → Delete ID) briše na serveru identity, njegove veze i push tokene; neaktivan ID se briše posle 12 meseci.
• ✦User IDs: 12-cifreni ID Caller ID i njegov Ed25519 javni ključ, za funkcionalnost aplikacije.
• ✦Device or other IDs: push token (FCM ili RuStore) koji isporučuje dolazne pozive, za funkcionalnost aplikacije; interni AppMetrica device id, bez reklamnih ID-jeva, za analitiku.
• ✦App interactions: sesije i događaji korišćenja iz AppMetrica-e, za analitiku.

Svaki tip je označen kao obavezan i ne-efemeran. Spisak onoga što se ne prikuplja jednako je važan, i za svaku stavku postoji razlog: nema imena, email-a ni broja telefona (nema naloga), nema kontakata (adresar se ne čita), nema zvuka (pozivi se ne snimaju), nema fotografija (QR skener radi na uređaju), nema lokacije (IP adresa se koristi za uspostavljanje veze i ne čuva se).

Korak 4: popunjavajte Data safety strogo unapred

Sa odgovorima na ekranu forma traje nekoliko minuta, pod uslovom da poštujete dve njene navike.

1. 01Počnite od prvog pitanja, „Does your app collect or share any of the required user data types?”, i odgovorite Yes.
2. 02Na ostala uvodna pitanja (šifrovanje u prenosu, brisanje podataka) odgovorite po listi.
3. 03Krećite se napred samo dugmetom Next. Ne skačite između koraka preko steppera.
4. 04Na koracima sa tipovima podataka označite svaki tip sa liste i za svaki podesite da li se prikuplja ili deli, da li je obavezan ili opcioni, i njegove svrhe.
5. 05Pre čuvanja otvorite pretpregled i proverite da su u njemu navedeni vaši tipovi podataka.
6. 06Sačuvajte i vratite se na izdanje. Naše dugme za slanje se otključalo čim je deklaracija odgovarala stvarnosti.

Korak 5: mali upitnici i slanje

1. 01Full-screen intent: deklarišite slučaj upotrebe za pozive (upućivanje i primanje poziva), sa dozvolom odobrenom podrazumevano.
2. 02Kategorija: Communication.
3. 03Kontakt podaci: email i sajt. Za razliku od deklaracija, njih je moguće podesiti preko Play Developer API-ja.
4. 04Prvo otpremite AAB na interni trek, pa napravite production izdanje. Mi smo izabrali 177 zemalja i potpuno uvođenje.
5. 05Uključite upravljano objavljivanje (managed publishing) ako želite sami da birate trenutak izlaska. Kada Google odobri, izdanje čeka na stranici sa pregledom objavljivanja dok ga neko ne objavi; ništa ne izlazi automatski.
6. 06Pošaljite izdanje na pregled.

Kada su upitnici počeli da govore istinu, sledeće izdanje je prošlo mirno: verzija 1.1 prošla je prethodnu proveru Play-a bez problema. Ostala su samo upozorenja koja ne blokiraju: nema R8 mapping fajla ni nativnih simbola za debagovanje.

Ček-lista

• ✦Pre nego što otvorite konzolu, popišite sve FOREGROUND_SERVICE_* dozvole iz manifesta.
• ✦Snimite jedan demo video u kojem poziv preživljava u pozadini (snimanje ekrana prvo proverite na uređaju) i pripremite link pre nego što otvorite deklaraciju.
• ✦Data safety odgovore držite u repozitorijumu, izvedene iz politike privatnosti i stvarnog popisa podataka. Push tokeni i analitika jesu prikupljeni podaci.
• ✦Nikada ne smatrajte „No data collected” bezbednim podrazumevanim izborom: Play to proverava pre pregleda.
• ✦U Data safety formi krećite se samo napred dugmetom Next i proverite pretpregled pre čuvanja. Back odbacuje nesačuvane odgovore, a „No” na prvo pitanje preskače tipove podataka.
• ✦Računajte da se App content upitnici popunjavaju samo u konzoli: API to neće uraditi umesto vas.
• ✦Uključite upravljano objavljivanje ako želite sami da odlučite kada odobreno izdanje izlazi.
• ✦Svaki novi SDK, bilo analitika ili prijava padova, znači novi prolaz kroz Data safety.