Как отправить звонилку в Google Play в 2026 году и не сойти с ума

В июле 2026 года мы отправили Android-сборку ID Caller — нашего приложения для приватных аудио- и видеозвонков без номера телефона — на ревью в production-трек Google Play. AAB подписан, листинг готов, во внутреннем треке уже лежал рабочий релиз, а кнопка отправки всё равно не нажималась. Держали две анкеты: декларация активных служб и Data safety. Обе живут только в Play Console: Play Developer API, через который мы ведём листинги, контакты, треки и заливку AAB, их не отдаёт.

Это гайд, которого нам не хватало в тот день. Скриншотов нет: консоль часто меняется, поэтому мы описываем, чего хочет каждая форма, а названия кнопок приводим по русскому интерфейсу — в нём мы и работали. Там, где консоль нас подловила, стоит предупреждение.

Что блокирует отправку

Для звонилки эти анкеты раздела App content должны быть заполнены, прежде чем Play примет релиз на ревью:

• ✦Data safety.
• ✦Декларация активных служб — к ней нужна ссылка на демо-видео.
• ✦Декларация полноэкранных intent'ов.
• ✦Категория приложения.
• ✦Контактный email.

Последние три занимают минуты; шаги ниже — в основном про первые две. Порядок такой: манифест, потом видео, потом письменные ответы для Data safety и только затем анкеты.

Шаг 1: выпишите, что заявляет манифест

На Android 14+ декларация активных служб строится по разрешениям FOREGROUND_SERVICE_* из манифеста, так что начинаем с него. Во время звонка ID Caller держит foreground-сервис, пока приложение в фоне: microphone — для звука, camera — для видео, phoneCall — потому что входящие идут через self-managed ConnectionService из Telecom.

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

<!-- Входящие через Telecom (self-managed) + FCM, full-screen UI с локскрина,
     FGS активного звонка -->
<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" />

<!-- ... -->

<!-- FGS активного звонка: microphone + camera (видео) + phoneCall (Telecom) -->
<service
  android:name=".call.CallForegroundService"
  android:exported="false"
  android:foregroundServiceType="phoneCall|microphone|camera" />

Три типизированных разрешения — три пункта, которые придётся обосновать в декларации; у USE_FULL_SCREEN_INTENT своя декларация (шаг 5). Запишите список: заодно это чек-лист для видео.

Рантайм-половина тех же типов

Три типа в манифесте не означают, что сервис всегда может стартовать со всеми тремя. Android 14+ проверяет runtime-разрешение за каждым типом, поэтому маску типов мы собираем из того, что пользователь действительно выдал:

// Android 14+ проверяет runtime-права под заявленные типы:
// microphone без RECORD_AUDIO и camera без CAMERA — SecurityException.
// phoneCall (MANAGE_OWN_CALLS — normal-право) допустим всегда.
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
}

Ревью этого не поймало. Поймали отчёты о сбоях в Play уже после релиза: 8 крашей у 3 пользователей ровно с этим SecurityException.

Шаг 2: сначала демо-видео, потом декларация

Декларация выглядит лёгкой: несколько чекбоксов и описаний. Подвох в том, что Google требует ссылку на видео по каждому разрешению активной службы. Поэтому видео — первым делом.

1. 01Возьмите тестовое устройство, на котором работает запись экрана через adb (adb shell screenrecord), и проверьте, что полученный файл действительно проигрывается.
2. 02Постройте сценарий так, чтобы видео показывало службы за работой в фоне. Наш: входящий видеозвонок → приём → Home (приложение уходит в фон, звонок жив) → шторка с нотификацией «ID Caller · Идёт звонок» → возврат в приложение → завершение.
3. 03Держите ролик коротким. Наш длится 50 секунд.
4. 04Выложите видео по ссылке, которую сможет открыть ревьюер.
5. 05В декларации отметьте разрешения камеры, микрофона и телефонного звонка и опишите применение: трансляция камеры и аудио, пока приложение в фоне, плюс VoIP-звонки.
6. 06Вставьте одну и ту же ссылку для каждого разрешения. Один ролик со всем сценарием звонка закрывает все три.
7. 07Сохраните форму.

Шаг 3: запишите ответы Data safety до того, как откроете форму

Именно эта анкета заблокировала нас наглухо. В ней стояло «приложение не собирает данные», и форма приняла это без возражений. Проблема всплыла только на предварительной проверке Google перед ревью: она выдала «Недействительная декларация о безопасности данных» и заблокировала кнопку отправки. На деле у приложения есть identity-ID, push-токен и аналитика AppMetrica.

Мы не знаем, на какой сигнал опирается проверка, и это неважно: декларация была неверной. Если у вашей звонилки есть push-токен или SDK аналитики, «данные не собираются» — неправда.

Исправление — заполнять форму по документу, а не по памяти. Ответы лежат в репозитории (docs/store/google-data-safety.md) и выведены из политики конфиденциальности и того, что реально хранит сервер. Для ID Caller это:

• ✦Собирает данные пользователей: да. Передаёт их: нет.
• ✦Шифрование при передаче: да. REST и WebSocket — только по TLS, медиа — по DTLS-SRTP.
• ✦Удаление по запросу: да. Удаление ID в приложении (Настройки → Аккаунт → Удалить ID) стирает на сервере identity, связи и push-токены; неактивный ID удаляется через 12 месяцев.
• ✦User IDs: 12-значный ID Caller ID и его публичный ключ Ed25519 — для работы приложения.
• ✦Device or other IDs: push-токен (FCM или RuStore), который доставляет входящие, — для работы приложения; внутренний device id AppMetrica без рекламных ID — для аналитики.
• ✦App interactions: сессии и события использования из AppMetrica — для аналитики.

Все типы отмечены как обязательные и не временные. Список того, что не собирается, важен не меньше, и у каждого пункта есть причина: ни имени, ни email, ни телефона (аккаунтов нет), ни контактов (адресная книга не читается), ни аудио (звонки не записываются), ни фото (QR-сканер работает на устройстве), ни геолокации (IP-адрес используется для установления соединения и не сохраняется).

Шаг 4: заполняйте Data safety строго вперёд

С ответами перед глазами форма занимает минуты — если уважать две её привычки.

1. 01Начните с первого вопроса — собирает ли приложение или передаёт ли оно обязательные типы данных пользователей (в английском интерфейсе — «Does your app collect or share any of the required user data types?») — и ответьте «Да».
2. 02На остальные вводные вопросы (шифрование при передаче, удаление данных) ответьте по шпаргалке.
3. 03Двигайтесь вперёд только кнопкой «Далее». Не прыгайте между шагами по степперу.
4. 04На шагах с типами данных отметьте каждый тип из шпаргалки и для каждого укажите: собирается или передаётся, обязателен или нет, с какими целями.
5. 05Перед сохранением откройте превью и убедитесь, что в нём перечислены ваши типы данных.
6. 06Сохраните и вернитесь к релизу. У нас кнопка отправки разблокировалась, как только декларация совпала с реальностью.

Шаг 5: мелкие анкеты и отправка

1. 01Полноэкранные intent'ы: заявите сценарий «Совершение и приём звонков» с разрешением по умолчанию.
2. 02Категория: «Связь».
3. 03Контакты: email и сайт. В отличие от деклараций, их можно проставить через Play Developer API.
4. 04Сначала залейте AAB во внутренний трек, потом создайте production-релиз. Мы выбрали 177 стран и полное внедрение.
5. 05Включите управляемую публикацию, если хотите сами выбирать момент выхода. После одобрения Google релиз ждёт на странице «Обзор публикации», пока кто-нибудь не нажмёт «Опубликовать»; автоматически ничего не выходит.
6. 06Отправьте релиз на ревью.

Когда анкеты стали говорить правду, следующий релиз прошёл спокойно: версия 1.1 прошла предварительную проверку Play без проблем. Остались только неблокирующие предупреждения: нет R8-mapping и нативных отладочных символов.

Чек-лист

• ✦Прежде чем открывать консоль, выпишите все разрешения FOREGROUND_SERVICE_* из манифеста.
• ✦Запишите одно демо-видео, где звонок живёт в фоне (запись экрана сначала проверьте на устройстве), и держите ссылку наготове до того, как откроете декларацию.
• ✦Храните ответы Data safety в репозитории и выводите их из политики конфиденциальности и реального перечня данных. Push-токены и аналитика — это собираемые данные.
• ✦Никогда не считайте «Данные не собираются» безопасным вариантом по умолчанию: Play проверяет это до ревью.
• ✦В форме Data safety двигайтесь только вперёд кнопкой «Далее» и проверяйте превью перед сохранением. «Назад» сбрасывает несохранённое, а «Нет» на первый вопрос пропускает типы данных.
• ✦Анкеты App content заполняются только в консоли: API за вас этого не сделает.
• ✦Включите управляемую публикацию, если хотите сами решать, когда одобренный релиз выйдет в стор.
• ✦Каждый новый SDK — аналитика, крэш-репортинг — означает новый проход по Data safety.